Presentation is loading. Please wait.

Presentation is loading. Please wait.

Path Selection and Power Save

Similar presentations


Presentation on theme: "Path Selection and Power Save"— Presentation transcript:

1 Path Selection and Power Save
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Path Selection and Power Save Date: Authors: Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

2 July 2007 doc.: IEEE yy/xxxxr0 July 2007 Abstract Power Save and Path Selection are logically independent mesh services. This presentation describes how path selection would be performed by devices in power saving mode. Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

3 Power Save Assumptions
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Power Save Assumptions Broadcast frames are transmitted after a Mesh TIM Unicast frames are sent either at a predetermined moment in time that a transmitter advertises to the intended recipient, or through a receiver-issued message to retrieve the notified buffered traffic Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

4 Power save and HWMP July 2007 Mode 1: On-demand Mode 2: Proactive PREQ
doc.: IEEE yy/xxxxr0 July 2007 Power save and HWMP Mode 1: On-demand Broadcast PREQ PREQ may be buffered: need for some built-in delay tolerance and appropriate lifetime Unicast PREP PREP may be buffered: need for built-in delay tolerance Mode 2: Proactive PREQ Broadcast Proactive PREQ The lifetime of the PREQ would have to be adjusted for propagation delay Mode 3: Proactive RANN Broadcast Proactive RANN The RANN is delayed anyway, so no change necessary Unicast PREQ PREQ may be buffered: need for built-in delay tolerance Unicast RREP Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

5 Power Save Options No synchronization Link synchronized
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Power Save Options No synchronization No power save is possible Link synchronized If the mesh is unsynchronized, each device must awake per each DTIM beacon of its neighboring peer MPs, since each MP sets its own DTIM TBTT timing independently This limits the number of peer links that a device in power save mode should establish Mesh synchronized If the mesh is synchronized, each device shares the same DTIM TBTT timing, and shares the same ATIM window following the DTIM TBTT There is no limit to the number of peer links that a device in power save mode should establish Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

6 On demand PREQ [link synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 On demand PREQ [link synchronized] MA,B + MB,C < MA,C PREP PREP A Metric to C = MA,B + MB,C PREQ PREP Metric to A = MA,B B Metric to C = MB,C PREQ C Metric to A = MA,B + MB,C Path established through B Reasonable delay Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

7 Proactive PREQ (1) [link synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive PREQ (1) [link synchronized] beacon PREQ beacon PREQ beacon PREQ A Metric = 0 B Metric = MA,B Next Hop = A C Metric = MA,B + MB,C Next Hop = B Reasonable lifetime Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

8 Proactive PREQ (2) [link synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive PREQ (2) [link synchronized] A Metric to C = MA,B + MB,C PREP B Metric to A = MA,B Metric to C = MB,C PREP C Metric to A = MA,B + MB,C Path established through B Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

9 Proactive RANN (1) [link synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive RANN (1) [link synchronized] beacon RANN beacon RANN beacon RANN A Metric = 0 B Metric = MA,B Candidate Next Hop = A C Metric = MA,B + MB,C Candidate Next Hop = B Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

10 Proactive RANN (2) [link synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive RANN (2) [link synchronized] PREP A Metric to C = MA,B + MB,C PREQ PREP B Metric to A = MA,B Metric to C = MB,C PREQ C Metric to A = MA,B + MB,C Path established through B Reasonable delay Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

11 On demand PREQ [mesh synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 On demand PREQ [mesh synchronized] PREP PREP A Metric to C = MA,B + MB,C PREQ PREP Metric to A = MA,B B Metric to C = MB,C PREQ C Metric to A = MA,B + MB,C Path established through B Reasonable delay Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

12 Proactive PREQ (1) [mesh synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive PREQ (1) [mesh synchronized] beacon PREQ beacon PREQ beacon PREQ A Metric = 0 B Metric = MA,B Next Hop = A C Metric = MA,B + MB,C Next Hop = B Reasonable lifetime Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

13 Proactive PREQ (2) [mesh synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive PREQ (2) [mesh synchronized] A Metric to C = MA,B + MB,C PREP B Metric to A = MA,B Metric to C = MB,C PREP C Metric to A = MA,B + MB,C Path established through B Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

14 Proactive RANN (1) [mesh synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive RANN (1) [mesh synchronized] beacon RANN beacon RANN beacon RANN A Metric = 0 B Metric = MA,B Candidate Next Hop = A C Metric = MA,B + MB,C Candidate Next Hop = B Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

15 Proactive RANN (2) [mesh synchronized]
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Proactive RANN (2) [mesh synchronized] PREP A Metric to C = MA,B + MB,C PREQ PREP B Metric to A = MA,B Metric to C = MB,C PREQ C Metric to A = MA,B + MB,C Path established through B Reasonable delay Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

16 Transport latency Link synchronized Mesh synchronized
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Transport latency Link synchronized Broadcast forwarding results in larger latency, since broadcast frames are transmitted only after the Mesh TIM of individual MPs. Mesh synchronized Broadcast forwarding latency could be smaller than that of locally synchronized networks, since all the synchronized MP share the same DTIM TBTT and broadcast forwarding could be done within an ATIM window. Slide 16 Guenael Strutt, Motorola et al. Page 16 Guenael Strutt, Motorola et al.

17 Observations on forwarding
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Observations on forwarding No matter how reliable, delivery will always incur a delay if a power saving device is in the forwarding path The device must wait for a specific time window to receive traffic The device must wait for a specific time window to forward traffic From the source node’s perspective: As long as the delay is known, the power saving device does not need to be “penalized”: the path selection metric is sufficient From the power saving device’s perspective: The power saving mechanism is a bonus feature (e.g. reduced energy consumption) The metric should take into account the additional latency The power saving mechanism is secondary to traffic forwarding (e.g. temporary wireless router) Should the power saving device advertise the fact that it is unwilling to forward? The power saving mechanism takes precedence over forwarding (e.g. a mobile client) The power saving device may ignore path selection messages The power saving device may simply not establish peer links with traffic sources Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

18 Summary Path selection is logically independent from power save
July 2007 doc.: IEEE yy/xxxxr0 July 2007 Summary Path selection is logically independent from power save To support power saving forwarding devices, HWMP can be adjusted (via network management): On-demand PREQ Long delay on broadcast PREQ before retry Long lifetime on PREQ Proactive PREQ Proactive RANN Long delay on unicast PREQ before retry Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.

19 References doc.: IEEE 802.11-07/1996r1 “Power save and Routing”
July 2007 doc.: IEEE yy/xxxxr0 July 2007 References doc.: IEEE /1996r1 “Power save and Routing” doc.: IEEE /2013r0 “Power save and routing use case examination” doc.: IEEE /2096r0 “Mesh Local Synchronization” doc.: IEEE /2095r3 “Thoughts on Interaction between Power Management and Path Selection “ Guenael Strutt, Motorola et al. Guenael Strutt, Motorola et al.


Download ppt "Path Selection and Power Save"

Similar presentations


Ads by Google