A Remote Code Update Mechanism for Wireless Sensor Networks Thanos Stathopoulos, John Heidemann and...

A Remote Code Update Mechanism for Wireless Sensor Networks

Thanos Stathopoulos, John Heidemann and Deborah Estrin

CEG 790 Presentation

By: Trevor Smith

OutlineOutline

● IntroductionIntroduction

● Problem DescriptionProblem Description

● Design DecisionsDesign Decisions

● EvaluationEvaluation

● ConclusionsConclusions

● Future WorkFuture Work

OutlineOutline

What is Wireless Sensor NetworkWhat is Wireless Sensor Network

● Sensor networks integrate sensing, computing and Sensor networks integrate sensing, computing and

communicationcommunication

● Can be used for monitoring environmental changes, water Can be used for monitoring environmental changes, water

contamination, seismic activity or structural building integritycontamination, seismic activity or structural building integrity

● Sensor resource constraintsSensor resource constraints

– Low PowerLow Power

– Limited MemoryLimited Memory

– Short range, low power radiosShort range, low power radios

IntroIntro

Once Deployed What Happens?Once Deployed What Happens?

● After deployment, motes might not be accessible again?After deployment, motes might not be accessible again?

● Also, we can’t always predict full range of sensor actions or Also, we can’t always predict full range of sensor actions or

might not have a full set of environment knowledge.might not have a full set of environment knowledge.

● What is the solution? Reprogram!What is the solution? Reprogram!

● How do we handle post deployment reprogramming?How do we handle post deployment reprogramming?

● How do we deal with the limited mote resources (battery, How do we deal with the limited mote resources (battery,

memory, etc.)?memory, etc.)?

IntroIntro

SolutionSolution

● Remote Code Distribution MechanismRemote Code Distribution Mechanism

● Author proposes MOAP (Multihop Over-the-Air Programming)Author proposes MOAP (Multihop Over-the-Air Programming)

– Discuss different design alternatives: Data Dissemination Discuss different design alternatives: Data Dissemination

protocols, retransmission policies and storage managementprotocols, retransmission policies and storage management

– Design Goals? Focus on energy consumption, memory Design Goals? Focus on energy consumption, memory

usage and latencyusage and latency

● Compare with floodingCompare with flooding

IntroIntro

OutlineOutline







OutlineOutline

Code Distribution PropertiesCode Distribution Properties

● 100% of image must reach all nodes100% of image must reach all nodes

– Reliability mechanism requiredReliability mechanism required

● If image cannot fit into single packet, it must be kept in stable If image cannot fit into single packet, it must be kept in stable

storage until the transfer is completestorage until the transfer is complete

● Network lifetime should not be severely affectedNetwork lifetime should not be severely affected

● Memory and storage requirements should not severely affect the Memory and storage requirements should not severely affect the

space required by the normal operations of the devicespace required by the normal operations of the device

Prob Prob

Desc.Desc.

Resource PrioritizationResource Prioritization

● Energy is most important resourceEnergy is most important resource

– Radio transmission is expensiveRadio transmission is expensive

● Transmit 3x cost of RecieveTransmit 3x cost of Recieve

– Stable storage accessStable storage access

● Write is 1/8 the cost of transmitting the same number of Write is 1/8 the cost of transmitting the same number of

bytesbytes

● EEPROM is optimized for read operations and read is an EEPROM is optimized for read operations and read is an

order of magnitude cheaper than writeorder of magnitude cheaper than write

Prob Prob

Desc.Desc.

Resource PrioritizationResource Prioritization

● Memory Utilization is a close secondMemory Utilization is a close second

– Static RAM in specificStatic RAM in specific

● Only about 4K on current gen. MotesOnly about 4K on current gen. Motes

– Must keep in mind reprogramming isn’t the motes only Must keep in mind reprogramming isn’t the motes only

operationoperation

● Main Goal: Limit energy consumptionMain Goal: Limit energy consumption

– Optimizations aren’t freeOptimizations aren’t free

– Trade latency for battery optimizationTrade latency for battery optimization

– Is latency that important in reprogramming?Is latency that important in reprogramming?Prob Prob

Desc.Desc.

OutlineOutline







OutlineOutline

Dissemination ProtocolDissemination Protocol

● How is the data propagatedHow is the data propagated

● All nodes must be reachedAll nodes must be reached

● ConcurrentlyConcurrently

– FloodingFlooding

● Minimal state requirementsMinimal state requirements

● Low energy prioritizationLow energy prioritization

● Step by StepStep by Step

– Ripple (neighborhood-by-neighborhood)Ripple (neighborhood-by-neighborhood)

● SlowSlowDesign Design

DecisionsDecisions

AssumptionsAssumptions

Design Design

DecisionsDecisions

DefinitionsDefinitions

Design Design

DecisionsDecisions

Flooding Dissemination ProtocolFlooding Dissemination Protocol

● Flooding does a receive and forward type of mechanismFlooding does a receive and forward type of mechanism

– Once packet is received the node retransmits itOnce packet is received the node retransmits it

● Expected # of transmissions for the network is:Expected # of transmissions for the network is:

● The average time for node i at distance hThe average time for node i at distance hii from the source from the source

is:is:

Design Design

DecisionsDecisions

Flooding Dissemination ProtocolFlooding Dissemination Protocol

Design Design

DecisionsDecisions

1 1

2

2 2

3

3

23

4 5

4

5

4

5

Ripple Dissemination ProtocolRipple Dissemination Protocol

● Transfer data Neighborhood-by-NeighborhoodTransfer data Neighborhood-by-Neighborhood

– Neighborhood is all nodes in the broadcast domainNeighborhood is all nodes in the broadcast domain

– Single hopSingle hop

– Multihop handled recursivelyMultihop handled recursively

● Receiver will attempt to become a source after entire Receiver will attempt to become a source after entire

image is receivedimage is received

– Use PUBLISH-SUBSCRIBE mechanismUse PUBLISH-SUBSCRIBE mechanism

● Since a source is in the same networkSince a source is in the same network

– Require all repairs to be local (one hop away)Require all repairs to be local (one hop away)Design Design

DecisionsDecisions


Design Design

DecisionsDecisions


● Expected # of transmissions for the network is:Expected # of transmissions for the network is:

● kki i can be no more than (ocan be no more than (oi i / 2) + 1/ 2) + 1

● The average time for node i at distance hThe average time for node i at distance hii from the source from the source

is:is:

Design Design

DecisionsDecisions

Reliability MechanismReliability Mechanism● Requires 100% of image deliveryRequires 100% of image delivery

● Who is responsible for detecting lossWho is responsible for detecting loss

– Sender (ACK)Sender (ACK)

– Receiver (NACK)Receiver (NACK)

● NACK based approach cuts down on control trafficNACK based approach cuts down on control traffic

● Require repairs localRequire repairs local

– Neighbors will have entire image in due timeNeighbors will have entire image in due time

– Reduce complexity by not routing NACKsReduce complexity by not routing NACKs

● What is our Retransmission Policy?What is our Retransmission Policy?

– Broadcast or UnicastBroadcast or UnicastDesign Design

DecisionsDecisions

Retransmission PolicyRetransmission Policy● Broadcast RREQ, no suppressionBroadcast RREQ, no suppression

– SimpleSimple

– High Probability of ReceptionHigh Probability of Reception

– Highly InefficientHighly Inefficient

– Zero LatencyZero Latency

● Broadcast RREQ, suppression based on randomized timersBroadcast RREQ, suppression based on randomized timers

– EfficientEfficient

– ComplexComplex

– Reply if timer interval expires and no one else has Reply if timer interval expires and no one else has

repliedrepliedDesign AltsDesign Alts

Retransmission Policy (cont’d)Retransmission Policy (cont’d)

● Broadcast RREQ, fixed reply probability Broadcast RREQ, fixed reply probability

– SimpleSimple

– Good Probability of ReceptionGood Probability of Reception

– Latency depends on probability of replyLatency depends on probability of reply

– Avg efficiencyAvg efficiency

● Broadcast RREQ, adaptive reply probabilityBroadcast RREQ, adaptive reply probability

– More complex than static caseMore complex than static case

– Latency and reception similarLatency and reception similar

Design AltsDesign Alts

Retransmission Policy (cont’d)Retransmission Policy (cont’d)

● Unicast RREQ, single replyUnicast RREQ, single reply

– Has the smallest prob. of successful receptionHas the smallest prob. of successful reception

– Highest EfficiencyHighest Efficiency

– Simple, as long as source doesn’t failSimple, as long as source doesn’t fail

– Zero latency, if source doesn’t failZero latency, if source doesn’t fail


Segment ManagementSegment Management

● No IndexingNo Indexing

– Read EEPROM to find if segment is missingRead EEPROM to find if segment is missing

● Full IndexingFull Indexing

– Bitmap in RAM, if entry i in RAM is empty, segment i Bitmap in RAM, if entry i in RAM is empty, segment i

is missingis missing


RAM

EEPROM

Segment Management (cont’d)Segment Management (cont’d)

● Partial IndexingPartial Indexing

– Bitmap kept in RAMBitmap kept in RAM

– i/k and check if entry in RAM is empty or fulli/k and check if entry in RAM is empty or full

– If empty, need to do k consecutive reads to find If empty, need to do k consecutive reads to find

missing segmentmissing segment


RAM

EEPROM

Segment Management (cont’d)Segment Management (cont’d)● Hierarchical Full IndexingHierarchical Full Indexing

– First level map kept in RAM, points to a page in First level map kept in RAM, points to a page in

EEPROMEEPROM

– Consider EEPROM data to be same as physical page Consider EEPROM data to be same as physical page

sizesize

– i div m finds page, i mod m in particular page finds i div m finds page, i mod m in particular page finds

segmentsegment


RAM

Segment Management (cont’d)Segment Management (cont’d)

● Sliding WindowSliding Window

– Bitmap of up to w segments kept in RAMBitmap of up to w segments kept in RAM

– Limited out of order toleranceLimited out of order tolerance

– Last segment received starting point of windowLast segment received starting point of window


Base Offset

Segment Management ComparisonSegment Management Comparison


OutlineOutline







OutlineOutline

EmulationEmulation

● EmStar emulation environmentEmStar emulation environment

● 30 Mica1 Motes30 Mica1 Motes

– Attached via serial cablesAttached via serial cables

● Transmitted image consists of 100 segmentsTransmitted image consists of 100 segments

– 1 segment per packet1 segment per packet

● Methods using sliding windowMethods using sliding window

– Window size = 16bitsWindow size = 16bits

EvalEval

EmulationEmulation

● Neighborhood size vs Power settingNeighborhood size vs Power setting


Energy ConsumptionEnergy Consumption● Ripple w/ Sliding WindowRipple w/ Sliding Window

● Flooding w/ Sliding WindowFlooding w/ Sliding Window

● Ripple w/ Full IndexingRipple w/ Full Indexing

EvalEval

Energy ConsumptionEnergy Consumption

● Flooding hangs around 100 transmissionsFlooding hangs around 100 transmissions

– Changes to power settings doesn’t affect itChanges to power settings doesn’t affect it

● Ripple produces large power savings in terms of Ripple produces large power savings in terms of

transmissions...WHY?transmissions...WHY?

● Ripple w/ Full Indexing performs better for sparse Ripple w/ Full Indexing performs better for sparse

networksnetworks

– Dense networks savings isn’t sufficient to justify using Dense networks savings isn’t sufficient to justify using

Full IndexingFull Indexing

EvalEval

LatencyLatency

● As we stated earlierAs we stated earlier

– We will trade latency for power efficiencyWe will trade latency for power efficiency

EvalEval

LatencyLatency

● Tx rate of 2 packets/secTx rate of 2 packets/sec

● A faster Tx rate will note saturate the channel for rippleA faster Tx rate will note saturate the channel for ripple

– However it would increase the number of collisions in However it would increase the number of collisions in

flooding, resulting in more retransmissionsflooding, resulting in more retransmissions

● Again Ripple w/ Full Indexing performs better than Ripple Again Ripple w/ Full Indexing performs better than Ripple

w/ Sliding Windoww/ Sliding Window

EvalEval

Retransmission PoliciesRetransmission Policies● Using ripple w/ sliding windowUsing ripple w/ sliding window

– Compare broadcast vs unicastCompare broadcast vs unicast

● Why is Unicast less than BroadcastWhy is Unicast less than Broadcast

EvalEval

Retransmission PoliciesRetransmission Policies

● Unicast performs better than BroadcastUnicast performs better than Broadcast

● But what happens if the link fails in UnicastBut what happens if the link fails in Unicast

– Receiver must locate another sourceReceiver must locate another source

– Author proposes MAC to do link level retransmissionsAuthor proposes MAC to do link level retransmissions

EvalEval

Mote ImplementationMote Implementation

● 15 Mica2 Motes15 Mica2 Motes

● 100 segments, 1 segment per packet100 segments, 1 segment per packet

● Mica2 Motes have a stronger radio than the Mica1 motesMica2 Motes have a stronger radio than the Mica1 motes

– This results in better link qualities, fewer This results in better link qualities, fewer

retransmissions and more rapid change in retransmissions and more rapid change in

neighborhood sizeneighborhood size

● No Full Indexing scheme in TinyOSNo Full Indexing scheme in TinyOS

EvalEval

Mote ImplementationMote Implementation

● Retransmissions significantly smaller than emulationRetransmissions significantly smaller than emulation

● Power settings not as high eitherPower settings not as high either

EvalEval

MOAP ImplementationMOAP Implementation

● Ripple disseminations, Unicast retransmission and Sliding Ripple disseminations, Unicast retransmission and Sliding

Window segment ManagementWindow segment Management

● Code is split up via packetizerCode is split up via packetizer

● Nodes use link statistics mechanism Nodes use link statistics mechanism

– Don’t subscribe to sources that are lossy, intermittent Don’t subscribe to sources that are lossy, intermittent

or unreliableor unreliable

● Once complete image is stored, send PUBLISH messagesOnce complete image is stored, send PUBLISH messages

– If no SUBSCRIBERS commit code with bootloader to If no SUBSCRIBERS commit code with bootloader to

program memoryprogram memory

EvalEval

MOAP Implementation (cont’d)MOAP Implementation (cont’d)

● Active sourcesActive sources

– After predetermined time has passed and After predetermined time has passed and

retransmissions have been handled retransmissions have been handled

– Commit the codeCommit the code

● Nodes detect lost segments with sliding windowNodes detect lost segments with sliding window

– Retransmission have higher priority than Data packetsRetransmission have higher priority than Data packets

– Duplicate request suppressed Duplicate request suppressed

● Node keeps track of sources activity with a keep alive Node keeps track of sources activity with a keep alive

timertimer

EvalEval

MOAP Implementation (cont’d)MOAP Implementation (cont’d)

● Node keeps track of sources activity with a keep alive Node keeps track of sources activity with a keep alive

timertimer

– Solves NACK’s “Last Packet Problem”Solves NACK’s “Last Packet Problem”

– If source dies the keep alive timer will broadcast a If source dies the keep alive timer will broadcast a

repair requestrepair request

● Late joiner mechanism allows nodes that have just Late joiner mechanism allows nodes that have just

recovered from a failure to get the new version of coderecovered from a failure to get the new version of code

– This requires that nodes advertise their version This requires that nodes advertise their version

periodicallyperiodically

EvalEval

OutlineOutline







OutlineOutline

ConclusionsConclusions

● As sensor networks grow remote programmability will As sensor networks grow remote programmability will

become a more critical servicebecome a more critical service

● MOAP is designed to be more energy and memory MOAP is designed to be more energy and memory

efficientefficient

– While trading latencyWhile trading latency

● Ripple dissemination achieves significant reductions in Ripple dissemination achieves significant reductions in

traffictraffic

– 60-90% better60-90% better

● Sliding Window performs adequately compared to more Sliding Window performs adequately compared to more

complex solutionscomplex solutionsConclusionsConclusions

OutlineOutline







OutlineOutline

Future WorkFuture Work

● Sending differences between code versionsSending differences between code versions

– Only transmit the differences between the codeOnly transmit the differences between the code

– Need a bootloader to reconstruct the image in Need a bootloader to reconstruct the image in

EEPROM before committing itEEPROM before committing it

– Results in an even larger amount of energy savingsResults in an even larger amount of energy savings

● Support for selective node updatesSupport for selective node updates

– Don’t require every node to commit the code after Don’t require every node to commit the code after

receiving it.receiving it.

– Intermediate nodes that are not interested just forward Intermediate nodes that are not interested just forward

the image on.the image on.Future Future

WorkWork

A Remote Code Update Mechanism for Wireless Sensor Networks Thanos Stathopoulos, John Heidemann and...

Documents

Transcript of A Remote Code Update Mechanism for Wireless Sensor Networks Thanos Stathopoulos, John Heidemann and...