Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 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, 200050, China] Voice:[+86-021-6251-1070], FAX: [+86-021-6213-2314], E-Mail:[huangheqing@mail.sim.ac.cn] Re: [IEEE P802.15.4e] Abstract: [This document describes a MAC proposal for IEEE 802.15.4e. While analyze the current MAC proposals of 802.15.4e, bring forward a MAC proposal meets the requirement and characteristics ratified by 802.15.4g TG.] Purpose: [Discussion in 802.15.4e Task Group] Notice: This document has been prepared to assist the IEEE P802.15. 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.

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 • Advantages • 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 • Advantages • 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 • 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

12. Unicast communication sequence

13. Multicast communication sequence

14. Collision Avoidance • Arch Rock 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 • Co-op MAC • Sender stop send wakeup command after received data req from receiver • Arch Rock MAC • Wakeup sequence persists the period of channel sample 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. Table 79―Values of the frame type subfield Required modification for 15.4e MAC Modify Wakeup frame • add source address field • 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 Add New MAC PIB Attribute, be inserted in Table 86

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 • 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