1. Submission Title: [Enhanced Low Power Consumption Proposal]
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Enhanced Low Power Consumption Proposal]
Date Submitted: [September 16, 2009]
Source: [H.Q. Huang, Y. Yang, J. Shen, H.T. Liu, L Li and B Zhou] [SIMIT, Vinno, Huawei]
Address [No.865 Changning Road, Shanghai, , China]
Voice:[ ], FAX: [ ],
Re: [IEEE P e]
Abstract: [This document describes a MAC proposal for IEEE e. While analyze the current MAC proposals of e, bring forward a MAC proposal meets the requirement and characteristics ratified by g TG.]
Purpose: [Discussion in e Task Group]
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 P

2. Characteristics of PHY proposals of 4g related to MAC
Multiple-Channel
Data rate variable
Energy efficiency
Support payload size control and long PHY frame size
Support simultaneous operation for at least 3 co-located orthogonal networks
Multiple topology support
Schedule of multiple channel and data rate
Low energy consumption
Multi-hop communication
Compatibility and scalability
Basic Requirement for MAC

3. Low-Power Consumption Proposals in 15.4e MAC Draft
Two Adopted Low-Power Consumption Proposals in 4E Draft
RIT MAC (NICT)
Low power MAC (Arch Rock)
One Suggestion for Co-op two proposals

4. Arch Rock MAC proposal
Periodically performs channel sample for a short period
Sends wakeup sequence if there is data waits to transmit
Asynchronous mode
Wakeup sequence persists the period of channel sample (cslMaxPeriod)
Synchronous mode
Sends wakeup sequence just before the corresponding slot, and persists only the guard time plus the transmission time of one wakeup frame
Upon reception of a wakeup frame, enable the receiver at the time indicated by the wakeup frame

5. Advantages & disadvantages
Improve low-power consumption performance
Support multi-channel
Perform channel sample on each channel
Wakeup sequence persists number_of_channels*cslMaxPeriod symbols in asynchronous mode, as sends a short wakeup sequence at the corresponding time by calculation
Support broadcast and multicast
Disadvantages
Multi-hop transmission delay is large
Wakeup sequence holds the channel for a long time
Only suitable for very low traffic

6. NICT MAC proposal for nonbeacon-based
Based on “Receiver-Initiated” scheme
Periodically wake up, transmit Data Request command, then wait a short period of time and go back to sleep
Enable the receiver and wait for Data Request command if there is data from higher layer
Upon reception of a Data Request command, the source node transmit data

7. Advantages & disadvantages
Improve low-power consumption performance
Disadvantages
multi-hop transmission delay is large
Not support robust transmission
Need more details to support multi-channel
Not support broadcast and multi-cast

8. Conclusion
Requirement
Multiple QoS support
Multi-channel support
Energy efficient
Channel occupation
time
Transmission delay
Broadcast & multicast
support
NICT
RIT MAC No
Yes
good
short
large
Arch Rock
Low power MAC
long
RIT MAC is hard to support broadcast & multicast communication
The transmission delay of both for one hop are up to the duration of a period
CSL Wakeup sequence holds the channel for a long time
Collision may be frequent in ‘many-to-one’ transmission

9. Suggestion for Co-op two proposals
Merge two MACs
From Arch Rock MAC
Keep CSL mechanism, same as Arch Rock MAC
Modify wakeup sequence
Insert idle listening (Duration: macDataReqWaitDuration) between every two wakeup command to receive data req from destination node (in Arch Rock MAC , which is back-to-back)
Modify wakeup frame
Add source address field
From RIT MAC
Modify data req command
Send data req only when received wakeup command
Modify data req frame
Add both source address and destination address
Co-op MAC
Periodically CSL channel sampling
Act as ‘RTS-CTS-DATA-ACK’ scheme to avoid collision.
Wakeup command acts as RTS, data req acts as CTS

10. Working procedure
Each node periodically performs channel sample for a short period to receive Wakeup command.
Wakeup command contains the destination’s address, which can be set as ‘0xffff’ to support broadcast/multicast communication.
The source node send a wakeup sequence (contain several wakeup commands and idle listening periods) if there is data to send.
When received Wakeup command, the destination node transmits Data_Req immediately, then waiting for DATA frame.
The source node transmits DATA frame immediately after received the Data_Req.
For multicast communication, act as Arch Rock MAC.

11. Working procedure Difference to Arch and NICT Transmission initiator
Channel sample
Send Wakeup command
Send Data request
Confirm mechanism
Arch Rock MAC
Sender
Periodically
Back-to-back no
DATA-ACK
NICT RIT MAC
Receiver
periodically
REQ-DATA-ACK
Co-op MAC
Separated, insert idle listening
When received wakeup command
RTS-CTS-DATA-ACK

12. Unicast communication sequence

13. Multicast communication sequence

14. Collision Avoidance Arch Rock MAC RIT MAC Co-op MAC
After the wakeup sequence, the source node A and C start data transmission directly, which cause collision.
RIT MAC
When received the Data req from B, both A and C start data transmission, which cause collision.
Co-op MAC
After B received wakeup command from both A and C, B send Data req to A and start data transmission, C received no Data req for itself, try it again in next period avoid the collision.

15. Power Consumption Arch Rock MAC Co-op MAC
Wakeup sequence persists the period of channel sample
Co-op MAC
Sender stop send wakeup command after received data req from receiver
power consumption of co-op proposal lower than CSL
Co-op MAC
Sender send wakeup command sequence, until received data req
Receiver wakeup and keep RX state periodically
RIT MAC
Sender wakeup and keep RX state, until received data req
Receiver send data req periodically
t RIT_TX ≈ t Co-op_RX
t RIT_RX ≈ t Co-op_TX
Power TX ≈ Power RX
power consumption of co-op proposal ≈ RIT

16. Required modification for 15.4e MAC
Table 79―Values of the frame type subfield
Required modification for 15.4e MAC
Modify Wakeup frame
add source address field
Oct:2 1 2
FCF
DSN
Dest PAN
Dest Addr
Src PAN
Src Addr
RZTime
FCS
Add New MAC frame – Data Req
to confirm the source node’s transmission request (wakeup command), and announce its neighbors to keep silence during the next data transmission
Oct:2 1 2
FCF
DSN
Dest PAN
Dest Addr
Src PAN
Src Addr
FCS
Add New MAC PIB Attribute, be inserted in Table 86
Attribute
Identifier
Type
Range
Description
Default
macDataReqWaitDuration
Integer
The maximum number of symbols to wait for a Data Req frame.

17. Advantages support broadcast/multicast communication
support multi-channel
Collision avoid for ‘many-to-one’ communication
Reduce wakeup sequence by a half statistically
half transmission delay for one hop
shorter channel occupy time
lower power consumption
Power consumption
CSL > RIT ≈ co-op proposal

18. Conlusion Co-op two proposals Add/modify 15.4e MAC Advantages
For multicast communication, use CSL mechanism
For unicast communication, Merge wakeup sequence in CSL and data req in RIT
Add/modify 15.4e MAC
Modify wakeup command
Modlfy data request command
Add new PIB: macDataReqWaitDuration
Advantages
support broadcast/multicast communication
Collision avoid for ‘many-to-one’ communication
Reduce wakeup sequence by a half statistically
Less power consumption CSL > RIT ≈ co-op proposal 18