1. Submission Title: IEEE802.15.3: Overview of Power Save Proposal.
August 2001
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: IEEE : Overview of Power Save Proposal.
Date Submitted: 14 August, 2001
Source: Jay Bain Company: Time Domain
Address: 7057 Old Madison Pike
Voice: , FAX: ,
Source: Mark E. Schrader Company: Eastman Kodak Co.
Address: 4545 East River Road, Rochester, NY
Voice: , FAX: ,
Abstract: This provides an overview of proposed incorporations in the draft standard relating to power management.
Purpose: To provide information and solicit comments on proposed power management
Notice: This document has been prepared to assist the IEEE P 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15
Jay Bain Time Domain, Mark Schrader Eastman Kodak

2. Overview of MAC Power Save
August 2001
Overview of MAC Power Save
Provide the protocol structure that will allow a range of applications the greatest opportunity to save power.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

3. Possible Power Save Scenarios
August 2001
Possible Power Save Scenarios
The mode with greatest power saving is OFF!
If OFF won’t do -- Associate with a network and then:
Take advantage of characteristics of contention free period – reduce power in slots not assigned to a device. (RPS)
Take advantage of higher layer inactivity - reduce power by skipping several beacons and superframes. (EPS)
Jay Bain Time Domain, Mark Schrader Eastman Kodak

4. The enemies of power saving
August 2001
The enemies of power saving
Constant high throughput requirements.
Time to progress from startup to data movement.
Failure by higher layers to correctly structure requirements for service
Real characteristics of PHY and MAC
Poor environmental conditions resulting in lost packets and use of lower transmission rates
Jay Bain Time Domain, Mark Schrader Eastman Kodak

5. Reduced Power Save RPS August 2001
Jay Bain Time Domain, Mark Schrader Eastman Kodak

6. Contention Free Period
August 2001
RPS Operation
Contention
Access
Period
Contention Free Period
Beacon
Assigned
Slot
Assigned
Slot
Period of Reduced Power Opportunity
PNC may be an RPS device
Stay awake for
Beacon
CAP
Assigned receive slot
Assigned send slot with activity
Consider receive slot as empty after 25% of duration
Slot location
Higher layers make realistic RPS QoS requirement known to device
PNC required to make best effort to locate assigned slot nearest beacon
Slot location is a consideration. It would be an advantage for a RPS device to have a single cycle of activity rather than multiples. Real systems are expected to require time to return from a reduced power state.
A realistic RPS QoS requirement is key to obtaining desired results. Higher layers inform the RPS device of power restrictions and also of a matching scenario of information expected to be exchanged while in an RPS mode of operation.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

7. Extended Power Save EPS
August 2001
Extended Power Save EPS
Jay Bain Time Domain, Mark Schrader Eastman Kodak

8. Sleeping really means waking periodically to check the beacon, etc.
August 2001
Presuppositions 1
Sleeping really means waking periodically to check the beacon, etc.
The sending station and the receiving station will synchronize their wakeups to the same superframe if possible.
The PNC needs to be able to communicate with EPS stations. It must know on what cycles the EPS station will be listening.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

9. August 2001
Presuppositions 2
The AWAKE QoS requirements will be greater than or equal to the EPS QoS requirements (which could go to zero).
There are two primary AWAKE scenarios needed to satisfy its AWAKE transmission requirements.
The sender may want only one superframe of AWAKE mode transmission before return to EPS.
The sender may want multiple or continuous superframes of AWAKE mode transmission.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

10. Proposed Solution Overview
August 2001
Proposed Solution Overview
Allow stations separate allocations of requested channel time for EPS and for AWAKE. Allow less than one slot per superframe as a valid period between allocated slots.
The existence of the CTA indicates that both stations will be awake for this superframe.
The PNC knows all EPS intervals.
Allow zero allocation length so that a CTA element (with EPS destination ID) will be generated by the PNC but no slot length will be allocated to the station.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

11. EPS Example Scenarios August 2001
Jay Bain Time Domain, Mark Schrader Eastman Kodak

12. Introduction to the Scenarios
August 2001
Introduction to the Scenarios
Four examples supported in EPS Mode
Inactive EPS to high throughput awake
Inactive EPS to very low throughput awake
Data in EPS to high throughput awake
Inactive EPS to Momentary awake
Jay Bain Time Domain, Mark Schrader Eastman Kodak

13. Scenario 1 – Inactive EPS to high throughput awake
August 2001
Scenario 1 – Inactive EPS to high throughput awake
AWAKE Mode
EPS Mode
EPS Mode
Sender & Receiver wake to beacon, read null CTA.
No traffic
Indicated
Sender: to PNC “Switch to AWAKE mode CTA” in CAP, receive ACK. Switch at end of EPS interval
Sender: In beacon on last data packet, “Switch to EPS mode CTA” in CAP (or CFP) to PNC and receive ACK. PNC returns to sending null CTAs at the EPS Mode rate.
Beacon
Sender & Receiver wake to beacon with AWAKE Mode CTAs set by PNC. Send first data packet in assigned slot. High rate AWAKE allocations shown
Contention Free Period
Beacon
Assigned
Slot
Other Members’ Slots
Jay Bain Time Domain, Mark Schrader Eastman Kodak

14. Scenario 2 – Inactive EPS to very low throughput awake
August 2001
Scenario 2 – Inactive EPS to very low throughput awake
EPS Mode
EPS Mode
AWAKE Mode
Contention Free Period
Other Members’ Slots
Beacon
Beacon
Beacon
Assigned
Slot
Sender /Receiver listen to this beacon, read null CTA. No slot
allocated.
Sender: Transmits to PNC “Switch to AWAKE mode CTA” in CAP, receives ACK from PNC. The mode will switch on next scheduled superframe with (null) CTA.
Sender & Receiver wake to beacon with AWAKE Mode CTA (with slot) set by PNC, Send first data packet in assigned slot. An identical-to-EPS-Mode rate is shown.
Sender: Transmits to PNC “Switch to EPS mode CTA” in CAP, receives ACK. The mode switches on next scheduled AWAKE Mode slot superframe.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

15. Scenario 3 – Data in EPS to high throughput awake
August 2001
Scenario 3 – Data in EPS to high throughput awake
AWAKE Mode
EPS Mode
EPS Mode
Sender & Receiver wake to beacon, and data is sent in EPS mode allocated slots.
Sender: transmit to PNC “Switch to AWAKE mode CTA” (Persistent) to PNC in CAP and receive ACK from PNC. Switch to AWAKE allocation at end of EPS interval
EPS interval
Beacon
Sender: Send in CAP on last data packet superframe, “Switch to EPS mode CTA” and receive ACK. PNC. This switches the allocation back to EPS Mode allocated slots.
Contention Free Period
Sender & Receiver wake to beacon. data is sent in AWAKE Mode allocated slots
Beacon
Assigned
Slot
Other Members’ Slots
Jay Bain Time Domain, Mark Schrader Eastman Kodak

16. Scenario 4 – Inactive EPS to Momentary awake
August 2001
Scenario 4 – Inactive EPS to Momentary awake
EPS Mode
EPS Mode
EPS interval
Sender & Receiver wake to beacon with AWAKE Mode CTA set by PNC. Sender transmits data packet in assigned slot.
PNC immediately reverts back to EPS Mode CTA..
Beacon
Beacon
Sender /Receiver listen to this beacon, read null CTA. No slot
allocated.
Sender: Transmits to PNC “Switch to AWAKE mode CTA” in CAP with “Momentary” parameter and receives ACK from PNC. The CTA mode will switch to EPS Mode at the end of this EPS interval.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

17. Changes to frame formats
August 2001
Changes to frame formats
Jay Bain Time Domain, Mark Schrader Eastman Kodak

18. EPS Notification via CTA
August 2001
EPS Notification via CTA
1 Octet
1 Octet
EPS Information
Element
Dest. DEV ID
“No-OP” CTA
Information
Element
1 Octet
1 Octet
2 Octet
2 Octet
SRC DEV
Address
DST DEV
Slot Start Time
Zero Value
Information bearing
CTA Information
Element
1 Octet
1 Octet
2 Octet
2 Octet
SRC DEV
Address
DST DEV
Address
Slot Start Time
Time Slot Duration
Jay Bain Time Domain, Mark Schrader Eastman Kodak

19. Channel Time Request Additions (Alternative 1)
August 2001
Channel Time Request Additions (Alternative 1)
Existing Channel
Time Request
CTA Switch
(2 Bits)
AWAKE Mode
Channel Time Request
EPS Mode
Channel Time Request 1
Reserved 1
Reserved 1
Jay Bain Time Domain, Mark Schrader Eastman Kodak

20. Channel Time Request Additions (Alternative 2)
August 2001
Channel Time Request Additions (Alternative 2)
Existing Channel
Time Request
CTA Switch
(1 Bit)
AWAKE Mode
Channel Time Request
EPS Mode
Channel Time Request 1
Jay Bain Time Domain, Mark Schrader Eastman Kodak

21. Management Primitives
August 2001
Management Primitives
Switch to EPS CTA
Persistent Only
Switch to AWAKE CTA
Persistent
Momentary
Jay Bain Time Domain, Mark Schrader Eastman Kodak

22. Benefits to Additions to PNC and CTA
August 2001
Benefits to Additions to PNC and CTA
Gives PNC the knowledge to communicate with EPS devices.
Provides sanity check for EPS receiving device that it is still in sync
Facilitates different models of QoS for EPS devices.
Utilizes existing CTA mechanisms to support a wide variety of power save scenarios.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

23. Additional Considerations
August 2001
Additional Considerations
Jay Bain Time Domain, Mark Schrader Eastman Kodak

24. August 2001
QoS Aspects for EPS
Higher order protocols dictate the latency of the EPS device waking for a beacon
Higher layers should not ask for more than needed
Two profile operation
Low duty cycle
High rate operation
Jay Bain Time Domain, Mark Schrader Eastman Kodak

25. Repeater Considerations
August 2001
Repeater Considerations
Use repeater in normal manner as piconet coverage enhancer.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

26. Superframe Considerations
August 2001
Superframe Considerations
Consideration of Beacon change (new superframe length)
PNC should not change the superframe length if not truly beneficial to traffic requirements
If it does change, the EPS device shall stay on to find the beacon – if once in a long while event, not a problem.
Clock drift calculation and leading of nominal beacon time is EPS device responsibility.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

27. MAC to PHY Communications
August 2001
MAC to PHY Communications
Taking James Gilb suggestion
Table of power save options in PHY sent to MAC. Content is time to return to normal operation.
MAC chooses the appropriate table index for each power down command to PHY.
MAC sends power on command to return the PHY to normal mode.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

28. Additional CTA thought
August 2001
Additional CTA thought
If the sender's CTA in the beacon contained the beacon count of its next (not current) allocated slot, this could assist with managing the time with respect to superframes, and help stations who were not in sync with the sender know when the sender was going to wake up next.
If there could be a special CTA that only indicated a sender's next wake up superframe, it could be broadcast in EVERY beacon as an indication of the next wakeup superframe. This "information only CTA" would allow everyone to resync very quickly and easily without listening for the normal CTA.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

29. Performance Modeling Note: these will be updated in the next rev, 5.
August 2001
Performance Modeling
Note: these will be updated in the next rev, 5.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

30. No-Op Wake Cycle Average Amp Chart
August 2001
No-Op Wake Cycle Average Amp Chart
This chart is described as follows: It uses an active power value suggested by Mark Schrader, James Gilb's 1 mS wakeup time (using Mark’s active power value), and Ed Callaway's TG4 sleep power of 20 uA. There are 5 series depicted. The chart shows average amps as y-axis (log) and wake-to-wake cycle time (seconds) (EPSTime ) as x-axis. Bounded between always active and always asleep are three plots.The one with the greatest power saving is a baseline of having no power up requirement (for all of these is the 65uS beacon length based on calculations including preamble, 16 slot CTA, and 22Mb/s). The next up is with 1 mS power up and depicts the approach proposed for EPS. The next up is the best I can figure for adding the necessary messaging to support Raju's protocol. There are three parts: message exchange indicating return to wake state; followed by the exchange requesting sleep state; and then the sleep state permit exchange. I fudged a bit and concluded that another 3 mS (a CAP of 1 mS, return of 1 mS, and another CAP of 1mS(second beacon of 65uS not in calculation)) would cover the exchanges that would take place over 2 or 3 superframes (I just lumped it into a return time of 4mS for the chart). A lot of this depends on the architectural divisions of implementations (would all three exchanges occur in a single CAP or would 2 or three be likely?).
If my analysis is correct and Excel didn't confound me, there is a substantial power consumption hit for the three exchanges of Raju's proposal.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

31. Revision changes Changes from R0 to R1 Changes from R1 to R2
August 2001
Revision changes
Changes from R0 to R1
Add MAC to PHY power management content
Change EPS sequence from text to diagram
Changes from R1 to R2
Add shoulds and shalls to text on beacon length, QoS,
Add chart of EPS savings
Add table of comparison of approaches
Note that R3 was a distributed but not presented early version. Content is in R4
Changes from R2 to R4
Separate channel time allocations (Qos profiles) for EPS and AWAKE.
Update proposal changing beacon content, synchronization, initialization, and CTA management for dual QoS profiles.
Jay Bain Time Domain, Mark Schrader Eastman Kodak

32. EPS Information Element Disposition
August 2001
EPS Information Element Disposition
Remove EPS gauge level bits. Average power decrease didn’t weigh well against the increased complexity
Remove the more bit. Message Header in assigned slot carries the intent that EPS receiver remains awake after that superframe
Remove Current sequence value. Use zero duration CTA element to reflect the presence or absence of information for the EPS receive device. Zero duration CTA only present during superframe for EPS wake.
Remove the Acknowledged sequence value. The desired effect is proved by exception handling
Remove the Active update bit. Define the sending QoS to be single message or multimessage. (assurance that an errant sending device doesn’t impact a receiving EPS device)
Jay Bain Time Domain, Mark Schrader Eastman Kodak