Réseaux de capteurs sans fil - IRITRéseaux de capteurs sans fil: comment fournir la qualité de...

Réseaux de capteurs sans fil: comment fournir la qualité de service

tout en économisant l’énergie

Ye-Qiong SONG LORIA - Université de Lorraine

[email protected]

Ecole d’été temps réel 2013 Toulouse 30/08/2013

Context and motivation WSAN (Wireless Sensor and Actuator Networks) ! CPS (Cyber-Physical Systems)

Need of QoS for interacting with the physical world Need to minimize energy consumption since battery-powered wireless device Need self-adaptation protocols since highly dynamic multi-hop networks

Agenda   State of the art low-power MAC protocols (duty-cycle)   iQueue-MAC: a queue length-aware hybrid CSMA and

TDMA MAC protocol for traffic adaptive duty-cycle   Introduction to energy-aware QoS routing

Fixed duty-cycled MAC protocol IEEE802.15.4 standard, Beacon-enabled mode

t

inactive

CAP CSMA/CA

CFP GTS

active

inactive active CAP CFP

SD=960x2SOx16 BI = 960x2BOx16

-  Hierarchic: coordinator and simple nodes -  Duty-cycle fixed at configuration (SO and BO),

not self-adaptive to the traffic variation -  Static topology (Star, may be extended to cluster-

tree but need beacon scheduling), not scalable -  Rendezvous time between neighboring nodes is

not natively supported, needs synchronization -  There are works on scheduling GTS slots or

generally active periods (see P. Minet’s presentation)

Adaptive duty-cycled MAC protocols   A new key issue in duty-cycled MAC (unlike other non duty-

cycled MAC): finding rendezvous time between a sender and its receiver (or next hop forwarder)

  Most representative ones are: –  S-MAC and its improvement T-MAC, known as synchronous MAC,

which are with explicit synchronization mechanism of rendezvous time (i.e., both in active period) between a sender and its receiver, in order to forward its packet

–  B-MAC and X-MAC, know as asynchronous MAC, which use LPL (low power listening) to find rendezvous time (sender-initiated)

–  RI-MAC, which is also asynchronous MAC, but uses receiver-initiated LPP (low power probing) to find rendezvous time

S-MAC -  Each node listens, then broadcasts its own active/inactive schedule !

Synchronizer and followers in a cluster -  CSMA/CA with RTS/CTS (802.11) + adaptive listening -  Fixed duty-cycle, so does not self-adaptive -  high overheads: SYNC, RTS/CTS, active period > clock drift, all

nodes of a cluster must be active but not only sender-receiver " idle listening problem

B A C

!"#$% !" #$%& '!( ()*+"',*$ *- .#/ 01*'*/*+2 ,$ 3,1(+(22 2($2*1 $('3*142& # 2"1)(5 6

2789: ; <=:>?@AB;8?@C D>89E7@8 F:8:B;E:= EG: =;C: =:AH>:89: @D <=:>?@AB;8?@C 8>CI:B= D@B EG: =;C: <;B;C:E:B=J03A.#/ >E7K7L:= EG: I:;9@8 C:==;F: >=:? 78 1,A.#/ E@B:K;M EG:=: <;B;C:E:B=N OM K:;B878F 8:7FGI@B=P <=:>?@AB;8?@CD>89E7@8 <;B;C:E:B=J ; 8@?: 9;8 :;=7KM 9;K9>K;E: EG: D>E>B:Q;R:A>< E7C: @D ;8M 8:7FGI@B78F 8@?:N /K@9R ?B7DEJ G;B?Q;B:;8? @<:B;E78F =M=E:C K;E:89M C;M 9;>=: <B:?79E7@8 :BB@B=N# =:8?:B 78 03A.#/ EG>= ;?S;89:= 7E= Q;R:A>< IM ; E7C:<:B7@? EG;E 7= ;?T>=E:? ;99@B?78F E@ EG: 9K@9R ?B7DE B;E:N ,8;??7E7@8J 7D ; =:8?:B !8?= EG;E EG: <B:?79E7@8 :BB@B U?:!8:?;= EG: ?7DD:B:89: I:EQ::8 EG: :=E7C;E:? Q;R:A>< E7C: @D EG:E;BF:E B:9:7S:B ;8? EG: ;9E>;K Q;R:A>< E7C: @D EG: B:9:7S:BV7= FB:;E:B EG;8 ; EGB:=G@K?J EG: =:8?:B B:H>:=E= ;8 ><?;E: @DEG: <B:?79E7@8 =E;E:N 'G7= :8=>B:= EG;E EG: <B:?79E7@8 :BB@B 7=Q7EG78 EG: =:8?:B Q;R:A>< ;?S;89: E7C: =@ EG;E ; =:8?:B Q7KK8@E C7== EG: B:9:7S:BP= I:;9@8N/>BB:8EKMJ EG: <=:>?@AB;8?@C D>89E7@8 <;B;C:E:B= ;B: !W:?

D@B :;9G 8@?:N ,D EG:=: <;B;C:E:B= 8::? E@ I: ;?T>=E:? ;99@B?A78F E@ =@C: @<E7C7L;E7@8 C:9G;87=C=J C;78E;7878F 78D@BC;AE7@8 9@8=7=E:89: ;C@8F 8:7FGI@B= Q@>K? I: ; <B@IK:CN ,8 ;?A?7E7@8J 9@8=E;8E 9;K9>K;E7@8 @D 8:7FGI@B=P =9G:?>K:= 78EB@?>9:=>88:9:==;BM 9@C<>E78F @S:BG:;?J QG79G 9;>=:= ;??7E7@8;K:8:BFM 9@8=>C<E7@8 ;8? 78EB@?>9:= ?:K;M D@B @EG:B =M=E:C@<:B;E7@8=N # <:B7@?79 Q;R:A>< =9G:?>K: 78 #2A.#/ XYZ[ 7=:;=7:B E@ D@KK@Q I>E 8@?:=P =9G:?>K:= C>=E I: ?7=EB7I>E:? E@;S@7? 9@8=E;8E 9@KK7=7@8=N

&% '())#*+,8 EG7= =:9E7@8J Q: G;S: =>BS:M:? S;B7@>= Q;M= E@ :=E;IK7=G

9@CC>879;E7@8 I:EQ::8 EQ@ 8@?:= 78 ;=M89GB@8@>= .#/<B@E@9@K=N 'G: B:=:;B9G =E;BE= Q7EG >=78F K@8F <B:;CIK: E@Q;R: 8@?:= ><N 'G: <B:;CIK: =;C<K78F C:EG@? 7= !B=E 7CA<B@S:? Q7EG ; I:EE:B @>EK7:B ?:E:9E7@8 I;=:? //# ;KF@B7EGC;8? G;= I::8 =>FF:=E:? E@ ?:9@><K: ?;E; EB;8=C7==7@8 DB@C<B:;CIK: =;C<K78FN 2@@8 D@>B ;<<B@;9G:= G;S: I::8 <B@A<@=:? E@ B:?>9: 9@=E ;E B:9:7S:B= ;8? =:8?:B= ;= =G@Q8 78-7FN \N 'G: !B=E =@K>E7@8 7= E@ 789K>?: >=:D>K 78D@BC;E7@878 <B:;CIK:N 'G7= ;??B:==:= EG: @S:BG:;B78F <B@IK:C I>E=E7KK 78G:B7E= EG: ?B;QI;9R @D 9@8=>C78F 9G;88:K I;8?Q7?EGD@B <B:;CIK: EB;8=C7==7@8N 'G: @EG:B EGB:: C:EG@?= 789K>?:=9G:?>K: K:;B878FJ =M89GB@87L:? <@KK78FJ ;8? B:9:7S:BA787E7;E:?+00N #KK @D EG: EGB:: C:EG@?= B:?>9: EG: ;C@>8E @D E7C:; <;7B @D 8@?:= @99><M EG: Q7B:K:== C:?7>C I:D@B: EG:M;9E>;KKM :W9G;8F: ?;E;N ,8 EG: D@KK@Q78F =:9E7@8 Q: Q7KK?7=9>== EG: =M89GB@87L:? <@KK78FJ QG79G =G;B:= =7C7K;B7EM Q7EG=9G:?>K: K:;B878F 78 EG;E 8@?:= ;B: =M89GB@87L:? E@ ; 9@CC@8=9G:?>K:N !@Q:S:BJ 9@8E:8E7@8 78 =M89GB@87L:? <@KK78F 7= C@B:=:S:B: EG;8 EG;E 78 =9G:?>K: K:;B878F I:9;>=: ;KK 8@?:= EG;E;B: =M89GB@87L:? E@ ; 9@CC@8 =9G:?>K: =G;B: EG: Q7B:K:==C:?7>C 78 =M89GB@87L:? <@KK78F QG:B:;= @8KM =:S:B;K =:8?:B=;B: =M89GB@87L:? E@ EG: E;BF:E B:9:7S:BP= =9G:?>K: 78 =9G:?>K:K:;B878FN # F@@? 9@CI78;E7@8 78 ;=M89GB@8@>=.#/ <B@E@9@K=Q@>K? I: B:9:7S:BA787E7;E:? +00 Q7EG ;>E@A#/4 E@ EG: I:;9@8;8? ?7=EB7I>E:? Q;R:A>< =9G:?>K:J I>E G@Q E@ :8=>B: EG;E EG:I:;9@8 Q7KK 8@E I: C7==:? QG7K: C787C7L78F EG: 7?K: K7=E:878F7= <K;ED@BC ?:<:8?:8EN *89: 8@?:= 9;8 B:;9G :;9G @EG:B:D!97:8EKMJ C@B: :DD@BE= 9;8 I: <>E @8 EGB@>FG<>E 7C<B@S:C:8E;8? ?:K;M B:?>9E7@8N

!"#$%&'

()*+$,%-./+)0$1 23$$'

4.5.2678 2(99:

8;<%/=,+$,+)=,%!),>=! ?52<%?$@&$*+A+=A2$,> 852<%83$"BA+=A2$,>

.

C

8

4

8; ?52

852

852

852

?522DE2

4.5.

4.5. .8F

.8F

5B",*G)+ ?$/$)0$ H0$BI$"B

?52

?52 852

8528;

-7FN ]N 'G: ;?;<E7S: K7=E:878F 78 2A.#/N

,,,N 25$/!1*$*"2 .#/ 01*'*/*+2

,8 EG7= =:9E7@8 Q: =>CC;B7L: EG: B:9:8E ?:S:K@<C:8E= 78=M89GB@8@>= .#/ <B@E@9@K=N 2M89GB@87L78F ;9E7S: E7C: @D8:7FGI@B78F 8@?:= 7= ; 8;E>B;K =@K>E7@8 E@ :=E;IK7=G 9@CC>A879;E7@8 I:EQ::8 EQ@ 8@?:=N !@Q:S:BJ 7E IB78F= EG: 9@=E @D;??7E7@8;K =M89GB@87L;E7@8 @S:BG:;?N,8 =M89GB@8@>= .#/ <B@E@9@K=J ; 8@?: K7=E:8= E@ EG:

9G;88:K D@B ; 9:BE;78 ;C@>8E @D E7C:N ,D 7E ?@:= 8@E G:;B;8M =9G:?>K: DB@C @EG:B 8@?:=J 7E ?:E:BC78:= 7E= 8:WE Q;R:A>< E7C: ;8? IB@;?9;=E= 7E= =9G:?>K:N 'G7= C;R:= EG: 8@?:I:9@C: ; =M89GB@87L:BN ,D ; 8@?: B:9:7S:= ; =9G:?>K: DB@C; 8:7FGI@B I:D@B: 9G@@=78F 7E= @Q8 =9G:?>K:J 7E D@KK@Q= EG:B:9:7S:? =9G:?>K:J QG79G C;R:= 7E ; D@KK@Q:BN %:8:B;KKMJ 8@?:=D@BC 9K>=E:B= @D =:S:B;K G@<=N #KK 8@?:= 78 ; 9K>=E:B ;B:=M89GB@87L:? E@ ; =M89GB@87L:B EG;E 7= @8: @B ; D:Q G@<=;Q;MN ,D ; 8@?: B:9:7S:= ; ?7DD:B:8E =9G:?>K: ;DE:B 7E =:E= 7E=@Q8 =9G:?>K: U7N:NJ :7EG:B G;= IB@;?9;=E:? 7E= @Q8 =9G:?>K:@B D@KK@Q:? ; <B:S7@>=KM B:9:7S:? =9G:?>K:VJ 7E ;?@<E= I@EG =@EG;E 7E 9;8 I: ; IB7?F: I:EQ::8 EQ@ 9K>=E:B=N ,8 @EG:B Q@B?=JEG: 8@?: Q;R:= >< ;E E7C:= @D I@EG 7E= 8:7FGI@B78F 9K>=E:B ;8?7E= @Q8 9K>=E:BN#= =9G:?>K: K:;B878F 7= 78EB@?>9:? E@ ;=M89GB@8@>= .#/

<B@E@9@K=J EG: I@>8?;BM I:EQ::8 =M89GB@8@>= .#/ ;8? ;=M8A9GB@8@>= .#/ FB;?>;KKM I:9@C:= D>LLMN # C;78 ?7DD:BA:89: 7= EG;E @8KM =:8?:B= Q;R: >< ;E EG: E;BF:E B:9:7S:BP=<@KK78F^<B@I78F E7C: 78 <B:?79E7@8 78E:FB;E:? ;=M89GB@8@>=.#/ <B@E@9@K= QG7K: ; 9K>=E:B @D 8@?:= Q;R: >< ;E EG: =;C:E7C: 78 =M89GB@8@>= .#/ <B@E@9@K=N 'G: 9@CC@8 ;9E7S:<:B7@? 7= 8@E B:=:BS:? D@B ; =78FK: B:9:7S:BN ,E 7= =G;B:? IM ;KK8@?:= 78 EG: 9K>=E:B ;8? EG:M C>=E 9@8E:8? D@B 9G;88:K ;99:==N,8 @EG:B Q@B?=J =M89GB@8@>= .#/ <B@E@9@K= B:H>7B: K@9;K E7C:=M89GB@87L;E7@8 QG7K: ; 8@?: 78 ;=M89GB@8@>= .#/ <B@E@9@K=9G@@=:= 7E= =9G:?>K: 78?:<:8?:8EKM Q7EG@>E ;Q;B:8:== @D 7E=8:7FGI@B=P =9G:?>K:=N2M89GB@8@>= .#/ <B@E@9@K= ?@ 8@E D;9: EG: <B@IK:C @D

:=E;IK7=G78F 9@CC>879;E7@8 I:EQ::8 8@?:= ;= ;=M89GB@8@>=.#/ <B@E@9@K=N 'G:B:D@B:J C@=E ?:=7F8= D@9>= @8 7C<B@S78FEGB@>FG<>E ;8? B:?>978F ?:K;MN 'G:M ;B: C@B: ;<<B@<B7;E: D@B;<<K79;E7@8= @D <:B7@?79 EB;D!9 QG:B: EG: Q;R:A>< =9G:?>K: 7=:;=M E@ ?:E:BC78:N

,% ,-#."/0! 1/2"!3/34# 9K;==79;K =M89GB@8@>= .#/ <B@E@9@K 7= !"#$% X__[J

QG:B: 8@?:= ;B: @BF;87L:? 78E@ 9K>=E:B= IM K@9;K E7C: =M89GB@A

!"#$%&'(#)*+%"&$%,++-%&))+.(+/%01'%#-)*2$#1-%#-%&%02(2'+%#$$2+%10%("#$%312'-&*4%51-(+-(%#$%0#-&*%&$%.'+$+-(+/6%7#("%("+%+8)+.(#1-%10%.&9#-&(#1-4

Figure from Huang et al. [7]

D

T-MAC improves S-MAC

!"#$%&"&!'()*+,&#$%&

•  !-./0(',&.11&()00.2)0&'/&3+-0,0&*4&5.-'.31)&1)/2,6&./7&01))8&3),9))/&3+-0,0&

•  :;/<6-*/'=.>*/&0'('1.-&,*&:"#$%&3+,&-)7+<)0&,6)&1'0,)/'/2&8)-'*7&'4&/*&.<>5',;&'0&7),)<,)7&

Delayed TX ! Assume re-TX !

T-MAC (Timeout-MAC) extends S-MAC and provides improvements: -  Shorten the listening period if no activity is detected -  Use a timeout (TA) after each data packet transmission. So if more

packets to transmit, they can be transmitted in a burst. -  Adaptive duty-cycle -  T-MAC saves more energy, but increases delay

B-MAC and X-MAC B-MAC and X-MAC: principle

LPL Receiver

t

Long preamble

LPL Sender Send data

t

Extended waiting time

Receive data

Periodic wake up

Listen for queued packets

X-MAC Receiver

t

Short preambles with address (strobes) X-MAC Sender Send data

t

ACK

Receive data

Periodic wake up

Periodic wake up

Periodic wake up

Periodic wake up

Send early ACK

Check interval

Preamble > check interval

ContikiMAC

Receiver

t

Repeated data packets until ACK Sender

data

t

ACK

Rcv data

Periodic wake up 2 CCA

Periodic wake up 2 CCA

Periodic wake up

ContikiMAC is similar to X-MAC and B-MAC, but repeatedly sends data packets instead of preamble strobes

data ACK

Optimization through phase-lock: after a succesful tx, sender learned receiver’s wake-up period (inspired from WiseMAC). Rmk:Broadcast is sent with repeated data packets for the full wake-up interval

data

Design consideration: sources of MAC energy wasting   Overhearing: To receive a packet a neighboring node should keep

waking up during long preamble in LPL, even if it is not the intended receiver. Overhearing results in wasted energy.

  Idle Listening: Another source of wasting energy occurs when a node has its radio on, listening to the medium while there are no transmissions.

  Collision: lead to useless transmissions, and retransmission of collided packets

  Control packet overheads (RTS/CTS, ACK, packet header)   Low channel utilization (bad QoS): during collision avoidance of

CSMA/CA, random backoff period reduces channel utilization and consumes energy (idle listening)

B-MAC and X-MAC B-MAC and X-MAC: discussions

-  Adaptive duty-cycle, more scalable than synchronous MAC (e.g. S-MAC and T-MAC) and less e2e delay

-  Energy efficiency -  B-MAC: long preamble and overhearing problems -  B-MAC: length of check interval (too long increases preamble, so

overhearing, collision, delay; too short increases idle listening) -  X-MAC: with slightly increased idle listening and Destination address

embedded in preamble (strobes), it reduces preamble and overhearing, but prevent to send to multiple next hop nodes (less robust routing)

-  Preamble period prevents other neighboring nodes from transmission " low channel utilization and longer delay

-  Hidden node collisions still exist -  Both suffer from intrinsic CSMA/CA low throughput when dealing with burst

traffic

Problems of LPL (e.g. X-MAC): Low channel utilization & hidden node collision

5

!"#$%&'()*$++&'(&#(,&*-.-//(0-#/1*(2-341*5/

ConvergecastBroadcast

6

6-.$3-7(,1*5

! X-MAC, uses short preambles to find rendezvous time

! X-MAC in TinyOS UPMA package (X-MAC-UPMA)

7

8*19.-%/

! This preamble occupies the medium for much longer than actual data

! Blocks transmissions from neighbors

8

8*19.-%/

! Preambles from hidden nodes continue colliding for a long time

! Wastes time/energy, accomplishes nothing5

!"#$%&'()*$++&'(&#(,&*-.-//(0-#/1*(2-341*5/

ConvergecastBroadcast

6

6-.$3-7(,1*5

! X-MAC, uses short preambles to find rendezvous time

! X-MAC in TinyOS UPMA package (X-MAC-UPMA)

7

8*19.-%/

! This preamble occupies the medium for much longer than actual data

! Blocks transmissions from neighbors

8

8*19.-%/

! Preambles from hidden nodes continue colliding for a long time

! Wastes time/energy, accomplishes nothingFigures from [Sun et al., RI-MAC, SenSys2008]

Improve throughput/delay with receiver-initiated LPP (Low Power Probing): RI-MAC principle •  Transmitter wakes up and waits silently for the intended receiver •  Each node periodically wakes up and broadcasts a beacon after sensing idle

medium, with sleep intervals randomly chosen from [0.5×interval, 1.5×interval] for avoiding beacon collisions

•  Upon receiving a beacon from intended receiver, the transmitter starts DATA transmission

•  A beacon serves both as an acknowledgment to previously received DATA and as a request for the initiation of the next DATA transmission to this node (for queued other packets of the sender)

! "### $%&&'("$)*"%(+ +',-#.+ / *'*%,")0+1 )$$#2*#3 4%, 2'50"$)*"%(

!

"

#

$

%&'()*+, -./.+0.

$12)34&,25&.'*67.28+,32,'&9.,2'::&.))

$ $ $ $ $

$

;$

$

!#<

!#< ;!%!

;!%!

!/,+0.

,

,

,

,

4678 98 ": ;<=>?@A B=@CD?E@ ;CDBE6:71 ;F>=< B=@CD?E@; >GGHBI <F@ J6=@E@;;D@A6HD H:<6E <F@ AC<C BCGK@< 6; A@E6L@=@A8

<> <=C:;D6< AC<C BCGK@<; <> <F@ =@G@6L@=8 &HE<6BE@ :>A@; DCIFCL@ AC<C M>= <F@ =@G@6L@=8 ): @M!G6@:< G>EE6;6>: =@;>EL6:7D@GFC:6;D 6; <FH; :@@A@A8 "M C :>A@ A>@; :>< =@G@6L@ C:I<F6:7M>= C G@=<C6: CD>H:< >M <6D@ CM<@= 6< ?=>CAGC;<; C ?@CG>:1 6<7>@; ?CGK <> ;E@@B8 *F@ CALC:<C7@ >M <F@ =@G@6L@=N6:6<6C<@A0>J 2>J@= 2=>?6:7 O022P A@;67: 6; <FC< <F@ GFC::@E 6; LCGC:<M>= H;@ ?@M>=@ <F@ <C=7@< =@G@6L@= 6; =@CAI <> =@G@6L@8 *F@6A@C >M ;F6M<6:7 G>DDH:6GC<6>: 6:6<6C<6>: M=>D <F@ ;@:A@= ;6A@<> <F@ =@G@6L@= ;6A@ 6; @C=EI B=@;@:<@A 6: !"#$! QRST C:A@DBE>I@A 6: %&"% QU!T M>= 6:M=C;<=HG<H=@ :@<J>=K;1 '()*)QUVT1 +,-.+# QUWT1 !"-.+# QUST1 C:A +-.+# QXYT M>=7@:@=CE ;@:;>= :@<J>=K;8 ZF@: C :>A@ ?=>CAGC;<; C ?@CG>:1D>=@ <FC: >:@ >M 6<; :@67F?>=; DCI =@;B>:A J6<F C AC<C BCGK@<8,"N&)$ =@;>EL@; G>EE6;6>:; ?I =@H;6:7 <F@ ?@CG>: D@;;C7@;C:A CEE>J; ?CGKN<>N?CGK AC<C <=C:;D6;;6>:8$>:;6A@=6:7 <FC< <F@ <=CM!G 6; E67F< D>;< >M <F@ <6D@ 6: C

;@:;>= :@<J>=K1 ,"N&)$ E@<; C :>A@ ?=>CAGC;< C ?C;@ ?@CG>:D@;;C7@ J6<F :> ?CGK>MM !@EA JF@: 6< JCK@; HB8 ); C =@;HE<1:@67F?>=6:7 :>A@; GC: ;<C=< AC<C <=C:;D6;;6>: <> <F@ :>A@6DD@A6C<@EI8 *F6; 6; >B<6D6[@A M>= E67F< <=CM!G E>CA ;G@:C=6>;JF@=@ <F@=@ 6; >:EI >:@ ;@:A@= D>;< >M <F@ <6D@8 ':A@= F@CLI<=CM!G E>CA1 G>EE6;6>:; DCI >GGH= C:A <F@ =@G@6L@= ?=>CAGC;<;C:><F@= ?@CG>: D@;;C7@ <FC< 6:GEHA@; C ?CGK>MM J6:A>J !@EA8(@67F?>=6:7 :>A@; J6EE ?CGK >MM =C:A>DEI CGG>=A6:7 <> <F@=C:A>D ?CGK>MM J6:A>J ;6[@ 6:A6GC<@A 6: <F@ :@J ?@CG>:D@;;C7@8 ZF@:@L@= C G>EE6;6>: 6; A@<@G<@A CM<@= C ?@CG>:1<F@ =@G@6L@= 6:G=@C;@; <F@ ?CGK>MM J6:A>J ;6[@ 6: C 56:C=I#\B>:@:<6CE 5CGK>MM O5#5P JCI H:<6E <F@ DC\6DHD J6:A>J;6[@ 6; =@CGF@A8 5@GCH;@ :@67F?>=6:7 :>A@;] G>:<@:<6>:; C=@;I:GF=>:6[@A ?I @CGF ?@CG>:1 G>EE6;6>: 6; ;<6EE <F@ DC^>=MCG<>= <FC< ?>H:A; <F@ <F=>H7FBH<8 ": CAA6<6>:1 >L@=F@C=6:7 C<=C:;D6;;6>: DCI 6:G>==@G<EI <=677@= <F@ =@G>L@=I D@GFC:6;D1E@CA6:7 <> D>=@ =@AH:AC:< ?@CG>:; C:A <F@: D>=@ G>EE6;6>:;8*> =@AHG@ G>EE6;6>:;1 ,$N&)$ QXRT H<6E6[@; <F@ <=@@ ;<=HG<H=@M>=D@A AH=6:7 AC<C 7C<F@=6:7 <> ;GF@AHE@ <F@ <=C:;D6;;6>:>M DHE<6BE@ :>A@;8 ):><F@= 6DB=>L@D@:< HB>: ,"N&)$ 6;<> A@L6;@ C B=@A6G<6>: D@GFC:6;D M>= @;<6DC<6:7 :@67F?>=;]JCK@NHB <6D@ C; 6:<=>AHG@A 6: 2ZN&)$ QXUT8 ,@G@:<EI1 +-.+# QXYT ;F>J; <FC< ?I @:C?E6:7 CH<>NCGK:>JE@A7@D@:< <>

!

"

"

%&'()*+, -./.+0.

"126.'/4(

"

" ;!%!

;!%!

!/,+0.

,

,

"

"

4678 _8 ": E>J B>J@= B=>?6:71 C ;@:A@= A>@; :>< >GGHBI <F@ J6=@E@;; D@A6HDH:<6E <F@ =@G@6L@= 6; =@CAI <> =@G@6L@8

<F@ ?@CG>: D@;;C7@1 C :>A@ 6; C?E@ <> `H6GKEI A@<@=D6:@JF@<F@= <F@=@ 6; C BCGK@< M>= 6<8

!" #$%&'$ ()**+,+)- +- #$'$+.$/ 0-+1+21$% 3/2-,4+,,+)-+6:G@ ;@:A@=; C=@ =@`H6=@A <> JCK@ HB ?@M>=@ =@G@6L@=;1

!#-.+# QXRT G>>=A6:C<@; DHE<6BE@ ;@:A@=;] <=C:;D6;;6>:; ?IB677I?CGK6:7 C ;GF@AHE6:7 D@;;C7@1 JF6GF ;B@G6!@; <F@ :>A@<FC< GC: <=C:;D6< HB>: =@G@6L6:7 <F@ D@;;C7@1 <> C: )$a8*F@ D@<F>A =@E6@; >: <FC< C AC<C 7C<F@=6:7 <=@@ @\6;<; >= 6;M>=D@A AH=6:7 =>H<@ A6;G>L@=I8 %: <F@ <=@@ ;<=HG<H=@1 C BC=@:<=@G@6L@; BCGK@<; M=>D DHE<6BE@ GF6EA=@: C:A M>=JC=A; BCGK@<;<> 6<; >J: BC=@:<8 ) BC=@:< CGK:>JE@A7@; 6<; GF6EA=@: J6<F C:)$a D@;;C7@ <FC< 6:A6GC<@; JF6GF GF6EA 6; <F@ :@\< ;@:A@=8*F@=@M>=@1 <F@ ;GF@AHE@A GF6EA GC: <=C:;D6< 6DD@A6C<@EI <>=@AHG@ EC<@:GI C:A ;6?E6:7 :>A@; J6EE ?CGK >MM <> CL>6AG>EE6;6>:;8 5I E@C=:6:7 <F@ ?C:AJ6A<F A@DC:A; >M GF6EA=@:1 CBC=@:< CA^H;<; <F@ GFC::@E CGG@;; >BB>=<H:6<6@; 6: CGG>=AC:G@J6<F <F@6= A@DC:A; ;> <FC< MC6=:@;; 6; @:;H=@A8 ,$N&)$CE;> @\BE6G6<EI 6:<@==HB<; <F@ ;GF@AHE6:7 >M C BC=@:<NGF6EA=@:H:6< ;> C; <> @:;H=@ <FC< :> H:6< GC: >GGHBI <F@ GFC::@E@\GEH;6L@EI8 *F@ ;GF@AHE6:7 =>H:A >M C H:6< 6; AI:CD6GCEEICA^H;<@A CGG>=A6:7 <> <F@ BC=@:<]; =@DC6:6:7 ?HMM@= ;6[@1 JF6GF?CEC:G@; <F@ GFC::@E CGG@;; >BB>=<H:6<6@; CD>:7 H:6<;8*F@ E>GCE ;GF@AHE6:7 D@<F>A =@AHG@; G>EE6;6>:; C:A 6:N

G=@C;@; <F=>H7FBH< 6: C ?C;6G BC=@:<NGF6EA=@: H:6<8 *F@ G>:N<@:<6>: CD>:7 H:6<;1 F>J@L@=1 ;67:6!GC:<EI CMM@G<; <F@ B@=NM>=DC:G@8 ,$N&)$ =@E6@; >: @\BE6G6< ?CGKN>MM <> =@AHG@6:<@==HB<6>: >M ;GF@AHE6:7 GCH;@A ?I G>:<@:<6>: CD>:7 H:6<;8$>@\6;<@:G@ >M H:6<; 6: C A@:;@ :@<J>=K1 F>J@L@=1 ;<6EE =@DC6:;C K@I 6;;H@8 &HE<6GFC::@E A@;67: 6; C B=>D6;6:7 ;>EH<6>: M>=CAA=@;;6:7 6:<@=M@=@:G@ CD>:7 H:6<;8

5" 6,1+421$ 17$ 829$:&; 3+4$ )< #$'$+.$/)E<F>H7F 022 6:G=@C;@; GFC::@E H<6E6[C<6>:1 >:EI <F@ =@N

G@6L@= ?@:@!<; M=>D <F@ =@G@6L@=N6:6<6C<@A A@;67:8 *F@ ;@:A@=FC; <> ;<CI CJCK@ H:<6E <F@ AC<C BCGK@<; C=@ A@E6L@=@A8 *>=@AHG@ @:@=7I G>:;HDB<6>: >M ;@:A@=;1 %/-.+# QXUT 6:<=>NAHG@; C D@<F>A <> B=@A6G< <F@ <C=7@< =@G@6L@=]; JCK@NHB <6D@;> <FC< C ;@:A@= >:EI :@@A; <> JCK@ HB ;E67F<EI ?@M>=@ <F@<C=7@< =@G@6L@=8 *F@ D><6LC<6>: 6; ;CD@ C; <FC< >M Z6;@&)$QU_T1 ?H< 2ZN&)$ CEE>J; :>A@; <> 6:A@B@:A@:<EI 7@:@=C<@B;@HA>N=C:A>D ;GF@AHE@;1 JF6GF CL>6A; B@=;6;<@:< G>EE6;6>:;GCH;@A ?I <J> ;6D6EC= JCK@NHB ;GF@AHE@;8 *F@ G>EE6;6>: GC:CE;> ?@ CL>6A@A ?I A6;<=6?H<6:7 :>A@;] ;GF@AHE@; C; 6:<=>AHG@A6: +,-.+# QUWT1 ?H< 2ZN&)$ CEE>J; <> H;@ LC=6C?E@ JCK@NHB 6:<@=LCE;8

!"#$%&'(#)*+%"&$%,++-%&))+.(+/%01'%#-)*2$#1-%#-%&%02(2'+%#$$2+%10%("#$%312'-&*4%51-(+-(%#$%0#-&*%&$%.'+$+-(+/6%7#("%("+%+8)+.(#1-%10%.&9#-&(#1-4

Figures from [Huang et al., IEEE communications survey and tutorials, 2013]

BDATA

DATA

B

B B

B

R

S

Node sends a beacon when it wakes up

Wake up to send and wait for beacon

Start data transmission upon receving R’s beacon

Node sends a beacon but goesto sleep since no incoming DATA

Figure 3: Overview of RI-MAC. Each node periodically wakesup and broadcasts a beacon. When node S wants to send aDATA frame to node R, it stays active silently and starts DATAtransmission upon receiving a beacon from R. Node S laterwakes up but goes to sleep after transmitting a beacon framesince there is no incoming DATA frame.

Hardware Preamble

Frame Length

FCF FCSSrc DstBW

RI-MAC-Specific

Figure 4: The format of an RI-MAC beacon frame for an IEEE802.15.4 radio. Dashed rectangles indicate optional fields. TheFrame Length, Frame Control Field (FCF), and Frame CheckSequence (FCS) are fields from IEEE 802.15.4 standard.

and X-MAC when the senders are hidden to each other, which canbe common in ad hoc sensor networks. As discussed in Section 3.4,after transmitting a beacon, a receiver detects collisions within theduration of the backoff window specified in the beacon, which ismuch shorter than the delay of a sleep interval needed in B-MACand X-MAC.RI-MAC also reduces overhearing, as a receiver expects incom-

ing data only within a small window after beacon transmission. To-gether with the lower cost for detecting collisions and recoveringlost DATA frames, RI-MAC achieves higher power efficiency, es-pecially when the network load increases. Even under light trafficload, which is the worst case for RI-MAC for power efficiency,RI-MAC still shows comparable performance to X-MAC in oursimulation and experimental evaluation onMICAzmotes. RI-MACstill decouples the sender’s and receiver’s duty cycle schedules asdo B-MAC and X-MAC, which removes the overhead of synchro-nization compared to synchronous duty cycle MAC protocols.

3.2. Beacon FramesA beacon frame in RI-MAC always contains a Src field, which isthe address of the source transmitting node of the beacon. We calla beacon with only a Src field a base beacon. A beacon can also in-clude two optional fields, depending on the roles the beacon serves:Dst, for destination address, and BW, for backoff window size. TheRI-MAC beacon frame format for an IEEE 802.15.4 radio is illus-trated in Figure 4 as an example.A node that receives a beacon can determine which fields are

present in the beacon by looking at the size of the beacon; with anIEEE 802.15.4 radio, size of a beacon is saved in the Frame Lengthfield. A beacon in RI-MAC can play two simultaneous roles: as anacknowledgment to previously received DATA, and as a request forthe initiation of the next DATA transmission, as illustrated in Fig-ure 5. After node R wakes up and senses clear medium, R transmitsa base beacon. If the medium is busy, R does a backoff and attemptsto transmit the beacon later. After receipt of the first DATA framefrom S in the figure, in the following beacon transmission by R, theDst field is set to S to indicate that this beacon also serves as theacknowledgment for the DATA received from S. Similar to ACK

BDATA

DATA

DATA

DATA

B B

B B BR

S

Transmit upon receiving the acknowledgment beacon

Send an acknowledgment beacon

Dwell time

Figure 5: The dual roles of a beacon in RI-MAC. A beaconserves both as an acknowledgment to previously received DATAand as a request for the initiation of the next DATA transmis-sion to this node.

transmission in IEEE 802.11, transmission of this acknowledgmentbeacon starts after SIFS delay, regardless of medium status. Nodesother than S ignore the Dst field in the beacon and treat it as a re-quest for the initiation of a new data transmission. The use of theBW field in a beacon is discussed in detail in Section 3.4.The duty cycle in RI-MAC is controlled by a parameter called

the sleep interval, which determines how often a node wakes upand generates a beacon to poll for pending DATA frames. Supposea sleep interval of L is used in some WSN. After a node generatesa beacon, the interval before the next beacon generation is set toa random value between 0.5!L and 1.5!L. In this way, we at-tempt to minimize the possibility that beacon transmissions fromtwo nodes become coincidentally synchronized.

3.3. Dwell Time for Queued PacketsAfter successfully receiving a DATA frame, a node remains activefor some extra time in order to allow queued packets to be sentto it immediately, as shown in Figure 5. We refer to this time asthe dwell time. Unlike in X-MAC, where the dwell time is set toa fixed value of the maximum backoff window, the dwell time inRI-MAC adapts to the number of contending senders. The durationof the dwell time is defined as the BW value from the last beaconplus SIFS and the maximum propagation delay. Since the BW ina beacon is automatically adjusted based on channel collisions ob-served by a node as discussed in detail next, so is the dwell time.The fewer contending senders and thus the fewer collisions, theshorter the dwell time. This self-adaptation helps RI-MAC usingthe shortest waiting time possible under light channel contentionwhile avoiding collisions under heavy channel contention.

3.4. DATA Frame Transmissions fromContending Senders

The challenges in handling transmissions from an unpredictablenumber of contending senders are twofold:

• minimize the active time of a receiver for power efficiency;and

• minimize the cost for collision detection and recovery of lostdata, whether or not senders are hidden to each other.

To meet these goals in RI-MAC, a receiver employs beaconframes to coordinate DATA frame transmissions from contendingsenders, as shown in Figure 6. The BW field in a beacon speci-fies the backoff window size senders should use when they contendfor the medium. If a received beacon does not contain a BW field(i.e., a base beacon), senders for this receiver should start transmit-ting DATA without backing off. If a beacon contains a BW field,each sender does a random backoff using the BW as the backoff

Improve throughput/delay in RI-MAC

9

!"#$%&'(!)*)+,)-#".+/+0/)1($%&(

! Each node periodically wakes up and broadcasts a beacon after sensing idle medium ! Sleep intervals randomly chosen from [0.5!interval, 1.5!interval]

! Transmitter wakes up and waits for the intended receiver

! Upon receiving a beacon from intended receiver, the transmitter starts DATA transmission

!"#$%&'()*+',--%)'."/%)

!"#$%&'(()"!"#$%&'(()"!"#$%&'(()"!"#$%&'(()"

*)+)',)"*)+)',)"*)+)',)"*)+)',)" !

!

!

! "#$#

"#$# time

! Receiver acknowledges the DATA with another beacon

10

!"#$%&(234,)5(60-4+)-(7-384)95

! Improves channel utilization

!Reduces the time a pair of nodes occupy the medium to reach a rendezvous time

11

!"#$%&(234,)5(60-4+)-(7-384)95

! Reduces collisions caused by hidden nodes

12

!)*)+,)-#&3./-344)1(:0*;3<< =+.13>

! Beacon specifies backoff window size to be used by a transmitter before DATA transmission

!Transmitter picks backoff delay over this range

! Receiver increases the backoff window size in beacons using binary exponential backoff

9

!"#$%&'(!)*)+,)-#".+/+0/)1($%&(

! Each node periodically wakes up and broadcasts a beacon after sensing idle medium ! Sleep intervals randomly chosen from [0.5!interval, 1.5!interval]

! Transmitter wakes up and waits for the intended receiver

! Upon receiving a beacon from intended receiver, the transmitter starts DATA transmission

!"#$%&'()*+',--%)'."/%)

!"#$%&'(()"!"#$%&'(()"!"#$%&'(()"!"#$%&'(()"

*)+)',)"*)+)',)"*)+)',)"*)+)',)" !

!

!

! "#$#

"#$# time

! Receiver acknowledges the DATA with another beacon

10

!"#$%&(234,)5(60-4+)-(7-384)95

! Improves channel utilization

!Reduces the time a pair of nodes occupy the medium to reach a rendezvous time

11

!"#$%&(234,)5(60-4+)-(7-384)95

! Reduces collisions caused by hidden nodes

12

!)*)+,)-#&3./-344)1(:0*;3<< =+.13>

! Beacon specifies backoff window size to be used by a transmitter before DATA transmission

!Transmitter picks backoff delay over this range

! Receiver increases the backoff window size in beacons using binary exponential backoff

Figures from [Sun et al., RI-MAC, SenSys2008]

Reduces the time a pair of nodes occupy the medium to reach a rendezvous time

Reduces preamble collisions caused by hidden nodes

Problem of LPP: multi-sender collision

DATA DATA

DATA

DATA

DATA

DATA DATA

B B B

B BB B

B B B BR

S1

S2

Beacon containing a larger backoff window

Collision Backoff

Figure 6: DATA frame transmission from contending sendersin RI-MAC. For the first beacon, the receiver R requestssenders (here, S1 and S2) to start transmitting DATA imme-diately upon receiving the beacon. If a collision is detected, Rsends another beacon with increased BW value to request thatsenders do a backoff before their next transmission attempt.

window size over which to choose the actual backoff. The receiverincreases the value of the BW field upon detecting collisions.If a node cannot start data transmission as soon as it receives a

beacon, prior to actual DATA transmission, a sender should makesure that the medium has been idle for at least Tp time using CCA(clear channel assessment) checks. The CCA checks prevent asender from starting DATA transmission while the intended receiveris generating an acknowledgment beacon to a DATA frame just re-ceived from another sender. The time Tp here is set to SIFS plus themaximum propagation delay. If a node needs more time to generateand send an acknowledgment beacon, such as a software ACK usedin TinyOS, Tp should be increased correspondingly, as described inSection 3.8.After waking up, a node always broadcasts a base beacon with

no BW field. We made this design choice to optimize RI-MAC forthe most common cases of a typical WSN where there is light orno traffic most of the time. By enforcing all senders with pend-ing DATA frames to transmit immediately, we attempt to minimizetime for the node to determine whether or not there is incomingDATA. The shorter this duration, the less energy is used at eachwakeup. In this way, we attempt to minimize energy consump-tion if the network is idle most of the time. The duration can bevery short, as it is the the maximum round trip propagation delayplus radio switch delay (SIFS in IEEE 802.15.4). If the receiverdetects no channel activity within this duration, the receiver goesto sleep immediately. Although a base beacon could lead to con-current DATA transmissions to a same receiver, we found that theydo not necessarily lead to collisions in our experimental implemen-tation on MICAz motes [6], due to the presence of capture effectin the CC2420 radio [4]. This feature makes it possible for onesender to successfully transmit a packet to the receiver even if thetransmission overlaps with others, especially when senders havedifferent distances to the receiver (and thus different received sig-nal strengths) [16, 17].

3.5. Collision Detection and RetransmissionsBy coordinating DATA frame transmissions at receivers, RI-MACgreatly reduces the cost for detecting collisions and recovering lostDATA frames compared to B-MAC and X-MAC. As a sendercan transmit DATA frame only upon receiving a beacon, and sincethe backoff window size is explicitly controlled by the intendedreceiver, the receiver knows the maximum delay before a DATAframe’s arrival. This delay can be calculated from the BW valuein the previous beacon. The receiver need only detect the Startof Frame Delimiter (SFD) to learn of an incoming frame. Ifno SFD is detected in time, while some channel activity is de-tected by the CCA (clear channel assessment) check, the receiver

BDATA

DATAB

BB

B BR

S

Initial beacon

Beacon sent on request from S’s beacon

Figure 7: RI-MAC beacon-on-request. When node S wakes upfor transmitting a pending DATA frame, it sends a beacon withthe Dst field set to the destination of the pending DATA. If thedestination node R is already active, R in response transmits abeacon to enable S to begin DATA transmission immediately.

will decide that there was a collision and will generate anotherbeacon with a larger BW value. In RI-MAC, this new beaconis transmitted after the longest possible DATA transmission hasfinished so that all senders’ radios are already in receive mode.Prior to transmitting the beacon, a node does a random backoffto avoid possible repeated collisions with beacons from anothernode.After detecting a collision, a receiver calculates the new BW

value that will be used in the next beacon, by employing somebackoff strategy such as binary exponential backoff (BEB) in IEEE802.11 or Sift [14,21], depending on the density of a network. BEBis used in our implementation in TinyOS, as we found it adapts tonetworks of different densities and resolves collisions efficiently inRI-MAC in our evaluations.As RI-MAC initiates transmissions at the receiver, retransmis-

sion in RI-MAC is significantly different from that in sender-initiated approaches such as IEEE 802.11. In RI-MAC, a receiverplays the major role in retransmission control by managing the tim-ing and number of beacon transmissions. If the BW value hasreached the maximum backoff window size, or if the receiver keepsdetecting collisions after a number of consecutive beacon transmis-sions, the receive goes to sleep without further attempts. The cor-responding senders also become involved in retransmission con-trol, because a sender could miss receiving a beacon either be-cause of collisions or poor channel conditions. Thus, a sendermaintains a retry count for each DATA frame. If no beacon hasbeen received from the intended receiver within a time span 3times as long as the sleep interval, the sender increases the cur-rent retry count by 1. In addition, the sender increases this retrycount if no acknowledgment beacon is received within the maxi-mum backoff window after the sender transmitted a DATA framefollowing receipt of a beacon. When the retry count reaches a pre-defined retry limit, the sender cancels the transmission of the DATAframe.

3.6. Beacon-on-RequestIt is possible that the intended receiver node for some sender is al-ready active when the sender wakes up to transmit a DATA frameto it. An optimization, called beacon-on-request, is for this sender,after waking up for DATA transmission, to broadcast a beacon fol-lowing a CCA check, as illustrated in Figure 7. In this beacon, thesender S sets the Dst field to the receiver’s address, R. If the receiverR happens to be active, it generates a beacon in response after somerandom delay longer than the BW announced in the received bea-con from S. This beacon generated by the receiver on request ofthe sender allows the sender to transmit the pending DATA frameimmediately, rather than waiting until the next scheduled beacontransmission by R.

•  At light traffic, only one sender has data to send following a receiver’s beacon

•  At heavy traffic, several senders may have data to send, provoking collisions just after a receiver’s beacon

RI-MAC for reducing multi-sender collision

13

!"#"$%"&'()*+&),,"-./0#1)22 3$*-)4

! Reduces collision recovery cost

!A receiver detects collisions quickly and controls retransmissions

14

!5'67(.8%0,90+$)*

! ns-2 simulation-based evaluation:

!Clique networks

!Grid networks

!Random networks

! TinyOS-based implementation and evaluation:

!Clique networks

!Networks with hidden nodes

15

! Radio parameters

! MAC protocol parameters

! 1-second duty cycle interval; 28-byte DATA frames

:$;9,0+$)*.<0&0;"+"&=

16

(,$>9".?"+4)&1=.

! Independent flows that do not share end nodes

! Packet generation interval is randomly chosen from [0.5, 1.5] seconds for each flow

S1

R1

S2

R2

S3

R3

S4

R4

•  RI-MAC uses “collision detection” and sends BEB backoff window length in the next beacon

•  Transmitters randomly select their backoffs within the BEB backoff window (BW)

Figure from [Sun et al., RI-MAC, SenSys2008]

“Collision detection” in RI-MAC   Collision detection is generally unfeasible in radio

transmission due to the tx/rx exclusion (a turn around latency is also necessary between tx #" rx modes)

  In RI-MAC, “collision detection” is feasible –  The receiver knows that data should arrive during backoff

window (set to a constant+random(0,0) at beginning) –  The receiver needs only detect the Start of Frame Delimiter

(SFD) to learn of an incoming packet. If no SFD is detected in time (during BW), while some channel activity is detected by the CCA check, the receiver will decide that there was a collision, and will generate another beacon with a larger BW value

LPP vs LPL, and insufficiency   RI-MAC has similar low duty cycle than X-MAC at light (or idle) traffic load   RI-MAC outperforms X-MAC at heavy traffic load   But the channel utilization (throughput) is still far from optimal one because of

the use of random backoff window

13

!"#"$%"&'()*+&),,"-./0#1)22 3$*-)4

! Reduces collision recovery cost

!A receiver detects collisions quickly and controls retransmissions

14

!5'67(.8%0,90+$)*

! ns-2 simulation-based evaluation:

!Clique networks

!Grid networks

!Random networks

! TinyOS-based implementation and evaluation:

!Clique networks

!Networks with hidden nodes

15

! Radio parameters

! MAC protocol parameters

! 1-second duty cycle interval; 28-byte DATA frames

:$;9,0+$)*.<0&0;"+"&=

16

(,$>9".?"+4)&1=.

! Independent flows that do not share end nodes

! Packet generation interval is randomly chosen from [0.5, 1.5] seconds for each flow

S1

R1

S2

R2

S3

R3

S4

R4

Figure from [Sun et al., RI-MAC, SenSys2008]

Wasted channel (collision + resolution)

RI-MAC vs. X-MAC

Ack+ProbeProbe Data

Receiver

Sender

Figure 1: Receiver-initiated radio duty cycling. The sender wakesup and awaits a data probe. Upon receiving a probe, the data packetis sent. Both nodes turn off their radios after the acknowledgement.

transmission is due to link fluctuations, packet collisions, or badwake up synchronization. The sender therefore repeatedly trans-mits the same data packet until it is acknowledged, or until it timesout after a full wake-up interval.

Receiver-initiated duty-cycling protocols use data probes; nodeswake up periodically and probe for incoming data with a probetransmission. Neighbors that want to send data wake up just be-fore they expect the data probe, and immediately transmit theirdata upon receiving such a probe, see Figure 1. The subsequentacknowledgement also serves as another data probe, enabling sev-eral data packets to be transmitted in a single wake-up. In contrastto sender-initiated protocols, receiver-initiated protocols do not re-peatedly transmit radio packets if the data packet is lost. Therefore,compared to sender-initiated protocols, receiver-initiated protocolsmay offer lower congestion and higher throughput [9].

Duty-cycling mechanisms such as WiseMAC [10] and X-MAC [6]configure their wake-up intervals high enough to avoid collisions,but as low as possible not to waste energy on waking up when thereis no data to be received. Another set of protocols additionallyadapt their wake-up intervals throughout network operation to ac-commodate for varying traffic loads [1, 15].

2.2 Traffic PeaksTraffic load variations are common in sensor networks. If all traf-

fic flows in a network are static and known a priori, for instance byhaving fixed packet transmission schedules and time synchroniza-tion in a network, radio duty-cycling overhead can be minimizedto a great extent [7]. Such networks are, however, uncommon. Bycontrast, many networks inherently induce traffic peaks. Consideran event-driven network, such as an alarm network, that lays dor-mant for an extended period of time until an event occurs. Upondetecting the event, several nodes simultaneously report it, caus-ing a sudden burst of network traffic [17]. Other common reasonsfor temporarily increased network traffic include network code up-dates [21], and bulk downloads of sensor data [18].

Traffic peaks occur also in periodic data collection networks.The introduction of a new node causes neighbor discovery servicesto temporarily generate more network traffic [3]. Moreover, thenetwork topology can change rapidly due to bursty links, generat-ing further traffic [34]. Even in stable collection networks, a routerthat forwards data from other nodes will experience traffic peaks,due to randomness in data generation and forwarding times.

2.3 Collisions in Duty-Cycled NetworksTraffic peaks increase the risk of radio collisions in a duty-cycled

network. Data collisions occur when multiple transmissions arriveat a receiver simultaneously, causing data loss and retransmissions.The risk of data collisions is aggravated in duty-cycled networks,since a receiver is awake less, and thus has fewer opportunities toreceive data. Data collisions do not necessarily cause data loss;if one transmission is stronger than all others the receiver maystill successfully decode it. This phenomenon is called capture ef-fect [20]. Several protocols have exploited it, e.g., for fast flood-ing [22].

1

10

1 10 100

Rec

eive

d da

ta (k

bit/s

)

Transmitted data (kbit/s)

Receiver-initiated (RI-MAC)Sender-initiated (X-MAC)

Figure 2: Receiver-initiated MAC protocols outperform sender-initiated in networks with hidden terminals and high traffic, sincethe sender-initiated network is flooded with colliding data packets.

Most low-power protocols are designed to cope with data colli-sions to some extent; typically using random backoff times beforeattempting to retransmit a packet to a busy receiver. However, innetworks with bursty traffic, backoff mechanisms result in high la-tency and energy costs, since data packets may again collide at thereceiver when they are retransmitted.

We perform a simple experiment that demonstrates how randombackoff behaves in a congested network, using both a receiver-initiated and a sender-initiated protocol. The experiment is per-formed on the TWIST testbed [14], where a large set of neigh-bors send data to a single node, causing severe network conges-tion. Figure 2 shows that, as expected, the receiver-initiated net-work (RI-MAC) achieves a significantly higher receiver goodputthan the sender-initiated network (X-MAC). This is due to packetfloods in the sender-initiated network: when a lost data packet isnot acknowledged by the receiver, the sender floods the networkfor a full wake-up interval (1 second), causing further data colli-sions. This experiment shows that receiver-initiated protocols havebetter performance than sender-initiated protocols in severely con-gested networks, and that random backoff does not fully avoid datacollisions. Indeed, although the sender-initiated protocol should re-frain from transmitting when it detects ongoing transmissions, datacollisions still occur due to hidden terminals.

2.4 Hidden TerminalsThe hidden terminal problem occurs when two or more nodes

that are outside each others’ communication ranges send data tothe same receiver. Data transmissions may therefore collide at thereceiver without the senders noticing; the nodes are hidden to eachother. RTS/CTS schemes have long been used to mitigate the hid-den terminal problem [36]. Data transmissions are preceded bya transmission request message (RTS). If the medium is availableand the transmission is granted (CTS), any potentially interferingneighbor refrains from accessing the medium for the duration ofthe data transmission.

In the context of low-power wireless, however, traditional RT-S/CTS protocols have been shown to induce a high overhead. Po-lastre et. al. show that an RTS/CTS mechanism can have an over-head of several hundred percent in low-power networks with smalldata payloads [27]. In receiver-initiated protocols, the problems oftraditional RTS/CTS-based protocols are further aggravated: due tothe implicit sender-synchronization by data probes, the RTS mes-sages themselves collide at the receiver.

3. STRAWMANStrawman is a contention resolution mechanism designed for

receiver-initiated radio duty-cycling protocols. Upon detecting datapacket collisions, Strawman dynamically and instantaneously en-ables increased network capacity by quickly receiving data fromseveral neighbors, and has otherwise zero overhead.

[Fig. from F. Osterlind et al., Strawman, IPSN2012]

In general, receiver-initiated MAC (LPP) outperforms sender-initiated MAC(LPL) in presence of hidden terminals and high traffic, since the sender-initiated network is flooded with colliding data packets. But one can notice that RI-MAC still cannot reach the ideal throughput of TDMA!

Queue-MAC and iQueue-MAC iQueue-MAC is a queue-length aware hybrid CSMA/TDMA MAC protocol for providing dynamic adaptation to traffic and duty-cycle variation in wireless sensor networks. It combines Queue-MAC and CoSenS [B. Nefzi, YQ. Song, Adhoc networks2012, S. Zhuo, YQ. Song et al, WFCS2012, SECON2013]

Main ideas: -  Use CSMA in light traffic, switch to TDMA in

heavy traffic (similar to Z-MAC) -  Designed for 2-level hierarchical (or cluster-tree)

networks: routers and simple nodes -  A simple node only wakes up when it has data to

send, so in sleeping mode during most of time to save energy

-  Router (like receiver in RI-MAC) executes iQueue-MAC scheme

Basic background on CSMA and TDMA   In general, CSMA is more efficient in light traffic,

while TDMA is better in heavy traffic

load

throughput

TDMA

CSMA

100%

100%

iQueue-MAC

nodes. We first give out the basic idea of iQueue-MAC and then present different aspects of the design. Implementation details are revealed in section 4, and we confirm the benefits of the new MAC by showing experimental results in section 5.

3.1 Basic Idea

! """""#$%&'()*"+*,(-. /+

! /+)0123

! #$%&'()*"+*,(-. /+

45-'6"%55-&%'*."'-"67*&(8(&"6*$.*,6

/-$'*$'(-$"+*,(-.

)%,(%95*"0123"7*,(-.

!*%&-$

0,%88(&"($&,*%6*

:;<

:=<

(>?*?*@23/

A'B*,"23/

4?7*,8,%C*"&D&5*

+,-5-$E*."/+"

F igure 1: Basic idea of iQueue-M A C Figure 1 shows the basic idea of iQueue-MAC. Most

duty-cycle MACs schedule an access window, the contention period (CP) in Figure 1, in the superframe cycle for simple nodes to transmit their packets [12][13]. When traffic grows, existing solutions prolong the CP period to grant for more transmissions (method (1) in Figure 1). However, as traffic loads may vary, how long the receiver should stay awake is not easy to determine. Moreover, during high traffic periods, fierce contention and retransmissions increase as multiple senders may compete for accessing the channel at the same time. Conversely, a pure TDMA solution schedules guaranteed slots to each sender but has the shortcoming of idle-listening during light traffic periods, leading to great power waste.

iQueue-MAC adopts a hybrid CSMA/TDMA mecha-nism to tackle those difficulties (method (2) in Figure 1). Instead of prolonging the CP period, iQueue-MAC allocates an extra variable TDMA period (vTDMA) within the inactive period to enhance throughput. Simple nodes first apply in CP for extra transmission slots if they have pending packets. Then a router allocates requested number of slots to those senders in the vTDMA period. To realize this in an energy-efficient way, a sender node piggybacks its queue length value onto every data packet. The router checks the queue length information upon receiving a data packet. If the queue length value is none zero, the router allocates the corresponding slots to the specific sender in the next cycle. In this way, iQueue-MAC dispatches packets in the TDMA phase as soon as packet queuing starts to build up, leading to short queue length and short packet delay. Moreover, iQueue-MAC has high energy-efficiency by transforming most of the communication into a slot-organized TDMA round.

The key issues of designing iQueue-MAC are described next, namely packet modification, the superframe structure and slot allocation.

3.2 Packet Modification To enable slots allocation, we slightly modify the packet

structure at the MAC layer. As shown in Figure 2, a one byte variable called queue indicator is set as the first byte of the packet payload without violating the existing IEEE802.15.4 standard [10].

!"#$%&'!"()*"+,-.'/0-1

23%3%'45+4#"&*6

F igure 2: M A C packet structure

The value of the queue indicator equals the number of buffered packets currently in the sender�s forwarding queue. By examining the value of the queue indicator, any receiver of the data packet can know how many packets the sender still holds for further transmission and thus enables accurate bandwidth allocation. For instance, node_1 has 5 packets in its queue and succeeds in sending one packet to router A, carrying a queue indicator of 4. After extracting the queue indicator, router A then allocates 4 slots to node_1 to dispatch its pending packets in the next frame cycle.

3.3 Superframe Structure Routers in the network broadcast beacons independently

to divide time into repeating superframes. As depicted in Figure 3, a superframe is comprised of beacon period, Subframe period, CP and TP (Transmitting Period).

! 0123"65-'6 4+ /+ 0+

4?9F,%C*

F igure 3: Superframe st ructure Subframe consists of two parts: vTDMA (variable

TDMA period) and SP (Sleeping Period). The vTDMA period consists of slots allocated to node devices while SP occupies the rest of Subframe period. During SP, a router sleeps most of the time but still waking up periodically according to a predefined wake-up interval to check for potential preamble packets from other routers (dotted lines in the SP period). When there is no traffic, Subframe consists of only SP. When traffic grows, more slots will be allocated accordingly, resulting in longer vTDMA and shorter SP. Before every superframe cycle, the Subframe duration is set to a random value with a predefined average S and varying between 0.5*S and 1.5*S to beacons beacons collisions.

CP follows the Subframe and works as the access window for nodes. Nodes that have pending packets contend for transmission using CSMA/CA mechanism in CP. With the piggybacked queue indicator, the role of the sent out packets in CP is twofold: on one hand, it is a normal data packet; on the other hand, it informs the router

In iQueue-MAC, router (receiver) collects queue-length information of their associated simple nodes and dynamically allocates time slots to them (during variable length TDMA period). This allows to avoid the inherent low throughput problem of CSMA

iQueue-MAC


3.1 Basic Idea

! """""#$%&'()*"+*,(-. /+

! /+)0123

! #$%&'()*"+*,(-. /+

45-'6"%55-&%'*."'-"67*&(8(&"6*$.*,6

/-$'*$'(-$"+*,(-.

)%,(%95*"0123"7*,(-.

!*%&-$

0,%88(&"($&,*%6*

:;<

:=<

(>?*?*@23/

A'B*,"23/

4?7*,8,%C*"&D&5*

+,-5-$E*."/+"







!"#$%&'!"()*"+,-.'/0-1

23%3%'45+4#"&*6





! 0123"65-'6 4+ /+ 0+

4?9F,%C*





3.1 Basic Idea

! """""#$%&'()*"+*,(-. /+

! /+)0123

! #$%&'()*"+*,(-. /+

45-'6"%55-&%'*."'-"67*&(8(&"6*$.*,6

/-$'*$'(-$"+*,(-.

)%,(%95*"0123"7*,(-.

!*%&-$

0,%88(&"($&,*%6*

:;<

:=<

(>?*?*@23/

A'B*,"23/

4?7*,8,%C*"&D&5*

+,-5-$E*."/+"







!"#$%&'!"()*"+,-.'/0-1

23%3%'45+4#"&*6





! 0123"65-'6 4+ /+ 0+

4?9F,%C*




Piggybacking queue length to inform router

Each router defines a superframe, with a subframe inside rand(0.5L, 1.5L) -  B: Beacon broadcast to synchronize the simple nodes and announce slot allocation and

when starts the CP -  SP: sleeping period, with regular short wakeups to detect neighboring routers’

preamble (like X-MAC) -  CP: contention period where each simple node may transmit only one packet. Router

continue to listen with a time-out to allow other nodes to send if any (like T-MAC) -  TP: transmission period: router sends its first packet with preamble, then in burst

mode the following (like T-MAC and RI-MAC) to the forwarder router

When there are data, simple node waits for beacon, sends during CP or TDMA

iQueue-MAC

to allocate slots for pending packets. To reduce the contention in CP, every node is restricted to send at most one packet in this period, with remaining packets kept in the queue for the following vTDMA phase. Packets that arrive in the meanwhile are held for the next superframe.

The duration of the CP period is also variable as in T-MAC [13]. Each router adjusts the CP to cope with the end of channel activity by extending CP duration to a certain amount upon every packet reception. CP has a minimum length L as:

2* cca CW dataL L L L� � �

where ccaL is the time for a CCA execution, CWL is the

length of the largest contention window, and dataL is the time for an intact data packet reception.

A router burst transmits collected packets to the next hop in TP using LPL (low power listening) technique [14][15]. When the CP ends, the router first sends out a sequence of preamble packets as in X-MAC [15] to inform the next hop router. The first preamble packet is sent out using CSMA for collision avoidance while other following preambles are not. Once acknowledged by preamble-ACK, a router transmits all its buffered packets to the receiver in a burst. In case a router collects no packets in a superframe, there will be no TP period as router has no packet to forward.

3.4 Slots A llocation Considering an extreme light traffic case where very few

nodes report data, which is also a common scenario in WSNs. As the traffic load is low, the CP period can handle all the scattered packets. Also, as no slots are allocated, there is no vTDMA period in the Subframe. Both routers and nodes sleep most of the time to save power.

When a sudden event is detected, nodes in the surrounding area may turn into intensive senders simultaneously and cause the traffic to grow significantly. Packet queuing starts to occur due to limited throughput. And by extracting the piggybacked queue indicator byte from every received data packet, a router knows exactly how many slots should be allocated to each sender to serve the increasing traffic load.

Every router maintains two lists: an ID list recording IDs of senders that have been allocated slots, and a Slot Allocating list for recording the numbers of the allocated slots. A router assesses slots allocation upon every packet reception, removes the node�s ID from ID list if the queue indicator instructs 0, or adds more slots if needed. The router merges the two lists into the beacon before sending it out, as shown in Figure 4.

!"#$"% &'()*+ ,($"*+ -./'0*) &'()/1''(2#)0(3/'0*)

F igure 4: Beacon structure

Upon receiving the beacon, a node checks for allocated slots and their locations. It first finds out its sequence K in the ID list. Then it can easily figure out the number of allocated slots [ ]slotsN K and the starting time of its slots

period [ ]startT K :

[ ] _ _ [ ]slotsN K Slot Alocation list K� ;

1

1

[ ] * [ ]K

start slot slotsi

T K Size N i�

�

� � ;

where slotSize is the size of a TDMA slot. Then the node

sleeps until [ ]startT K and transmits its pending packets back to back in its allocated slots. In case that the node finds no slots are allocated to it, it continues trying to send its packet during CP. On the other hand, if the node still finds itself with pending packets at the end of its slots period, it skips the contention in CP by knowing that it should have been allocated slots in the next superframe cycle. This execution further relieves the contention in CP by ticking out an additional number of contenders.

45

,/6

,/7

.

.

4

4

. 1

1

. 1

1

89 4

4

4

. .

. . . .

. . . . . . .

&:;<=%#>"/9"%0($ ?(3)"3)0(3/9"%0($/@?9A 4"#2(3/2(3)#0303B/#/8.C1/*'()*/*2D"$:'03B/'0*)

4"#2(3

.#)#/E#2F")1?G

.

F igure 5: An example run of iQueue-M A C

Figure 5 shows an example run of iQueue-MAC. Both N1 and N2 have multiple data packets to send. After receiving the router�s first beacon, each of them sends out one packet during the CP of the first superframe after the generation of the packets and then retreat from CP. By checking the queue indicator of the received data packet, router R schedules 3 slots for N1 and 4 slots for N2 in the next cycle. Each node waits for the second beacon that contains a schedule list, finds the allocated slots period and sends out all the scheduled packets in a burst. Slot A llocation Strategy: Assuming that one TDMA slot is just sufficient for one single packet transmission with ACK confirm, we use a flat strategy in slots allocation: the number of allocated slots for a node is proportional to its current queue indicator value. For a given Subframe duration sub frameL � , the number of available slots N is bounded to a maximum value M:

1_ _ [ ]

ksub frame

i slot

LN Slot Alocation list i M

Size�

�

� �� Beacon structure:

to allocate slots for pending packets. To reduce the contention in CP, every node is restricted to send at most one packet in this period, with remaining packets kept in the queue for the following vTDMA phase. Packets that arrive in the meanwhile are held for the next superframe.

The duration of the CP period is also variable as in T-MAC [13]. Each router adjusts the CP to cope with the end of channel activity by extending CP duration to a certain amount upon every packet reception. CP has a minimum length L as:

2* cca CW dataL L L L� � �

where ccaL is the time for a CCA execution, CWL is the

length of the largest contention window, and dataL is the time for an intact data packet reception.

A router burst transmits collected packets to the next hop in TP using LPL (low power listening) technique [14][15]. When the CP ends, the router first sends out a sequence of preamble packets as in X-MAC [15] to inform the next hop router. The first preamble packet is sent out using CSMA for collision avoidance while other following preambles are not. Once acknowledged by preamble-ACK, a router transmits all its buffered packets to the receiver in a burst. In case a router collects no packets in a superframe, there will be no TP period as router has no packet to forward.

3.4 Slots A llocation Considering an extreme light traffic case where very few

nodes report data, which is also a common scenario in WSNs. As the traffic load is low, the CP period can handle all the scattered packets. Also, as no slots are allocated, there is no vTDMA period in the Subframe. Both routers and nodes sleep most of the time to save power.

When a sudden event is detected, nodes in the surrounding area may turn into intensive senders simultaneously and cause the traffic to grow significantly. Packet queuing starts to occur due to limited throughput. And by extracting the piggybacked queue indicator byte from every received data packet, a router knows exactly how many slots should be allocated to each sender to serve the increasing traffic load.

Every router maintains two lists: an ID list recording IDs of senders that have been allocated slots, and a Slot Allocating list for recording the numbers of the allocated slots. A router assesses slots allocation upon every packet reception, removes the node�s ID from ID list if the queue indicator instructs 0, or adds more slots if needed. The router merges the two lists into the beacon before sending it out, as shown in Figure 4.

!"#$"% &'()*+ ,($"*+ -./'0*) &'()/1''(2#)0(3/'0*)

F igure 4: Beacon structure

Upon receiving the beacon, a node checks for allocated slots and their locations. It first finds out its sequence K in the ID list. Then it can easily figure out the number of allocated slots [ ]slotsN K and the starting time of its slots

period [ ]startT K :

[ ] _ _ [ ]slotsN K Slot Alocation list K� ;

1

1

[ ] * [ ]K

start slot slotsi

T K Size N i�

�

� � ;

where slotSize is the size of a TDMA slot. Then the node

sleeps until [ ]startT K and transmits its pending packets back to back in its allocated slots. In case that the node finds no slots are allocated to it, it continues trying to send its packet during CP. On the other hand, if the node still finds itself with pending packets at the end of its slots period, it skips the contention in CP by knowing that it should have been allocated slots in the next superframe cycle. This execution further relieves the contention in CP by ticking out an additional number of contenders.

45

,/6

,/7

.

.

4

4

. 1

1

. 1

1

89 4

4

4

. .

. . . .

. . . . . . .

&:;<=%#>"/9"%0($ ?(3)"3)0(3/9"%0($/@?9A 4"#2(3/2(3)#0303B/#/8.C1/*'()*/*2D"$:'03B/'0*)

4"#2(3

.#)#/E#2F")1?G

.

F igure 5: An example run of iQueue-M A C

Figure 5 shows an example run of iQueue-MAC. Both N1 and N2 have multiple data packets to send. After receiving the router�s first beacon, each of them sends out one packet during the CP of the first superframe after the generation of the packets and then retreat from CP. By checking the queue indicator of the received data packet, router R schedules 3 slots for N1 and 4 slots for N2 in the next cycle. Each node waits for the second beacon that contains a schedule list, finds the allocated slots period and sends out all the scheduled packets in a burst. Slot A llocation Strategy: Assuming that one TDMA slot is just sufficient for one single packet transmission with ACK confirm, we use a flat strategy in slots allocation: the number of allocated slots for a node is proportional to its current queue indicator value. For a given Subframe duration sub frameL � , the number of available slots N is bounded to a maximum value M:

1_ _ [ ]

ksub frame

i slot

LN Slot Alocation list i M

Size�

�

� ��

Example: N1 has 4 and N2 has 5 packets

iQueue-MAC performance (measurement on implementation)

The router stops scheduling new slots once N is equal to M and k represents the number of nodes with queued packets. M ulti-channel Operation: iQueue-MAC reduces contention by utilizing multi-channel technique in the vTDMA period. We assume that a channel scheduling algorithm allocates non-overlapping sub-channels to different routers in a local area, but the channel allocation problem is out of scope of this paper. The beacon contains the router�s sub-channel sequence and each node switches to the defined sub-channel before transmission in the vTDMA period. After the vTDMA period, all nodes and the router switch back to the public channel.

3.5 Discussion By using the hybrid CSMA/TDMA mechanism, we can

deal with varied traffic conditions in an efficient way. When the network is with light traffic, it is sufficient to use CP to handle all the rarely generated packets. As traffic grows, iQueue-MAC enhances its throughput immediately by allocating extra slots into the Subframe period. CP actually absorbs only a small part of the traffic load and mostly acts as a signaling mechanism to inform the router to setup the following TDMA period, which will handle most of the transmissions. As almost all the slots are allocated based on queue-length requests, no slot is wasted. Thus iQueue-MAC maintains high energy-efficiency. On the other hand, iQueue-MAC allocates slots as soon as buffering emerging, thus achieving immediate throughput enhancement and guaranteeing short packet delay.

4. IPL E M E N T A T I O N We have successfully implemented iQueue-MAC on

IEEE.802.15.4 standard STW32W108 chips [11], and conducted numerous experiments for intensive evaluation. For comparison, we also implemented CoSenS and RI-MAC, and extended RI-MAC with multi-channel operation. We refer to this RI-MAC implementation as RI-MAC-MC. Except for the first beacon broadcast on the public channel, the RI-MAC-MC router guides the following communication procedure onto its sub-channel. CoSenS does not use multi-channel technique.

For iQueue-MAC and RI-MAC-MC, we assume the existence of a channel allocation algorithm at the initiating stage of the network. However, at this point we actually predefine non-overlapping sub-channels to different routers.

To explore iQueue-MAC�s performance under different scenarios, we set up two sample experiments and a general one, all of them on real world test-beds. In the first sample experiment, we test the performance of the different MACs in a wide range of traffic loads, while in the second sample experiment, we measure how different MACs react to sudden traffic bursts. We simulate a real-world general application scenario with a 46 nodes test-bed in the last experiment. Key MAC parameters are shown in Table 1

.Table 1: K ey M A C Protocol Parameters iQueue-MAC CoSenS RI-MAC-MC

Mean Subframe 500ms 500ms 500ms (sleep interval)

Minimum CP 15ms 6ms -

Slot size 5ms - -

Max retry 5 (in CP) 5 (in WP) 5

Multichannel Yes No Yes

Data packet size is always 120 bytes, and the slot size in the experiment is set to 5ms to grant one packet transmission. An actually larger minimum CP value is used in iQueue-MAC as we found that it seems to yield the best performance in numerous experiments. Available IEEE802.15.4 channels from channel 11th to channel 21th are used in iQueue-MAC and RI-MAC-MC.

5. E XPE RI M E N T A L R ESU L TS 5.1 Adapting To Varying T raffic Loads. Setting.We set up a simple test bed that contains one router and 10 simple nodes as depicted in Figure 6. Each node continuously generates up to 500 data packets and sends them to the router, and the router further relays those packets to the sink node. Each experimental run lasts for 800 seconds. By varying the data rate from 1packet/1500ms to 1packets/100ms, we measured the performance of the three MACs.

!"#$

%&'()*

F igure 6: Sample experiment topology

Results:

F igure 7: Average delay comparison of first experiment

1234567891011121314150

1

2

3

4

5

6

7

8

9

10x 104

Data Rate - 1 packet / X 100ms

Adve

rage

Pac

ket D

elay

- m

s

CoSenSRI-MAC-MCiQueue-MAC

The router stops scheduling new slots once N is equal to M and k represents the number of nodes with queued packets. M ulti-channel Operation: iQueue-MAC reduces contention by utilizing multi-channel technique in the vTDMA period. We assume that a channel scheduling algorithm allocates non-overlapping sub-channels to different routers in a local area, but the channel allocation problem is out of scope of this paper. The beacon contains the router�s sub-channel sequence and each node switches to the defined sub-channel before transmission in the vTDMA period. After the vTDMA period, all nodes and the router switch back to the public channel.

3.5 Discussion By using the hybrid CSMA/TDMA mechanism, we can

deal with varied traffic conditions in an efficient way. When the network is with light traffic, it is sufficient to use CP to handle all the rarely generated packets. As traffic grows, iQueue-MAC enhances its throughput immediately by allocating extra slots into the Subframe period. CP actually absorbs only a small part of the traffic load and mostly acts as a signaling mechanism to inform the router to setup the following TDMA period, which will handle most of the transmissions. As almost all the slots are allocated based on queue-length requests, no slot is wasted. Thus iQueue-MAC maintains high energy-efficiency. On the other hand, iQueue-MAC allocates slots as soon as buffering emerging, thus achieving immediate throughput enhancement and guaranteeing short packet delay.

4. IPL E M E N T A T I O N We have successfully implemented iQueue-MAC on

IEEE.802.15.4 standard STW32W108 chips [11], and conducted numerous experiments for intensive evaluation. For comparison, we also implemented CoSenS and RI-MAC, and extended RI-MAC with multi-channel operation. We refer to this RI-MAC implementation as RI-MAC-MC. Except for the first beacon broadcast on the public channel, the RI-MAC-MC router guides the following communication procedure onto its sub-channel. CoSenS does not use multi-channel technique.

For iQueue-MAC and RI-MAC-MC, we assume the existence of a channel allocation algorithm at the initiating stage of the network. However, at this point we actually predefine non-overlapping sub-channels to different routers.

To explore iQueue-MAC�s performance under different scenarios, we set up two sample experiments and a general one, all of them on real world test-beds. In the first sample experiment, we test the performance of the different MACs in a wide range of traffic loads, while in the second sample experiment, we measure how different MACs react to sudden traffic bursts. We simulate a real-world general application scenario with a 46 nodes test-bed in the last experiment. Key MAC parameters are shown in Table 1

.Table 1: K ey M A C Protocol Parameters iQueue-MAC CoSenS RI-MAC-MC

Mean Subframe 500ms 500ms 500ms (sleep interval)

Minimum CP 15ms 6ms -

Slot size 5ms - -

Max retry 5 (in CP) 5 (in WP) 5

Multichannel Yes No Yes

Data packet size is always 120 bytes, and the slot size in the experiment is set to 5ms to grant one packet transmission. An actually larger minimum CP value is used in iQueue-MAC as we found that it seems to yield the best performance in numerous experiments. Available IEEE802.15.4 channels from channel 11th to channel 21th are used in iQueue-MAC and RI-MAC-MC.

5. E XPE RI M E N T A L R ESU L TS 5.1 Adapting To Varying T raffic Loads. Setting.We set up a simple test bed that contains one router and 10 simple nodes as depicted in Figure 6. Each node continuously generates up to 500 data packets and sends them to the router, and the router further relays those packets to the sink node. Each experimental run lasts for 800 seconds. By varying the data rate from 1packet/1500ms to 1packets/100ms, we measured the performance of the three MACs.

!"#$

%&'()*

F igure 6: Sample experiment topology

Results:

F igure 7: Average delay comparison of first experiment

1234567891011121314150

1

2

3

4

5

6

7

8

9

10x 104


Adve

rage

Pac

ket D

elay

- m

s


iQueue-MAC performance

F igure 8: Received packet number comparison of first

experiment

Figure 7 shows the average packet delay over different traffic conditions. At the beginning, all MACs have short delay under light traffic. When the data rate exceeds 1packet/800ms, RI-MAC-MC and CoSenS starts to suffer from notably increasing delay. iQueue-MAC successfully maintains low packet delay over all scenarios.

Figure 8 shows the number of successfully received packets. Each experimental run consists of generating 5000 packets. All MACs maintain high packet reception ratio under light traffic. When the data rate exceeds 1packet/600ms, a large number of packets are dropped in CoSenS and RI-MAC-MC due to limited throughput, as most nodes have already reached their maximum queue-length. When the network is with high traffic, a single inquiring beacon in RI-MAC-MC causes fierce contention as it wakes multi nodes to compete the channel simultaneously in every round, which is an inherent drawback of the protocol. We have also observed on the sniffer that packets from different nodes continuously collided with each other and the contention window got increasingly extended but still failed to mitigate the contention and retransmissions. Similar to RI-MAC-MC, CoSenS suffers from heavy retransmissions and packet loss as most of the nodes compete for transmission during the same contending period. On the contrary, iQueue-MAC succeeds in absorbing almost all the generated packets, proving that iQueue-MAC is robust to varied traffic.

Figure 9 shows the average queue length of nodes in different MACs. iQueue-MAC succeeds in maintaining very short queue-length over all experimental scenes. That is due to the fact that iQueue-MAC suppresses queuing by allocating the corresponding slots. CoSenS and RI-MAC-MC, however, failed to provide enough bandwidth as traffic grows, resulting in substantial packet accumulation and long queue lengths, which also explain the larger delays in Figure 7 and the strong packets loss in Figure 8.

F igure 9: Average queue length comparison of first

experiment

F igure 10: Duty-cycle comparison of first experiment

Figure 10 is about the duty-cycle every MAC achieves. As we can see, CoSenS is less energy-efficient than iQueue-MAC and RI-MAC-MC, both of which have similar performances. For all MACs the duty-cycle drops as the data rate grows beyond 1packet/600ms. Since under high traffic load RI-MAC-MC and CoSenS drop many packets due to queue overflows, the result is a lower number of packets transmitted and thus a shorter active time. On the other hand, as higher traffic loads usually lead to longer queue lengths, iQueue-MAC arranges more slots in the vTDMA period when data rate grows. As the scheduled TDMA transmission is more efficient than contention based transmissions, iQueue-MAC thus consumes less active time during high traffic period, and achieves higher efficiency. 5.2 Reacting To Burst T raffic Setting. We used the same test-bed as described in section 5.1 and conducted a new set of experiments to show how different MACs react to peak or burst traffic. Initially, all nodes generate packets under a low data rate of 1packet/5seconds. Two bursts are set to occur at 100s and

1234567891011121314150

500

1000

1500

2000

2500

3000

3500

4000

4500

5000


Rec

eive

d pa

cket

num


1234567891011121314150

10

20

30

40

50

60

70

80

90

100

110

120


Aver

age

queu

e le

ngth


1234567891011121314150

2

4

6

8

10

12

14

16

18

20


Dut

y cy

cle

(%)



experiment





experiment



1234567891011121314150

500

1000

1500

2000

2500

3000

3500

4000

4500

5000


Rec

eive

d pa

cket

num


1234567891011121314150

10

20

30

40

50

60

70

80

90

100

110

120

Data Rate - 1 packet / X 100msAv

erag

e qu

eue

leng

th


1234567891011121314150

2

4

6

8

10

12

14

16

18

20


Dut

y cy

cle

(%)


iQueue-MAC performance


experiment





experiment



1234567891011121314150

500

1000

1500

2000

2500

3000

3500

4000

4500

5000


Rec

eive

d pa

cket

num


1234567891011121314150

10

20

30

40

50

60

70

80

90

100

110

120


Aver

age

queu

e le

ngth


1234567891011121314150

2

4

6

8

10

12

14

16

18

20


Dut

y cy

cle

(%)


iQueue-MAC performance: burst

500s respectively and both last for 50s. During the burst period, all nodes adopt a higher data rate of 5packets/1second. We measured key metrics along with the time.

F igure 11: Average delay comparison of second experiment

F igure 12: Average queue length comparison of second

experiment

Results. Figure 11 shows the network average packet delay. At the beginning, all MACs have low latency. Then, when burst occurs, RI-MAC-MC and CoSenS start to suffer from sharply increasing delay. The situation continues to deteriorate until all buffered packets are dispatched. Compared to the other MACs, iQueue-MAC maintains its low latency even under the burst period. Figure 12 reveals the average queuing situation in all MACs which also explains the results in Figure 11. It clearly shows that iQueue-MAC outperforms the other two MACs in maintaining a short queue length. That is because iQueue-MAC can stop packets from accumulating by providing sufficient extra bandwidth. RI-MAC-MC and CoSenS, on the other hand, are vulnerable to traffic bursts. Their bounded throughput leads to large packets queuing.

F igure 13: Online throughput comparison of second

experiment

F igure 14: Slots allocation in iQueue-M A C

Figure 13 shows the measured throughput of each MAC. We clearly see that iQueue-MAC sharply enhances its throughput at the emergence of a burst period, while RI-MAC-MC and CoSenS can only provide about one fourth of the throughput of iQueue-MAC and spread over a wider period. As a result, iQueue-MAC eliminates queuing and performs much better than the other MACs. The key of the bandwidth enhancement of iQueue-MAC is highlighted in Figure 14, which is the sudden allocation of TDMA slots. As we can see, iQueue-MAC allocates large numbers of slots during the burst periods. These allocated slots contribute to higher instantaneous bandwidth and thus shorter packet delay. Compared to other solutions, iQueue-MAC uses queue length as the feedback value for taking further control actions. This allows iQueue-MAC to react much faster as it does not need to predict the traffic loads.

5.3 General Experiment Setting. As depicted in Figure 15, we set up a more general testing environment for simulating a real-world multi-hop application scenario. A test-bed of 46 nodes scattered over

0 100 200 300 400 500 600 700 800 9000

2

4

6

8

10

12x 104

Time - s

Aver

age

dela

y - m

s

iQueue-MACRI-MAC-MCCoSenS

0 100 200 300 400 500 600 700 800 9000

20

40

60

80

100

120

140

160

180

Time - s

Aver

age

queu

e le

ngth


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

80

Time - s

Onl

ine

thro

ughp

ut


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Allo

cate

d sl

ots

num

- iQ

ueue

-MAC

iQueue-MAC

Two burst periods of 50 s: at 100 s and 500 s




experiment



experiment




0 100 200 300 400 500 600 700 800 9000

2

4

6

8

10

12x 104

Time - s

Aver

age

dela

y - m

s


0 100 200 300 400 500 600 700 800 9000

20

40

60

80

100

120

140

160

180

Time - s

Aver

age

queu

e le

ngth


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

80

Time - s

Onl

ine

thro

ughp

ut


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Allo

cate

d sl

ots

num

- iQ

ueue

-MAC

iQueue-MAC

iQueue-MAC performance: burst




experiment



experiment




0 100 200 300 400 500 600 700 800 9000

2

4

6

8

10

12x 104

Time - s

Aver

age

dela

y - m

s


0 100 200 300 400 500 600 700 800 9000

20

40

60

80

100

120

140

160

180

Time - s

Aver

age

queu

e le

ngth


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

80

Time - s

Onl

ine

thro

ughp

ut


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Allo

cate

d sl

ots

num

- iQ

ueue

-MAC

iQueue-MAC




experiment



experiment




0 100 200 300 400 500 600 700 800 9000

2

4

6

8

10

12x 104

Time - s

Aver

age

dela

y - m

s


0 100 200 300 400 500 600 700 800 9000

20

40

60

80

100

120

140

160

180

Time - s

Aver

age

queu

e le

ngth


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

80

Time - s

Onl

ine

thro

ughp

ut


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Allo

cate

d sl

ots

num

- iQ

ueue

-MAC

iQueue-MAC

iQueue-MAC performance: multi-hop case

one layer of the lab building and arranged into a 4 clusters network contains at most 4-hops transmission distance. Each cluster is placed in a lab room and contains 10 children-nodes and one router (parent) node. Data relaying paths are also fixed to factor out routing influence on experimental results. Initially, all children-nodes generate packets under a light data rate of 1packet/5seconds. Then, to simulate a series of urgent events, each cluster will experience a burst period adopting a higher data rate of 2packets/1s, as shown in Table 2. To evaluate a more critical scenario in the network, all children-nodes simultaneously switch to the burst state during the final burst. The whole experiment lasts for 900 seconds.

Table 2: Burst Per iods During General Exper iment Burst period

100s-120s 200s-220s 300s-320s 400s-420s 600s-620s

Cluster Cluster_1 Cluster_2 Cluster_3 Cluster_4 All Clusters

!"#$%&'()

!"#$%&'(* !"#$%&'(+ !"#$%&'(,

-.#%&'()

-.#%&'(*

-.#%&'(+ -.#%&'(,

-.#%&'(/

0123

F igure 15: General experiment topology

Results.

F igure 16: Average delay comparison of general experiment Figure 16 shows the average packet delay of the general

experiment. RI-MAC-MC has the worst performance during each burst period and CoSenS performs better, while iQueue-MAC behaves the best. iQueue-MAC maintains low packet delay over the whole experiment. Figure 17 shows the buffering situations with all MACs. Again, iQueue-MAC succeeds in maintaining much shorter

F igure 17: Average queue length comparison of general

experiment

F igure 18: Online throughput comparison of general

experiment

queue lengths than other MACs. This is achieved by iQueue-MAC allocating a sufficient number of slots to node senders as soon as packets queuing is detected. Conversely, CoSenS and RI-MAC-MC lead to relatively longer queues during the burst periods as they react slower to the traffic changes.

Figure 18 shows that iQueue-MAC provides faster and stronger throughput enhancement when burst traffic occurs. Higher throughput leads to faster packets dispatching thus iQueue-MAC also achieves shorter delay and queue length as depicted in Figure 16 and Figure 17, respectively. On the other hand, the slower reactions in throughput adaptation in CoSenS and RI-MAC-MC result in worse performance.

6. C O N C L USI O NS In this paper, we presented iQueue-MAC, a MAC

protocol for WSNs that efficiently manages the RF wireless medium resource under varying traffic conditions. This management combines CSMA and TDMA types of

0 100 200 300 400 500 600 700 800 9000

0.5

1

1.5

2

2.5x 104

Time - s

Aver

age

dela

y - m

s


0 100 200 300 400 500 600 700 800 9000

5

10

15

Time - s

Aver

age

queu

e le

ngth


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Onl

ine

thro

ughp

ut





100s-120s 200s-220s 300s-320s 400s-420s 600s-620s


!"#$%&'()

!"#$%&'(* !"#$%&'(+ !"#$%&'(,

-.#%&'()

-.#%&'(*

-.#%&'(+ -.#%&'(,

-.#%&'(/

0123


Results.




experiment


experiment





0 100 200 300 400 500 600 700 800 9000

0.5

1

1.5

2

2.5x 104

Time - s

Aver

age

dela

y - m

s


0 100 200 300 400 500 600 700 800 9000

5

10

15

Time - s

Aver

age

queu

e le

ngth


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Onl

ine

thro

ughp

ut




100s-120s 200s-220s 300s-320s 400s-420s 600s-620s


!"#$%&'()

!"#$%&'(* !"#$%&'(+ !"#$%&'(,

-.#%&'()

-.#%&'(*

-.#%&'(+ -.#%&'(,

-.#%&'(/

0123


Results.




experiment


experiment





0 100 200 300 400 500 600 700 800 9000

0.5

1

1.5

2

2.5x 104

Time - s

Aver

age

dela

y - m

s


0 100 200 300 400 500 600 700 800 9000

5

10

15

Time - sAv

erag

e qu

eue

leng

th


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Onl

ine

thro

ughp

ut





100s-120s 200s-220s 300s-320s 400s-420s 600s-620s


!"#$%&'()

!"#$%&'(* !"#$%&'(+ !"#$%&'(,

-.#%&'()

-.#%&'(*

-.#%&'(+ -.#%&'(,

-.#%&'(/

0123


Results.




experiment


experiment





0 100 200 300 400 500 600 700 800 9000

0.5

1

1.5

2

2.5x 104

Time - s

Aver

age

dela

y - m

s


0 100 200 300 400 500 600 700 800 9000

5

10

15

Time - s

Aver

age

queu

e le

ngth


0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

70

Time - s

Onl

ine

thro

ughp

ut


Energy-aware QoS routing

  In multi-hop WSN, transmitting data from source to destination within the deadline for real-time applications, but still saving energy

source destination

Challenges and Goals

 Network characteristics – Unreliable nature of wireless link – Energy constraint (and duty-cycled nodes)

 QoS requirement – Deadline Miss Ratio – Energy efficiency

Common requirements of RT routing protocols

 For RT applications, routing is to find good metric capable of deciding which path is the best one – For meeting deadline – For minimizing energy consumption (or

prolongating the network life time)

! Real-Time Energy-Aware routing

Some Design approaches  Most of existing routing protocols for

WSN do not support RT  Some specific RT routing protocols:

SPEED, RPAR [Univ. Virginia]  Two families of routing protocols

– General routing, e.g. AODV adopted by Zigbee

– Geographic routing and its extensions

!RT QoS enhancement must be made

Geographic routing: principle Typical One: Greedy Perimeter Stateless Routing (GPSR):

S"

D"Closest to D"

A"

-  Find neighbors who are the closer to the destination -  Forward the packet to the neighbor closest to the destination -  A node only needs to remember the location info of one-hop neighbors

Geographic routing: discussion   Greedy forwarding does not always work

–  Static obstacles (water pool, …) –  Dynamic network topology holes (due to energy depletion,

or overload, or duty-cycle, …) –  Not robust:

»  link asymmetry between sender and receiver »  Weak correlation between distance and quality of tx (Geographic

proximity does not mean electromagnetic proximity !)

  Virtual coordinates may be used (as in RPL of IETF ROLL)

  SPEED protocol proposes a more robust metric: speed = Distance + delay estimation

Virtual coordinate: principle

[figure from Watteyne]

Relative coordinates of node V are defined as a vector V1, V2, . . . , VN where Vi is the hop distance from the current node to anchor node i, and N the number of anchor nodes

1

2

3

Each anchor brodcasts its ID and the hop count is incremented by fowarder

Virtual distance between V and W may be defined as:

SUBMITTED TO IEEE COMMUNICATIONS SURVEYS & TUTORIALS 12

A

{1,2,3}

{0,3,3}

{1,2,2}{2,3,1}

{2,2,1}

{3,2,0}{2,1,2}{2,1,3}

{4,1,1}

{4,1,1}

{3,0,2}B

C

Fig. 13. An example topology where each node is as-signed virtual coordinates. Each small white circle repre-sents a node; edges interconnect nodes capable of com-municating. A small white square represents an anchornode. A virtual coordinate is a vector of number of hopsto anchor nodes A, B and C, respectively.

current node to anchor node i, and N the number of an-chor nodes. A simple way of assigning these coordinatesis to ask each anchor node to periodically broadcast amessage containing a counter incremented at each hopas it propagates through the network. Note that nodescan learn how many anchor nodes there are by listeningto these broadcast messages. Virtual coordinates are notrelated to real coordinates. An example topology whereeach node is assigned virtual coordinates is presented inFig. 13.

Geographic routing protocols require a notion of dis-tance to function. As we discuss later, note that theresulting virtual distance is not directly related to phys-ical distance. [60] proposes to infer distance from hopcount to the anchor nodes using Euclidian distance. Intheir proposal, virtual distance ||D|| between nodes V =V1, V2, . . . , VN and W = W1,W2, . . . ,WN is calculated as

||D|| =

!

"

"

#

N$

i=1

(Vi ! Wi)2

Several aspects of virtual coordinates need to be clari-fied. First, several distinct nodes may end up having thesame coordinates. We refer to nodes with the same coor-dinates as “zones”. Furthermore, because coordinates arenot orthogonal (i.e. having more than three anchor nodesin a plane or four in a 3D space introduces redundancy),||D|| is not directly related to physical distance.

Despite these peculiarities, using virtual coordinates isa promising approach to routing in WSNs. Simulation re-sults in [60] show that, with the virtual coordinate space,less voids are encountered. This means that the successratio of greedy geographic routing when using virtualcoordinates is higher than when using real coordinates,and hence more energy in the network is conserved.

Beacon Vector Routing (BVR) [61] is an exampleof a virtual coordinate-based routing protocol. In BVR,anchor nodes are randomly chosen and need not adhereto any particular structure. BVR uses greedy forwardingover virtual coordinates. [61] presents experimental re-sults obtained by implementing BVR on a two testbeds

(42 mica2dot motes [62] in an indoor office environmentof approximately 20x50m; 74 mica2dot motes deployedon a single office floor). This work serves as a proof-of-concept experiment for virtual coordinate routing inWSNs.

The Virtual Coordinate Assignment Protocol (VCap)[63] elects anchor nodes dynamically during an initial-ization phase. A distributed protocol is designed to electa predefined number of anchor nodes, evenly distributedaround the edge of the network. This obviates the needfor manual selection and enhances the efficiency of therouting protocol as anchor nodes are placed far fromeach other.

VCost [64] is an extension of VCap. The authors keepthe same anchor election scheme and virtual coordinateassignment process, yet replace greedy routing by costover progress routing. In this approach, a node electsas next hop its neighbor which minimizes the ratiobetween cost (several energy models are presented) overprogress (decrease in virtual distance to sink). Althoughthe energy consumption of finding a multi-hop path isreduced, delivery ratio is low.

During network ramp-up, LTP [65] assigns a hier-archical label to each node, starting from a root nodeoutwards. The root node (which can be any of the nodesin the network) assigns labels 1, 2, 3, etc. to its neighbors.Neighbors i will then assign labels i1, i2, i3, etc. toits neighbors, and so forth. As a result, nodes obtaina label formed by consecutive numbers; the length ofthe label representing the distance in hops to the rootnode. Routing is then done hierarchically. A messagesent between two nodes passes through their closestcommon ancestor in the label tree. As an example, amessage sent from node 1234 to node 1256 will travelfrom node 1234 to node 12, and then from node 12 tonode 1256. Although discovered routes are not optimalin number of hops, LTP guarantees delivery.

Hector is an Energy effiCient Tree-based OptimizedRouting protocol (HECTOR) [66] and combines thestrengths of VCost and LTP. Each node obtains a tuplecoordinate consisting of a VCost relative coordinate andan LTP label (the VCost anchor nodes and LTP root nodecan be chosen randomly among the network nodes). Therouting strategy is a hybrid between VCost and LTP:while LTP guarantees delivery, VCost enables energy-efficient routing. Simulation results presented in [66]show that obtained paths are 30% longer than the onesobtained by a centralized approach.

Reference [67] is interesting in several aspects. Like theprotocols presented so far, it uses a multi-dimensionalvector of hop distances to a set of anchor nodes as a basefor geographic routing3. Yet, Zhao et al. present someunique enhancements. First, instead of having each an-chor node periodically broadcast messages to update thevirtual coordinates which out-date when the topologychanges, the coordinates are piggybacked in the Hello

3. In [67], these virtual coordinates are called “hop IDs”.

May be used to run gradient routing

Gradient routing for “convergecast” SUBMITTED TO IEEE COMMUNICATIONS SURVEYS & TUTORIALS 15

1

P,2

R,2 F,2

B,1

C,2

H,2

K,3

L,2

G,1

D,1

M,1

N,1

R,3

S,3

T,3

U,3

V,3

Q,2I,2

Y,3

2

3

0A,0

E,1

O,2

Fig. 16. Illustrating gradient routing. Nodes are identifiedby[Id,Height].

4.3 Gradient Routing for MP2P trafficThe concept of gradient is particularly useful for con-vergecast networks such as WSNs. In the simplest con-vergecast scenario, all traffic is sent to a single sink node.In this case, a single gradient – rooted at the sink node –is built and maintained in the network. Fig. 16 depicts atopology where nodes are assigned heights calculated asa function of hop count. When node Y at height 3 sendsa message, it sends it to its neighbor of smallest heightI ; similarly I relays the message to G, and G to A.

Gradient-Based Routing (GBR) [73] is the canonicalgradient routing protocol. On top of the basic idea de-scribed above, an energy-based scheme can be used as adata dissemination technique, where a node increases itsheight when its energy drops below a certain thresholdso that other sensors are discouraged from sending datato it.

GRAdient Broadcast (GRAB) [74] enhances the reli-ability of data delivery trough path diversity. Similarto EAR [75], GRAB builds and maintains a gradient,providing each sensor the direction to forward sens-ing data. However, unlike all the previous approaches,GRAB forwards data along a band of interleaved meshfrom each source to the receiver.

To collect data reports, the sink first builds a gra-dient by propagating advertisement (ADV) packets inthe network. The height at a node (dubbed “cost” inGRAB) is the minimum energy overhead to forward apacket from this node to the sink along a path; nodescloser to the sink have a smaller cost. GRAB makes theassumption that each node has the means to estimate thecost of sending data to nearby nodes, e.g., through SNRmeasurements of neighbors’ transmissions. Each nodekeeps the cost of forwarding packets from itself to thesink. Since only receivers with smaller costs may forwardthe packet at each hop, the packet is forwarded bysuccessive nodes to follow the decreasing cost directionto reach the bottom of the cost field, which is the sink.

Multiple paths of decreasing cost can exist and in-terleave to form a forwarding mesh (see Fig. 17). Tolimit the width of this mesh in order to avoid creating

D

S

Fig. 17. Forwarding mesh in GRAB, where the blacknodes forward the packet to the sink collectively [74].

excessive redundancy and wasting resources, a sourceassigns a credit to its generated packet. The credit issome extra budget that can be consumed to forward thepacket. The sum of the credit and the source’s cost is thetotal budget that can be used to send a packet to the sinkalong a path. A packet can take any path that requiresa cost less than or equal to the total budget. Multiplenodes in the mesh make collective efforts to deliver datawithout dependency on any specific node.

Performance analysis of GRAB shows the advantageof interleaved mesh over multiple parallel paths andshows that GRAB can successfully deliver over 90% ofpackets with relatively low energy cost, even under theadverse conditions of node failures and link messagelosses.

The Collection Tree Protocol (CTP) [76] uses ExpectedTransmission Count (ETX) as a link metric for setting upthe gradient. Using ETX, the height of a node indicateshow many times a message originated at that node istransmitted before it reaches the sink. These transmis-sions include the hops from node to node, as well as theretransmissions needed upon link failure.

CTP piggybacks gradient setup information in beaconmessages, and uses the Trickle algorithm [77] to regulatethe beaconing interval. In the absence of topologicalchanges, this interval is regularly doubled until it reachesa maximum value which triggers only a few beacons perhour. Upon topological changes, the interval is reducedto allow for fast gradient re-convergence. Experimentalresults on 12 different testbeds show that CTP requires73% fewer beacons than a solution with a fixed 30-second beacon interval, for an idle duty cycle of 3%.

The IETF, through its Routing Over Low-power andLossy network (ROLL) working group [3], has identifiedgradient routing as particularly suited for WSNs. It isstandardizing the Routing Protocol for Low Powerand Lossy Networks (RPL) (pronounced “Ripple”) [18],which captures most of the ideas exploited by the aca-

[Figure from Wattenye11, IEEE com surveys&tutorials]

Convergecast: MP2P

ETX in CTP   ETX (Expected Transmission Count) is a link

metric for setting up the gradient, used in CTP (collection tree protocol)

  ETX indicates the average delay (in hop counts) for successfully transmitting a packet from the node to the sink, including retransmissions upon link failures

  CTP uses beacon broadcast to maintain gradient. Beacon broadcast is regulated using Trickle algorithm (double beacon broadcast interval if no topology change)

IETF RPL of ROLL SUBMITTED TO IEEE COMMUNICATIONS SURVEYS & TUTORIALS 16

k

4.0etx

3.1etx

ab

cd

e

f

g

i

j

1.4etx1.0etx

90ms80ms 2.5etx2.5etx

40ms1.8etx

20ms

20ms1.4etx

70ms1.8etx

50ms1.2etx

2.5etx

1.9etx40ms

60ms 40ms

0ms

0ms,

20ms1.2etx

1.3etx40ms

10ms1.7etx

50ms0.0etx

1.7etx40ms

2.7ms60ms

120ms3.7etx

1.9etx80ms

2.5etx40ms

1.2etx10ms

1.8etx70ms

1.3etx80ms

20ms1.5etx

Fig. 18. A typical building monitoring WSN running IETFROLL’s RPL protocol [18].

demic proposals listed above. RPL represents, to ourknowledge, the state-of-the-art in gradient routing forconvergecast WSNs.

In RPL, a gradient (called Directed Acyclic Graph,DAG) is defined by the following fours elements: (1) aset of sink node(s), (2) the set of atomic metrics collectedon each link (e.g. bandwidth, Packet Deliver Ratio –PDR, etc.), (3) how these atomic metrics are combinedto obtain the link’s cost (by adding, multiplying, etc. theatomic metrics) and (4) how link costs are combined toform a multi-hop path cost (by adding, multiplying, etc.the link costs). A given network can contain multiplegradients.

As an example application, depicted in Fig. 18, con-sider a building equipped with a WSN in which:

• some nodes (represented by white disks) monitorthe power consumption of appliances in the build-ing. These nodes report to a single intelligent metere in a way so as to extend the network lifetime. Thistranslates into the following gradient constraints: itis grounded at node e, ETX is the link cost, and eachnode calculates its height as the minimum among itsneighbors of that neighbor’s ETX, plus the ETX ofthe link to that neighbor.

• other nodes (represented by shaded disks) are at-tached to smoke detectors, and report alarms toeither one of two fire-monitoring hubs j and k.Communication between the smoke detectors andthe hubs needs to happen with lowest possiblelatency. This translates into the following gradientconstraints: it is grounded at nodes j and k, latencyis the link cost, and each node calculates its heightas the minimum among its neighbors of that neigh-bor’s latency, plus the latency of the link to thatneighbor.

In Fig. 18, latency and ETX metrics are attached toeach link; these are used to calculate the latency andETX heights of each node. When node a has to transmitan alarm packet which is intended for either i or j, it

chooses its neighbor with lowest latency height (herenode c); by repeating this process at each hop, the packetfollows path a ! c ! i ! j. Similarly, a packet sent bynode c follows the ETX gradient, i.e. sequence c ! d ! e.

RPL is strictly compliant with IPv6 architecture; allthe signaling used to set up and maintain the gradientsare carried as options to the IPv6 Router Advertisements(RAs). These packets are periodically exchanged be-tween neighbors in the network. To avoid unnecessarilyexchanging maintenance traffic while the gradient is sta-ble, the RA period is governed by the Trickle algorithmin a fashion similar to CTP [76].

5 SUMMARY AND CONCLUSIONSTable 1 lists the proposals described in this document inchronological order, and indicates the main characteristicof each. Flooding protocols were introduced in the early2000’s. The IETF MANET working group standardizedprotocols which flood requests inside a network to findroute on-demand (DSR [28], AODV [29], DYMO [30])and which optimize the number of relaying nodes (OLSR[23]).

From a small number of mobile nodes (for whichprotocols by IETF MANET are built), early commercialdeployments indicated that WSNs would be composedof a larger number of static nodes. To alleviate the scala-bility issues inherent to flooding-based protocols (knownas the ”broadcast storm” [20]), clustering was introducedto subdivide the broadcast area into smaller clusters.Initial proposals used a random cluster head electionmechanism (LEACH [24]); later proposals introduceddistributed clusterhead election scheme which use a hy-brid between node energy and topological informationsuch as node degree (HEED [33]). Cluster heads canbe used to aggregate information (TEEN [34], APTEEN[35]). Technical difficulties (maintaining consistent statethroughout the network when links are unreliable isinherently hard) and the shift of interest towards con-vergecast WSNs caused clustering protocols never toreally take off.

Because environmental monitoring was seen as animportant application for WSNs, this meant that sensorscould safely be assumed to know their geographicallocation. This also meant that the older idea of usinggeographical knowledge for routing (GFG [46] and GPRS[48] were published in 1999 and 2000, resp.) suddenlymade perfect sense. Because of the void problem, geo-graphical protocols need to switch between a greedy anda face traversal mode to guarantee delivery [41], [44],[49]. Because face traversal introduces longer multi-hoppaths, several designed elegant ways to circumnavigatevoids efficiently [50]–[52]. Geographic routing, however,is most of the time based on the Unit Disk Graphassumption, which does not hold, especially indoors.Kim et al. showed in 2005 how these protocols failin real-world indoor deployments [59]. Moreover, themarket started to indicate an interest in WSNs for indoor

[Figure from Wattenye11, IEEE com surveys&tutorials]

RPL principle   Over IPv6 (or 6lowPAN)   Building gradient tree: sink node builds DODAG (Destination

Oriented Directed Acyclic Graph) using DIO (DODAG Information Object) message broadcast which contains ID of DODAG, version, Metric, sender’s rank in DODAG

  Data packet routing based on neighbors’ rank   Maintenance of DODAG using periodic DIO message exchanges

with « trickle timer » [Im, 2MxIm]   Trickle timer doubles its value if no network problem until 2MxIm,

re-initializes to Im if network problem (e.g. loose of parent)   A threshold δRC limits the number of DIO messages allowed to be

sent since the beginning of a trickle period

SPEED: principle -  Beacon exchanges (periodic + on demand) between one-hop neighbors

(Could be piggybacked into data packets to reduce control overhead) -  to learn and update the neighbor nodes geographic position (xi, yi). -  to estimate the delay to its neighbors (like RTT estimation of TCP) -  Backpressure beacon to inform the upstream forwarder that no

route can be found -  Neighborhood table (NeighborID, Position, SendToDelay,

ExpireTime)

!

"#$%!"&#'!()*+,!)-,!.#'/+'',.!#$!"&,!$,0"!',/"#1$2!

!"#"! $%&'()*+,-.',-/0)3,!+',! '#$%*,!&14!.,*)5!)'! "&,!6,"-#/! "1!)44-10#6)",!

"&,!*1).!17!)!$1.,2!3,!$1"#/,!"&)"!"&,!.,*)5'!,04,-#,$/,.!85!8-1)./)'"! 4)/9,"'! )$.! +$#/)'"! 4)/9,"'! )-,! :+#",! .#77,-,$"!.+,! "1! .#77,-,$"! &)$.*#$%! #$'#.,! "&,! ;<=! *)5,-! )$.! "&)"!+$#/)'"!4)/9,"!.,*)5!#'!61-,!)44-14-#)",!71-!6)9#$%!-1+"#$%!.,/#'#1$'2! >$! )! '/)-/,! 8)$.?#."&! ,$(#-1$6,$"@! ?,! /)$$1"!)771-.! "1! +',! 4-18#$%! 4)/9,"'! "1! ,'"#6)",! "&,! '#$%*,! &14!.,*)52!>$'",).!?,!+',!"&,!.)")!4)/9,"'!4)''#$%!"&#'!$1.,!"1!4,-71-6!"&#'!6,)'+-,6,$"2!A,*)5!#'!6,)'+-,.!)"!"&,!',$.,-@!?&#/&! "#6,'")64'! "&,! 4)/9,"! ,$",-#$%! "&,! $,"?1-9! 1+"4+"!:+,+,!)$.!/)*/+*)",'!"&,!-1+$.!"-#4!'#$%*,!&14!.,*)5!71-!"&#'!4)/9,"! ?&,$! -,/,#(#$%! "&,! <=B2!<"! "&,! -,/,#(,-! '#.,@! "&,!.+-)"#1$!71-!4-1/,''#$%!)$!<=B!#'!4+"!#$"1!"&,!<=B!4)/9,"2!C&,! '#$%*,D"-#4! "#6,! #'! /)*/+*)",.! 85! '+8"-)/"#$%! -,/,#(,-!'#.,!4-1/,''#$%!"#6,!7-16!"&,!-1+$.!"-#4!.,*)5!,04,-#,$/,.!85!"&,!',$.,-2!3,!/164+",!"&,!/+--,$"!.,*)5!,'"#6)"#1$!85!/168#$#$%! "&,!$,?*5!6,)'+-,.!.,*)5!?#"&!4-,(#1+'!.,*)5'!(#)!"&,!,041$,$"#)*!?,#%&",.!61(#$%!)(,-)%,!EF3;<G!HIJ2!K-14)%)"#1$!.,*)5!#'!#%$1-,.2!3,!)-%+,!"&)"!"&#'!.,*)5!,'"#D6)"#1$!#'!)!8,"",-!6,"-#/!"&)$!)(,-)%,!:+,+,!'#L,!71-!-,4-,D',$"#$%! "&,! /1$%,'"#1$! *,(,*! 17! "&,! ?#-,*,''! $,"?1-9@!8,/)+',! "&,! '&)-,.! 6,.#)! $)"+-,! 17! "&,! ?#-,*,''! $,"?1-9!)**1?'!"&,!$,"?1-9!"1!8,!/1$%,'",.!,(,$!#7!:+,+,!'#L,'!)-,!'6)**2!

!"!"! 1,',%&%++)2/034%,%5.-0-+,-6)7%/85'9:-6);/53<'54-08)=127;>)

M,71-,!,*)81-)"#$%!1$!NOPQ@!?,! #$"-1.+/,! "&-,,!.,7#D$#"#1$'R!�! C&,!P,#%&81-!N,"!17!P1.,!!R!"#!$#'!"&,!',"!17!$1.,'!"&)"!)-,!#$'#.,!"&,!-).#1!-)$%,!17!$1.,!!2!P1",@!?,!.1!$1"!)'D'+6,!"&)"!"&,!/166+$#/)"#1$!-).#+'!#'!)!4,-7,/"!/#-/*,2!NKFFA!?1-9'!?#"&!#--,%+*)-!-).#1!4)"",-$'2!!

?

@?3?A2%B,

21;1

-$

!Q#%+-,!S2!PN!)$.!QN!.,7#$#"#1$'!

�! C&,! Q1-?)-.#$%! =)$.#.)",! N,"! 17! P1.,! !R! <! ',"! 17!$1.,'!"&)"!8,*1$%!"1!!"#!!)$.!)-,!/*1',-!"1!"&,!.,'"#$)D"#1$2!Q1-6)**5@!%#!$&'()*!+,*!-+.$/$0+-1($�$"#!$$ 2$3$4$35+(6*$7$89!?&,-,!3!#'!"&,!.#'")$/,!7-16!$1.,!!!"1!"&,!.,'"#$)"#1$! )$.! 35+(6*! #'! "&,! .#'")$/,! 7-16! "&,! $,0"!&14! 71-?)-.#$%! /)$.#.)",! "1! "&,! .,'"#$)"#1$2! C&,',!$1.,'! )-,! #$'#.,! "&,! /-1''D&)"/&,.! '&).,.! )-,)! )'!'&1?$!#$!Q#%+-,!S2!3,!/)$!,)'#*5!18")#$!%#!$&'()*!+,:*!-+.!85!'/)$$#$%!"&,!"#!',"!17!$1.,'!1$/,2!

>"! #'! ?1-"&! $1"#/#$%! "&)"! "&,! 6,68,-'&#4! 17! "&,!$,#%&81-! ',"! 1$*5!.,4,$.'!1$! "&,! -).#1! -)$%,@! 8+"! "&,!6,68,-'&#4!17!"&,!71-?)-.#$%!',"!)*'1!.,4,$.'!1$!.,'D"#$)"#1$!)-,)2!

�! T,*)5!N4,,.2!T,*)5!'4,,.!#'!/)*/+*)",.!85!.#(#.#$%!"&,!).()$/,!#$!.#'")$/,!7-16!"&,!$,0"!&14!$1.,!U!85!"&,!,'D"#6)",.!.,*)5!"1!71-?)-.!)!4)/9,"!"1!$1.,!U2!!!Q1-6)**5@!

;!

;! <-='(>,?

+(6*33+'()*!+,*!-#=((1 VGE �� 2!

N#$/,! #$! NKFFA@! $1.,'! 9,,4! "&,! P,#%&81-! N,"! EPNG@!8+"! .1$W"! 9,,4! )! -1+"#$%! ")8*,! 1-! 7*1?! #$71-6)"#1$@! "&,!6,61-5! -,:+#-,6,$"'! )-,!1$*5!4-141-"#1$)*! "1! "&,!$+68,-!17!$,#%&81-'2!!

M)',.!1$! "&,!.,'"#$)"#1$!17! "&,!4)/9,"!)$.! "&,!/+--,$"!QN@!"&,!N")",*,''!P1$D.,",-6#$#'"#/!O,1%-)4&#/!Q1-?)-.#$%!ENPOQG!41-"#1$!17!1+-!4-1"1/1*! -1+",'! "&,!4)/9,"'!)//1-.D#$%!"1!"&,!71**1?#$%!-+*,'R!!X2! K)/9,"'!)-,!71-?)-.,.!1$*5!"1!"&,!$1.,'!"&)"!8,*1$%!"1!

"&,!%#!$&'()*!+,*!-+.2!>7!"&,-,!#'!$1!$1.,!#$'#.,!"&,!%#!$&'()*!+,*!-+G@!4)/9,"'!)-,!.-144,.!)$.!)!8)/94-,''+-,!8,)/1$! #'! #''+,.! "1! +4'"-,)6!$1.,'! "1! 4-,(,$"! 7+-"&,-!.-14'!E',,!Y2ZG2!C1!-,.+/,!"&,!/&)$/,!17!'+/&!.-14'@!?,!.,.+/,!)!*1?,-!81+$.!17!$1.,!.,$'#"5!"&)"!/)$!(#-"+)**5!,*#6#$)",!"&,',!.-14'!E)44,$.#0!<G2!!

S2! !NKFFA!.#(#.,'! "&,! $,#%&81-! $1.,'! #$'#.,!%#!$ &'()*!:+,*!-+.!#$"1!"?1!%-1+4'2![$,!%-1+4!/1$")#$'!"&,!$1.,'!"&)"! &)(,! -,*)5! '4,,.'! *)-%,-! "&)$! )! /,-")#$! .,'#-,.!'4,,.!N',"41#$"@! "&,!1"&,-!/1$")#$'! "&,!$1.,'! "&)"! /)$$1"!'+'")#$!'+/&!.,'#-,.!'4,,.2!C&,!N',"41#$"! #'!)!'5'",6!4)D-)6,",-! "&)"!.,4,$.'!1$! "&,!/166+$#/)"#1$!/)4)8#*#"5!17!"&,!$1.,'!)$.!.,'#-,.!"-)77#/!?1-9*1).!)!',$'1-!$,"D?1-9!'&1+*.!'+441-"2!!

\2! C&,! 71-?)-.#$%! /)$.#.)",! #'! /&1',$! 7-16! "&,! 7#-'"!%-1+4@!)$.!"&,!$,#%&81-!$1.,!?#"&!&#%&,'"!-,*)5!'4,,.!&)'!)!&#%&,-!4-18)8#*#"5!"1!8,!/&1',$!)'!"&,!71-?)-.#$%!$1.,2! >$! 1+-! )44-1)/&@! ?,! +',! )! .#'/-,",! ,041$,$"#)*!.#'"-#8+"#1$!"1!"-).,!177!8,"?,,$!*1).!8)*)$/#$%!)$.!14D"#6)*!4)"&!*,$%"&2!

Y2! >7! "&,-,! )-,! $1! $1.,'! 8,*1$%#$%! "1! "&,! 7#-'"! %-1+4@! )!-,*)5! -)"#1! #'! /)*/+*)",.! 8)',.! 1$! "&,! P,#%&81-&11.!Q,,.8)/9!]114!EPQ]G@!?&#/&!#'!.#'/+'',.!#$!61-,!.,D")#*! #$! ',/"#1$! Y2^2!3&,"&,-! )! 4)/9,"! .-14! ?#**! -,)**5!&)44,$! .,4,$.'! 1$! ?&,"&,-! )! -)$.16*5! %,$,-)",.!$+68,-!8,"?,,$!E_@XG!#'!8#%%,-!"&)$!"&,!-,*)5!-)"#12!>$!NKFFA!)!4)/9,"!#'!.-144,.!1$*5!?&,$!$1!.1?$'"-,)6!$1.,!/)$!%+)-)$",,! "&,!'#$%*,!&14!'4,,.!',"!41#$"!N',"D41#$"!)$.!.-144#$%!4)/9,"'!6+'"!8,!4,71-6,.! "1!-,.+/,!"&,! /1$%,'"#1$2! C&1+%&! 1$,! /)$! /1$'#.,-! 8+77,-#$%!4)/9,"'!)'!)$!)*",-$)"#(,!"1!"&,!.-144#$%@!&1?,(,-@!?,!)-%+,! "&)"! +$.,-! -,)*D"#6,! )$.! '6)**! 6,61-5! /1$D'"-)#$'@!.-144#$%!#'!17",$!)!8,"",-!/&1#/,2!!!

!!!NPOQ!4-1(#.,'!"?1!$#/,!4-14,-"#,'!"1!&,*4!6,,"!1+-!.,'#%$!%1)*'2!Q#-'"@! '#$/,! NPOQ! ',$.'!4)/9,"'! "1! "&,!.1?$'"-,)6!

-  Select among nodes in forwarding set making progress toward the destination

!

"#$%!"&#'!()*+,!)-,!.#'/+'',.!#$!"&,!$,0"!',/"#1$2!

!"#"! $%&'()*+,-.',-/0)3,!+',! '#$%*,!&14!.,*)5!)'! "&,!6,"-#/! "1!)44-10#6)",!

"&,!*1).!17!)!$1.,2!3,!$1"#/,!"&)"!"&,!.,*)5'!,04,-#,$/,.!85!8-1)./)'"! 4)/9,"'! )$.! +$#/)'"! 4)/9,"'! )-,! :+#",! .#77,-,$"!.+,! "1! .#77,-,$"! &)$.*#$%! #$'#.,! "&,! ;<=! *)5,-! )$.! "&)"!+$#/)'"!4)/9,"!.,*)5!#'!61-,!)44-14-#)",!71-!6)9#$%!-1+"#$%!.,/#'#1$'2! >$! )! '/)-/,! 8)$.?#."&! ,$(#-1$6,$"@! ?,! /)$$1"!)771-.! "1! +',! 4-18#$%! 4)/9,"'! "1! ,'"#6)",! "&,! '#$%*,! &14!.,*)52!>$'",).!?,!+',!"&,!.)")!4)/9,"'!4)''#$%!"&#'!$1.,!"1!4,-71-6!"&#'!6,)'+-,6,$"2!A,*)5!#'!6,)'+-,.!)"!"&,!',$.,-@!?&#/&! "#6,'")64'! "&,! 4)/9,"! ,$",-#$%! "&,! $,"?1-9! 1+"4+"!:+,+,!)$.!/)*/+*)",'!"&,!-1+$.!"-#4!'#$%*,!&14!.,*)5!71-!"&#'!4)/9,"! ?&,$! -,/,#(#$%! "&,! <=B2!<"! "&,! -,/,#(,-! '#.,@! "&,!.+-)"#1$!71-!4-1/,''#$%!)$!<=B!#'!4+"!#$"1!"&,!<=B!4)/9,"2!C&,! '#$%*,D"-#4! "#6,! #'! /)*/+*)",.! 85! '+8"-)/"#$%! -,/,#(,-!'#.,!4-1/,''#$%!"#6,!7-16!"&,!-1+$.!"-#4!.,*)5!,04,-#,$/,.!85!"&,!',$.,-2!3,!/164+",!"&,!/+--,$"!.,*)5!,'"#6)"#1$!85!/168#$#$%! "&,!$,?*5!6,)'+-,.!.,*)5!?#"&!4-,(#1+'!.,*)5'!(#)!"&,!,041$,$"#)*!?,#%&",.!61(#$%!)(,-)%,!EF3;<G!HIJ2!K-14)%)"#1$!.,*)5!#'!#%$1-,.2!3,!)-%+,!"&)"!"&#'!.,*)5!,'"#D6)"#1$!#'!)!8,"",-!6,"-#/!"&)$!)(,-)%,!:+,+,!'#L,!71-!-,4-,D',$"#$%! "&,! /1$%,'"#1$! *,(,*! 17! "&,! ?#-,*,''! $,"?1-9@!8,/)+',! "&,! '&)-,.! 6,.#)! $)"+-,! 17! "&,! ?#-,*,''! $,"?1-9!)**1?'!"&,!$,"?1-9!"1!8,!/1$%,'",.!,(,$!#7!:+,+,!'#L,'!)-,!'6)**2!

!"!"! 1,',%&%++)2/034%,%5.-0-+,-6)7%/85'9:-6);/53<'54-08)=127;>)

M,71-,!,*)81-)"#$%!1$!NOPQ@!?,! #$"-1.+/,! "&-,,!.,7#D$#"#1$'R!�! C&,!P,#%&81-!N,"!17!P1.,!!R!"#!$#'!"&,!',"!17!$1.,'!"&)"!)-,!#$'#.,!"&,!-).#1!-)$%,!17!$1.,!!2!P1",@!?,!.1!$1"!)'D'+6,!"&)"!"&,!/166+$#/)"#1$!-).#+'!#'!)!4,-7,/"!/#-/*,2!NKFFA!?1-9'!?#"&!#--,%+*)-!-).#1!4)"",-$'2!!

?

@?3?A2%B,

21;1

-$

!Q#%+-,!S2!PN!)$.!QN!.,7#$#"#1$'!

�! C&,! Q1-?)-.#$%! =)$.#.)",! N,"! 17! P1.,! !R! <! ',"! 17!$1.,'!"&)"!8,*1$%!"1!!"#!!)$.!)-,!/*1',-!"1!"&,!.,'"#$)D"#1$2!Q1-6)**5@!%#!$&'()*!+,*!-+.$/$0+-1($�$"#!$$ 2$3$4$35+(6*$7$89!?&,-,!3!#'!"&,!.#'")$/,!7-16!$1.,!!!"1!"&,!.,'"#$)"#1$! )$.! 35+(6*! #'! "&,! .#'")$/,! 7-16! "&,! $,0"!&14! 71-?)-.#$%! /)$.#.)",! "1! "&,! .,'"#$)"#1$2! C&,',!$1.,'! )-,! #$'#.,! "&,! /-1''D&)"/&,.! '&).,.! )-,)! )'!'&1?$!#$!Q#%+-,!S2!3,!/)$!,)'#*5!18")#$!%#!$&'()*!+,:*!-+.!85!'/)$$#$%!"&,!"#!',"!17!$1.,'!1$/,2!

>"! #'! ?1-"&! $1"#/#$%! "&)"! "&,! 6,68,-'&#4! 17! "&,!$,#%&81-! ',"! 1$*5!.,4,$.'!1$! "&,! -).#1! -)$%,@! 8+"! "&,!6,68,-'&#4!17!"&,!71-?)-.#$%!',"!)*'1!.,4,$.'!1$!.,'D"#$)"#1$!)-,)2!

�! T,*)5!N4,,.2!T,*)5!'4,,.!#'!/)*/+*)",.!85!.#(#.#$%!"&,!).()$/,!#$!.#'")$/,!7-16!"&,!$,0"!&14!$1.,!U!85!"&,!,'D"#6)",.!.,*)5!"1!71-?)-.!)!4)/9,"!"1!$1.,!U2!!!Q1-6)**5@!

;!

;! <-='(>,?

+(6*33+'()*!+,*!-#=((1 VGE �� 2!

N#$/,! #$! NKFFA@! $1.,'! 9,,4! "&,! P,#%&81-! N,"! EPNG@!8+"! .1$W"! 9,,4! )! -1+"#$%! ")8*,! 1-! 7*1?! #$71-6)"#1$@! "&,!6,61-5! -,:+#-,6,$"'! )-,!1$*5!4-141-"#1$)*! "1! "&,!$+68,-!17!$,#%&81-'2!!

M)',.!1$! "&,!.,'"#$)"#1$!17! "&,!4)/9,"!)$.! "&,!/+--,$"!QN@!"&,!N")",*,''!P1$D.,",-6#$#'"#/!O,1%-)4&#/!Q1-?)-.#$%!ENPOQG!41-"#1$!17!1+-!4-1"1/1*! -1+",'! "&,!4)/9,"'!)//1-.D#$%!"1!"&,!71**1?#$%!-+*,'R!!X2! K)/9,"'!)-,!71-?)-.,.!1$*5!"1!"&,!$1.,'!"&)"!8,*1$%!"1!

"&,!%#!$&'()*!+,*!-+.2!>7!"&,-,!#'!$1!$1.,!#$'#.,!"&,!%#!$&'()*!+,*!-+G@!4)/9,"'!)-,!.-144,.!)$.!)!8)/94-,''+-,!8,)/1$! #'! #''+,.! "1! +4'"-,)6!$1.,'! "1! 4-,(,$"! 7+-"&,-!.-14'!E',,!Y2ZG2!C1!-,.+/,!"&,!/&)$/,!17!'+/&!.-14'@!?,!.,.+/,!)!*1?,-!81+$.!17!$1.,!.,$'#"5!"&)"!/)$!(#-"+)**5!,*#6#$)",!"&,',!.-14'!E)44,$.#0!<G2!!

S2! !NKFFA!.#(#.,'! "&,! $,#%&81-! $1.,'! #$'#.,!%#!$ &'()*!:+,*!-+.!#$"1!"?1!%-1+4'2![$,!%-1+4!/1$")#$'!"&,!$1.,'!"&)"! &)(,! -,*)5! '4,,.'! *)-%,-! "&)$! )! /,-")#$! .,'#-,.!'4,,.!N',"41#$"@! "&,!1"&,-!/1$")#$'! "&,!$1.,'! "&)"! /)$$1"!'+'")#$!'+/&!.,'#-,.!'4,,.2!C&,!N',"41#$"! #'!)!'5'",6!4)D-)6,",-! "&)"!.,4,$.'!1$! "&,!/166+$#/)"#1$!/)4)8#*#"5!17!"&,!$1.,'!)$.!.,'#-,.!"-)77#/!?1-9*1).!)!',$'1-!$,"D?1-9!'&1+*.!'+441-"2!!

\2! C&,! 71-?)-.#$%! /)$.#.)",! #'! /&1',$! 7-16! "&,! 7#-'"!%-1+4@!)$.!"&,!$,#%&81-!$1.,!?#"&!&#%&,'"!-,*)5!'4,,.!&)'!)!&#%&,-!4-18)8#*#"5!"1!8,!/&1',$!)'!"&,!71-?)-.#$%!$1.,2! >$! 1+-! )44-1)/&@! ?,! +',! )! .#'/-,",! ,041$,$"#)*!.#'"-#8+"#1$!"1!"-).,!177!8,"?,,$!*1).!8)*)$/#$%!)$.!14D"#6)*!4)"&!*,$%"&2!

Y2! >7! "&,-,! )-,! $1! $1.,'! 8,*1$%#$%! "1! "&,! 7#-'"! %-1+4@! )!-,*)5! -)"#1! #'! /)*/+*)",.! 8)',.! 1$! "&,! P,#%&81-&11.!Q,,.8)/9!]114!EPQ]G@!?&#/&!#'!.#'/+'',.!#$!61-,!.,D")#*! #$! ',/"#1$! Y2^2!3&,"&,-! )! 4)/9,"! .-14! ?#**! -,)**5!&)44,$! .,4,$.'! 1$! ?&,"&,-! )! -)$.16*5! %,$,-)",.!$+68,-!8,"?,,$!E_@XG!#'!8#%%,-!"&)$!"&,!-,*)5!-)"#12!>$!NKFFA!)!4)/9,"!#'!.-144,.!1$*5!?&,$!$1!.1?$'"-,)6!$1.,!/)$!%+)-)$",,! "&,!'#$%*,!&14!'4,,.!',"!41#$"!N',"D41#$"!)$.!.-144#$%!4)/9,"'!6+'"!8,!4,71-6,.! "1!-,.+/,!"&,! /1$%,'"#1$2! C&1+%&! 1$,! /)$! /1$'#.,-! 8+77,-#$%!4)/9,"'!)'!)$!)*",-$)"#(,!"1!"&,!.-144#$%@!&1?,(,-@!?,!)-%+,! "&)"! +$.,-! -,)*D"#6,! )$.! '6)**! 6,61-5! /1$D'"-)#$'@!.-144#$%!#'!17",$!)!8,"",-!/&1#/,2!!!

!!!NPOQ!4-1(#.,'!"?1!$#/,!4-14,-"#,'!"1!&,*4!6,,"!1+-!.,'#%$!%1)*'2!Q#-'"@! '#$/,! NPOQ! ',$.'!4)/9,"'! "1! "&,!.1?$'"-,)6!

Enhancing geographic routing by exploring k-hop neighborhood information

Simulated example comparing performance of 1-hop and 2-hop:

How long the lens of the telescope should focus?

  Asymptotic performance of k-hop

A concrete design: two-hop based SPEED routing protocol

  Two-hop neighborhood search without increasing control traffic (piggybacking)

  Energy aware probabilistic drop (near to sink packet has less drop probability)

  Energy consumption balance (possible to choose slower paths when allowed)

j

NF

i D

m

n

F2k

Some definitions

j

NF

i D

m

n

F2k

H

I

J

K

G

d(S,D)=100 m

d(A,D)=80 m

d(G,D)=60 m

DelaySA =0.1s

DelayS B=0.14sB

d(B,D)=76 mDelayBG =0.06s

A

Fd(F,D)=65 m

DelayAF =0.08s

S

C

D

d(C,D)=85 m

DelayS C=0.09s

Ed(E,D)=78 m

Del

ayA

E =0.0

6s

d(H,D)=65 m

d(I,D)=78 m

DelayB H=0.05sDelayC I=0.04s

An example of Two-hop SPEED

Architecture

TH-SPEED

Cost function for energy consumption balance

Energy efficient probabilistic dropDelay estimation

Application

MAC

Link quality model

Two-hop based forwarding strategy

Evaluation metrics  Deadline miss ratio: DMR  Average energy consumed per

successfully transmitted packet : ECP

DMR,ECP vs. deadline, 1,2 with #node=200, 3 with #node=400, #source=10

Sim

ulat

ion

Res

ults

(1)

1 2

3

Simulation Results (2)

DMR and ECP vs. workload, #node=200,deadline=800ms

Sim

ulat

ion

Res

ults

(3)

Energy consumption distribution with cost function embedded, deadline is not rigorous, =3000ms

SPEED

TH-SPEED Routing Protocol SPEED TH-SPEED

DMR 17% 0%

ECP (mA*ms/packet) 2472.3 2486.8

Conclusion and future directions   Design of duty-cycled MAC protocols has been extensively

investigated. Trend is to focus on adaptive duty-cycled MAC –  there is still design space for new higher performance, multi-channel

ones which can self-adapt to dynamic traffic –  High performance MAC integrating energy harvesting components

  There exists few QoS routing protocols. RPL attracts more attention. –  How to take into account duty-cycle of underlying MAC to improve

RPL? What enhancement for making it to support QoS routing? Need new QoS routing protocols?

–  What types of QoS guarantee? SRT? probabilistic? (see J.D. Decotignie’s presentation)

Main references P. Huang, L, Xiao, S. Soltani, M. Mutka, N.Xi. The evolution of MAC protocols in wireless sensor networks: a survey, Communications Surveys & Tutorials, IEEE, Volume: 15 , Issue: 1, pp.101-120, 2013. T. Watteyne, A. Molinaro, M.G. Richichi, M. Dohler, From MANET To IETF ROLL Standardization: A Paradigm Shift in WSN Routing Protocols, Communications Surveys & Tutorials, IEEE, Volume: PP, vol. 13, no. 4, pp. 688-707, 2011 S.G. Zhuo, Y.Q. Song, Z. Wang, Z.B. Wang, “Queue-MAC: A queue-length aware hybrid CSMA/TDMA MAC protocol for providing dynamic adaptation to traffic and duty-cycle variation in wireless sensor networks”, IEEE WFCS2012. Zhuo S.G., Wang Z. Song Y.Q., Wang Z.B., Almeida L., “iQueue-MAC : a traffic adaptive duty-cycled MAC protocol with dynamic slot allocation”, IEEE SECON 2013. Li Y., Chen C.S., Song Y.Q., Wang Z. Sun Y., “Enhancing real-time delivery in wireless sensor networks with two-hop information”, IEEE Transactions on Industrial Informatics Vol.5, No.2 (May 2009), pp113-122.

Réseaux de capteurs sans fil - IRITRéseaux de capteurs sans fil: comment fournir la qualité de...

Documents

Transcript of Réseaux de capteurs sans fil - IRITRéseaux de capteurs sans fil: comment fournir la qualité de...