1. Rudra Dutta CSC 453-001, Fall, 2012 A Simple Sensing Program Structure

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 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, NCSU2

3. Requirements / Issues Rendezvous – 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 Fall 2013, Rudra Dutta, NCSU3

4. Big Picture to Design Problem Copyright Fall 2013, Rudra Dutta, NCSU4

5. Syntax “Wire format” of application layer PDU – 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) Copyright Fall 2013, Rudra Dutta, NCSU5 PreambleAction CodeID CodeMeaning 0Rendezvous request 1Rendezvous reply 2Req. capabilities 3Reply capabilities 4Set requirements list 5Reporting sensed data 6Sensed data ACK ……

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 Fall 2013, Rudra Dutta, NCSU6

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 Copyright Fall 2013, Rudra Dutta, NCSU7 Server Comm Client Sensor Mgr

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 Copyright Fall 2013, Rudra Dutta, NCSU8 PreambleAction CodeID PreambleAction CodeID

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) Copyright Fall 2013, Rudra Dutta, NCSU9 PreambleAction CodeID PreambleAction CodeIDRep. Freq.

10. Distributed Server Copyright Fall 2013, Rudra Dutta, NCSU10 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

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 Fall 2013, Rudra Dutta, NCSU11

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 Fall 2013, Rudra Dutta, NCSU12

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 Copyright Fall 2013, Rudra Dutta, NCSU13 PreambleAction CodeIDQuantityRepresentationMax Sns. Freq. PreambleAction CodeIDQuantitySens. Freq. PreambleAction CodeID (Multiple instances) Seq. Nbr. Rep. Freq.

14. State Maintenance (HeartBeat) ASD sends periodic “I am alive” messages to server – Possibly broadcast Reasonable to include capabilities of sensor, ID if available Copyright Fall 2013, Rudra Dutta, NCSU14 PreambleAction CodeIDQuantityRepresentationMax Sns. Freq. (Multiple instances)

15. Sensing Reporting Client maintains timer(s), collects sensor readings Client maintains reporting timer, transmits sensor readings Server transmits acknowledgement Copyright Fall 2013, Rudra Dutta, NCSU15 PreambleAction CodeID PreambleAction CodeID QuantityRepresentationReadingTimestampRep. Time (Multiple instances) Seq. Nbr.

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 Fall 2013, Rudra Dutta, NCSU16

17. ASD Multi-thread Design Copyright Fall 2013, Rudra Dutta, NCSU17 Idle 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 Sensor 1 Timer Read Sensor 1, buffer On Heartbeat Timer Broadcast capabilities, ID, time, sequence number

18. ASD Single-thread Design Merge “idle” states into a single one Merge timers into a single one with variable alarm period Copyright Fall 2013, Rudra Dutta, NCSU18 Idle On Tx Timer OR Flag is UP If buffer not empty Broadcast one packet On Heartbeat Timer Broadcast capabilities, ID, time, sequence number RX ACK for measurement Discard top measurement Flag  UP On Measurement Timer Take readings and buffer Flag  UP RX SET If SET is for this ASD, new SEQ # Broadcast ACK/NACK Do SET action (change setting) Record SEQ #

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

20. Server Program Design Copyright Fall 2013, Rudra Dutta, NCSU20 Idle RX Measurement from Client (From ASD) Broadcast ACK (WiFi) Take Measurement Action RX Heartbeat Timer (From ASD) Process Heartbeat RX User SET Command Buffer SET command to be sent to all ASDs On ClientSETTxTimer For each SET in the the SETbuffer If entry expired then remove it else broadcast it (to ASDs) 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 ClientSETACK (from ASD) Broadcast SETACK to all mesh nodes RX SETACK (from Mesh Nodes) Remove SET from SETBuffer RX SET (from other Mesh Node) Buffer SET command to be sent to sensor node(s) Buffer SET command to be sent to all other mesh nodes and the ASDs Set Originating=TRUE Remove SET from buffer

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 Fall 2013, Rudra Dutta, NCSU21