July 2004 doc IEEE 802 15 04 0313

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Enhancements to IEEE 802. 15. 4] Date Submitted: [July 5, 2004] Source: [Huai-Rong Shao, Jinyun Zhang, 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 the call for proposal of IEEE 802. 15. 4 b, Doc Number: 15 -04 -0239 -00 -004 b. ] Abstract: [Discussion for several enhancements to current IEEE 802. 15. 4] 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

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Enhancements to 802. 15. 4 Huai-Rong Shao, Jinyun Zhang, and Hui Dai Mitsubishi Electric Research Laboratories Submission 2 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Proposals • Solutions to Direct and Indirect beacon conflicts in a WPAN with multiple coordinators • Solutions to beacon conflicts between coordinators at different WPANs • Time synchronization solutions for 802. 15. 4 • Time offset problem for big superframe • Parameter mismatch problem: A MAC packet could be larger than a superframe • Multiple superframe sizes in the same WPAN • Error in Figure 76 • Priorities between commands and data • Duplicated ASSOCIATE. response • Further explanations for beacon conflict and time synchronization topics Submission 3 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Direct and Indirect Beacon Conflict Problems within the same WPAN • • 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 4 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Three Cases for Indirect Beacon Conflicts (1) Beacon C 1 D 1 C 2 C 3 C 2 • Case 1: D 1 has been associated to coordinator C 1 and is keeping waking up. Then Coordinator C 2 joins the WPAN by associating to 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 5 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -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 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 6 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -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. Then 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 nobeacon” because there actually two coordinators close to D 1. Submission 7 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solutions to Direct Beacon conflict (1) • Asynchronous superframe mode – 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 8 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solutions to Direct Beacon conflict (2) • • 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? – Each coordinator maintains and updates a neighboring coordinator table which records the beacon time information of its direct and indirect neighboring coordinators. – 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 9 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solutions to Direct Beacon conflict (3) • 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 10 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -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 11 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -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 12 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solutions to Indirect Beacon conflict (3) • Reactive approach – For the third case: • Just do nothing if we allow the “fake no-beacon” to be reported. • 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 improved 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 improved orphan 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 13 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -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 14 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Direct and Indirect Beacon Conflict among different WPANs • • Direct conflict: Indirect conflict: – Coordinators cannot reach other directly but there are devices within the overlapped area of their POSes – Example: Two WPANs use the same channel and their POSes overlap with each other – Multiple coordinators within the same POS but belong to different WPANs – Example: Two PAN coordinators at 868 Mhz close to each other. D 1 C 2 PAN 1 Beacon D 1 C 2 PAN 2 Beacon C 1 C 2 Submission C 1 15 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solutions to Beacon conflicts among coordinators in different PANs • If there is superframe synchronization requirement between two WPANs, similar solutions with those for the same WPAN. • If there is no superframe synchronization requirement between two WPANs, but coordinators are synchronized in each WPAN, the devices within the overlapped area need to detect the beacon conflict, and calculate the time relation between superframes from two WPANs. With the time relation, similar solutions to solve the beacon conflicts with those for coordinators within the same PAN. • If the two PANs choose different Superframe sizes, the coordinator with the bigger superframe need to maintain a table to record those time slots in CAP and CFP allocated to beacons in the other WPAN to avoid the collisions between beacon and data frames. Another solution is to set different transmission priorities for beacons and data frames. Submission 16 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Problem Statement for Time Synchronization in 802. 15. 4 • Time synchronization is important – Maintain superframe/slot synchronization among devices – fine-tuned coordination of wake/sleep duty cycles to reduce power consumption – Preserve the event orders – Time synchronization is also important to security protocols since the clock reading is often used for encryption key generation – Loop free routing (Robert Poor said) • Difficulty – Time drift due to various reasons including both software and hardware Submission 17 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Timing in Packet Transmission Coordinator Packet created at t 1 First bit on Channel at t 2 • • Device MAC PHY Packet reach MAC layer at t 4 First bit of Packet is received at t 3 At t 1, packet is created in MAC layer. t 1 is the carried timestamp At t 2, the first bit of Packet is put on the channel by sender At t 3, the first bit of Packet is received by receiver At t 4, packet passes the PHY layer and is accepted by MAC layer Submission 18 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Timing Orders t 1 t 2 t 3 t 4 Coor’s Clock t 1’ t 2’ t 3’ t 4’ Device’s Clock At the same time point, the time readings maybe different due to clock drift Submission 19 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b In the above scenario … • Simple case: – Device simply adjusts its timer from t 4’ to t 1 is the timestamp in the packet received. • However, t 4’ should be set to t 4 • Errors Sources: – Propagation Delay • t 3 – t 2 : message propagation time in the air – Access Error • t 2 – t 1: time needed for processing at sender’s network interface before being put in the channel – Receive Error • t 4 – t 3: time needed for processing at receiver’s network interface • We need to minimize/estimate Access Error, Receive Error and estimate Propagation Delay Submission 20 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Propagation Delay Beacon Interval Coordinator Propagation Delay Device • • • Propagation Delay varies for different devices POS is limited to 10 m in 802. 15. 4 -2003 Propagation Delay is small (<=33. 33 ns) and relatively easier to calculate Submission 21 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Processing Error • If there is no processing delay on both sides: – Packet Timestamp t 1 should be the same as t 2, i. e the time when the first bit is passed to the channel – Receiving time t 4’ should be the same as t 3’, i. e. the time when the first bit is received • Thus, to increase accuracy … – Timer should be read at the PHY layer in order to minimize the error. • However, packet is created at the MAC layer, which implies the timestamp in sender side must be obtained at MAC layer Submission 22 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solution 1 • Similar to 802. 11, access error and receive error are estimated at the MAC layer • Mechanism – Coordinator estimates T = t 2 -t 1 and accordingly adjusts the timestamp in packet as t 1+T – Device estimates T’ = t 4’-t 3’ – At t 4’, device sets its timer to t 1+T+ T’. Submission 23 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solution 2 • Require the Physical layer support time reading function • Mechanism: – At the coordinator side, it still estimates T=t 2 -t 1 and accordingly adjusts the timestamp in packet to t 1+T. – While in the device side, it reads the time at exactly t 3’ at PHY layer. Thus, the receiver error is minimized. – Device adjusts its timer by adding t 1+T– t 3’=t 2 -t 3’~=t 3 -t 3’. • Add attributes to PHY PIB – phy. Time. On: boolean • Switch physical timer between on and off to avoid overhead – phy. Rx. Time: • The receiving time of the first bit of latest PSDU from the physical medium Submission 24 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solution 3: To be more accurate • Based on Solution 2, but the coordinator sends two packets to the device. The synchronization message carries the adjusted timerstamp while the following MAC command carries the actual transmitting time at the physical layer. • Mechanism: – Coordinator estimates access error t 2 -t 1 and accordingly adjusts the timestamp in synchronization message – Coordinator sends synchronization message to device. t 2 is recorded in phy. Tx. Time – Device receives synchronization message and reads the time t 3’ at physical layer – Coordinator sends MLME-TIME. notify to device – Device set its timer by adding t 2– t 3’. • If the MAC command is lost due to packet collision, the device could still use the adjusted timestamp to correct the local clock. Submission 25 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solution 3: To be more accurate (Cont. ) • Add another attribute to PHY PIB – phy. Tx. Time • The sending time of the first bit of previous PSDU at the physical medium • Adding a new MAC command – MLME-TIME. notify – To carry phy. Tx. Time Submission 26 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Error Upper Bound Estimation for All Above Solutions • Define new variable – max. Processing. Error – max. Propagation. Delay • Synchronization Error Upper Bound: – max. Processing. Error + max. Propagation. Delay Submission 27 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Other Issues in Time Synchronization • Time synchronization conducted at association procedure • Use Beacon for time synchronization in beaconenable network – Add optional timestamp fields to Beacon payload – Adjusting Synchronization period • Add a new variable : a. Time. Sync. Order • a. Superframe. Duration. Time*a. Time. Sync. Order • Use specific message for time synchronization in non -beacon network Submission 28 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Time offset problem for big superframe • PPM means parts per million which means, for 1 milliion pulses, how many deviation will be there. Thus 40 ppm means for every 1 million (10^6) pulses, there would be 40 deviation. For a crystal with K MHZ, the clock offset per second would be 1/K * 40 = 40 us. And two neighboring nodes’ clock difference could be up to 80 us per second in the worst case. • With beacon order k, the length of the superframe is 60*2 k*16/62. 5 ms = 0. 01536 * 2 ks. • At 2. 5 Ghz band, – Transmission time for 1 symbol is 16 us (1/62. 5 ms) – A bit transmission takes about 1/250 ms = 4 us • In order to receive a packet, a node needs to sense at least 2 out of the 4 preambles in order to make sure it’s actually a packet. Thus, it can only miss at most 16 bits. On the 2. 4 G band, the transmission time of 2 bytes is 16/250 = 0. 064 ms = 64 us. Submission 29 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Beacon order Superframe duration Clock offset per superframe (40 ppm) Offset of bits per superframe Offset of symbosls per superframe Frequency (1 sync per # of superframes) 0 15. 36 ms 0. 61 us <1 bit <1 65 1 30. 72 ms 1. 23 us <1 bit <1 32 2 61. 44 ms 2. 46 us <1 bit <1 18 3 122. 88 ms 4. 92 us About 1 bit <1 8 4 245. 76 ms 9. 83 us About 2 bits <1 4 5 491. 52 ms 19. 66 us About 4 bits 1 2 6 983. 04 ms 39. 32 us 8=1 byte 2 <=1 7 1. 966 s 78. 64 us 16=2 bytes 4 <=1 8 3. 93 s 157. 29 us 32=4 bytes 8 <=1 9 7. 86 s 314. 57 us 64=8 bytes 16 <=1 10 15. 73 s 629. 14 us 128=16 bytes 32 <=1 11 31. 46 s 1. 26 ms 256=32 bytes 64 <=1 12 62. 91 s 2. 52 ms 512=64 bytes 128 <=1 13 125. 83 s 5. 03 ms 128 bytes 256 <=1 14 251. 66 s 10. 07 ms 256 bytes 512 <=1 Submission 30 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Time offset problem found from the table • When beacon order is high, the slot boundary calculation might be inaccurate at the end of the superframe. • Solution 1: Parameter adjustment • Solution 2: Clarify that in beacon-enabled network with big superframe size, GTS cannot be used. But how to decide the maximal Beacon order? Submission 31 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Parameter mismatch problem: A MAC packet could be larger than a superframe • In some parameter settings, packet size could be bigger than superframe size – 915 MHZ superframe order=0 Beacon order=0 • a. Base. Superframe. Duration =16*60/40 = 24 (ms) • However. . – a. Max. PHYPacket. Size = 127 byte – Time to tx maxpacket = 127*8/40 = 25. 4 ms > 24 ms • Maximum possible size – Without backoff, 120 bytes, – with 1 backoff & 2 CCA, at most 112 bytes – Same problem in 868 MHZ band Submission 32 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solutions to parameter mismatch problem • Solution 1: Decrease the maximum packet size for 915 and 868 Mhz • Solution 2: max. Superframe. Order and mac. Beacon. Order begins from 1 instead of 0 Submission 33 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Multiple superframe sizes in the same WPAN • P. 100, 7. 1. 14. 1 MLME-START. request and P. 148 7. 5. 2. 4 Beacon generation, both PAN coordinators and coordinators can specify the Beacon order and superframe order • 802. 15. 4 -2003 didn’t specify all coordinators within the same beacon-enabled WPAN should use the same superframe size • If use different superframe sizes, collisions between data and beacon frames may happen • Solution 1: Specify same superframe size for all coordinators in the same WPAN by the PAN coordinator. • Solution 2: Either distinguish priorities of data and beacon transmissions Submission 34 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Error in Figure 76 • • According to page. 148, 7. 5. 2. 3 Starting a PAN requires to perform Active Scan Page. 180, Figure 76 should add Active Scan after the Energy detection SCAN but before selecting PANId, short. Address, and Logical. Channel Submission 35 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Priorities between commands and data • Suggest to set different priorities for command, data and maybe ad-hoc beacon frames. • Why? – Some MAC commands would be more important than data – Some commands or data may broadcast and cannot use ACK for reliable transmission • Solution 1: Set different back off contention window sizes for different priorities packets • Solution 2: Add some period of delay before back off, and different priorities packet will choose different delay time. Submission 36 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Duplicated ASSOCIATE. response Problem Scenario : p. 71 Figure 25 ASSOCIATE. request Acknowledgement Device ASSOCIATE. response Coordinator Ack Lost ? ? • • ASSOCIATE. response (retransmission) ACK frame could be lost even no access collision. What should device do with retransmitted ASSOCIATE. response ? Submission 37 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Solution to Duplicated ASSOCIATE. response • Solution – When a device receives duplicated ASSOCIATE. response, it checks whether it’s the same as the local configuration. If they are not matched, the device sends back ACK to the coordinator that sent this ASSOCIATE. response. Otherwise, it discards this ASSOCIATE. response. Submission 38 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Answers three questions on beacon conflicts • Q 1: What’s the probability of indirect beacon conflict? If it is rarely happens, there is no need to add mechanisms to make the standard complicated. • A: The probability could be high enough in some cases by theoretical analysis. • Q 2: Why to handle beacon conflicts at the MAC layer? It should be handled at the network layer. • A: It is possible to ask network layer to perform some tasks, however, MAC layer cannot avoid taking some actions besides a time information. In addition, handling beacon conflicts at MAC layer can avoid extra interactions between Network and MAC layers. • Q 3: What’s the minimized change to current 802. 15. 4 to handle direct and indirect beacon conflicts? • A: Very small changes. Submission 39 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b The probability of beacon conflict • Two coordinators with parent-child relation must have beacon conflicts under 802. 15. 4 -2003 if they synchronize to each other. • A tree topology with three coordinators (grandfatherparent-child) 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, indirect beacon conflicts cannot be regarded as small probability event and be ignored. Submission 40 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b The probability analysis for Indirect beacon conflicts • Assume Beacon period can hold n beacons totally. • In a simple tree based multicoordinator topology showed on the right, the probability of indirect beacon conflict is at least 1/(n-1). • 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 41 C 2 C 3 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b The probability analysis for Indirect beacon conflicts • Generally, assume Beacon period can hold n beacons totally, and a coordinator want to join the WPAN by association, and there are 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 1/(n-m-k). • For example, in the right diagram, if n=8, m=4, and k=1, the beacon conflict probability should be no less than 33%. Submission 42 GC 1 PC 2 C 1 C 2 C Cm H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Handling beacon conflicts: at MAC or Network layer? • P. 17 of 802. 15. 4 -2003, features of MAC sub layer are beacon management, …. . • When a coordinator associate, it gets neighboring coordinators’ beacons during the scan stage at the MAC layer, 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 the overhead of Interactions between two layers. • Beacon conflicts can only happen with the double transmission range, it is local issue, can be handled at MAC layer. • Beacon conflict detection can be handled at MAC layer • PAN descriptor and device list handled at the MAC layer • Neighboring table is handled at the network layer • What could be taken at either network or MAC? What must be taken at the MAC layer? Submission 43 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Indirect beacon conflict area None beacon conflict area C r r Direct beacon conflict area Different beacon conflict areas for a coordinator Submission 44 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Minimal changes to 802. 15. 4 for handling beacon conflicts (1) • Introduce new MAC constants or PIB attributes: Length of beacon period mac. Beacon. Period. Duration, beacon slot size a. Beacon. Slot. Duration, beacon slot number assigned to the coordinator mac. Beacon. Slot. Assigned, or other similar parameters about beacon period. • (If consider beacons can have variable sizes, mac. Beacon. Period. Duration, mac. Beacon. Frame. Duration and mac. Beacon. Starting. Position can replace the above three parameters). • The above three parameters are required in both direct and indirect beacon conflict handlings. Submission 45 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b Minimal changes to 802. 15. 4 for handling beacon conflicts (2) • Beacon conflict notification command needs to be added for indirect beacon conflict. • Beacon time notification command needs to be added if “fake no-beacon” case need to be solved (optional). • Neighboring coordinator table needs to be added if try to provide proactive method for indirect beacon conflict (optional). Submission 46 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -01 -004 b More explanations about time synchronization part – The ideas of solution 2 and 3 are very similar with those specified in IEEE-1588 (Thanks Ed for providing the information) – However, IEEE-1588 doesn’t define the related PIB attributes, MAC commands and Performance up bound parameters. – We suggest the follow terms be specified in 802. 15. 4 as optional • Up bound parameters – max. Processing. Error – max. Propagation. Delay • Solution 2: – phy. Time. On: boolean • Switch physical timer between on and off to avoid overhead – phy. Rx. Time: • The receiving time of the first bit of latest PSDU from the physical medium • Solution 3: – phy. Tx. Time – MLME-TIME. notify – Why? Some people told me their WPAN device hardware supports time reading and setting functions already. Parameter standardization helps to implement time synchronization between devices from different device providers. Submission 47 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric