A Simple Sensing Program Structure Rudra Dutta CSC 453-001, Spring, 2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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