Doc.: IEEE 802.15-04-0457-00-004b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 1 Project: IEEE P802.15 Working Group for.

Slides:



Advertisements
Similar presentations
Doc.: IEEE e Submission Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Modifying.
Advertisements

An introduction Jan Flora Department of Computer Science University of Copenhagen.
Doc.: IEEE Submission ETRI May 2015 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
IEEE e Submission: Wireless Ping for Network Management 8 September 2008 Bhatti, Mitsubishi ElectricSlide 1 Project: IEEE P
Doc.: IEEE Submission September 2004 Poor, Shao et al: Ember, Mitsubishi Electric Research LabsSlide 1 Project: IEEE P Working.
Doc.: IEEE /037r0 Submission January 2003 Ed Callaway, Motorola Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE /xxxr0 Submission Phil Jamieson November 2002 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: e Submission Liang Li, J Shen,Betty ZhouSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE b Submission September 2004 Myung Lee, et al,Slide 1 NOTE: Update all red fields replacing with your information; they.
Doc.: IEEE e SubmissionSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [beacon.
Doc.: IEEE b Submission Sept H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 1 Project: IEEE P Working Group for Wireless.
Doc.: IEEE b Submission July 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 1 Project: IEEE P Working Group for Wireless.
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE :
Doc.: IEEE /080r0 Submission February 2004 Welborn, MotorolaSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc: IEEE Submission May 2015 Hernandez,Li,Dotlić,Miura (NICT)Slide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE Submission May 2014, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Response.
e Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [The embedded.
Doc.: IEEE Submission May 2015 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE Submission Oct Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: b Submission Mar Song-Lin Young[Sharp Labs.] Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE /115r1 Submission February 2001 Mark Schrader, Eastman Kodak Co.Slide 1 Project: IEEE P Working Group for Wireless Personal Area.
Submission Slide 1 doc.: IEEE e September 2009 [Lee, et al] Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.IEEE b Submission Nov 2004 Liang Li, WXZJ Inc. Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.:IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE e Submission Jan, 2009 Ning Gu, Liang Zhang, Haito Lui Slide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE COEX-02/004r0 Submission 23 January, 2001 James P. K. Gilb, Appairent Technologies Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE b Submission Aug H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 1 Project: IEEE P Working Group for Wireless.
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Communicating.
Doc.: IEEE e Submission July 2009 Andy Summers, Skip Ashton, EmberSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE m SubmissionSlide 1 May 2012 Project: IEEE P Working Group for Wireless Personal Area Networks(WPANs) Submission.
Submission Title: [EGTS Subgroup Report for IEEE e]
March 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Synchronized Beacon Propagation for Spanning.
doc.: IEEE <doc#>
<month year> xxx e March 2008
May Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Introduction of MAC related proposals] Date.
<doc.: IEEE −doc>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<month year> doc.: IEEE <01/137> March 2001
doc.: IEEE <doc#>
Submission Title: [Beacon scheduling MAC hooks]
November, 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposal for PostBeaconDelay in b]
Submission Title: [Extend-Superframe and Extend-GTS Structure]
Date Submitted: [November 9, 2009]
doc.: IEEE <doc#>
Submission Title: IEEE : Management Slots in the MAC.
Date Submitted: [November 9, 2009]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
November 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Distributed channel hopping MAC for industrial.
Submission Title: IEEE : Management Slots in the MAC.
July 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Enhancements to IEEE ] Date Submitted:
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Supporting peer to peer and improving throughput by.
24 February 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Issues with Beacon-Mode SuperFrame.
< April, 2012 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improvement of Data Transmission in.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<month year> doc.: IEEE <doc#>
doc.: IEEE <doc#1>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Name - WirelessHD March 2010
doc.: IEEE <doc#>
<month year> doc.: IEEE August 2014
4 May 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Issues with Beacon-Mode SuperFrame Structure.
doc.: IEEE <doc#1>
Aug Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Explanation and Revision of Previous Time.
Source: [Chunhui Zhu] Company [Samsung]
Aug Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Explanation and Revision of Previous Time.
Presentation transcript:

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Solutions and discussions to direct and indirect beacon conflict problem for IEEE b ] Date Submitted: [August 24, 2004] Source: [Huai-Rong Shao, Jinyun Zhang and Hui Dai] Company [Mitsubishi Electric Research Labs] Address [8th Floor, 201 Broadway, Cambridge, MA ] Voice:[ ], FAX: [ ], Re: [Response to call for proposal of IEEE b, Doc Number: b.] Abstract:[Further discussion and revision of beacon conflict proposal in b. Original proposal is at b ] Purpose:[Proposal to IEEE b Task Group] Notice:This document has been prepared to assist the IEEE P 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

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 2 Solutions and discussions to direct and indirect beacon conflict problem for IEEE b –Original proposal is at b Huai-Rong Shao, Jinyun Zhang and Hui Dai Mitsubishi Electric Research Laboratories

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 3 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?

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 4 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. C2 C1 Beacon C1C2 D1 C3

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 5 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.

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 6 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.

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 7 Direct and Indirect Beacon Conflict Problems 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 C1C2 D1 C2 C1 Beacon C2 C1 Beacon C1C2 D1

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 8 Three Cases for Indirect Beacon Conflicts (1) Case 1: D1 is an end-device or a coordinator. D1 has been associated to coordinator C1 and is keeping waking up. Then Coordinator C2 joins the WPAN by associating to a 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. C2 C1 Beacon C1C2 D1 C3

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 9 Three Cases for Indirect Beacon Conflicts (2) 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 a 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. C2 C1 Beacon C1C2 D1 C3

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 10 Three Cases for Indirect Beacon Conflicts (3) 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. D1 is an end-device or a coordinator. 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 within the POS of D1. C2 C1 Beacon C1C2 D1

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 11 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. Beacon BP Time CAPCFP Superframe CAP: Contention Access Period CFP: Contention Free Period BP: Beacon Period BP CAPCFP Superframe

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 12 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 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!

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 13 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 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.

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 14 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 C1C2 D1 C3

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 15 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 as follows. –Before D1 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 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 above scan procedure can also solve the problems in Case 1 and 2, but introduces more signaling overhead and changes to

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 16 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 , 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.

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 17 Discussion: Why b must solve beacon conflict problem? definitely allows multiple coordinators with the same WPAN. Two coordinators with parent-child relation must have beacon conflicts under if they synchronize to each other (100% collision rate). A tree topology with three coordinators (grandparent- parent- 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, direct and indirect beacon conflicts cannot be regarded as small probability event and be ignored.

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 18 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 C1 and C2 already exist, the probability of indirect beacon conflict is at least 1/(n-1) when coordinator C3 associates to C2. 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%. C1 C2 C3

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 19 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 are 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%. C GC1 PC2 C1C2Cm GC2

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 20 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. C2 C1 C3 C1 C2 D1 C3

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 21 Discussion: Other Possible Solutions to Beacon Conflict Take advantage of Inactive portion (See 10.4 in ZigBee Network Specification V0.92, Doc r9,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?

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 22 Discussion: Handling beacon conflicts at MAC or Network Layer? From P.17 of , “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.

doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 23 Discussion: Handling beacon conflicts at MAC or Network Layer? IEEE 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, still need to be changed. –Adding StartTime 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 macBeaconTxTimeOffset attribute to MAC PIB –Any other changes?