1. Power save and Routing Date: 2007-06-13 Authors: June 2007
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Kazuyuki Sakoda

2. Abstract What the power saving is for ?
June 2007
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
Kazuyuki Sakoda

3. What the power saving is for?
June 2007
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.)
Kazuyuki Sakoda

4. What the power saving is for ? (Cont’d)
June 2007
What the power saving is for ? (Cont’d)
Residential scenario
Kazuyuki Sakoda

5. What the power saving is for ? (Cont’d)
June 2007
What the power saving is for ? (Cont’d)
Residential scenario
Let the battery-powered device save the power.
Kazuyuki Sakoda

6. What the power saving is for ? (Cont’d)
June 2007
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)
Kazuyuki Sakoda

7. What the power saving is for ? (Cont’d)
June 2007
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.
Kazuyuki Sakoda

8. What the power saving is for ? (Cont’d)
June 2007
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.
Kazuyuki Sakoda

9. What the power saving is for ? (Cont’d)
June 2007
What the power saving is for ? (Cont’d)
Public safety / Military scenario
Some MPs could save power while other MPs are communicating.
Kazuyuki Sakoda

10. June 2007
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.
Kazuyuki Sakoda

11. June 2007
A quantitative analysis of benefit derived from power management mechanism
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
Kazuyuki Sakoda

12. June 2007
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 1
current
duration
C [mA_sec]
Power [mWatt]
Doze
0.9890
9.8900
Idle
0.0108
1.6848
7.9186
Receive
0.0002
0.0380
0.1786
Transmit
0.0000
Total
1.0000
Kazuyuki Sakoda

13. June 2007
A quantitative analysis of benefit derived from power management mechanism
Some calculation for “stand-by” operation:
Case 2: In case all the MPs are unsync 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 2
current
duration
C [mA_sec]
Power [mWatt]
Doze
0.9450
9.4500
Idle
0.0540
8.4240
Receive
0.0000
Transmit
0.0010
0.2840
1.3348
Total
1.0000
Kazuyuki Sakoda

14. June 2007
A quantitative analysis of benefit derived from power management mechanism
Some calculation for “stand-by” operation:
Case 3: In case all the MPs are unsync 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 3
current
duration
C [mA_sec]
Power [mWatt]
Doze
0.8790
8.7900
Idle
0.1188
Receive
0.0012
0.2280
1.0716
Transmit
0.0010
0.2840
1.3348
Total
1.0000
Kazuyuki Sakoda

15. June 2007
A quantitative analysis of benefit derived from power management mechanism
Some calculation for “stand-by” operation:
Case 4: In case all the MPs are unsync 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 4
current
duration
C [mA_sec]
Power [mWatt]
Doze
0.9378
9.3780
Idle
0.0600
9.3600
Receive
0.0012
0.2280
1.0716
Transmit
0.0010
0.2840
1.3348
Total
1.0000
Kazuyuki Sakoda

16. June 2007
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 0
current
duration
Power [mWatt]
Doze
0.0000
Idle
0.9978
Receive
0.0012
0.2280
1.0716
Transmit
0.0010
0.2840
1.3348
Total
1.0000
Kazuyuki Sakoda

17. Issues regarding power save and routing (1)
June 2007
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.
Kazuyuki Sakoda

18. Issues regarding power save and routing (2)
June 2007
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 ? ”
Kazuyuki Sakoda

19. Issues regarding power save and routing (Cont’d)
June 2007
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.)
Kazuyuki Sakoda

20. Discussion on the issue (1)
June 2007
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.
Kazuyuki Sakoda

21. A suggestion to the issue (1)
June 2007
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
Kazuyuki Sakoda

22. Discussion on the issue (2)
June 2007
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”.
Kazuyuki Sakoda

23. Some options for capability (configuration) bits setting
June 2007
Some options for capability (configuration) bits setting
Define following Mesh configuration bits
Power Save Support enabled
Power Save Support with low latency BC/MC delivery
Willingness to Power Save
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
Kazuyuki Sakoda

24. Some options for capability setting
June 2007
Some options for capability setting
Combination of bit setting
For power save supporting MP (1) (2)  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  N/A 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 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.
Kazuyuki Sakoda

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

26. June 2007
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.
Kazuyuki Sakoda

27. June 2007
References
[1] “Investigating the Energy Consumption of a Wireless　Network Interface in an Ad Hoc Networking Environment”, Laura Marie Feeney, Martin Nilsson
Kazuyuki Sakoda