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