July 2004 doc IEEE 802 15 04 0313

  • Slides: 35
Download presentation
July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Project: IEEE

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Enhancements to

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Proposals •

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 • Parameter mismatch problem • Duplicated ASSOCIATE. response • Priorities between commands and data • Multiple superframe sizes in the same WPAN • Error in Figure 76 Submission 3 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Direct and

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Three Cases

July 2004 doc. : IEEE 802. 15 -04 -0313 -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 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 -00 -004 b Three Cases

July 2004 doc. : IEEE 802. 15 -04 -0313 -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 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 -00 -004 b Three Cases

July 2004 doc. : IEEE 802. 15 -04 -0313 -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. 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 -00 -004 b Solutions to

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Solutions to

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Solutions to

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Solutions to

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

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Solutions to

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

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Solutions to

July 2004 doc. : IEEE 802. 15 -04 -0313 -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” 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 -00 -004 b Solutions to

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

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Direct and

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Solutions to

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Problem Statement

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Problem Statement for Time Synchronization in 802. 15. 4 • Time synchronization is important – Detect the Superframe/Slot Boundary – Maintain superframe synchronization among coordinators – Preserve the event orders. • Difficulty – Clock 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 -00 -004 b Timing in

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Timing Orders

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b In the

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b In the above scenario … • Ideal 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 -00 -004 b Propagation Delay

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Processing Error

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 in 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 -00 -004 b Solution 1

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Solution 1 • Similar to 802. 11, access error and receive error are estimated • 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 -00 -004 b Solution 2

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Solution 2 • Require the Physical layer support time reading function • Mechanism: – In the coordinator side, it still estimates 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’. • 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 -00 -004 b Solution 3:

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Solution 3:

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Error Upper

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 -00 -004 b Other Issues

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 l. 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 -00 -004 b Parameter mismatch

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Parameter mismatch problem • 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 = 27*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 29 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Solutions to

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

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Duplicated ASSOCIATE.

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Duplicated ASSOCIATE. response Problem Scenario : ASSOCIATE. request Acknowledgement Device ASSOCIATE. response Coordinator Ack Lost ? ? ASSOCIATE. response (retransmission) • What should device do with retransmitted ASSOCIATE. response ? Submission 31 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Solution to

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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 matched, the device sends back ACK to the coordinator that sent this ASSOCIATE. response. Otherwise, it discards this ASSOCIATE. response. Submission 32 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Priorities between

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Priorities between commands and data • Suggest to set different priorities for command, data and maybe ad-hoc beacon frames. • Why? – Command frame usually is more important than data – Some commands broadcast and cannot use ACK for reliable transmission • How? Set different backoff time between command data transmissions Submission 33 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Multiple superframe

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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: Either distinguish priorities of data and beacon transmissions or specify same superframe size for all coordinators in the same WPAN. Submission 34 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -004 b Error in

July 2004 doc. : IEEE 802. 15 -04 -0313 -00 -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