210 likes | 320 Views
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
E N D
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 • 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 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 • 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 • 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) • 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 • 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
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
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 • 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
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) • 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
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
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
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
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
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) • 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) • 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) • 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 • 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