A Simple Sensing Program Structure
Rudra Dutta
CSC 453-001, Fall, 2012
Overview

Designing the program on the mobile platform
–
–
–

Assumes a wireless multihop (mesh) network
–
–

Brings up issues and representative solutions
Possibly useful in project
Not mandated to be template – not a “standard”
Nodes perform routing, forwarding, sensing
Some or all nodes can act as 802.11 Aps
Mobile auxiliary sensing devices (ASD)
–
–
Sensor rich, 802.11, moderate processing/memory
Flexibly connecting and disconnecting from mesh
Copyright Fall 2013, Rudra Dutta, NCSU
2
Requirements / Issues

Rendezvous
–

Context management
–

Cannot assume accurate clock at auxiliary nodes
Semantics
–
–

Agreeing on frequency of sensing, reporting
Timestamping
–

Benefits if same device is recognized
Sensing Management
–

Mobile devices’ presence is transient
Physical quantities corresponding to readings, units
Heterogeneity: Multiple types of sensing devices
Robustness
–
State refresh, soft state
Copyright Fall 2013, Rudra Dutta, NCSU
3
Big Picture to Design Problem
Copyright Fall 2013, Rudra Dutta, NCSU
4
Syntax

“Wire format” of application layer PDU
–
–
–

Signals – header design
Data – sensed data format in payload
Meta – type of packet, details
Common header format
–
–
–
Code Meaning
Preamble – application specific
distinct pattern
Action code – type of packet,
interpretation of rest of packet
ID – identity of ASD (from / to)
0
Rendezvous request
1
Rendezvous reply
2
Req. capabilities
3
Reply capabilities
4
Set requirements list
5
Reporting sensed data
Preamble
6
Sensed data ACK
…
…
Copyright Fall 2013, Rudra Dutta, NCSU
Action Code
ID
5
Rendezvous
Auxiliary Sensing device’s presence is transient
 Rendezvous with AP when close
 MAC / IP : Inbuilt into protocol

–

Entry to network of AP, IP address by DHCP
Application level rendezvous
–
–
–
–
Periodic beacons from Server, optionally
Periodic broadcasts for discover from ASD Client,
when ready to connect
Subnet broadcast at IP level, but specific UDP port
Reply is unicast, completing application layer
association
Copyright Fall 2013, Rudra Dutta, NCSU
6
Rendezvous
Sensor
Mgr
Client

Server
Does ASD perform sensing while disconnected?
–
–

Comm
Auxiliary Sensing device’s presence is transient
Comm

May be useful in many cases; mobility trace etc. that
can be post-analyzed
Less useful for managed sensing systems
ASD requires local auxiliary storage
Copyright Fall 2013, Rudra Dutta, NCSU
7
Context Management


ASDs may connect and disconnect multiple times, to
multiple servers (APs)
Recognizing previously encountered ones can be
beneficial
–
–

May be able to “connect” space-time differentiated sensor
readings (location, mobility)
May help in calibration, self-calibration
Simple approach: ASD puts ID (if assigned) in
rendezvous packet, Server assigns in reply
–
Allows continuity of readings without PII, supports heterogeneity
Preamble
Action Code
Preamble
Copyright Fall 2013, Rudra Dutta, NCSU
ID
Action Code
ID
8
Sensor Management




ASDs may connect and disconnect multiple times, to
multiple servers
Different servers may have different ability/requirement
to serve multiple clients
Must be capable of telling the client to report at a certain
frequency
Reasonable to piggyback on the rendezvous interaction
–
Or use a general-purpose SET message (later)
Preamble
Action Code
Preamble
Copyright Fall 2013, Rudra Dutta, NCSU
ID
Action Code
ID
Rep. Freq.
9
Distributed Server

To utilize the distributed nature of the
mesh, server must run as distributed
coordinated process
 Human user / controlling application at one
node (may or may not be mesh node)
–
–

Commands issued at any mesh node should reach
any and all ASDs
Sensor readings reported to any mesh node should
be available at central database
May not be necessary for simple applications
Copyright Fall 2013, Rudra Dutta, NCSU
10
Timestamping

Each ASD keeps its own clock
–

Stores sensor readings with timestamps by local
time
–

Not guaranteed to be very accurate
When reporting to Server, includes a “reporting
timestamp”
Server is expected to maintain accurate clock
–
Synchronized across the mesh
– Can calibrate/update ASD timestamps by comparing
time at server with ASD reporting time
Copyright Fall 2013, Rudra Dutta, NCSU
11
Semantics

Further sensing management tasks
–
–
–

Must be able to exchange information about
sensing capabilities
–
–

Not all sensor readings may be “needed” by server at
all times
Sensor readings need not be collected unnecessarily
ASDs are heterogeneous – not all have similar
sensing capability
“Sensed quantity”
“Representation”
Code values in application logic – or config file
–
Similar to action code
Copyright Fall 2013, Rudra Dutta, NCSU
12
Sensing Management (SET)

After rendezvous, interaction to setup recurrent sensing
–
Client sends capabilities with every heartbeat (see next)
Preamble
–
ID
Quantity
Representation
Max Sns. Freq.
(Multiple instances)
Server sets requirements

–
Action Code
“SET” actions have soft state (decay over time)
May also set reporting frequency
Preamble
Action Code
ID
Seq. Nbr.
Quantity
Sens. Freq.
Rep. Freq.
(Multiple instances)
Preamble
Copyright Fall 2013, Rudra Dutta, NCSU
Action Code
ID
Seq. Nbr.
13
State Maintenance (HeartBeat)

ASD sends periodic “I am alive” messages to server
–

Possibly broadcast
Reasonable to include capabilities of sensor, ID if
available
Preamble
Action Code
ID
Quantity
Representation
Max Sns. Freq.
(Multiple instances)
Copyright Fall 2013, Rudra Dutta, NCSU
14
Sensing Reporting

Client maintains timer(s), collects sensor readings
 Client maintains reporting timer, transmits sensor
readings
 Server transmits acknowledgement
Preamble
Action Code
ID
Rep. Time
Seq. Nbr.
Quantity
Representation
Reading
Timestamp
(Multiple instances)
Preamble
Copyright Fall 2013, Rudra Dutta, NCSU
Action Code
ID
Seq. Nbr.
15
ASD Program Design

Multi-thread implementation possible
–
–
–

One thread for each sensor – block on timer
One thread for server communication – block on read
One thread for transmitting – block on timer
Issues of concurrence
–
Different threads wake up at different times
– May be “simultaneous”
– Global memory to communicate state
– Behavior of server communication thread
unpredictable

More demanding of platform capabilities
Copyright Fall 2013, Rudra Dutta, NCSU
16
ASD Multi-thread Design
On Tx Timer
If buffer not empty
Broadcast one packet
On Sensor 1 Timer
On Heartbeat Timer
Read Sensor 1, buffer
Broadcast capabilities, ID,
time, sequence number
Idle
Copyright Fall 2013, Rudra Dutta, NCSU
Idle
Idle
On Rx
If SET for this ASD, fresh
Change settings
Record sequence #
If ACK
Purge packet from buffer
Idle
Idle
17
ASD Single-thread Design
On Measurement Timer
Take readings and buffer
Flag  UP
On Tx Timer OR Flag is UP
If buffer not empty
Broadcast one packet
RX SET
Idle
If SET is for this ASD, new SEQ #
Broadcast ACK/NACK
Do SET action (change setting)
Record SEQ #
On Heartbeat Timer
RX ACK for measurement
Broadcast capabilities, ID,
time, sequence number


Discard top measurement
Flag  UP
Merge “idle” states into a single one
Merge timers into a single one with variable alarm period
Copyright Fall 2013, Rudra Dutta, NCSU
18
ASD Single-thread Program Flow
x  min (NxtTimes)-t
Other
Block Receive with x
second timeout
Fresh SET for this ASD
ACK
Rx
Broadcast ACK / NACK
Take SET action
Record SEQ #
NO
NO
NO
Copyright Fall 2013, Rudra Dutta, NCSU
Discard top measurement
Flag  UP
Timeout
t>
NxtMeasureme
nt Time?
t > NxtTx Time
OR Flag UP ?
t>
NxtHeartBeat
Time?
YES
Take readings and buffer
Flag  UP
NxtMeasurementTime += MeasurementTimer
YES
If buffer not empty
broadcast one packet
NxtTxTime += TxTimer
NO
Broadcast capabilities, ID, time, sequence
number
NxtHeartBeatTime += HBTimer
19
Server Program Design
RX Heartbeat Timer (From ASD)
Process Heartbeat
RX Measurement from Client (From ASD)
Broadcast ACK (WiFi)
Take Measurement Action
On ClientSETTxTimer
For each SET in the the SETbuffer
If entry expired
then remove it
else broadcast it (to ASDs)
RX ClientSETACK (from ASD)
Idle
RX User SET Command
RX SETACK (from Mesh Nodes)
Buffer SET command to be sent to all
ASDs
Buffer SET command to be sent to all
other mesh nodes and the ASDs
Set Originating=TRUE
On ServerSETTxTimer
For each SET in the the SETbuffer
If entry expired
then remove it
elseif Originating=TRUE
then Bcast to all other mesh nodes
Copyright Fall 2013, Rudra Dutta, NCSU
Broadcast SETACK to all mesh nodes
Remove SET from buffer
Remove SET from SETBuffer
RX SET (from other Mesh Node)
Buffer SET command to be
sent to sensor node(s)
20
Summary

Even simple system requires some design
 Semantics and client-server management need
to be designed
 Sits on top of networking and communication
semantics
Copyright Fall 2013, Rudra Dutta, NCSU
21