a remote code update mechanism for wireless sensor networks thanos stathopoulos, john heidemann and...

of 45 /45
A Remote Code Update Mechanism for Wireless Sensor Networks Thanos Stathopoulos, John Heidemann and Deborah Estrin CEG 790 Presentation By: Trevor Smith

Author: christal-crawford

Post on 04-Jan-2016




1 download

Embed Size (px)


  • 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


  • 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