August 2004 doc IEEE 802 15 04 0457

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Solutions and discussions to direct and indirect beacon conflict problem for IEEE 802. 15. 4 b ] Date Submitted: [August 24, 2004] Source: [Huai-Rong Shao, Jinyun Zhang and Hui Dai] Company [Mitsubishi Electric Research Labs] Address [8 th Floor, 201 Broadway, Cambridge, MA 02139 ] Voice: [617 -621 -7517], FAX: [617 -621 -7550], EMail: [shao@merl. com] Re: [Response to call for proposal of IEEE 802. 15. 4 b, Doc Number: 15 -04 -0239 -00 -004 b. ] Abstract: [Further discussion and revision of beacon conflict proposal in 802. 15. 4 b. Original proposal is at 15 -04 -0313 -01 -004 b ] Purpose: [Proposal to IEEE 802. 15. 4 b Task 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. Submission 1 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Solutions and discussions to direct and indirect beacon conflict problem for IEEE 802. 15. 4 b –Original proposal is at 15 -04 -0313 -01 -004 b Huai-Rong Shao, Jinyun Zhang and Hui Dai Mitsubishi Electric Research Laboratories Submission 2 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Outline • Summary of the Proposal • Detailed Problem Statement for Direct and Indirect Beacon Conflicts • Detailed Solutions to Beacon Conflict • Discussions – Probability analysis for indirect beacon conflict – Other possible solutions to beacon conflict – At which layer beacon conflicts problem should be solved? Network or MAC? Submission 3 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Proposal Summary (1) • Problem Statement: – Direct beacon conflict: Multiple coordinators within the same POS may encounter beacon conflict if they use the same channel. – Indirect beacon conflict: Multiple coordinators cannot hear to each other directly but their POSes overlap, beacon conflict may happen at devices (either Coordinator or End-Device) within the overlapped area. – Direct and indirect beacon conflict can happen within the same WPAN or between different WPANs. Beacon C 1 D 1 C 2 C 3 C 2 Submission 4 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Proposal Summary (2) • Solution 1: Reactive solution – 1. During the scanning stage, the coordinator will choose a beacon transmission time (slot) not occupied by its neighboring coordinators within its POS. – 2. (Optional) The coordinator doesn’t transmit beacons immediately. Instead, it senses the channel during the first one or several beacon transmission durations. If the channel is idle, it will start to send beacons regularly. Otherwise, it will re-choose its beacon transmission time. – 3. A device may become an orphan due to beacon conflict. After receiving an orphan notification command, coordinators reply with either coordinator realignment command or beacon time notification command. If beacon time conflict is found, the device will send out a beacon conflict notification command to notify coordinators to adjust their beacon transmission time. Submission 5 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Proposal Summary (3) • Solution 2: Proactive solution – 1. During the scanning stage, a device sends out a beacon request command. On receiving a beacon request command, • a) A coordinator will put its parent coordinator’s beacon time information in its beacon frame’s payload. • b) An end-device will reply with a beacon time notification command to report its parent coordinator’s beacon time information. – 2. If the device wants to be a coordinator, it will choose a beacon transmission time (slot) not conflicting with other coordinators. – 3. A device may become an orphan due to beacon conflict. After receiving an orphan notification command, coordinators reply with either coordinator realignment command or beacon time notification command. If beacon time conflict is found, the device will send out a beacon conflict notification command to notify coordinators to adjust their beacon transmission time. Submission 6 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Direct and Indirect Beacon Conflict Problems • • Direct conflict: Indirect conflict: – Coordinators cannot reach other directly but there are devices within the overlapped area of their POSes – Example: Two coordinators use the same channel and their POSes overlap with each other – Multiple coordinators within the same POS – Example: Two coordinators with parent-child relationship D 1 C 2 C 1 Beacon C 2 Beacon C 1 C 2 Submission D 1 7 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Three Cases for Indirect Beacon Conflicts (1) Beacon C 1 D 1 C 2 C 3 C 2 • Case 1: D 1 is an end-device or a coordinator. D 1 has been associated to coordinator C 1 and is keeping waking up. Then Coordinator C 2 joins the WPAN by associating to a coordinator C 3. D 1 is also within C 2’s POS. C 2 cannot hear C 1’s beacon and may use the same channel with C 1 and send beacons at almost the same time with C 1. The beacon conflict happens at D 1 will lose its synchronization with C 1 and conduct orphan scan. After it gets C 1’s coordinator realignment command, it still cannot get C 1’s beacons. Submission 8 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Three Cases for Indirect Beacon Conflicts (2) Beacon C 1 D 1 C 2 C 3 C 2 • Case 2: D 1 has been associated to coordinator C 1 and often goes to sleep. During its sleep period, Coordinator C 2 joins the WPAN by associating to a coordinator C 3, and uses the same channel with C 1 and send beacons at almost the same time with C 1. D 1 is also within C 2’s POS. When D 1 wakes up, it loses its synchronization with C 1 and conducts orphan scan. After it gets C 1’s coordinator realignment command, it still cannot get C 1’s beacons. Submission 9 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Three Cases for Indirect Beacon Conflicts (3) Beacon C 1 D 1 C 2 C 1 C 2 • Case 3: Two coordinators C 1 and C 2 have been in the WPAN. They cannot hear to each other and may use the same channel and send beacons almost the same time. D 1 is an end-device or a coordinator. D 1 wants to join the WPAN but it happens to be at the overlapped area of C 1 and C 2 with indirect beacon conflicts. And there are no other coordinators within D 1’s POS to allow D 1 to associate. D 1 conducts active or passive scan but cannot get any beacons correctly due to indirect beacon conflicts. It will report “no-beacon” to upper layers. But this is a kind of “fake no-beacon” because there actually two coordinators within the POS of D 1. Submission 10 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Solutions to Direct Beacon conflict (1) • Change the superframe structure as starting with a Beacon period which can contain multiple beacon frames. • How does each coordinator choose a sending time of its own beacon frame within the Beacon period to avoid beacon conflicts? – Beacon time information is included in the beacon frame. – Before a coordinator associates or starts a new PAN, it conducts active scan. It can records the beacon times allocated to other coordinators and put the information into the neighboring coordinator table. Then it can choose its own beacon transmission time to avoid collisions with coordinators within its POS. BP CAP CFP CAP BP Superframe CAP: Contention Access Period CFP: Contention Free Period BP: Beacon Period Submission Superframe CFP Time Beacon 11 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Solutions to Direct Beacon conflict (2) • However, if two coordinators within the same POS join the WPAN almost at the same time, it is still possible that the two coordinators choose the conflicted beacon transmission time. – A simple solution: After a coordinator receives the association response command indicating successful and begins to do MLME-START, it will not send out a beacon in the first superframe. Instead, in the first one or several superframes, it will sense the channel during its beacon transmission time. If the channel idle, it will send beacons periodically, otherwise, it will rechoose its beacon transmission time to avoid conflicts. – The beacon conflict cannot be avoided completely. A beacon conflict notification command should be added to report beacon collisions. • • But how does a coordinator know the beacon time information of other coordinators outside its POS but have potential indirect beacon collisions with it? Indirect beacon conflict is a serious problem but not easy to solve! Submission 12 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Solutions to Indirect Beacon conflict (1) • Based on the beacon period solution • Two kinds of methods – Reactive approach • A coordinator doesn’t do much to avoid the indirect beacon collisions during its association stage. The indirect beacon collisions can be detected and resolved later. • Simplementation. Very small changes to 802. 15. 4 -2003. But long time to recover from indirect beacon collisions. – Proactive approach • A coordinator tries its best to avoid the indirect beacon collisions during association stage. If cannot avoided in advance, the indirect beacon collisions can be detected and resolved later. • Any device (FFD or RFD) needs to have the capability of forwarding its parent coordinator’s beacon time information. • A new command, beacon time notification, is added. • Complicated to maintain the neighboring coordinator table but lower possibility to cause indirect beacon conflicts. Submission 13 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Solutions to Indirect Beacon conflict (2) • Reactive approach – For the first case: After D 1 loses its synchronization with C 1, it will conduct orphan scan. After it gets C 1’s coordinator realignment command, if it cannot get beacons from C 1, it will do orphan scan again. After it gets the realignment command again but still cannot get beacon’s from C 1. It will send out a beacon conflict notification command which contains C 1’s address and beacon time information. Coordinators receiving the beacon conflict notification command will adjust its beacon time if a beacon conflict is found. – For the second case: After D 1 wakes up, it will lose synchronization with its coordinator. It will conduct similar procedure with that for the first case. Beacon C 1 D 1 C 2 C 3 C 2 Submission 14 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Solutions to Indirect Beacon conflict (3) • Reactive approach – For the third case: • Just do nothing if we allow the “fake no-beacon” exist. • If we want to detect this kind of “fake no-beacon” caused by beacon conflict, we can improve orphan scan procedure in 802. 15. 4 -2003 as follows. – Before D 1 reports “no-beacon”, it will do the scan procedure similar with orphan scan in which all coordinators who received the orphan notification command will respond. If a coordinator finds a device record of D 1 in its device list, it will reply with a coordinator realignment command, otherwise, it will reply with a beacon time notification command the tell its own beacon time information. If D 1 doesn’t receive any coordinator realignment command or beacon time notification command, it will report “no-beacon”, otherwise, D 1 will analyze the commands received and send out a beacon conflict notification command if finds any conflicts. Coordinators receiving the beacon conflict notification command will adjust its beacon time if a beacon conflict is found. – It can been seen the above scan procedure can also solve the problems in Case 1 and 2, but introduces more signaling overhead and changes to 802. 15. 4 -2003. Submission 15 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Solutions to Indirect Beacon conflict (4) • Proactive approach – First case: • Suggest that all devices respond to the beacon request command actively or passively. However, in 802. 15. 4 -2003, only coordinators can respond beacon request command. • After receiving a beacon request command, if a device is a coordinator, besides its beacons sent periodically, it will also reply with a beacon time notification command to report its parent coordinator’s beacon time information. • ( Another possible method: allow that one beacon frame can contain both its own and its parent coordinator’s beacon time information, so beacon notification commands from coordinators can be avoided). • If a device who received the beacon request command is not a coordinator, it will reply with a beacon time notification command to report its parent coordinator’s beacon time information. • With the above improvement, at the association stage, a coordinator can get beacon time information of other coordinators that have potential indirect beacon conflict with it. – Solutions for the second and the third case are the similar with those in reactive approach. Submission 16 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Discussion: Why 802. 15. 4 b must solve beacon conflict problem? • 802. 15. 4 -2003 definitely allows multiple coordinators with the same WPAN. • Two coordinators with parent-child relation must have beacon conflicts under 802. 15. 4 -2003 if they synchronize to each other (100% collision rate). • A tree topology with three coordinators (grandparent- parentchild) is an obvious case for indirect beacon conflicts. • The probability of direct and indirect beacon conflict depends on superframe size, beacon period size, and WPAN density, etc. In some cases it could be high. • In a word, direct and indirect beacon conflicts cannot be regarded as small probability event and be ignored. Submission 17 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b The probability analysis for Indirect beacon conflicts • Assume Beacon period can hold n beacons totally. • In a simple tree based multi-coordinator topology showed on the right, if coordinator C 1 and C 2 already exist, the probability of indirect beacon conflict is at least 1/(n-1) when coordinator C 3 associates to C 2. • If the superframe size is small, n should not be very large, for example, if n=8, the beacon conflict probability should be no less than 14. 3%. Submission 18 C 1 C 2 C 3 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b The probability analysis for Indirect beacon conflicts • Generally, assume beacon period can hold n beacons totally, and a coordinator C wants to join the WPAN by association, and there already m other coordinators within its POS and k other coordinators within its indirect beacon conflicts area. • The probability of indirect beacon conflict is at least k/(n-m). • For example, in the right diagram, if n=8, m=4, and k=2, the beacon conflict probability should be no less than 50%. Submission 19 GC 1 GC 2 PC 2 C 1 C 2 C Cm H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Discussion: Other Possible Solutions to Beacon Conflict • Asynchronous superframe mode (Using Ad hoc Beacon) – If there is no superframe synchronization requirement among coordinators in a WPAN, Asynchronous mode can be used, i. e. , each coordinator decides its superframe starting point randomly to avoid beacon conflicts with others. – However, this method introduces a new problem of collision between beacon and data frames. – In addition, most beacon-enabled WPANs require synchronization among coordinators. C 1 C 2 D 1 C 2 C 3 Submission 20 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Discussion: Other Possible Solutions to Beacon Conflict • Take advantage of Inactive portion (See 10. 4 in Zig. Bee Network Specification V 0. 92, Doc. 02130 r 9, July 29, 2004) • Question 1: If Indirect beacon conflict happens at an end-device, how to detect and report beacon conflict? • Question 2: Parent and Child coordinators’ CAP area don’t overlap, how can they transmit data to each other? • Question 3: Does a coordinator need to keep waking up, listen to the channel, receive data or even transmit data at its inactive period? Submission 21 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Discussion: Handling beacon conflicts at MAC or Network Layer? • • • From P. 17 of 802. 15. 4 -2003, “Features of MAC sub layer are beacon management, channel access, …”, it can be seen that beacon scheduling belongs to the MAC layer. The task of beacon scheduling is to find a suitable time slot for beacons. It is the typical medium access control problem. It should be done at the MAC layer. Beacon frames mark the MAC superframe boundaries and carry other control information. Beacons are only used by the MAC layer, not by the network layer at all. Beacon transmission only happens between nodes with one-hop distance. It is local issue, never uses routing information provided by the network layer. When a coordinator try to join an existed WPAN or start a new WPAN, it gets neighboring coordinators’ beacons during the scan stage, it can choose the beacon time at the MAC layer. There is no need to report to network layer first and then schedule beacons at the network layer by introducing extra overhead of Interactions between two layers. Submission 22 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

August 2004 doc. : IEEE 802. 15 -04 -0457 -00 -004 b Discussion: Handling beacon conflicts at MAC or Network Layer? • IEEE 802. 15. 4 standard is independent to other upper layer standard for WPAN. We cannot expect all other WPAN upper layer standards can help to solve the beacon conflict problem. • Even beacon scheduling is preferred to be done at the network layer rather than MAC layer, 802. 15. 4 still need to be changed. – Adding Start. Time to MLME-START. request() – Add the Beacon conflict notification command to detect and report beacon conflict because beacon conflict cannot be avoided completely with any solution. – Add the Beacon time notification command if “fake none-beacon” problem need to be solved. – Add mac. Beacon. Tx. Time. Offset attribute to MAC PIB – Any other changes? Submission 23 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric