A Remote Code Update Mechanism for Wireless Sensor Networks

Thanos Stathopoulos, John Heidemann and Deborah EstrinCEG 790 PresentationBy: Trevor Smith

OutlineIntroductionProblem DescriptionDesign DecisionsEvaluationConclusionsFuture WorkOutline

What is Wireless Sensor NetworkSensor networks integrate sensing, computing and communicationCan be used for monitoring environmental changes, water contamination, seismic activity or structural building integritySensor resource constraintsLow PowerLimited MemoryShort range, low power radiosIntro

Once Deployed What Happens?After deployment, motes might not be accessible again?Also, we cant always predict full range of sensor actions or might not have a full set of environment knowledge.What is the solution? Reprogram!How do we handle post deployment reprogramming?How do we deal with the limited mote resources (battery, memory, etc.)?Intro

SolutionRemote Code Distribution MechanismAuthor proposes MOAP (Multihop Over-the-Air Programming)Discuss different design alternatives: Data Dissemination protocols, retransmission policies and storage managementDesign Goals? Focus on energy consumption, memory usage and latencyCompare with floodingIntro

OutlineIntroductionProblem DescriptionDesign DecisionsEvaluationConclusionsFuture WorkOutline

Code Distribution Properties100% of image must reach all nodesReliability mechanism requiredIf image cannot fit into single packet, it must be kept in stable storage until the transfer is completeNetwork lifetime should not be severely affectedMemory and storage requirements should not severely affect the space required by the normal operations of the deviceProb Desc.

Resource PrioritizationEnergy is most important resourceRadio transmission is expensiveTransmit 3x cost of RecieveStable storage accessWrite is 1/8 the cost of transmitting the same number of bytesEEPROM is optimized for read operations and read is an order of magnitude cheaper than writeProb Desc.

Resource PrioritizationMemory Utilization is a close secondStatic RAM in specificOnly about 4K on current gen. MotesMust keep in mind reprogramming isnt the motes only operationMain Goal: Limit energy consumptionOptimizations arent freeTrade latency for battery optimizationIs latency that important in reprogramming?Prob Desc.

OutlineIntroductionProblem DescriptionDesign DecisionsEvaluationConclusionsFuture WorkOutline

Dissemination ProtocolHow is the data propagatedAll nodes must be reachedConcurrentlyFloodingMinimal state requirementsLow energy prioritizationStep by StepRipple (neighborhood-by-neighborhood)SlowDesign Decisions

AssumptionsDesign Decisions

DefinitionsDesign Decisions

Flooding Dissemination ProtocolFlooding does a receive and forward type of mechanismOnce packet is received the node retransmits itExpected # of transmissions for the network is:

The average time for node i at distance hi from the source is:

Design Decisions

Flooding Dissemination ProtocolDesign Decisions112223323454545

Ripple Dissemination ProtocolTransfer data Neighborhood-by-NeighborhoodNeighborhood is all nodes in the broadcast domainSingle hopMultihop handled recursivelyReceiver will attempt to become a source after entire image is receivedUse PUBLISH-SUBSCRIBE mechanismSince a source is in the same networkRequire all repairs to be local (one hop away)Design Decisions

Ripple Dissemination ProtocolDesign Decisions

Ripple Dissemination ProtocolExpected # of transmissions for the network is:

ki can be no more than (oi / 2) + 1The average time for node i at distance hi from the source is:

Design Decisions

Reliability MechanismRequires 100% of image deliveryWho is responsible for detecting lossSender (ACK)Receiver (NACK)NACK based approach cuts down on control trafficRequire repairs localNeighbors will have entire image in due timeReduce complexity by not routing NACKsWhat is our Retransmission Policy?Broadcast or UnicastDesign Decisions

Retransmission PolicyBroadcast RREQ, no suppressionSimpleHigh Probability of ReceptionHighly InefficientZero LatencyBroadcast RREQ, suppression based on randomized timersEfficientComplexReply if timer interval expires and no one else has repliedDesign Alts

Retransmission Policy (contd)Broadcast RREQ, fixed reply probability SimpleGood Probability of ReceptionLatency depends on probability of replyAvg efficiencyBroadcast RREQ, adaptive reply probabilityMore complex than static caseLatency and reception similarDesign Alts

Retransmission Policy (contd)Unicast RREQ, single replyHas the smallest prob. of successful receptionHighest EfficiencySimple, as long as source doesnt failZero latency, if source doesnt failDesign Alts

Segment ManagementNo IndexingRead EEPROM to find if segment is missingFull IndexingBitmap in RAM, if entry i in RAM is empty, segment i is missingDesign AltsRAMEEPROM

Segment Management (contd)Partial IndexingBitmap kept in RAMi/k and check if entry in RAM is empty or fullIf empty, need to do k consecutive reads to find missing segmentDesign AltsRAMEEPROM

Segment Management (contd)Hierarchical Full IndexingFirst level map kept in RAM, points to a page in EEPROMConsider EEPROM data to be same as physical page sizei div m finds page, i mod m in particular page finds segmentDesign AltsRAM

Segment Management (contd)Sliding WindowBitmap of up to w segments kept in RAMLimited out of order toleranceLast segment received starting point of windowDesign AltsBaseOffset

Segment Management ComparisonDesign Alts

OutlineIntroductionProblem DescriptionDesign DecisionsEvaluationConclusionsFuture WorkOutline

EmulationEmStar emulation environment30 Mica1 MotesAttached via serial cablesTransmitted image consists of 100 segments1 segment per packetMethods using sliding windowWindow size = 16bitsEval

EmulationNeighborhood size vs Power settingDesign Alts

Energy ConsumptionRipple w/ Sliding WindowFlooding w/ Sliding WindowRipple w/ Full IndexingEval

Energy ConsumptionFlooding hangs around 100 transmissionsChanges to power settings doesnt affect itRipple produces large power savings in terms of transmissions...WHY?Ripple w/ Full Indexing performs better for sparse networksDense networks savings isnt sufficient to justify using Full IndexingEval

LatencyAs we stated earlierWe will trade latency for power efficiencyEval

LatencyTx rate of 2 packets/secA faster Tx rate will note saturate the channel for rippleHowever it would increase the number of collisions in flooding, resulting in more retransmissionsAgain Ripple w/ Full Indexing performs better than Ripple w/ Sliding WindowEval

Retransmission PoliciesUsing ripple w/ sliding windowCompare broadcast vs unicastWhy is Unicast less than BroadcastEval

Retransmission PoliciesUnicast performs better than BroadcastBut what happens if the link fails in UnicastReceiver must locate another sourceAuthor proposes MAC to do link level retransmissionsEval

Mote Implementation15 Mica2 Motes100 segments, 1 segment per packetMica2 Motes have a stronger radio than the Mica1 motesThis results in better link qualities, fewer retransmissions and more rapid change in neighborhood sizeNo Full Indexing scheme in TinyOSEval

Mote ImplementationRetransmissions significantly smaller than emulationPower settings not as high eitherEval

MOAP ImplementationRipple disseminations, Unicast retransmission and Sliding Window segment ManagementCode is split up via packetizerNodes use link statistics mechanism Dont subscribe to sources that are lossy, intermittent or unreliableOnce complete image is stored, send PUBLISH messagesIf no SUBSCRIBERS commit code with bootloader to program memoryEval

MOAP Implementation (contd)Active sourcesAfter predetermined time has passed and retransmissions have been handled Commit the codeNodes detect lost segments with sliding windowRetransmission have higher priority than Data packetsDuplicate request suppressed Node keeps track of sources activity with a keep alive timer

Eval

MOAP Implementation (contd)Node keeps track of sources activity with a keep alive timerSolves NACKs Last Packet ProblemIf source dies the keep alive timer will broadcast a repair requestLate joiner mechanism allows nodes that have just recovered from a failure to get the new version of codeThis requires that nodes advertise their version periodicallyEval

OutlineIntroductionProblem DescriptionDesign DecisionsEvaluationConclusionsFuture WorkOutline

ConclusionsAs sensor networks grow remote programmability will become a more critical serviceMOAP is designed to be more energy and memory efficientWhile trading latencyRipple dissemination achieves significant reductions in traffic60-90% betterSliding Window performs adequately compared to more complex solutionsConclusions

OutlineIntroductionProblem DescriptionDesign DecisionsEvaluationConclusionsFuture WorkOutline

Future WorkSending differences between code versionsOnly transmit the differences between the codeNeed a bootloader to reconstruct the image in EEPROM before committing itResults in an even larger amount of energy savingsSupport for selective node updatesDont require every node to commit the code after receiving it.Intermediate nodes that are not interested just forward the image on.Future Work