1. MBCA and Beacon Timing element clean up
November 2007
MBCA and Beacon Timing element clean up
Date:
Authors:
Kazuyuki Sakoda

2. November 2007
Abstract
The following slides present the suggested clean up of MBCA subclause and Beacon Timing element.
Suggested change potentially resolves CID762, 896, 3968, 89, 90, 772, and 5664.
Kazuyuki Sakoda

3. November 2007
MBCA rationale
MBCA (Mesh Beacon Collision Avoidance) is designed to provide a tool to avoid continuous collision of beacon frames from hidden nodes.
Hidden node is not a corer case problem in mesh environment.
MP-A
MP-B
MP-C
Collision is observed when MP-A and MP-C transmit a frame at the same time.
This collision is observed only at MP-B if MP-A and MP-C are out of range each other.
Kazuyuki Sakoda

4. MBCA rationale (Cont’d)
November 2007
MBCA rationale (Cont’d)
Collision between beacon frames
Unlike most of other frames, beacon frames are transmitted periodically.
Hence, the beacon collision will be repeated continuously if both of the beacons are transmitted at the same beacon interval. TX RX TX RX TX RX
MP-A
time RX TX RX TX RX TX
MP-B
time TX RX TX RX TX RX
MP-C
time
Kazuyuki Sakoda

5. MBCA rationale (Cont’d)
November 2007
MBCA rationale (Cont’d)
D1.07 defines an optional “Mesh Beacon Collision Avoidance”
Step1: MP-B records the reception timing of beacons from its neighbors (MP-A and/or MP-C), and report it through beacon timing element.
Step2: MPs receiving beacon timing element can get a timing information of periodic interference source. MP-A and MP-C is informed when they should not transmit beacon frames (when MP-B is receiving beacon frames).
MP-A
MP-B
MP-C
Kazuyuki Sakoda

6. MBCA rationale (Cont’d)
November 2007
MBCA rationale (Cont’d)
According to D1.07:
In page 190 (11A.11.4), “Non-synchronizing MPs may optionally adjust their TSF timers and synchronizing MPs may optionally adjust their offsets to reduce the chances that they will transmit Beacon frames at the same time as one of their neighbors or neighbors’ neighbors.”  MPs may adjust its TSF timer and shift its TBTT, using the beacon timing information from its neighbors.
Kazuyuki Sakoda

7. Concerns on MBCA CID 89,90: CID772: CID5664:
November 2007
Concerns on MBCA
CID 89,90:
Ask for the clarification on the use of Beacon Timing element among synchronizing MPs and non-synchronizing MPs.
CID772:
Concerned about the inconsistency of the use of Beacon Timing element and beacon bloat.
Resolution notes says: Recommended to spread the beacon timing element to two different information elements.
CID5664:
Request to convey the TBTT information via non-synchronizing MPs. See doc s-problems-with-mbca-mechanism.
Kazuyuki Sakoda

8. November 2007
Beacon Timing element
Beacon timing element carries following two information:
The Mesh TSF offset information for synchronizing MPs.
Neighbor’s TBTT information.
Kazuyuki Sakoda

9. Concerns on Beacon Timing element
November 2007
Concerns on Beacon Timing element
CID762:
Concerned that this information element could be potentially large if the MP has large number of neighboring MPs (or APs), and it carries all the TBTT information.
Ask for the performance analysis of the amount of overhead.
CID896:
Ask for the clarification of the usage of “last byte of MAC address” field.
CID3968:
Concerned about beacon bloat.
Ask for the clarification of the usage of this information element.
Kazuyuki Sakoda

10. The size of beacon frame (example)
November 2007
The size of beacon frame (example)
Beacon frame typically consists of following information elements. (1/3)
Octets
(8)
(2)
(2)
(2)
(10)
(3)
(16)
(8-256)
(3)
(8)
Kazuyuki Sakoda

11. The size of beacon frame (example)
November 2007
The size of beacon frame (example)
Beacon frame typically contains of following information elements. (2/3)
(4)
(3)
(8)
(3-257)
(40)
(20)
Kazuyuki Sakoda

12. The size of beacon frame (example)
November 2007
The size of beacon frame (example)
Beacon frame typically contains of following information elements. (3/3)
Octets
(10)
(2-34)
(17)
(41)
(4-257)
(7)
(6-256)
(4)
(41)
(4-257)
(0)
(4-257)
(9)
Kazuyuki Sakoda

13. The size of beacon frame (example)
November 2007
The size of beacon frame (example)
Total amount of information elements could be around 260 octets.
Incl. 6 neighboring peer MP entry in neighbor list IE (41 octets).
Incl. 6 neighboring peer MP entry in beacon timing IE (43 octets).
Incl. 0 entry in MDAOP advertisement IE (0 octets).
Total PSDU amount of beacon frame could be around 290 octets.
Incl. 26 octet legacy MAC header and 4 octet FCS.
Kazuyuki Sakoda

14. The size of beacon frame
November 2007
The size of beacon frame
With 290 octet PSDU, length of beacon frame is:
@ 1Mbps b/g
2,512[usec]=192[usec]+2,320[usec]
@ 2Mbps b/g, with short preamble
1,256[usec]=96[usec]+1,160[usec]
@ 6Mbps a
408[usec] = 20[usec]+388[usec]
With 247octet PSDU (w/o beacon timing), length of beacon frame is:
2,168[usec]=192[usec]+1,976[usec]
1,084[usec]=96[usec]+988[usec]
352[usec] = 20[usec]+332[usec]
With 206octet PSDU (w/o beacon timing and neighbor list), length of beacon frame is:
1,840[usec]=192[usec]+1,648[usec]
920[usec]=96[usec]+824[usec]
296[usec] = 20[usec]+276[usec]
Kazuyuki Sakoda

15. Overhead required to advertise beacon timing element
November 2007
Overhead required to advertise beacon timing element
The current beacon timing element consumes roughly % of entire beacon frame air time.
@ 1Mbps b/g
Beacon timing element consumes 344[usec] air time out of 2,512[usec].
@ 2Mbps b/g, with short preamble
Beacon timing element consumes 172[usec] air time out of 1,256[usec].
@ 6Mbps a
Beacon timing element consumes 58[usec] air time out of 408[usec].
Kazuyuki Sakoda

16. Suggested changes to the draft spec
November 2007
Suggested changes to the draft spec
Beacon Timing element and MBCA:
Separate the “Mesh TSF offset information” and “neighbor’s TBTT information” into two information elements.
Unify the format to report the neighbor’s TBTT information in its local TSF value.
Replace “Last byte of MAC address” with “Least octet of AID”, in order to ensure the orthogonality of this number.
The precision of the “beacon rx time” is reduced to 256[usec]., since this information does not need to be accurate to be expressed in 1[usec] resolution.
“Mesh TSF offset information” presents at every beacon frame when it utilizes mesh TSF.
“Neighbor’s TBTT information” presents only at DTIM beacon and the MP do not need to carry all the neighboring TBTT information once. (Implementer's choice)
Clean up the subclause 11A.11.4.
Kazuyuki Sakoda

17. Suggested changes to the draft spec
November 2007
Suggested changes to the draft spec
Mesh TSF offset information” element
Beacon Timing element:
Octets: 1 1 4 ID
Leng th
Mesh TSF
offset
Octets: 1 1 5 5 ID
Leng th
Beacon
Reception
Info 1
...
Beacon
Reception
Info N 1 2 2
Least octet of
AID assigned to
MP 1
Last
Rx Time
of MP 1
Beacon
Interval
of MP 1
Kazuyuki Sakoda

18. The effectiveness of the suggested resolution to beacon bloat issue
November 2007
The effectiveness of the suggested resolution to beacon bloat issue
Before:
6 neighboring peer MP entry in neighbor list IE (41 octets).
6 neighboring peer MP entry in beacon timing IE (43 octets).
Total :83 octets
After:
neighbor list IE is removed (0 octet).
6 neighboring peer MP entry in beacon timing IE (32 octets) with lower frequency.
Total :32 octets with lower frequency
Kazuyuki Sakoda

19. The effectiveness of the suggested resolution to beacon bloat issue
November 2007
The effectiveness of the suggested resolution to beacon bloat issue
Beacon length with D1.07 format, assuming 6 entry for BT IE & NL IE:
@ 1Mbps b/g
2,512[usec]=192[usec]+2,320[usec]
@ 2Mbps b/g, with short preamble
1,256[usec]=96[usec]+1,160[usec]
@ 6Mbps a
408[usec] = 20[usec]+388[usec]
Beacon length with suggested format, assuming 6 entry for BT IE:
2,096[usec]=192[usec]+1,904[usec]
1,048[usec]=96[usec]+952[usec]
340[usec] = 20[usec]+320[usec]
Beacon length without BT IE:
1,840[usec]=192[usec]+1,648[usec]
920[usec]=96[usec]+824[usec]
296[usec] = 20[usec]+276[usec]
Kazuyuki Sakoda

20. Summary Suggested to clean up Beacon Timing element.
November 2007
Summary
Suggested to clean up Beacon Timing element.
Suggested to clean up subclause 11A.11.4.
The proposed text is provided in 11-07/xxxxr0.
Kazuyuki Sakoda

21. November 2007
References
[1] Draft Amendment Mesh Networking: IEEE P802.11s /D1.07, September 2007.
[2] doc.: IEEE /0023r50 “Resolution of comments received during IEEE Letter Ballot 93“
Kazuyuki Sakoda

22. November 2007
Motion
Move to accept the resolution to CID762, 896, 3968, 89, 90, 772, and 5664, as proposed in document 11-07/xxxxr0.
Moved by:
Second by:
Result (Yes/No/Abstain):
Kazuyuki Sakoda

23. November 2007
Backup
The following slides present the goal of MBCA and beacon collision mitigation in mesh.
Kazuyuki Sakoda

24. What is the beacon collision problem in mesh?
November 2007
What is the beacon collision problem in mesh?
Beacon collision in BSS
Within a BSS network, there is no beacon collision since only a single STA (AP) transmits beacon within that BSS.
Very basic assumption is that BSS does not care overlapping BSS operation, although beacon report is defined (as a part of 11k) to let STAs to measure the overlapping BSS and to report back the status.
Beacon collision in IBSS
IBSS beacon transmission method is based on the assumption that all the STAs are in the radio range each other.
It is known that the IBSS network is not robust when the STAs are in hidden node situation.
Beacon collision in Mesh
We should have something to mitigate this issue...
Kazuyuki Sakoda

25. What is the beacon collision problem in mesh?
November 2007
What is the beacon collision problem in mesh?
The consequence of the “continuous” beacon collision:
Lack of beacon reception may be interpreted as a link loss.
Or, may result in a frequent probe request frame transmission invoking for the probe response frame transmission.
May result in the loss of synchronization, which further results in:
Vulnerability of power save operation
Vulnerability of MDA operation
Beacon frame is a “beacon” in the night ocean, especially for power saving MPs.
Kazuyuki Sakoda

26. What is the beacon collision problem in mesh?
November 2007
What is the beacon collision problem in mesh?
Should we care the collision between beacon and other frames?
Data frames are transmitted based on the random backoff, which has a large fluctuation in frame transmission time and not repeated regularly unlike beacon frame.
Beacon frame is more important when the MPs are operating in power save mode or operating MDA.
When operating in power save mode, traffic is supposed to be less.
e.g. Less traffic during the night time.
When operating MDA, MDA will provide a protection to scheduled transmission.
It might be OK to leave the “beacon and data” collision issue untouched at this moment.
We do not want to develop complicated protocol.
Kazuyuki Sakoda