1. A Simple Sensing Program Structure
Rudra Dutta
CSC , Spring, 2015

2. Overview Designing the program on the mobile platform
Brings up issues and representative solutions
Possibly useful in project
Not mandated to be template – not a “standard”
Assumes a wireless multihop (mesh) network
Nodes perform routing, forwarding, sensing
Some or all nodes can act as Aps
Mobile auxiliary sensing devices (ASD)
Sensor rich, , moderate processing/memory
Flexibly connecting and disconnecting from mesh
Copyright Spring 2015, Rudra Dutta, NCSU

3. Requirements / Issues Rendezvous Context management Sensing Management
Mobile devices’ presence is transient
Context management
Benefits if same device is recognized
Sensing Management
Agreeing on frequency of sensing, reporting
Timestamping
Cannot assume accurate clock at auxiliary nodes
Semantics
Physical quantities corresponding to readings, units
Heterogeneity: Multiple types of sensing devices
Robustness
State refresh, soft state
Copyright Spring 2015, Rudra Dutta, NCSU

4. Big Picture to Design Problem
Copyright Spring 2015, Rudra Dutta, NCSU

5. Syntax “Wire format” of application layer PDU Common header format
Signals – header design
Data – sensed data format in payload
Meta – type of packet, details
Common header format
Preamble – application specific distinct pattern
Action code – type of packet, interpretation of rest of packet
ID – identity of ASD (from / to)
Code
Meaning
Rendezvous request 1
Rendezvous reply 2
Req. capabilities 3
Reply capabilities 4
Set requirements list 5
Reporting sensed data 6
Sensed data ACK …
Preamble
Action Code ID
Copyright Spring 2015, Rudra Dutta, NCSU

6. 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 Spring 2015, Rudra Dutta, NCSU

7. Rendezvous Auxiliary Sensing device’s presence is transient
Does ASD perform sensing while disconnected?
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
Sensor
Mgr
Client
Server
Comm
Comm
Copyright Spring 2015, Rudra Dutta, NCSU

8. 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 ID
Preamble
Action Code ID
Copyright Spring 2015, Rudra Dutta, NCSU

9. 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 ID
Preamble
Action Code ID
Rep. Freq.
Copyright Spring 2015, Rudra Dutta, NCSU

10. 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 Spring 2015, Rudra Dutta, NCSU

11. Timestamping Each ASD keeps its own clock
Not guaranteed to be very accurate
Stores sensor readings with timestamps by local time
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 Spring 2015, Rudra Dutta, NCSU

12. Semantics Further sensing management tasks
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
Must be able to exchange information about sensing capabilities
“Sensed quantity”
“Representation”
Code values in application logic – or config file
Similar to action code
Copyright Spring 2015, Rudra Dutta, NCSU

13. Sensing Management (SET)
After rendezvous, interaction to setup recurrent sensing
Client sends capabilities with every heartbeat (see next)
Server sets requirements
“SET” actions have soft state (decay over time)
May also set reporting frequency
Preamble
Action Code ID
Quantity
Representation
Max Sns. Freq.
(Multiple instances)
Preamble
Action Code ID
Seq. Nbr.
Quantity
Sens. Freq.
Rep. Freq.
(Multiple instances)
Preamble
Action Code ID
Seq. Nbr.
Copyright Spring 2015, Rudra Dutta, NCSU

14. 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 Spring 2015, Rudra Dutta, NCSU

15. 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
Action Code ID
Seq. Nbr.
Copyright Spring 2015, Rudra Dutta, NCSU

16. 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 Spring 2015, Rudra Dutta, NCSU

17. ASD Multi-thread Design
On Tx Timer
If buffer not empty
Broadcast one packet
On Rx
If SET for this ASD, fresh
Change settings
Record sequence #
If ACK
Purge packet from buffer
On Heartbeat Timer
Broadcast capabilities, ID, time, sequence number
On Sensor 1 Timer
Read Sensor 1, buffer
Idle
Idle
Idle
Idle
Idle
Copyright Spring 2015, Rudra Dutta, NCSU

18. 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
If buffer is now empty
Flag  DOWN
RX SET
If SET is for this ASD, new SEQ #
Broadcast ACK/NACK
Do SET action (change setting)
Record SEQ #
Idle
On Heartbeat Timer
Broadcast capabilities, ID, time, sequence number
RX ACK for measurement
Discard top measurement
Flag  UP
Merge “idle” states into a single one
Merge timers into a single one with variable alarm period
Copyright Spring 2015, Rudra Dutta, NCSU

19. ASD Single-thread Program Flow
x  min (NxtTimes)-t
Block Receive with x second timeout
Other
Fresh SET for this ASD
ACK Rx
Broadcast ACK / NACK
Take SET action
Record SEQ #
Discard top measurement
Flag  UP
Timeout
t > NxtMeasurement Time?
YES NO
Take readings and buffer
Flag  UP
NxtMeasurementTime += MeasurementTimer
t > NxtTx Time OR Flag UP ?
YES NO
If buffer not empty
broadcast one packet
NxtTxTime += TxTimer NO
t > NxtHeartBeat
Time? NO
Broadcast capabilities, ID, time, sequence number
NxtHeartBeatTime += HBTimer
Copyright Spring 2015, Rudra Dutta, NCSU

20. Server Program Design Idle 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)
Idle
RX ClientSETACK (from ASD)
Broadcast SETACK to all mesh nodes
Remove SET from buffer
RX User SET Command
RX SETACK (from Mesh Nodes)
Buffer SET command to be sent to all
ASDs
Remove SET from SETBuffer
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
RX SET (from other Mesh Node)
Buffer SET command to be sent to sensor node(s)
Copyright Spring 2015, Rudra Dutta, NCSU

21. 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 Spring 2015, Rudra Dutta, NCSU