July 2004 Project: IEEE P802.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 [8th 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.4b, Doc Number: 15-04-0239-00-004b.] Abstract: [Discussion for several enhancements to current IEEE 802.15.4] Purpose: [Proposal to IEEE 802.15.4b 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. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Enhancements to 802.15.4 Huai-Rong Shao, Jinyun Zhang, and Hui Dai July 2004 Enhancements to 802.15.4 Huai-Rong Shao, Jinyun Zhang, and Hui Dai Mitsubishi Electric Research Laboratories H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 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 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Direct and Indirect Beacon Conflict Problems within the same WPAN July 2004 Direct and Indirect Beacon Conflict Problems within the same WPAN Direct conflict: Multiple coordinators within the same POS Example: Two coordinators with parent-child relationship Indirect conflict: Coordinators cannot reach each 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 C1 C2 D1 Beacon C2 C1 Beacon D1 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Three Cases for Indirect Beacon Conflicts (1) July 2004 Three Cases for Indirect Beacon Conflicts (1) Beacon D1 C1 C2 C1 C3 C2 Case 1: D1 has been associated to coordinator C1 and is keeping waking up. Then Coordinator C2 joins the WPAN by associating to coordinator C3. D1 is also within C2’s POS. C2 cannot hear C1’s beacon and may use the same channel with C1 and send beacons at almost the same time with C1. The beacon conflict happens at D1. D1 will lose its synchronization with C1 and conduct orphan scan. After it gets C1’s coordinator realignment command, it still cannot get C1’s beacons. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Three Cases for Indirect Beacon Conflicts (2) July 2004 Three Cases for Indirect Beacon Conflicts (2) C2 C1 Beacon D1 C3 Case 2: D1 has been associated to coordinator C1 and often goes to sleep. During its sleep period, Coordinator C2 joins the WPAN by associating to coordinator C3, and uses the same channel with C1 and send beacons at almost the same time with C1. D1 is also within C2’s POS. When D1 wakes up, it loses its synchronization with C1 and conducts orphan scan. After it gets C1’s coordinator realignment command, it still cannot get C1’s beacons. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Three Cases for Indirect Beacon Conflicts (3) July 2004 Three Cases for Indirect Beacon Conflicts (3) C2 C1 Beacon D1 Case 3: Two coordinators C1 and C2 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 D1 wants to join the WPAN but it happens to be at the overlapped area of C1 and C2 with indirect beacon conflicts. And there are no other coordinators within D1’s POS to allow D1 to associate. D1 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 are actually two coordinators close to D1. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Direct Beacon conflict (1) July 2004 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. C2 C1 C3 D1 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Direct Beacon conflict (2) July 2004 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. Beacon BP Time CAP CFP Superframe CAP: Contention Access Period CFP: Contention Free Period BP: Beacon Period H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Direct Beacon conflict (3) July 2004 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 re-choose 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! H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Indirect Beacon conflict (1) July 2004 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. Simple implementation. 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. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Indirect Beacon conflict (2) July 2004 Solutions to Indirect Beacon conflict (2) Reactive approach For the first case: After D1 loses its synchronization with C1, it will conduct orphan scan. After it gets C1’s coordinator realignment command, if it cannot get beacons from C1, it will do orphan scan again. After it gets the realignment command again but still cannot get beacon’s from C1. It will send out a beacon conflict notification command which contains C1’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 D1 wakes up, it will lose synchronization with its coordinator. It will conduct similar procedure with that for the first case. C2 C1 Beacon D1 C3 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Indirect Beacon conflict (3) July 2004 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 D1 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 D1 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 D1 doesn’t receive any coordinator realignment command or beacon time notification command, it will report “no-beacon”, otherwise, D1 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. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Indirect Beacon conflict (4) July 2004 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. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Direct and Indirect Beacon Conflict among different WPANs July 2004 Direct and Indirect Beacon Conflict among different WPANs Direct conflict: Multiple coordinators within the same POS but belong to different WPANs Example: Two PAN coordinators at 868Mhz close to each other. Indirect conflict: Coordinators cannot reach each 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 C1 C2 D1 Beacon C2 C1 Beacon D1 PAN1 PAN2 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to Beacon conflicts among coordinators in different PANs July 2004 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. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Problem Statement for Time Synchronization in 802.15.4 July 2004 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 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Timing in Packet Transmission July 2004 Timing in Packet Transmission Coordinator Device Packet reach MAC layer at t4 Packet created at t1 MAC MAC PHY PHY First bit on Channel at t2 First bit of Packet is received at t3 At t1, packet is created in MAC layer. t1 is the carried timestamp At t2, the first bit of Packet is put on the channel by sender At t3, the first bit of Packet is received by receiver At t4, packet passes the PHY layer and is accepted by MAC layer H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Timing Orders t1 t2 t3 t4 Coor’s Clock t1’ t2’ t3’ t4’ Device’s Clock July 2004 Timing Orders t1 t2 t3 t4 Coor’s Clock t1’ t2’ t3’ t4’ Device’s Clock At the same time point, the time readings maybe different due to clock drift H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

In the above scenario … Ideal case: However, t4’ should be set to t4 July 2004 In the above scenario … Ideal case: Device simply adjusts its timer from t4’ to t1. t1 is the timestamp in the packet received. However, t4’ should be set to t4 Errors Sources: Propagation Delay t3 – t2 : message propagation time in the air Access Error t2 – t1: time needed for processing at sender’s network interface before being put in the channel Receive Error t4 – t3: time needed for processing at receiver’s network interface We need to minimize/estimate Access Error, Receive Error and estimate Propagation Delay H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Propagation Delay Coordinator Device Beacon Interval Propagation Delay July 2004 Propagation Delay Beacon Interval Coordinator Propagation Delay Device Propagation Delay varies for different devices POS is limited to 10m in 802.15.4-2003 Propagation Delay is small (<=33.33ns) and relatively easier to calculate H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Processing Error If there is no processing delay on both sides: July 2004 Processing Error If there is no processing delay on both sides: Packet Timestamp t1 should be the same as t2, i.e the time when the first bit is passed to the channel Receiving time t4’ should be the same as t3’, 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 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 Solution 1 Similar to 802.11, access error and receive error are estimated Mechanism Coordinator estimates T = t2-t1 and accordingly adjusts the timestamp in packet as t1+T Device estimates T’ = t4’-t3’ At t4’, device sets its timer to t1+T+ T’. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solution 2 Require the Physical layer support time reading function July 2004 Solution 2 Require the Physical layer support time reading function Mechanism: In the coordinator side, it still estimates t2-t1 and accordingly adjusts the timestamp in packet to t1+T. While in the device side, it reads the time at exactly t3’ at PHY layer. Thus, the receiver error is minimized. Device adjusts its timer by adding t1+T– t3’. Add attributes to PHY PIB phyTimeOn: boolean switch physical timer between on and off to avoid overhead phyRxTime: The receiving time of the first bit of latest PSDU from the physical medium H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solution 3: To be more accurate July 2004 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 t2-t1 and accordingly adjusts the timestamp in synchronization message Coordinator sends synchronization message to device. t2 is recorded in phyTxTime Device receives synchronization message and reads the time t3’ at physical layer Coordinator sends MLME-TIME.notify to device Device set its timer by adding t2– t3’. If the MAC command is lost due to packet collision, the device could still use the adjusted timestamp to correct the local clock. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solution 3: To be more accurate (Cont.) July 2004 Solution 3: To be more accurate (Cont.) Add another attribute to PHY PIB phyTxTime The sending time of the first bit of previous PSDU at the physical medium Adding a new MAC command MLME-TIME.notify To carry phyTxTime H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Error Upper Bound Estimation for All Above Solutions July 2004 Error Upper Bound Estimation for All Above Solutions Define new variable maxProcessingError maxPropagationDelay Synchronization Error Upper Bound: maxProcessingError + maxPropagationDelay H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Other Issues in Time Synchronization July 2004 Other Issues in Time Synchronization Time synchronization conducted at association procedure Use Beacon for time synchronization in beacon-enable network Add optional timestamp fields to Beacon payload Adjusting lSynchronization period Add a new variable : aTimeSyncOrder aSuperframeDurationTime*aTimeSyncOrder Use specific message for time synchronization in non-beacon network H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Parameter mismatch problem July 2004 Parameter mismatch problem In some parameter settings, packet size could be bigger than superframe size 915 MHZ superframe order=0 Beacon order=0 aBaseSuperframeDuration =16*60/40 = 24 (ms) However .. aMaxPHYPacketSize = 127 byte Time to tx maxpacket = 27*8/40 = 25.4ms > 24 ms Maximum possible size Without backoff, 120 bytes, with 1 backoff & 2 CCA, at most 112 bytes Same problem in 868 MHZ band H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solutions to parameter mismatch problem July 2004 Solutions to parameter mismatch problem Solution 1: Decrease the maximum packet size for 915 and 868 Mhz Solution 2: maxSuperframeOrder and macBeaconOrder begins from 1 instead of 0 H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Duplicated ASSOCIATE.response Problem July 2004 Duplicated ASSOCIATE.response Problem Scenario : ASSOCIATE.request Acknowledgement Device Coordinator ASSOCIATE.response Ack Lost ASSOCIATE.response ?? (retransmission) What should device do with retransmitted ASSOCIATE.response ? H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Solution to Duplicated ASSOCIATE.response July 2004 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. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Priorities between commands and data July 2004 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 and data transmissions H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

Multiple superframe sizes in the same WPAN July 2004 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. H. Shao, J. Zhang, H. Dai, Mitsubishi Electric

July 2004 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, shortAddress, and LogicalChannel H. Shao, J. Zhang, H. Dai, Mitsubishi Electric