Submission Title: [Enhanced Low Power Consumption Proposal] 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. 6213 2314

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

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

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

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

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

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

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

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

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.

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

Unicast communication sequence

Multicast communication sequence

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.

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

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.

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

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