rudra dutta csc 453-001, fall, 2012 a simple sensing program structure

Rudra DuttaCSC 453-001, Fall, 2012

A Simple Sensing Program StructureA Simple Sensing Program Structure

OverviewOverview 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, NCSU 2

Requirements / IssuesRequirements / 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


Big Picture to Design ProblemBig Picture to Design Problem


SyntaxSyntax “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)


Preamble Action Code ID

Code Meaning

0 Rendezvous request

1 Rendezvous reply

2 Req. capabilities

3 Reply capabilities

4 Set requirements list

5 Reporting sensed data

6 Sensed data ACK

… …

RendezvousRendezvous 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


RendezvousRendezvous 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


Server

Co

mm

Co

mm

Client

SensorMgr

Context ManagementContext 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




Sensor ManagementSensor 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 Rep. Freq.

Distributed ServerDistributed Server


To utilize the distributed nature of themesh, 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

TimestampingTimestamping 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


SemanticsSemantics 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


Sensing Management (SET)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.

Preamble Action Code ID Quantity Sens. Freq.


(Multiple instances)


Seq. Nbr.

Seq. Nbr.

Rep. Freq.

State Maintenance (HeartBeat)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.


Sensing ReportingSensing Reporting Client maintains timer(s), collects sensor readings Client maintains reporting timer, transmits sensor

readings Server transmits acknowledgement




Quantity Representation Reading TimestampRep. Time


Seq. Nbr.

Seq. Nbr.

ASD Program DesignASD 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


ASD Multi-thread DesignASD Multi-thread Design


Idle Idle Idle Idle 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

ASD Single-thread DesignASD Single-thread Design

Merge “idle” states into a single one Merge timers into a single one with variable alarm period


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 measurementFlag UP

On Measurement Timer

Take readings and bufferFlag UP

RX SET

If SET is for this ASD, new SEQ # Broadcast ACK/NACK Do SET action (change setting) Record SEQ #

ASD Single-thread Program FlowASD Single-thread Program Flow


x min (NxtTimes)-t

Block Receive with x second timeout

Rx

Discard top measurementFlag UP

Broadcast ACK / NACKTake SET actionRecord SEQ #

t > NxtMeasureme

nt Time?

t > NxtTx Time OR Flag UP ? If buffer not empty

broadcast one packetNxtTxTime += TxTimer

Take readings and bufferFlag UPNxtMeasurementTime += MeasurementTimer

t > NxtHeartBeat

Time?

YES

NO

Fresh SET for this ASD ACK

Timeout

Broadcast capabilities, ID, time, sequence numberNxtHeartBeatTime += HBTimer

YESNO

NO

NO

Other

Server Program DesignServer Program Design


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 allASDs

On ClientSETTxTimer

For each SET in the the SETbufferIf entry expired then remove it else broadcast it (to ASDs)

On ServerSETTxTimer

For each SET in the the SETbufferIf 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 ASDsSet Originating=TRUE

Remove SET from buffer

SummarySummary Even simple system requires some design Semantics and client-server management need

to be designed Sits on top of networking and communication

semantics


rudra dutta csc 453-001, fall, 2012 a simple sensing program structure

Documents

copyright fall

rudra duttacsc

frequency of sensing

multiple times

managed sensing systemsasd

ip level

asd client

transientdoes asd