lightweight overlap mitigation for 802 11
Download
Skip this Video
Download Presentation
Lightweight Overlap Mitigation for 802.11

Loading in 2 Seconds...

play fullscreen
1 / 21

Lightweight Overlap Mitigation for 802.11 - PowerPoint PPT Presentation


  • 94 Views
  • Uploaded on

Lightweight Overlap Mitigation for 802.11. Lucent Technologies - Bell Labs Arjan de Heer Harold Teunissen Agere Systems WCND Wim Diepstraten. Layout. To get overlap mitigation to work as proposed in initial baseline proposal (00/071) for (legacy) PCF operating cells

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Lightweight Overlap Mitigation for 802.11' - egil


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
lightweight overlap mitigation for 802 11

Lightweight Overlap Mitigation for 802.11

Lucent Technologies - Bell Labs

Arjan de Heer

Harold Teunissen

Agere Systems WCND

Wim Diepstraten

Harold Teunissen, et al. - Lucent

layout
Layout
  • To get overlap mitigation to work as proposed in initial baseline proposal (00/071) for (legacy) PCF operating cells
  • Look at other ways of solving overlap for (legacy) PCF
  • See what is lacking in current proposal
  • Came up with lightweight mechanism that can be applied to both centralized as distributed access mechanisms (also for contention free bursting) for synchronizing neighboring BSSs
  • Assumptions
    • Detection of Overlap out of the scope of this presentation
    • Dynamic Frequency Selection has done its work
    • Mechanisms for silencing BSS or one particular STA are not discussed here
    • AP synchronization of TSFs is essential for any algorithm to work, but not discussed here

Harold Teunissen, et al. - Lucent

overlap situations
Overlap Situations

Overlap STA-AP

No Overlap

Passive Overlap STA-STA

Overlapping STAs

Overlapping APs

for 11 Mbps, x=3 (approx.)

Harold Teunissen, et al. - Lucent

alternatives to resolve overlap
Alternatives to Resolve Overlap
  • Do not schedule overlapping STA in CFP, let it use the CP (possibly using RTS/CTS)
  • Schedule STA in another part of the CFP. The STA might be scheduling in such way that it experiences overlap. By re-ordering the CFP the overlap might be reduced.
  • Dynamic Frequency Selection (switch frequency of complete cell). Consequence that new and worse overlap situation is created.
  • Automatic Rate Control (drop rate to that specific STA). This improves the receive quality but at the other hand it could increase overlap in neighbouring cells.
  • Drop QoS connections (if available) or disassociate STA completely. This seems better than degradation of service. In addition the neighbouring cells "get more air".
  • Live with it. This is the simplest solution. We still need to see if the overlap management algorithms are worth the effort.

Harold Teunissen, et al. - Lucent

resolving overlap for legacy pcf
Resolving Overlap for (Legacy) PCF
  • Re-schedule CFP
    • Round Robin
    • Restart at beginning of list per CFP
    • Resume scheduling of list at next CFP
    • Static Scheduling (STAs are scheduled at regular intervals)
    • Shifting of static schedule (schedule is shifted to left or right)
    • Pure Random

Harold Teunissen, et al. - Lucent

original algorithm see doc ieee802 11 00 071
Original algorithm (see doc IEEE802.11-00/071)
  • Basic approach
    • APs exchange information about the Tols* and Nols in the BSS’.
    • Based on this information each AP calculates its own (CFP) schedule, that is the length of the periods and the time to execute them
    • This information is distributed using ProxyBeacons
  • Problem
    • The calculated schedules have to match each other (Tol vs. TS), but the AP use different information to base the calculation on

*) Ttol  Total Overlap Period (Tol+TS)Tol  Overlap Period, TS  Silence Period, Nol  Non-overlap Period

Harold Teunissen, et al. - Lucent

original algorithm
Original algorithm
  • In a proxy beacon an AP sends:
    • Own Tol and Nol
    • Ttol of its overlapping BSS
    • List of overlapping BSS
  • As a consequence each AP knows:
    • Tol and Nol of the overlapping BSS’s
    • Ttol of the overlapping BSS’s of the BSS’s overlapping with the BSS of this AP
    • Which Tol’s can be scheduled in Parallel
  • Then the AP calculates its schedule based on this information using the rules:
    • Start with the longest Tol
    • Schedule Tol’s as much as possible in parallel

Harold Teunissen, et al. - Lucent

original algorithm working example

OL

CD

D

OL

C

OL

BD

AB

OL

OL

A

OL

B

BC

BC

BA

TS

TS

Tol

Nol

Tol

TS

Tol

Nol

Nol

Nol

Tol

TS

A:

B:

C:

D:

Original Algorithm Working Example
  • Suppose Ttol(A)>Ttol(C)>Ttol(B)>Ttol(D)
  • After exchanging beacons each AP has the following information:

Ttol(A)||Ttol(C)

TS(A)||Ttol(B)

Largest Ttol: Ttol(A)

Ttol(B)||Ttol(D)

TS(B)||Ttol(A)||Ttol(C)\

Largest Ttol: Ttol(A)

Ttol(C)||Ttol(A)

TS(C)||Ttol(B)||Ttol(D)

Largest Ttol; Ttol(A)

Ttol(D)||Ttol(B)

TS(D)||Ttol(C)

Largest Ttol: Ttol(C)

A||B means A can be scheduled in parallel with B

The calculated schedules are:

Harold Teunissen, et al. - Lucent

original algorithm problem example

OL

CD

D

OL

C

OL

BD

AB

OL

OL

A

OL

B

BC

BC

BA

Tol

TS

Nol

A:

B:

TS

Tol

Nol

C:

Tol

TS

Nol

D:

Tol

TS

Nol

Original Algorithm Problem Example
  • The same example with Ttol(A)>Ttol(B)>Ttol(C)>Ttol(D)
  • Each AP has the following information:

Ttol(A)||Ttol(C)

TS(A)||Ttol(B)

Largest Ttol: Ttol(A)

Ttol(B)||Ttol(D)

TS(B)||Ttol(A)||Ttol(C)\

Largest Ttol: Ttol(A)

Ttol(C)||Ttol(A)

TS(C)||Ttol(B)||Ttol(D)

Largest Ttol; Ttol(A)

Ttol(D)||Ttol(B)

TS(D)||Ttol(C)

Largest Ttol: Ttol(B)

The calculated schedules are:

Problem with C&D!!!

Because D does not know Ttol(A) as C does know

Harold Teunissen, et al. - Lucent

disadvantages of proposed mechanism
Disadvantages of proposed mechanism
  • Schedule information should be distributed along complete network
  • Scalability
  • Ordering of periods unclear (start with longest Tol not enough)
  • How to accomplish fairness?

Harold Teunissen, et al. - Lucent

lightweight mechanism

notSilent

Isilent

Usilent

Nol

Lightweight Mechanism
  • AP’s regularly inform the AP’s of overlapping BSS’s of their own (CFP) schedule by exchanging proxy beacons
  • It is not necessary to limit the schedule to the CFP period only, as long as the schedule is repetitive (this holds for any mechanism!)
  • The proxy beacon contains the following information
    • When (and how long) is the BSS of the sender of the proxy beacon silent (Isilent);
    • When is the BSS of the receiver of the proxy beacon expected to be silent (Usilent);
    • When is the sender serving stations not experiencing overlap from the BSS of the receiver, but the sender is experiencing overlap from other BSS’s (notSilent);
    • When the sender is serving stations not experiencing any overlap at all (Nol).
  • Example proxy beacon info:

Harold Teunissen, et al. - Lucent

lightweight mechanism 2
Lightweight Mechanism (2)
  • As a result of the exchange of proxy beacons, each AP knows the (CFP) schedule of the overlapping BSS’s
  • Whenever a station experiences overlap from an BSS, it should be scheduled during a silence period of the overlapping BSS’s
  • The AP can check using its own schedule and the schedules of the overlapping BSS, if such a silence period already exist. If so it can serve the station during this period.
  • If such a period does not exist yet, the AP can check if it is possible to create such a period, by asking the overlapping BSS to be silent in that period. It is asked by creating a Usilent period in the proxy beacon sent to the AP of the BSS which should be silent.
  • If the AP of the BSS which should be silent grants the request, it will inform the requestor by adding the Isilent period in the proxy send to the requestor.
  • If the requestor does not get the confirmation, it may request another period

Harold Teunissen, et al. - Lucent

lightweight mechanism example

OL

OL

CB

C

AB

OL

A

B

BC

OL

BA

Nol

Nol

Nol

A:

B:

C:

Lightweight Mechanism Example
  • Initially none of the stations has detected overlap, so they are all served in the NOL period, and no proxy beacons are exchanged.
  • Each AP knows only its own schedule:
  • This schedule is repeated every CFP or specific Beacon interval

Harold Teunissen, et al. - Lucent

lightweight mechanism example1

B

C

A

Nol

Nol

A:

Nol

B:

Nol

Nol

C:

B:

Nol

A:

Nol

Lightweight Mechanism Example
  • Than some stations of A detect the overlap from B, this requires A to schedule them against a silence period of B
  • A starts sending the proxy beacon to B. B will respond by sending a proxy beacon to A
  • As a consequence A and B know each others schedules

Harold Teunissen, et al. - Lucent

lightweight mechanism example2

B

C

A

Nol

Nol

ISilent

ISilent

USilent

Nol

Tol(B)

Nol

ISilent

Nol

Nol

Nol

USilent

A:

B:

C:

B:

A:

Lightweight Mechanism Example
  • B receives the proxy beacon, sees the request for silence, checks that the silence is possible and adds the silence to the schedule. The update of the schedule is acknowlegded to A by the proxy beacon
  • Knowing B’s schedule A sees no silence period exist for B, it request one by adding one in the proxy beacon to B
  • A receives the proxy beacon, and sees that B has added the silence period. A starts servicing the overlap stations during that silence period, the schedules:

Harold Teunissen, et al. - Lucent

lightweight mechanism example3

B

C

A

Nol

Nol

Nol

Tol(B)

USilent

USilent

Nol

Tol(B)

ISilent

Nol

Nol

ISilent

ISilent

Nol

Lightweight Mechanism Example
  • C will on receipt of the proxy beacon from B see that there is a silence period of B and will start servicing its overlapping stations during that period. This information is added to the proxy beacon for B. The schedules:
  • Some time later stations in C are also experiencing overlap from B. B starts sending the proxy beacon to B and B will on receipt start sending a proxy beacon to C

Nol

ISilent

Nol

A:

B:

C:

B:

B:

A:

C:

Harold Teunissen, et al. - Lucent

lightweight mechanism example4

B

C

A

ISilent

Nol

Tol(B)

ISilent

Tol(B)

USilent

Nol

ISilent

Nol

Nol

ISilent

ISilent

ISilent

Tol(B)

Nol

USilent

Nol

Nol

ISilent

ISilent

Nol

Nol

Nol

USilent

ISilent

Tol(A&C)

USilent

Tol(A&C)

ISilent

ISilent

B:

C:

A:

B:

A:

B:

C:

Lightweight Mechanism Example
  • Than the stations in B will start complaining about overlap. B has two choices: Either he asks A and C to be silent at the same time, or he asks them to be silent in different periods. Suppose the first option is chosen
  • B will check in the schedule of both A and C if there is a period they are both silent. This is not the case, so B will ask them to be silent using the proxy beacons to both

Harold Teunissen, et al. - Lucent

remarks 1
Remarks (1)
  • APs only need to have knowledge of the overlapping Aps
    • Overlap detection shall be out of the scope of the standard
    • STAs could detect neighboring Beacons and forward BSSID to own AP
    • Passive overlap difficult to overcome
  • A and C use the same silence period of B, without knowing of each others existing. This is achieved because C checks if B is already silent, before requesting a (new) silence period. Overlap mitigation is a local process.
  • As a consequence the schedules may not be optimal. For example, suppose BSS’s A and B resolve their overlap. The same holds for BSS’s C and D. The periods B silent and C silent are at the same time. Than B experiences overlap from C. It will look in the schedule for B and see that B has a silence period, but at that time C is silent itself. It will then ask for a new silent period for B
  • The problem above can be solved when B adapts its own schedule, but this will affect the schedule of C too (thus consequences for locality)

Harold Teunissen, et al. - Lucent

remarks 2
Remarks (2)
  • The resulting schedules depend on the order the requests for the silence period are made. Not only the length of the required silences is needed to calculate the schedules, the history influences the outcome
  • The mechanism only delivers a way to ask the overlapping BSS for silence. The overlapping BSS may or may not grant this request
  • Each AP is only synchronizing with the AP’s of the overlapping BSS. Before using a silence period from an overlapping BSS, this silence must be granted via the proxy beacon. So changes in schedule will go smoothly, without distorting other BSS, except for the neighbors BSSs
  • For a start “full = full” holds. Changing from this discipline may cause the system to become unstable
  • APs are free in what periods of silence are requested, and where in the schedule they are requested
  • (Repetitive) Contention Free Bursting can easily be incorporated

Harold Teunissen, et al. - Lucent

remarks 3
Remarks (3)
  • Suggestion to change Proxy Beacon to Overlap Mitigation message (OM)
  • Transmit at lowest rate to reduce number of relays of OM (e.g. AP to STA to STA to AP). Unguided OM broadcast could increase disturbance and reduce performance
  • Suggestion to adapt the proposed Overlap Mitigation mechanism to be included in the Baseline

Harold Teunissen, et al. - Lucent

references
References
  • 00/071R1E, IEEE 802.11 QoS MAC Enhancements (AT&T, Lucent, Sharewave)
  • 00/194E, Collision avoidance in overlapping BSSs (Gerard G.Cervello and Sunghyun Choi, Philips)
    • Based on RTS/CTS, ONAV
  • 00/448, An Integrated 802.11 QoS Model with Point-controlled Contention Arbitration (Robert C. Meier et al., Cisco)
    • Based on Dynamic Frequency Selection

Harold Teunissen, et al. - Lucent

ad