doc.: ieee 802.11-07/2819r1 submission november 2007 kazuyuki sakodaslide 1 mbca and beacon timing...

November 2007

Kazuyuki Sakoda

Slide 1

doc.: IEEE 802.11-07/2819r1

Submission

MBCA and Beacon Timing element clean up

Date: 2007-11-12

Name Company Address Phone email Kazuyuki Sakoda Sony

Corporation 5-1-12 Kita-Shinagawa Shinagawa-ku, Tokyo, 141-0001 Japan

+81-3-5448-4017 [email protected]

Authors:

November 2007

Kazuyuki Sakoda

Slide 2

doc.: IEEE 802.11-07/2819r1

Submission

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.

November 2007

Kazuyuki Sakoda

Slide 3

doc.: IEEE 802.11-07/2819r1

Submission

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 corner case problem in mesh environment.

MP-A MP-B

MP-CCollision 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.

November 2007

Kazuyuki Sakoda

Slide 4

doc.: IEEE 802.11-07/2819r1

Submission

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.

MP-A

MP-B

MP-C

TX

TX

TX

TX

TX

TX

TX TX TX

time

time

time

RX

RX

RX

RX

RX

RX

RX RX RX

November 2007

Kazuyuki Sakoda

Slide 5

doc.: IEEE 802.11-07/2819r1

Submission


• 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

November 2007

Kazuyuki Sakoda

Slide 6

doc.: IEEE 802.11-07/2819r1

Submission


• 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.

November 2007

Kazuyuki Sakoda

Slide 7

doc.: IEEE 802.11-07/2819r1

Submission

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 11-07-1946-00-000s-problems-with-mbca-mechanism.

November 2007

Kazuyuki Sakoda

Slide 8

doc.: IEEE 802.11-07/2819r1

Submission

Concerns on MBCA (Cont’d)

• Current MBCA does not provide a tool to request neighboring MP to adjust its TBTT explicitly.– Although MP-B infers that MP-A’s beacon and MP-B’s beacons are

colliding each other, MP-B has nothing to do with it.

– We may want to provide such a tool.

MP-A MP-B

MP-C

November 2007

Kazuyuki Sakoda

Slide 9

doc.: IEEE 802.11-07/2819r1

Submission

Beacon Timing element

• Beacon timing element carries following two information:– The Mesh TSF offset information for synchronizing MPs.

– Neighbor’s TBTT information.

November 2007

Kazuyuki Sakoda

Slide 10

doc.: IEEE 802.11-07/2819r1

Submission

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.

November 2007

Kazuyuki Sakoda

Slide 11

doc.: IEEE 802.11-07/2819r1

Submission

The size of beacon frame (example)

• Beacon frame typically consists of following information elements. (1/3)

(8)(2)(2)

(2)

(10)

(3)

(16)

(3)

(8)

(8-256)

Octets

November 2007

Kazuyuki Sakoda

Slide 12

doc.: IEEE 802.11-07/2819r1

Submission


• Beacon frame typically contains of following information elements. (2/3)

(4)

(3)

(8)

(40)

(20)

(3-257)

November 2007

Kazuyuki Sakoda

Slide 13

doc.: IEEE 802.11-07/2819r1

Submission


• Beacon frame typically contains of following information elements. (3/3)

(10)

(17)

(41)

(2-34)

(4-257)

(6-256)

(4-257)

(4-257)

(7)

(4)

(41)

(0)

(9)

Octets

November 2007

Kazuyuki Sakoda

Slide 14

doc.: IEEE 802.11-07/2819r1

Submission


• 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.

November 2007

Kazuyuki Sakoda

Slide 15

doc.: IEEE 802.11-07/2819r1

Submission

The size of beacon frame

1. With 290 octet PSDU, length of beacon frame is:– @ 1Mbps 802.11b/g

• 2,512[usec]=192[usec]+2,320[usec]– @ 2Mbps 802.11b/g, with short preamble

• 1,256[usec]=96[usec]+1,160[usec]– @ 6Mbps 802.11a

• 408[usec] = 20[usec]+388[usec]

2. With 247octet PSDU (w/o beacon timing), length of beacon frame is:– @ 1Mbps 802.11b/g


• 1,084[usec]=96[usec]+988[usec]– @ 6Mbps 802.11a

• 352[usec] = 20[usec]+332[usec]

3. With 206octet PSDU (w/o beacon timing and neighbor list), length of beacon frame is:– @ 1Mbps 802.11b/g


• 920[usec]=96[usec]+824[usec]– @ 6Mbps 802.11a

• 296[usec] = 20[usec]+276[usec]

November 2007

Kazuyuki Sakoda

Slide 16

doc.: IEEE 802.11-07/2819r1

Submission

Overhead required to advertise beacon timing element

• The current beacon timing element consumes roughly 13-14% of entire beacon frame air time.

• @ 1Mbps 802.11b/g– Beacon timing element consumes 344[usec] air time out of

2,512[usec].

• @ 2Mbps 802.11b/g, with short preamble– Beacon timing element consumes 172[usec] air time out of

1,256[usec].

• @ 6Mbps 802.11a– Beacon timing element consumes 58[usec] air time out of 408[usec].

November 2007

Kazuyuki Sakoda

Slide 17

doc.: IEEE 802.11-07/2819r1

Submission

Suggested changes to the draft spec

• Beacon Timing element and MBCA:– Put MBCA capability bits in Mesh configuration element.

(B0: capability to report beacon timing, B1: capability to shift its TBTT)– 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. For instence, MP carries neighbor’s TBTT information only when multiple beacons are received relatively close. (Implementer's choice)

– Define a frame to request to adjust TBTT.– Clean up the subclause 11A.11.4.

November 2007

Kazuyuki Sakoda

Slide 18

doc.: IEEE 802.11-07/2819r1

Submission


• Mesh TSF offset information” element

• Beacon Timing element:

ID

Octets: 1

Length

1Beacon

Reception Info 1

...Beacon

Reception Info N

5 5

Least octet of AID assigned to

MP 1

Last Rx Timeof MP 1

Beacon Interval of MP 1

1 2 2

ID

Octets: 1

Length

1

Mesh TSF offset

4

November 2007

Kazuyuki Sakoda

Slide 19

doc.: IEEE 802.11-07/2819r1

Submission


• TBTT shift request frame

Order Timestamp Notes

1 Beacon Timing

November 2007

Kazuyuki Sakoda

Slide 20

doc.: IEEE 802.11-07/2819r1

Submission

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

November 2007

Kazuyuki Sakoda

Slide 21

doc.: IEEE 802.11-07/2819r1

Submission

The effectiveness of the suggested resolution to beacon bloat issue

1. Beacon length with D1.07 format, assuming 6 entry for BT IE & NL IE:– @ 1Mbps 802.11b/g


• 1,256[usec]=96[usec]+1,160[usec]– @ 6Mbps 802.11a

• 408[usec] = 20[usec]+388[usec]

2. Beacon length with suggested format, assuming 6 entry for BT IE:– @ 1Mbps 802.11b/g


• 1,048[usec]=96[usec]+952[usec]– @ 6Mbps 802.11a

• 340[usec] = 20[usec]+320[usec]

3. Beacon length without BT IE:– @ 1Mbps 802.11b/g


• 920[usec]=96[usec]+824[usec]– @ 6Mbps 802.11a

• 296[usec] = 20[usec]+276[usec]

November 2007

Kazuyuki Sakoda

Slide 22

doc.: IEEE 802.11-07/2819r1

Submission

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.

November 2007

Kazuyuki Sakoda

Slide 23

doc.: IEEE 802.11-07/2819r1

Submission

References

[1] Draft Amendment Mesh Networking: IEEE P802.11s /D1.07, September 2007.

[2] doc.: IEEE 802.11-07/0023r50 “Resolution of comments received during IEEE 802.11 Letter Ballot 93“

November 2007

Kazuyuki Sakoda

Slide 24

doc.: IEEE 802.11-07/2819r1

Submission

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):

November 2007

Kazuyuki Sakoda

Slide 25

doc.: IEEE 802.11-07/2819r1

Submission

Backup

• The following slides present the goal of MBCA and beacon collision mitigation in mesh.

November 2007

Kazuyuki Sakoda

Slide 26

doc.: IEEE 802.11-07/2819r1

Submission

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...

November 2007

Kazuyuki Sakoda

Slide 27

doc.: IEEE 802.11-07/2819r1

Submission


• 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.

November 2007

Kazuyuki Sakoda

Slide 28

doc.: IEEE 802.11-07/2819r1

Submission


• 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.

doc.: ieee 802.11-07/2819r1 submission november 2007 kazuyuki sakodaslide 1 mbca and beacon timing...

Documents