Download presentation
Presentation is loading. Please wait.
Published byΊρις Ζαΐμης Modified over 5 years ago
1
Some thoughts on potential issues in mesh operation
January 2006 doc.: IEEE /340r0 May 2006 Some thoughts on potential issues in mesh operation Date: Authors: Notice: This document has been prepared to assist IEEE 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
2
January 2006 doc.: IEEE /340r0 May 2006 Abstract Slides for discussion of the potential issues which may occur in the mesh environment, specifically focusing on : The size of routing table Reliability risk of broadcast frames Broadcast Storm Problem Beacon Broadcaster rotation TSF synchronization and Topology dynamics Motivation of these slides is to check how the current draft spec treats these issues. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
3
The size of routing table
January 2006 doc.: IEEE /340r0 May 2006 The size of routing table The number of routing table entry equals to the number of destination node (identified by the MAC address) handled in the mesh. Number of the destination node potentially includes: Mesh Points in the mesh. STAs under the umbrella of MAPs. Any other nodes which are identified by 48-bit universal LAN MAC address and maintain connectivity via L2 bridging with Mesh Portals. The number of the routing table entry may be increased significantly, if the mesh has a large number of STAs under its MAPs and/or the Mesh Portals provide a large connectivity via L2 bridging. The number of routing table entry effects the processing overhead and the required memory size. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
4
The size of routing table (cont’d)
January 2006 doc.: IEEE /340r0 May 2006 The size of routing table (cont’d) In this example, the routing table entry includes all the node from STA#1 thru Node#9. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
5
The size of routing table (cont’d)
January 2006 doc.: IEEE /340r0 May 2006 The size of routing table (cont’d) Isn’t is possible that MPP and MAP perform proxy? May contradict with route discovery... Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
6
Reliability risk of broadcast frames
January 2006 doc.: IEEE /340r0 May 2006 Reliability risk of broadcast frames According to P REVma/D5.2 : “The fundamental access method of the IEEE MAC is a DCF known as carrier sense multiple access with collision avoidance (CSMA/CA)” [in subclause 9.1.1], which has a risk for collision and depends on ARQ mechanisms for recovery. “There is no MAC-level recovery on broadcast or multicast frames, except for those frames sent with the ToDS bit set” [in subclause 9.2.7], where the exception implies the message is directed to AP only. This assumption is not valid for broadcasting in mesh environment. “As a result, the reliability of this traffic is reduced, relative to the reliability of directed traffic, due to the increased probability of lost frames from interference, collisions, or time-varying channel properties”. It is concluded that the reliability of broadcast traffic is low, (especially in the absence of a PCF). Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
7
January 2006 doc.: IEEE /340r0 May 2006 Reliability risk of broadcast frames particularly in the mesh environment Level 1: Broadcast traffic without any treatment is under the risk of collisions, interference, or time-varying channel properties. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
8
January 2006 doc.: IEEE /340r0 May 2006 Reliability risk of broadcast frames particularly in the mesh environment Level 2: Broadcast traffic with scheduled transmission is under the risk of hidden node, interference, or time-varying channel properties. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
9
January 2006 doc.: IEEE /340r0 May 2006 Reliability risk of broadcast frames particularly in the mesh environment Level 3: Broadcast traffic with scheduled TX/RX becomes as reliable as broadcast frame transmission using PCF in BSS. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
10
January 2006 doc.: IEEE /340r0 May 2006 Reliability risk of broadcast frames particularly in the mesh environment Level 4: Broadcast traffic with ARQ recovery becomes as reliable as directed frame transmission. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
11
Broadcast storm problem
January 2006 doc.: IEEE /340r0 May 2006 Broadcast storm problem According to P802.11s-D0.01 : Broadcast Data Packets “Any layer-2 broadcast mechanism can be used to deliver broadcast packets, so long as the packets are delivered to all Mesh nodes. As an example, broadcast data packets can be delivered to all nodes in the Mesh by flooding.” [in subclause 11A ] RREQ frames “This frame is typically transmitted in a broadcast manner. The intermediate MP rebroadcasts this frame.” [in subclause ] The broadcasting mechanism within the mesh is not defined specifically. RREQ frame loss (especially due to collision) will cause significant route setup delay, or serious failure in route discovery. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
12
Broadcast storm problem (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 Broadcast storm problem (Cont’d) RREQ frames will be re-broadcasted, upon the reception. RREQ RREQ Potential collision RREQ RREQ RREQ RREQ RREQ RREQ RREQ RREQ RREQ Potential collision RREQ Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
13
Beacon Broadcaster Rotation
January 2006 doc.: IEEE /340r0 May 2006 Beacon Broadcaster Rotation According to P802.11s-D0.01 : “By default the beacon broadcaster in a mesh is rotating between the MPs. MAP may need to send a beacon even if another MP had already sent a beacon on that same TBTT.” [in subclause 11A.13.8] “An MP not supporting this service will use a random backoff procedure for sending of Beacons as described for IBSS operation in the standard.” [in subclause 11A.13.8] “If a neighbor assigned to be the beacon broadcaster fails to transmit its beacon, other MPs will attempt to take over its role. MPs supporting the deterministic beacon broadcasting will start attempting to send beacons using the standard backoff procedure with a ....” [in subclause 11A.13.9] BB is switched regularly in the default operation. If MPs see the BB rotation fails, MPs will utilize the random backoff procedure for beaconing. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
14
Beacon Broadcaster Rotation (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 Beacon Broadcaster Rotation (Cont’d) MP#3 is a designated beacon broadcaster. Neighboring MPs listen to the BB’s beacon. BB is switched from MP#3 to MP#5. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
15
Beacon Broadcaster Rotation (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 Beacon Broadcaster Rotation (Cont’d) The beacon frames from MP#5 potentially collide with beacon frame from MP#2 and MP#1 at MP#3 and MP#6. MP#3 and MP#6 may try to transmit beacons upon the absence of beacon reception at the TBTT. 240octet beacon = 320usec CW size = 2* CWmin[AC_VO] * 9usec = 54usec where CWmin[AC_VO]=(aCWmin+1)/4 – 1 MP#2 and MP#1 are out of range of MP#5, and try to transmit the beacon using the random backoff procedure like IBSS. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
16
TSF synchronization and Topology dynamics
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics According to P802.11s-D0.01 : “The synchronizing behavior for the two classes is defined as follows” [in subclause 11A.12.1], which are unsynchronizing MPs and synchronizing MPs (optional). “Synchronizing MPs should attempt to maintain a common TSF time called the Mesh TSF time” [in subclause 11A ], where the mesh TSF is assumed to be maintained commonly throughout the mesh. “Synchronization and beacon generation services in a WLAN mesh are based upon the procedures defined in clause 11.1 of the IEEE specification for Infrastructure and IBSS modes of operation.” [in subclause 11A.12.1] As for the synchronizing MPs, mesh TSF is assumed to be synchronized throughout the mesh. Can we assume the same synchronization mechanism as IBSS in mesh kind of environment? Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
17
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of IBSS Every STA are within the range of each STAs. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
18
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of mesh Some of the MPs are typically not within the range of some of the MPs. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
19
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of mesh Some of the MPs are typically not within the range of some of the MPs. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
20
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of mesh Beacon broadcaster will be distributed. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
21
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of mesh Clock drift compensation will be distributed. Eventually, causes the unsynchronized mesh TSF in a mesh. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
22
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of mesh Topology could be changed by mobility of the MPs, as well as activity of MPs, etc... ANY partial disconnection will cause the topology change. Users may shut down the MP’s power supply in order to: Make sure to achieve the complete power save (power down). Operate the technical maintenance or recovery from the failure. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
23
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of mesh Possibly disconnected mesh TSF value will be drifted independently, and cause the unsynchronized mesh TSF. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
24
TSF synchronization and Topology dynamics (Cont’d)
January 2006 doc.: IEEE /340r0 May 2006 TSF synchronization and Topology dynamics (Cont’d) In case of mesh Eventually, the mesh is re-connected and it has two unsynchronized mesh TSF value in a single mesh. Will the mesh TSF compensated again? This problem is NOT localized, and affects the operation of entire mesh. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
25
January 2006 doc.: IEEE /340r0 May 2006 Summary Some of the potential issues which may occur in the mesh environment are discussed. The size of routing table Proxy may contribute the reduction of routing table entry. Reliability risk of broadcast frames There are some reliability levels for broadcast frame delivery. Level 3 protection mechanism seems to be lacked so far. Broadcast Storm Problem Recall the relationship between RREQ flooding and the broadcast reliability. Beacon Broadcaster rotation Some potential issues are depicted. TSF synchronization and Topology dynamics Recall the potential TSF synchronization issues. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
26
References [1] P802.11-REVma/D5.2 [2] P802.11s-D0.01
January 2006 doc.: IEEE /340r0 May 2006 References [1] P REVma/D5.2 [2] P802.11s-D0.01 [3] “The Broadcast Storm Problem in a Mobile Ad Hoc Network”, Wireless Networks 8, 153–167, 2002 Kluwer Academic Publishers. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
27
January 2006 doc.: IEEE /340r0 May 2006 End of slides Comments/Questions/Suggestions/Corrections are purely welcomed. Kazuyuki Sakoda Donald Eastlake 3rd, Motorola
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.