September 2004 doc IEEE 802 15 04 0536

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Combined proposal of Enhancements to IEEE 802. 15. 4] Date Submitted: [16 September, 2004] Source: [Myung Lee, Jianliang Zheng, Yong Liu, Huai-Rong Shao, Hui Dai and Jinyun Zhang, Hoin Jeon] Company [Samsung Lab @ CUNY, Mitsubishi Electric Research Lab, Kyungwon University] Address [T 677, EE Dept. Steinman Hall 140 th Street and Convent Ave, NY 10031 ] Voice: [212 -650 -7260], FAX: [212 -650 -8249], EMail: [lee@ccny. cuny. edu] Re: [Response to the call for proposal of IEEE 802. 15. 4 b, MAC Enhancement. ] [If this is a response to a Call for Contributions, cite the name and date of the Call for Contributions to which this document responds, as well as the relevant item number in the Call for Contributions. ] [Note: Contributions that are not responsive to this section of the template, and contributions which do not address the topic under which they are submitted, may be refused or consigned to the “General Contributions” area. ] Abstract: [Discussion for several potential enhancements for current IEEE 802. 15. 4 MAC] Purpose: [For the discussion at IEEE 802. 15. 4 b Study Group] Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate fields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph. Submission 1 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Combined Beacon Scheduling Proposal to IEEE 802. 15. 4 b Myung Lee, Jianliang Zheng, Yong Liu Samsung Lab@ CUNY Huai-Rong Shao, Hui Dai, Jinyun Zhang Mitsubishi Electric Research Labs. Ho-in Jeon Kyungwon University Submission 2 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Proposed Change to 802. 15. 4 • Add only one attribute “mac. Postbeacondelay” in MAC PIB. Submission 3 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (1) • Beacons are very important to network operations. • Beacon transmissions do not follow CSMA/CA. • In a multi-hop beacon enabled network, each node has to prevent its beacons and data packets from destroying the beacons from its parent and its neighbors’ parents. • Current 802. 15. 4 MAC has to be enhanced to support beacon scheduling operated at the upper layer. Submission 4 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (2) • To assign a contention-free time-slot to a node u in a tree type network – (c. 1) u’s time-slot must be different from u’s parent’s time-slot. – (c. 2) u’s time-slot must not be the time-slot of the parent of anyone of u’s neighbors, excluding u’s own children. • In other words, the time-slot used by one node is “unavailable” to its children and their neighbors. Submission 5 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (3) • For example – The time-slot used by node 0 is unavailable to its children: 1, 16, as well as their neighbors: 2, 9, 17, 24. – The time-slot used by node 1 is unavailable to its children: 2, 9, as well as their neighbors: 3, 6, 10, 13, 18, 17. – However, node 1 and node 16 can share the same time-slot since they do not have common children. – Node 3 can share the same timeslot with node 0 since they are three -hop away. Submission 6 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (4) • Since the time-slot used by one node is “unavailable” to its children and their neighbors, – Each coordinator has to obtain its parent’s time-slot and notify its neighbors about its parent’s timeslot. – It has to collect the time-slots used by its neighbors’ parents. – It has to select a time-slot different from those of its parent and its neighbors’ parents. Submission 7 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (5) • Approach 1: – Each coordinator selects a contention-free time-slot for its active period. – It includes the Beacon_Tx_Offset (between its beacon and its parent’s beacon) in its beacon payload. – Every new coordinator obtains its neighbors and their parents time-slots from the neighbors’ beacons. Submission 8 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (6) • Problems of approach 1: – Assumption: very low duty cycle and very short active period. • Shall we limit the beacon-enabled mode only to low duty-cycle applications? – Active period cannot be dynamically extended, unless sufficient guard interval is provided. – Every coordinator has to wake up in both its own active period and its parent’s active period. – Direct communications between sibling nodes are problematic if each node only wakes up in its own active period and its parent’s active period. Submission 9 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (7) • Approach 2: – Every coordinator selects a contention-free time-slot within the Beacon-only-Period to transmit its own beacon. Submission 10 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (8) • Approach 2 (cont. ): – A Beacon-only-Period is formed at the beginning of each superframe. – At the beacon scheduling stage, the coordinators have to include the Beacon-only-Period parameters (beginning time, length) and their parent’s time-slot numbers in their beacon payloads. – A post. Beacon. Delay has to be added to the MAC PIB to delay the data transmissions to the end of the Beacononly-Period. Submission 11 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (9) • Benefits of approach 2: – Without the limitation of low duty-cycle – Superframes/Active-Periods are nicely synchronized • Coordinators can freely extend their active-periods based on their own traffic conditions. • Every node only needs to wake up once within one beacon interval. • Coordinators can directly talk with siblings since they share the same active period. – Beacon-enabled network can also conduct Zigbee integrated routing. • Enable instant packet relays and multihop GTS alignment. Submission 12 Myung Lee, et al,

September 2004 doc. : IEEE 802. 15 -04 -0536 -00 -004 b Support of Multi-hop Beacon Enabled Networks (10) • Backward compatibility: – For 15. 4 device, the NWK layer has to prevent the MAC layer from sending packets before the end of the Beacon-only-Period. • At the end of each active period, NWK layer of 15. 4 devices shall purge (MCPS-PURGE) the packets queued at the MAC layer. • mac. Auto. Request is always set as FALSE to prevent the MAC layer of 15. 4 devices from sending data request command automatically. • The NWK layer of 15. 4 devices issues MCPS-DATA or MLME -POLL only after the Beacon-only-Period ends. Submission 13 Myung Lee, et al,