Self Organizing Wireless Sensor Network Middleware CleanPoint

NESTANSCD

University of Virginia

Self Organizing Wireless Sensor Network Middleware

CleanPoint

Self Organizing Wireless Sensor Network Middleware

CleanPoint

University of Virginia PI: John A. Stankovic

December 2004

NESTANSCD


OutlineOutline

•Operational Scenario•Goals•Overview and Status of Middleware•Middleware Services

– Key Services•Power Management/Sentry/Tripwire Service•Group Management Service•3-Tier Classification•Self-healing

– Other Services

•Lessons Learned•Remaining Work FY ‘05

NESTANSCD


1. An unmanned plane (UAV) deploys motes

2. Motes establish an sensor network with power management

3.Sensor network detects

vehicles and wakes up the sensor nodes

Zzz...

Energy Efficient Surveillance SystemEnergy Efficient Surveillance System

Diffusion Routing

Neighbor Discovery

Time Synchronization

Parameterization

Sentry Selection

Coordinate Grid

Data Aggregation

Data Streaming

Group Management

Leader Election

Localization

Network Monitor

Tripwire Service

Reconfiguration

Reliable MAC

Leader Migration

Scheduling

State Synchronization

……

Sentry

NESTANSCD


GoalsGoals

•Develop an operational self-organizing sensor network of size 1000

•Cover an area of 1000m x 100m•Stealthy•Lifetime 3-6 months•Timely detection, track and classification

– Large or small vehicle– Person, person with weapon

•Wakeup other devices when necessary– Extend the lifetime of those devices as well

•Exhibit self-healing capabilities

NESTANSCD


ID Task Name

1 Version 1.0 Development


3 More Component Design

4 Component Test

5 Integration

6 Small-Scale Test

7 Large-Scale Test

8 Version 1.1 Commit

9 Version 1.1 Test

10 Lab Testing

11 Filed Test

12 Field Assessment one

13 Version 1.2 Release


15 Version 1.2 Test

16 Field Assessment Two

17 Version 1.3 Release


19 Vesion 1.3 Test

20 Final Demo

5/28

8/6

10/29

12/6

January February March April May June July August September October November December January

Project Milestones FY04Project Milestones FY04

March 3rd May 28th Aug. 6 Oct.29 Dec 6/13 V1.0 V1.1 V1.2 V1.3 Final

NESTANSCD


Summary: DeliverablesSummary: Deliverables

• ANSCD V1.3 middleware code delivered– About 40,000 lines of code and 600 files– About 30 Middleware services provided– Tested with a network with hundred(s) of nodes

• ANSCD Data Packages V1.3 Delivered –System Architecture designed/documented–Mote-Relay Interface designed/documented–Relay requirements defined/documented–Requirements analysis/documented–Demo Test scenario design/documented –ANSCD & Mission GUI Manual documented –Wireless Download Manual documented

• About 20 related papers published

NESTANSCD


Summary: Objectives Achieved

Summary: Objectives Achieved

Metrics Objective Achieved Metrics Objective Achieved

Coverage (T) 30m by 1000 m (O) 100m by 1000m

Yet to be tested

Sensor Modality Magnet and PIR (T), Acoustic and other (O)

YES

Scale 1000 motes Yet to be tested

Self-Localization Real Coordinates (O) YES

Deployment Manual (T); Airdrop (O)

YES Reconfiguration True(T/O) YES

Ad hoc Routing True(T/O) YES Robustness Backbone True(T/O) YES

False Alarm <5% (T); <1% (O) YES Time Synchronization True(T/O) YES

Detection True (T/O) YES Interface Control Doc True(T/O) YES

Tracking True (T/O) YES Tracking Trace True (T/O) YES

Classification True (T/O) YES Network Topology Report

True(T/O) YES

Accuracy 90%(T); 95%(O) YES Sentry Control True(T/O) YES

Tracking Speed 30 mph (T); 50mph (O)

YES Sentry Health Report True(T/O) YES

Sentry Service True (T/O) YES Source Code True(T/O) YES

Endurance 3 mo (T); 6 mo (O) YES Documents True(T/O) YES

Energy Balance True(T/O) YES Technical Support True(T/O) YES

Stealthness True (T/O) YES Multi-hop Reprogramming

N/A YES

DataDissemination

Relay/RSC (T) SISA(O)

YES Golden Image N/A YES

NESTANSCD


ANSCD Architecture V1.3ANSCD Architecture V1.3

TimeSync

GroupMgmt

SentryService

DynamicConfig

RobustDiffusion Tree

MAC

MICA2 /XSM /XSM2 / MICA2DOT Motes

Application Layer

Middleware Layer

Network Layer

Data Link Layer

EnviroTrack False AlarmFiltering Engine

Display at C&C

AsymmetricDetection

PowerMgmt.

Radio-BaseWakeup

ReportEngine

RelayVelocityRegression

Localization

Classification

TripwireMngt

Frequency-Filter

Sensor Drivers

ContinuousCalibrator

Interference avoidance

Sensing Layer

NESTANSCD


Time-Driven System OperationTime-Driven System Operation

RESET

Phase I

System Initialization

Phase III

Localization

Phase VNetwork Partition & Diffusion

Tree Constrcution

Phase VI

Sentry Selection

Phase VII

Health Report

StartPhase VIII

Power Mgmt

Event Tracking

Phase II

Time SyncPhase IV

Asymmetri Detection

Phase VIII

Event Tracking

Power Mgmt

Dormant Section

Tripwire Section

Wakeup Service

NESTANSCD


Key Software Components (1)


•2-way software interface to RSCC and Avalanche (see ICD)

•Flexible Tripwire based power management with sentry and wakeup services

•Group-Based Entity Tracking (EnviroTrack)•Hierarchical Multi-tier Detection and

Classification via heterogeneous sensors (4 PIRs (motion), acoustic, magnetometers)

•Frequency-Filter and continuous threshold adaptations for robust sensing

NESTANSCD




•Flow control with Aggregate display/health/Tracking message

•Localization (walking GPS)•Radio-based network wakeup •Asymmetry detection for robust routing

establishment •Robust velocity calculation with least

squares estimation•Wakeup service for relay to conserve

energy

NESTANSCD




•Stripped-down version of Vanderbilt clock sync

•Multi-hop Dynamic reconfiguration•Multi-hop wireless download (Berkeley’s

Deluge)•Golden image support•Modified B-MAC to avoid communication-

sensing interference

NESTANSCD


System Scenario Supported (1)


300 Meters ( 3 tripwire section with 100 motes (5 x 20 ) in each section)

50

me

ters

Base0 Base2Base1

802.11g 802.11gLaptop1 Laptop0 Laptop2

Road

Router (optional)

• Flexibility to define various system architectures• Independent deployment with Tripwires

– ANSCD Middleware V1.3– ANSCD GUI

NESTANSCD




•ANSCD Middleware 1.3•Single RSCC •Mission GUI

300 Meters ( 3 tripwire section with 100 motes (5 x 20 ) in each section)

50 meters

Base0

Road

Laptop

RSCC

NESTANSCD




•ANSCD Middleware V1.3 with Tripwires•RSCC•Relay•C2PC•SISA•…

SENSOR RSCC(SENSORNETWORK) MOC/P

Mission GUI

IR/EOCAMERA(s)

SOPHISTICATEDSENSORS (SS)

RFSENSOR

FIELD

RSCC

AdditionalRSCC and Sensor

Networks Long Haul (LH)CommsLink

MOTE-FIELD

MOTEFIELD

SEIWGAntenna

CommsAntenna

TCP/IPPortal

CStat

Mission GUI

C2PCGateway(& Client)

MOC/P

FCD

C2PC Client

LH SocketConverter

RS232Interface MOC

ServerInterface

LH Server

Interface

Socket

Socket

Socket

Ground Station Element

TACTICAL DISPLAY

Long HaulRadio

RELAY

SENSOR RSCC(SENSORNETWORK) MOC/P

Mission GUI

Mission GUI

IR/EOCAMERA(s)

IR/EOCAMERA(s)

SOPHISTICATEDSENSORS (SSU)

RFSENSOR

FIELD

RFSENSOR

FIELD

RSCC

AdditionalRSCC and Sensor

Networks Long Haul (LH)CommsLink

MOTE-FIELD

MOTEFIELD

SEIWGAntenna

CommsAntenna

TCP/IPPortal

CStat

Mission GUI

C2PCGateway(& Client)

MOC/P

FCD

C2PC ClientC2PC Client

LH SocketConverter

RS232Interface

LH SocketConverter

RS232Interface MOC

ServerInterface

LH Server

Interface

Socket

Socket

Socket

Ground Station Element

TACTICAL DISPLAY

Long HaulRadio

RELAY

Hardwired Sensors

Courtesy of Northrop Grumman

NESTANSCD


ANSCD GUI – Vehicle & Person

ANSCD GUI – Vehicle & Person

NESTANSCD


ANSCD GUI – Person w/ WeaponANSCD GUI – Person w/ Weapon

NESTANSCD


Mission GUIMission GUI

NESTANSCD


Mote - Relay Interface V1.5Mote - Relay Interface V1.5

Address AMID

GroupID

ByteCount

Flags RecordType

SourceID

MessageID

Data CRC

Format of notification and command messages

Notification Data Records Command Data Records• Tracking Request• Node status Reset• Network configuration

NodeID

X-Coord

Y-Coord

ParentID

#Sentries

#Nodes

Voltage

CmdID

EventID

EventType

LeaderID

Velocity X-Coord

Y-Coord

Conf.Level

MagnetNumber

MotionNumber

AcousticNumber

Event Type Attribute Type

Confidence Value

Accuracy Periodicity

Tracking recordTracking record

Aggregate status recordAggregate status record

Request recordRequest record

NESTANSCD


Power ManagementPower Management

•Sentry Service•Tripwire•Rotation

1

4

3

2

Sentry

Non-Sentry

Base node

10mA@3v

NESTANSCD


Tripwire-based SurveillanceTripwire-based Surveillance

•Partition sensor network into multiple sections.

•Turn off all the nodes in dormant sections.•Apply sentry-based power management in

tripwire sections•Periodically, sections rotate to balance energy.

Road

Dormant DormantDormant Active ActiveDormant ActiveActive Dormant Dormant

NESTANSCD


Estimation of Network LifetimeEstimation of Network Lifetime

0

10

20

30

40

50

60

70

Time (seconds)

En

erg

y(m

w)

Sentry

NonSentry

Initialization Duration = 5 minutes

Surveillance Duration = 1day

Without system rotation:NonSentry Life Time: 250 daysSentry LifeTime: 7 days

• Lifetime is determined by– Individual Mica 2 mote

consumption • Energy plot for a sentry node • Energy plot for a sleep node

NESTANSCD


Tripwire + SentryTripwire + Sentry

One tripwire section out of every 4 sections with 10% sentry expected 142 days (20x) lifetime.

Power Draw (Tripwire+SBPM vs SBPM)(Based on 10 events per day, 24/7 full Coverage )

0 0.5 1 1.5

Initialization

Sleep

Event Process

Communication

Surveillance

Wakeup

Power Draw(mA@3v)

Tripwire+SBPM

SBPM

NESTANSCD


Lifetime AnalysisLifetime Analysis

Network Life Time

Number of Tripwires (10 regions, 30% sentry, 7 day life)

4 3 2 1

2 AA Batteries

50 days 70 days

105 days

210 days

4 AA Batteries

100 days 140 days

210 days

420 days

NESTANSCD


Group Management

Group Management

IR Camera

NESTANSCD


Group Management

Group Management

IR Camera

NESTANSCD


Detection Delay Detection Delay

DETECTION DELAY (S)

CLASSIFICATION DELAY (S)

VELOCITY DELAY (S)

REPORTED VELOCITY (MPH)

ACTUAL VELOCITY (MPH)

2.7 3.2 3.2 25.0/10.9 N/A

1.8 3.2 3.2 24.6 N/A

1.7 2.7 3.2 17.6 N/A

3.8 4.8 5.3 9.3 N/A

1.7 2.7 2.8 11.1 10

2.6 3.1 3.6 18.5 20

1.9 2.4 2.4 23.0 20

2.6 2.9 3.2 12.7 12

0.9 2.5 2.5 22.1 20

4.5 8.1 8.1 6.2 N/A

NESTANSCD


3-Tier Classification3-Tier Classification

Group

Group

Group

Base mote

Report

Report

Performing base level classification

Group leader, performing group level classification

Normal mote, performing sensor (mote) level classification

NESTANSCD


First Tier: Robust SensingFirst Tier: Robust Sensing

•PIR Sensing•Magnetic Sensing•Acoustic Sensing

•Commonality:– Initial Threshold Calibration– Continuous Threshold Calibration with changing

environment – Power & Frequency Filtering

NESTANSCD


PIR Sensing Module (1)PIR Sensing Module (1)

• The current PIR detection algorithm using XSM sensors can distinguish walking persons in a range of 12-20 ft in hot environments – About 19 ft/person running – About 12 ft/person walking

• 30-40 ft in cool environments. • Almost all false alarms are reliably

removed.• Radio interference has been also removed.

NESTANSCD


PIR Sensing Module (2) PIR Sensing Module (2)

•Environmental factors– Grass and Trees.– Temperature. – Wind and Sunshine.

•Frequency Analysis – Uses high/low-pass filters to filter out noise, so

that no false alarms are generated due to environmental effects.

•Self-adaptive– Continuous filtering and calibration to adapt to

environment.

•Data sampling is turned off for 60 ms when there is radio transmission.

NESTANSCD


PIR Sensing Module (3): DataPIR Sensing Module (3): Data

This figure displays the raw data, the dynamic threshold, and the confidence of the detection. The detection report is based on frequency analysis of the signals and compared with an adaptively adjusted threshold.

NESTANSCD


Magnetometer Sensing (1)Magnetometer Sensing (1)

• Requirement– Detect vehicles and persons with a weapon

• Challenges– ADC reading may saturate– Response latency– Magnetic and electric noise from environment

and mote circuitry– Thermal reading drift– Radio/Mag interference– Short range– XSM-2 has greater noise than XSM-1

NESTANSCD



• Raw ADC reading can saturate

• Translate the pair of POT/ADC values to a single scaled mag point

• Moving average of recent scaled ADC readings.

• Compare to difference between slow and fast moving average

NESTANSCD



Response time•Mag sensor chain needs about 40ms to settle. •ADC readings need about 50ms to settle after a potentiometer change.

•The averaging algorithm needs at least 3 initial readings to perform computation.

•A fast-detect logic speeds up detection of obvious signals

NESTANSCD



– Signal/noise ratio• Signals (Scaled ADC readings)

are hard to distinguish for small targets or targets at far distances

– Signals for iron bar moving at 5 ft.

• Use a moving average of recent readings (Mag Points) to filter out noise.

• Mag Points show signals whose amplitude is often lower than that of noise

– Mag Points for iron bar moving at 5 ft.

NESTANSCD


Acoustic Sensing (1)Acoustic Sensing (1)

•Properties:– Power based approach.– Automatic and continuous calibration due to

temperature fluctuations, noisy environments and individual sensor characteristics.

– Differentiates between vehicles, humans, background noise and wind (collaboration with PIR sensors necessary).

•Limitations:– No differentiation between small-big vehicles

currently available.

NESTANSCD



Three Cars

Initial Calibration

No Detection

Detection whenEnergy Crosses

Standard Deviation

NESTANSCD



•Moving average curve plus 3 times the standard deviation curve = THR curve (called standard deviation on previous slide)

•Count number of crossings of THR out of the last N readings and if percentage is greater than x% then this is a target– X is about 60%

NESTANSCD


DOA controls minimal aggregation degreeto reduce false alarms

Second Tier: Group Aggregation

Second Tier: Group Aggregation

Awareness Range

Detection Range

Node

Member

Follower

Leader

NESTANSCD


System Issues: False alarms System Issues: False alarms

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

1 2 3 4 5 6

Degree of aggregation (DOA)

Pro

bab

ilit

y o

f fa

lse

alar

ms

false positives

false negatives

• Probability of false positivesreduces as DOA increases

• Probability of false negativesincreases as DOA increases

•With DOA = 3 we had zero false alarms

•The DOA parameter can be tuned based on sensing range and thedensity with which motes are deployed

Impact of DOA on False Alarms

Spatial-temporal correlated data aggregation can effectively reduce false alarms

NESTANSCD


Third Tier: Base Mote (1)Third Tier: Base Mote (1)

• The base mote keeps received tracking messages in FLASH.

• It then makes use of the spatio-temporal correlation to decide which target a tracking message belongs to. (e.g., 30 m and 5 sec)

• When a specific target gets enough (according to a adjustable parameter) messages for one target, a “detection” report is sent from the base mote to the RSCC.

NESTANSCD


Third Tier: Base Mote (2)Third Tier: Base Mote (2)

• After the “detection” report is sent and enough information is gathered for classification, a “classification” report is sent from the base mote to RSCC. (2 additional reports beyond detection)

• The base mote also uses a least square calculation to calculate the velocity of the target. A “velocity” report is sent to RSCC. (5 additional reports beyond classification)

• Afterwards, send reports according to an adjustable

flow rate parameter. X D

ista

nce

Time

Slope = X Velocity ( Least Square Estimation)

NESTANSCD


Classification SchemeClassification Scheme

PIR

SensorAcoustic Sensor

Magnetic Sensor

Target Type Status

Detection XFalse Alarm by Wind Done

Detection X Any Target Done

Detection X[n] Person Done

Detection X XPerson with Weapon Done

Detection X X X Vehicle Done

Freq. Analysis X Big/Small Vehicle

Potential

Num Hits X X X Big/Small VehiclePotential

Group Size X X Big/Small VehiclePotential

NESTANSCD


Detection/Classification/Velocity Delay Detection/Classification/Velocity Delay

DETECTION DELAY (S) CLASSIFICATION DELAY (S)

VELOCITY DELAY (S)

REPORTED VELOCITY (MPH)

ACTUAL VELOCITY (MPH)

2.7 3.2 3.2 25.0/10.9 N/A

1.8 3.2 3.2 24.6 N/A

1.7 2.7 3.2 17.6 N/A

3.8 4.8 5.3 9.3 N/A

1.7 2.7 2.8 11.1 10

2.6 3.1 3.6 18.5 20

1.9 2.4 2.4 23.0 20

2.6 2.9 3.2 12.7 12

0.9 2.5 2.5 22.1 20

4.5 8.1 8.1 6.2 N/A

NESTANSCD


Self-Healing (1)Self-Healing (1)

•Wide spectrum of capabilities•Not binary

•In Routing– Multiple parents in backbone tree

•No cost for periodic probing•Stealthiness is maintained•Local decision on choosing alternative parent is fast•Re-create n-parent tree on system rotation

•In MAC– For unicast – retransmission of lost packet

NESTANSCD



•At Application Level– Critical messages are transmitted multiple

times to better ensure delivery

•In Sensing– Fail-stop – use of many sensors as targets

move avoids problems here– Byzantine failure – detect node continuously

reporting and shut it down

•In Localization– If node fails to obtain location during walking

GPS, it gets info from neighbors and uses tri-lateration

NESTANSCD



•In System Initialization– Each phase is coordinated and sequential– If a node is not in-step it becomes silent until

next system rotation

•In Tracking– If group leader fails, info is still with the

members and is passed to next leader

•In Wakeup– Decentralized and if some nodes fail to wake-up

it is not a problem because many others will be awake

NESTANSCD



•Limited Effect– Clock sync, neighbor discovery, etc. are highly

decentralized and local. Single node failures only affect that node and does not propagate to the rest of the network.

•System Rotation– Can correct many issues – Currently, only executed based on time– Could be extended to re-run when many

failures are detected BUT this means extra messages which affects lifetime and stealthiness!

NESTANSCD


Other Middleware Services Other Middleware Services

•System Initialization– List of system parameters

•MAC•Routing•Asymmetric Detection•Localization – Walking GPS•Clock Sync•Velocity Calculation

NESTANSCD


System InitializationSystem Initialization

•Place motes in field – turn on mote; get location via walking GPS

•Turn on relay and base mote•Turn on RSCC•RSCC requests system parameters to relay•Relay asks base mote for parameters

(from flash)•Base mote sends to relay and relay sends

to RSCC •RSCC then asks each other base mote the

same thing in turn

NESTANSCD


System InitializationSystem Initialization

•RSCC then sends out Origin of Reference – broadcast to all relays

•Each relay adds its location to location of RSCC and sends to base mote

•RSCC broadcasts master clock – essentially a start message

•Relay sends start signal to base mote •Base mote sends out parameters and then

begin mote field initialization, e.g., clock sync, localization, etc.

NESTANSCD


System ParametersSystem Parameters

• Multi-hop reconfiguration with tunable parametersParameter Name Units Description of the Parameter Value

GRID_X meter Controls the topology of the network under static localization scheme

Sentry Range meter Controls disperse/density of the sentries.

Power Mode N/A Controls the power consumption of the non-sentries

SD Threshold 1% Threshold to decide whether a link is symmetry or not

Pm TimeOut second The duration a non-sentry should remain awake after it is waken by sentry nodes

FlowRate second Specifies the minimum periodicity with which the tracking updates

PIR Threshold N/A Used to tune the sensitivity of the PIR sensors

DetectionThreshold N/A The minimum number of reports accumulated before a basemote declares the detection

Magnetic Threshold N/A Used to tune the sensitivity of the magnetic sensors

Acoustic Threshold N/A Used to tune the sensitivity of acoustic sensor sensors

shutDownThreshold 1% Used to shutdown chaos motes

Phase Delay second Controls the duration of each phase to accommodate

TrackingPhaseCount Delay The duration of the tracking phase = TrackingPhaseCount * Phase Delay

Settings N/A Defines various kind of binary control

Schedule N/A Defines tripwire sleep/awake schedule

NESTANSCD


MAC: B-MACMAC: B-MAC

• A derivative version of CSMA – Listen before send. Linear back off if channel is busy.

• Support dynamic noise floor during carrier sense

• Support MAC Layer reliability through 1 byte ACK

• Support flexible back off scheme to meet requirement of application

• Support lower power listening to trade off fast response

NESTANSCD


Routing (1)Routing (1)

Reliability in routing infrastructure – Asymmetric link detection – MAC level delivery failure detection– Routing layer retransmission– Multi-Parent diffusion tree– Local parent switch in case of failure– Robust to base failure

A B

1

5 3

2

4

6 7Symmetric Link Detection

Local Switch

NESTANSCD


Routing (2)Routing (2)

•Robust diffusion tree with asymmetry detection – It requires no location information.– It requires small portion of nodes awake.– Small cost to maintain (1 byte ACK detection).– It matches to multiple relay scenario.

•Robust diffusion tree with local switch– Robust to failure of parent nodes – Stealthiness (no need to maintain route

periodically)– It requires small portion of nodes to be awake.

NESTANSCD


Asymmetric DetectionAsymmetric Detection

•Neighbors perform discovery via beacons

•Neighbors then also exchange neighbor tables

•Node must hear from a neighbor node and be in that node’s table => symmetric link

•If link is asymmetric – drop neighbor from neighbor table

NESTANSCD


• GPS Mote assembly:– Garmin eTrex Legend

GPS device (WAAS enabled)

– MICA2 mote– helmet, RS232 cable,

board, wristband– Memory size: 17 Kbytes

(code), 600 Bytes (data)• Sensor Node: – Mica2, XSM– Memory: 1 Kbytes

(code), data: 120 bytes

Walking GPS

NESTANSCD


• The sensor node deployer (soldier or vehicle) has a GPS Mote assembly attached to it.

• The GPS Mote periodically beacons its location. • Sensor Motes that receive this beacon infer

their location based on the information present in this beacon.

• From the localization perspective, two distinct software components exist.

Sensor Mote

Localization

GPS Mote

GPS

Walking GPS

NESTANSCD


• Two deployment types: – mote powered on at deployment

• first INIT_LOCALIZATION packet gives the location

– mote powered on all the time • INIT_LOCALIZATION stored in circular

buffer, if RSSI > Threshold• Choose best value

• Two stages for Localization:– at deployment time: Walking GPS– during system initialization:

HELP_REQUEST/REPLY, if no location information present (for robustness)

Walking GPS: Sensor Mote

NESTANSCD


Walking GPS Evaluation

• First deployment type: sensor motes turned on at the place of deployment, right before being deployed

• Localization error: 0.8 meters • Standard deviation: 0.5 meters

• Second deployment type: sensor motes turned on all the time.

• Localization error: 1.5 meters • Standard deviation: 0.8 meters

NESTANSCD


• Second deployment type using two GPS devices

• Each line along the length of the grid deployed with a different GPS device

• Localization error: 1.6 meters

• Standard deviation: 0.9 meters

Walking GPS Evaluation

NESTANSCD


Clock Sync (1)Clock Sync (1)

•A strip-down version of Vanderbilt TimeSyn to meet the requirement of ANSCD system

– Normal crystal accuracy 10~50 PPM. Worst case drift 0.03~0.142 second/per day. Average drift is even less.

– Enough for ANSCD requirement

•Used in ANSCD for:– Velocity calculation– Phase transition – Timestamp events

NESTANSCD


Clock Sync (2)Clock Sync (2)

1. Root node accepts time from RSCC through MASTER CLOCK command.

2. Disseminate time through flooding.

3. Time stamping performed right before Timestamp is sent out to avoid un-predictability in MAC access delay

4. Abandon continuous clock drift calibration to achieve stealthiness in operation

5. Rotation to compensate for clock drift

NESTANSCD


Velocity CalculationVelocity Calculation

•Performed at base mote attached to relay•Messages are ordered via the timestamps•Wait for “n” messages before calculating

velocity•Calculate x-comp and y-comp of velocity

separately using least squares curve fitting

NESTANSCD


Lessons Learned (1)Lessons Learned (1)

•System-wide energy solution is needed– Include system init; communication; sensing;

use one flooding for multiple purposes

•Many links are asymmetric – use conservative communication range and an explicit asymmetric detection module

•Timely Delivery of hardware is crucial– Unstable hardware version costs us significant

effort on continuous tuning the sensing & classification algorithms

NESTANSCD


Lessons Learned (2)Lessons Learned (2)

•Higher bandwidths and more data memory

•Re-send lost messages based on semantics of messages (at application level) – too expensive to re-send every lost packet at MAC layer

•System would be better with higher densities

•Sensing ranges need to be increased

NESTANSCD


Remaining Work FY ‘05Remaining Work FY ‘05

•Robustness testing and performance evaluation– Large scale testing (1000 motes)

•Aggressive Power Management•Further reduce false alarms•Classify accurately

– Classify small-large vehicles

•Air Drop Localization•Increased self-healing properties•Supporting field tests/demo

– Full integration and testing with sophisticated sensors

NESTANSCD


EndEnd