doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 1 Power save and Routing Date: Authors:

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 2 Abstract What the power saving is for ? –Review the benefit and cost regarding power save for MPs –Recall the characteristic of devices/UMs (usage models) which leverage power save mode A quantitative analysis of benefit derived from power management mechanism –Some calculation results are shown Issues regarding power save and routing –Quick review on what is recognized as issues Discussion on the issues and possible resolution to the issues –Adding some more “capability bits” could be a good hook

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 3 What the power saving is for? The benefit of power saving mechanism are : –Introduce the low power consumption capability by reducing the active duty cycle of PHY/MAC. Reduction of power consumption is one of the mandatory requirement for battery- powered devices. Longer battery life, such as cell-phone, laptop PC, etc... Low power capability is going to be an important requirements even for AC- powered devices, at least in the area of CE devices. Environmental and/or ecology oriented motivation, conformance to Kyoto Protocol, etc... –Devices for infrastructure may not leverage the power saving functions. The cost of power saving mechanism are : –Add the extra complexity to support the PS functionality. –Introduce some inflexibility in terms of the frame delivery. (Transmitter shall make sure that receiving MP is in awake state prior to the transmission of the frame.)

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 4 Residential scenario What the power saving is for ? (Cont’d)

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 5 What the power saving is for ? (Cont’d) Residential scenario –Let the battery-powered device save the power.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 6 What the power saving is for ? (Cont’d) Residential scenario –If the player is on the cradle, use this route and consume less wireless media. (and possibly let other devices fall in sleep)

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 7 What the power saving is for ? (Cont’d) Residential scenario –In night time, most of the applications are not running. –Let all the devices save power. –The mesh have to be capable to re-activate the operation in the morning.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 8 What the power saving is for ? (Cont’d) Public safety / Military scenario –Some/many of the MPs are mobile terminal. –Longer battery life is preferred. Portable battery-powered devices would like to save the power all the time.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 9 What the power saving is for ? (Cont’d) Public safety / Military scenario –Some MPs could save power while other MPs are communicating.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 10 The characteristic of devices/UMs (usage models) which leverage power save mode In some deployment scenario, the active mesh operations do not need to be maintained 24 hours a day, 365 days a year. –The device should operate in the PS mode during the idle time. –The mesh should be capable to re-activate the operation when needed. The “willingness to save power” could be dynamic. –The device may choose to save power, but may choose to serve as a forwarder. The battery-powered devices need power saving functionality, such as handheld devices. –The need for a longer battery life. –The battery-powered devices are usually “mobile” devices, where the device mobility leads to physical topology change.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 11 Some calculation: –Assumption on the power consumption  captured from [1] –Operational parameter setting Beacon interval : 200ms DTIM interval : 5 ATIM Window : 10ms Ramp up margin: 1ms Number of neighbouring peer MPs : 6 Beacon frame length: 200us Take this parameters for example A quantitative analysis of benefit derived from power management mechanism

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 12 A quantitative analysis of benefit derived from power management mechanism Some calculation for “stand-by” operation: –Case 1: In case all the MPs are sync MPs (non-beaconing MP) Total power consumption per 1[sec] = 1 x (ramp up + beacon reception + ATIM Wakeup) + rest of time x Doze State power drain = 54.58[mWatt]; Case 1currentdurationC [mA_sec]Jule*duration/sec[mJ] Doze Idle Receive Transmit Total [mWatt]

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 13 A quantitative analysis of benefit derived from power management mechanism Some calculation for “stand-by” operation: –Case 2: In case all the MPs are sync MPs (beaconing MP) Total power consumption per 1[sec] = 5 x (ramp up + beacon transmission + ATIM Wakeup) + rest of time x Doze State power drain = 85.34[mWatt]; Case 2currentdurationC [mA_sec]Jule*duration/sec[mJ] Doze Idle Receive Transmit Total [mWatt]

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 14 A quantitative analysis of benefit derived from power management mechanism Some calculation for “stand-by” operation: –Case 3: In case all the MPs are non-sync MPs Total power consumption per 1[sec] = 5 x (ramp up + beacon transmission + ATIM Wakeup) + 6 x (ramp up + beacon reception + ATIM Wakeup) + rest of time x Doze State power drain = [mWatt]; Case 3currentdurationC [mA_sec]Jule*duration/sec[mJ] Doze Idle Receive Transmit Total [mWatt]

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 15 A quantitative analysis of benefit derived from power management mechanism Some calculation for “stand-by” operation: –Case 4: In case all the MPs are non-sync MPs with improvement suggested by CID5665 Total power consumption per 1[sec] = 5 x (ramp up + beacon transmission + ATIM Wakeup) + 6 x (ramp up + beacon reception) + rest of time x Doze State power drain = 90.48[mWatt]; Case 4currentdurationC [mA_sec]Jule*duration/sec[mJ] Doze Idle Receive Transmit Total [mWatt]

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 16 A quantitative analysis of benefit derived from power management mechanism Some calculation for “stand-by” operation: –Case 0: active MP Total power consumption per 1[sec] = [mWatt]; Case 0currentdurationC [mA_sec]Jule*duration/sec[mJ] Doze Idle Receive Transmit Total [mWatt]

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 17 Issues regarding power save and routing (1) Power save will impact on broadcast/multicast frame delivery delay By current definition, –“All broadcast and multicast traffic shall be buffered by Power Save supporting MPs that maintains peer relationship with Power Saving MP. These frames are transmitted immediately after the Mesh DTIM beacon transmission.” –This implies that BC/MC frame delivery will be delayed due to power save support, even if there are other peer MPs in active mode. –May cause a path setup delay due to power save support, as well as BC/MC frame delivery delay in general.  may cause some more issue in routing mechanisms.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 18 Issues regarding power save and routing (2) Does Power saving MP become a forwarding MP ? –It is unsure whether the power saving MP could be a forwarding node. –In some scenario, power saving forwarder may be useful.  We should not close the door for this capability. –If the power saving MP could be a forwarding node, “What to do, if there is an alternate path ? ” “What to do, if there is no alternate path ? ”

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 19 Issues regarding power save and routing (Cont’d) Summary of comments regarding power save and routing –Explicitly address the issue of the effect of power management mode on route stability. –Consider the sub-modes on power save (route discovery active or not). –Need to define a new message to carry the power save mode information. –Clarify Power save related “capability bit”. –If it is certain that specific multicast addresses are not intended for PS MP's, the implementor should have the option to turn off buffering for this traffic. –(Make PS support mandatory.)

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 20 Discussion on the issue (1) Regarding to broadcast/multicast frame delivery delay: –Option 1: Leave the frame delivery delay issue as it is defined. –Option 2: Do not deliver path selection related BC frames to power saving MPs.  Power saving MP can not live with routing.  General BC/MC frame delivery delay still remains. –Option 3: Power save supporting MP transmits BC/MC frames to active MP and PS MPs, twice.  BC/MC frames can be transmitted without unnecessary delay.  Path selection management messages will be delivered to PS MP.  Adds complexity to power save supporting MP.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 21 A suggestion to the issue (1) Option 3 seems to be reasonable. Suggest to add one more capability (configuration) bit for power save supporting MP to indicate the advanced BC/MC frame delivery capability. Suggest to add (bring back) one more configuration bit for MP to indicate that “I may be in PS mode in the future”.  “Willingness to power save” bit

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 22 Discussion on the issue (2) Regarding to power save mode as a forwarding MP: –Advertising “Willingness to be a forwarder” may become a helpful information to neighboring peer MPs. –Suggest to add one more configuration bit for power saving MP to indicate the “willingness to be a forwarder”.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 23 Some options for capability (configuration) bits setting Define following Mesh configuration bits (1)Power Save Support enabled (2)Power Save Support with low latency BC/MC delivery (3)Willingness to Power Save (4)Willingness to be a forwarder Additionally, PS bit in Frame Control field indicate the current PM mode of the MP. (5) MP power save mode

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 24 Some options for capability setting Combination of bit setting –For power save supporting MP (1) (2) 0 0  Power save support is not enabled by this MP. This MP will reject any peer link establishment with MPs which may be operated in PS mode. 0 1  N/A 1 0  Power save support is enabled by this MP. But, BC/MC delivery scheme is limited and may impact the path selection performance. This MP may reject peer link establishment with MPs which may be operated in PS with PS mode to maintain path selection performance. 1 1  Power save support is enabled by this MP. And, BC/MC delivery does not impact the path selection performance. This MP will establish peer link establishment with MPs which may be operated in PS with PS mode, without impacting the path selection performance.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 25 Some options for capability setting Combination of bit setting –For power saving MP (3) (4) 0 0  MP may not transit to PS. not to be a forwarder. (This is an aka-NFMP in active mode.) 0 1  MP may not transit to PS. Willing to be a forwarder. This is a generic MP in active mode. 1 0  MP may transit to PS. not to be a forwarder. This is an aka-NFMP may be operated in PS mode. 1 1  MP may transit to PS. Willing to be a forwarder. Controversial MP, but the route could be set up via this MP.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 26 Conclusion Power save is an important feature to some devices and some use cases. –Power management mechanisms help in reducing the power consumption of the MP. The negative impact of power save operation to the routing could be mitigated by adding some frame delivery schemes. –Suggested to add some more configuration bits to notify the capability of advanced frame delivery and willingness information. MP can decide whether it should open peer link or not referring its own capability/configuration and the candidate peer MP’s capability/configuration. –Appropriate logic selection leads to an appropriate marriage of peer MPs in different configuration.

doc.: IEEE /1996r2 Submission June 2007 Kazuyuki SakodaSlide 27 References [1] “Investigating the Energy Consumption of a Wireless Network Interface in an Ad Hoc Networking Environment”, Laura Marie Feeney, Martin Nilsson