Doc.: IEEE 802.11-07/2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution Date: 2007-11-09 Authors:

Slides:



Advertisements
Similar presentations
PS-Poll TXOP Using RTS/CTS Protection
Advertisements

Doc.: IEEE /630r4a Submission S. Choi, Philips Research January 2002 Slide 1 HC Recovery and Backoff Rules Sunghyun Choi and Javier del Prado.
Dynamic Sensitivity Control V2
Doc.: IEEE /1012r0 Submission Sept 2013 Dynamic Sensitivity Control Improvement to area throughput Date: Authors: Graham Smith, DSP GroupSlide.
Doc.: IEEE /879r3 Submission August 2004 Abel Dasylva, Nortel NetworksSlide 1 Class-based Contention Periods (CCP) for the n MAC A. Dasylva,
Doc.: IEEE /0806r0 SubmissionSlide 1 Date: Authors: aj (45 GHz) Channelization and Channel Operation Jul 2014 Bo Sun, ZTE Corp.
Doc.: IEEE /0025r0 Submission Jan 2015 Dynamic Sensitivity Control Roaming Date: 2015-January Authors: Graham Smith, SR TechnologiesSlide 1.
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 10 Authors:
Doc.: IEEE /2684r0 Submission November 2007October 2007 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution Date: Authors:
Doc.: IEEE /1290r0 Submission Nov 2013 Dynamic Sensitivity Control for HEW SG Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0256r0 Submission March 2010 Zhou Lan NICTSlide 1 Proposal of Synchronized Quiet Period for Incumbent User Detection Date: 2010-March.
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 15 Authors:
Doc.: IEEE /678r1 Submission January 2003 Mark Bilstad, Cisco SystemsSlide 1 Uniform e Admissions Control Signaling for HCF and EDCF Bob.
Doc.: IEEE /0880r2 Submission Scheduled Trigger frames July 2015 Slide 1 Date: Authors: A. Asterjadhi, H. Choi, et. al.
Doc.: IEEE /0062r0 Submission Jan 2010 Alex Ashley, NDS LtdSlide 1 OBSS HCCA Race Condition Date: Authors:
Doc.: IEEE / aa Submission May 2009 Graham Smith, DSP GroupSlide 1 Considerations for Statistical Multiplexing Support in OBSS Proposal.
Doc.: IEEE / aa Submission November 2009 Graham Smith, DSP GroupSlide 1 Outline of Proposed Overlapping BSS Solution Date: 2009, November.
Doc.: IEEE / aa Submission March 2009 Graham Smith, DSP GroupSlide 1 OBSS “OSQAP” QoS Issues Date: Authors:
Doc.: IEEE /0014r0 Submission January mc TXOP Limits Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0779r2 Submission June 2014 Dynamic Sensitivity Control Practical Usage Date: 2014-July Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /1378r0 Submission November 2008 Darwin Engwer, Nortel NetworksSlide 1 Improving Multicast Reliability Date: Authors:
Submission doc.: IEEE 11-12/535r1 May 2012 Jarkko Kneckt, NokiaSlide 1 Scanning and FILS requirements Date: Authors:
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Considerations for Statistical Multiplexing Support in OBSS Proposal.
Doc.: IEEE / aa Submission Feb 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: Authors:
Doc.: IEEE /0294r1 Submission Dynamic Sensitivity Control Channel Selection and Legacy Sharing Date: Authors: Graham Smith, DSP GroupSlide.
Doc.: IEEE /0097r0 SubmissionJarkko Kneckt (Nokia)Slide 1 Bandwidth Specific TXOP Limits Date: Authors: January 2011.
Resolutions to Static RTS CTS Comments
Doc.: IEEE /0126r1 Submission January mc HEMM Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0415r0 Submission April mc CIDs 1136,1118,1458 Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /0212r3 Submission Feb 2016 TG ax Enterprise Scenario, Color and DSC Date: Authors: Graham Smith, SR TechnologiesSlide 1.
Doc.: IEEE /0635r1 Submission May 2014 Dynamic Sensitivity Control Implementation Date: 2014-May Authors: Graham Smith, DSP GroupSlide 1.
Submission doc.: IEEE /0353r1 March 2016 Hanseul Hong, Yonsei UniversitySlide 1 MU-RTS/CTS for TWT Protection Date: Authors:
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:
Overlapping BSS Proposed Solution – “OSQAP”
Improvements to for Video Applications
Overlapping BSS Proposed Solution
QoS Tutorial Date: Authors: Nov 2008 Nov 2008
Overlapping BSS Proposed Solution
Outline of Proposed Overlapping BSS Solution
Consideration on Interference Management in OBSS
Class-based Contention Periods (CCP) for the n MAC
Considerations for OBSS Sharing using QLoad Element
HCCAOP Scheme, Efficiency and Sharing
Peer Power Save Mode for TDLS
OBSS Sharing with Access Fraction
Empirical Formula for EDCA Bandwidth Factor
HCCAOP Scheme, Efficiency and Sharing
20/40MHz Channel Selection
OBSS Sharing with Access Fraction
Stray and Overlapping STAs
802.11e QoS Tutorial Date: Authors: Nov 2008 Nov 2008
Overlapping BSS Proposed Solution – “OSQAP”
HCCAOP Scheme, Efficiency and Sharing
OBSS HCCA Race Condition
Stray and Overlapping STAs
Proposed Overlapping BSS Solution
Proposed Overlapping BSS Solution
Applicability of 11s MCCA to HCCA OBSS
Recommendation for EDCA Bandwidth Factor
Considerations for OBSS Sharing using QLoad Element
VTS Robust Multicast/Broadcast Protocol
HCCAOP Scheme, Efficiency and Sharing
Comment resolution #79 Date: 2009, November 17 Authors: November 2009
OBSS Sharing with Access Fraction
Scheduled Peer Power Save Mode for TDLS
Applicability of 11s MCCA to HCCA OBSS
OBSS Requirements Date: Authors: July 2008 July 2008
802.11e QoS Tutorial Date: Authors: Oct 2008 Oct 2008
Overlapping BSS Proposed Solution
OBSS Requirements Date: Authors: July 2008 July 2008
Presentation transcript:

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution Date: Authors:

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 2 Abstract The problem of OBSS is quantified and examined A solution for OBSS is presented and discussed A set of recommendations is given.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 3 OBSS – Estimation of Size of Problem Floor Plan of Apartments Each Apartment 26 x 40 feet, about 1000 square feet Imagine similar floors above and below this one. Indoor propagation loss formula used: Lp = – log F + 40 log d + WAF (p) + FAF (q)F in MHz, d in feet At shorter distances, the Free Space formula dominates, Lp =– log F + 20 log d + WAF (p) + FAF (q) The predicted propagation loss is the higher of the two. Each wall (WAF) and floor (FAF) between apartments is assumed to be 10dB penetration loss (fireproof). Ceiling height is assumed to be 10 feet.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 4 Received Signal Strengths 1Inside same apartment 2Next door (one each side) x2 3Two away (one each side) x2 4Three away (one each side) x2 5Opposite 6Opposite, across one (one each side) x2 7Opposite, across two (one each side) x2 8Opposite, across three (one each side) x2 9Directly up and down x2 10Up or down, neighbor (one each side) x4 11Up or down, two away (one each side) x4 12Up or down, three away (one each side) x4 13Opposite, up and down x2 14Opposite, up and down, two across x4 15Opposite, up and down, one across x4 16Opposite, up and down, three across x4 17Two floors directly up and down x2 30dB power control

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 5 Number of OBSS – DFS and TPC Table 1 – Theoretical OBSS for Apartments sq. ft. Ideal DFS reduces problem significantly! Table 2 – Theoretical OBSS with 30dB Power Reduction Received signal strength within each apartment is high, better than -40dBm. Theoretically, therefore, the power could be reduced by 30dB with no deterioration in the throughput. Solves OBSS! Frequency BandNumber of Interfering Networks Interfering Networks per 20MHz Channel Interfering Networks per 40MHz Channel 2.4GHz GHz Frequency BandNumber of Interfering Networks with 30dB power reduction Interfering Networks per 20MHz Channel with 30dB power reduction Interfering Networks per 40MHz Channel with 30dB power reduction 2.4GHz833 5GHz400 5GHz for Home!

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 6 Effects of OBSS - 1 #Network AOBSS Network BEffectResult 1Legacy Traffic simply competes  Reduced bandwidth in each network  No lost packets  Not recommended for streaming 2EDCALegacyHigher priority traffic in Network A will drive down traffic in Network B  AC_VO and AC_VI traffic dominates. Could be OK for streaming traffic but no admission policy  Network A “wins” 3EDCA Traffic competes on a priority basis. Networks compete on an ‘equal’ basis  Reduced bandwidth in each network  No real protection for streaming traffic in either network

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 7 Effects of OBSS - 2 4Admission Control LegacyHigher priority traffic in Network A will drive down traffic in Network B  AC_VO and AC_VI traffic dominates. Could be OK for streaming traffic  Network B bandwidth can be drastically reduced 5Admission Control EDCATraffic competes on a priority basis. Admission Control in Network cannot control traffic in Network B  No protection for admitted traffic in Network A 6Admission Control Admission Control Traffic competes on a priority basis. Admission Control in either Network cannot control traffic in other Network  No protection for admitted traffic in either Network #Network AOBSS Network B EffectResult These cases are cause for concern, Admission Control is the highest QoS presently certified and it breaks down in OBSS!

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 8 Effects of OBSS - 3 7HCCALegacyScheduled TXOPs in Network A also apply CFP to Network B.  Full protection for scheduled traffic in Network A  Network B bandwidth reduced 8HCCAEDCAScheduled TXOPs in Network A also apply CFP to Network B.  Full protection for scheduled traffic in Network A  Network B bandwidth reduced 9HCCAAdmission Control Scheduled TXOPs in Network A also apply CFP to Network B Admitted traffic Network B is lower priority than scheduled traffic in Network A  Full protection for scheduled traffic in Network A  Network B bandwidth reduced  Both Networks using TSPECS 10HCCA Each HCCA AP will admit streams and allocate time to them BUT each AP and STA will obey the TXOP allocation of the other. No guarantee that each Network can allocate time when it needs to.,  Reduced protection for scheduled traffic in either network.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 9 OBSS and QoS For non-QoS (non-real time streaming) applications OBSS is simply a sharing or reduced bandwidth per network. For QoS applications, OBSS can be a disaster QoS = It starts good, it must stay good This is the problem that needs to be solved! e QoS = EDCA Admission Control and HCCA EDCA on its own does not provide any protection in its own network, let alone OBSS

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 10 OBSS – EDCA on EDCA Table clearly shows that OBSS is a problem for when it is intended to be used for applications that require QoS. EDCA does not address the problem at all. EDCA Admission Control only solves the bandwidth allocation problem within its own network and does not address OBSS. HCCA does overcome OBSS problems in all but the case where two HCCA networks overlap. Conclusions: 1.EDCA is not providing QoS in OBSS situation and any higher bandwidth streaming application is not protected 2.If we wish to solve OBSS problem then the use of HCCA would seem to be mandatory and we need to look into solving the OBSS situation for two HCCA networks and, at the same time, solving it for Admission Control

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 11 Solving OBSS Channel Selection is first important step TPC is probably difficult to assume If so, it could be assumed that the OBSS situation could be eliminated or limited to a maximum of two QAPs Objective: –Two HCCA networks can co-operate –HCCA and Admission Control QAPs can co-operate –Two Admission Control QAPs co-operate Note: Still not protected against EDCA OBSS

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 12 Channel Selection NOW A possible basic method for QoS networks to co-operate is: QAP selects a Channel Listen for another Beacon on that channel If clear, then allow STAs to associate If Beacon indicates AP is not a QAP, note this but continue to seek a clear channel. If after cycling through the channels, no clear channel is found then –Select a channel that is shared with a non-QoS AP. –Allow STAs to associate Issue a standard Beacon Request/Report (802.11k) to the STAs. If no other QAP is reported, then the QAP may choose that channel If another QAP is reported (on a different ESS), try to find another channel. No idea of QoS Load, No method of Sharing Bandwidth (but should be used NOW)

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 13 OBSS – Basic Starting Point 1.When QSTAs associate, they send their TSPEC(s) corresponding to their expected requirements 2.Using the TSPECs, QAP ‘A’ builds knowledge of the QoS demands of its network, we shall call this the “Q Load” 3.Another QAP ‘B’, looking for a spare channel or whether to share, would interrogate QAP ‘A’ to establish the Q Load ‘A’. Based on this QAP ‘B’ can make a decision on whether to stay or not 4.Assuming that QAP ‘B’ does stay, then it determines its own Q Load ‘B’ 5.QAP ‘A’ and QAP ‘B’ now negotiate the bandwidth, based upon their Q Loads EDCA Admission Control only QAPs are now co-operating. Note, however, that they still do not have protection against legacy EDCA networks. 6.If a successful outcome then HCCA networks proceed to step 7. If not, then QAP B must leave to seek another Channel. 7.QAP ‘A’ and QAP ‘B’ harmonize such that they schedule TXOPs correctly with respect to both networks Each step will now be examined in more detail.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 14 OBSS - TSPEC Exchange Figure 10 – TSPEC Element On association, a QSTA sends its TSPEC, QAP knows the STA’s requirement (s). The TSPEC has Inactivity Interval set to 0 (needs to be added for Admission Control) Causes the TSPEC to expire instantly, once accepted. QAP could recognize this as a special case and know that the intention is for the QSTA to inform the QAP of its expected load Note that the QAP must remember the allocation required for all the ‘sign on’ TSPECs and respond accordingly

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 15 QAP Q Load Reporting QBSS Load element Format Not adequate for purpose Propose to add or replace similar new Element – “Q Load Element” Scheduled Slot field Base timing for the Scheduled Service Intervals that the HC is using Allocated Admitted field Amount of medium time that has been approved for EDCA Admission Control Allocated Scheduled Total of Scheduled TXOPs that has been approved for HCCA STAs Also could be used in 11r Fast Handoff avoiding need to pre-register

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 16 Channel Priority – Finding a Clear Channel When a QAP is searching for a channel, it should do so in the following order: 1.Set its CHP (Channel Priority) to 1 2.Check no other AP present 3.Check no other QAP present 4.If another QAP present, then check QAP Q Load is small enough such that the two can share If QAP selects its channel based upon 1 or 2, then 5.Check that no other QAP is within range of its network QSTAs using Beacon Request Report 6.If positive, and decides to stay, set CHP to 0 If 4, and QAP chooses to share, sets CHP to 0 NOTE: Non QAPS would also try to avoid QAPs.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 17 QAPs Negotiate Basic options for sharing ‘rules’ are: –First Come, First served (FCFS). TSPECs are accepted, HCCA and EDCA, in the order they appear. Both QAPs must know the prevailing total Q Load so as not to over-allocate. –Negotiated Bandwidth Simple Proportion (SPNB) Based upon the potential Q-Load of each QAP, the bandwidth is proportioned up between them accordingly. This way, each QAP knows its modified maximum bandwidth allocation On-Demand Negotiated Bandwidth (ODNB) Basically, when a QAP receives an ADDTS request, that, if accepted, would take the QAP over the SPNB allocation, it must get permission from the other QAP to accept it. Preferred Method (it’s easy) This is enough for WMM-Admission Control QAPs, HCCA QAPS need to Harmonize

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 18 Harmonizing HCCA QAPs Explanation of Scheduling of TXOPs Schedule for QSTAs Desirable that the start times of the TXOPs are maintained at the same interval. This enables the QSTA use efficient S-APSD, Maintain the minimum service interval (SI) requirement as per the TSPEC

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 19 Fixed Slot time 10ms Min and Max Service Intervals for Voice and Video CategoryMinimum Service IntervalMaximum Service Interval Voice G711, G729, AMR-NB, AMR-WB, iLBC, EVRC, VMR-WB 20ms Voice G711,G729,G ms Voice G ms Video SDTV, HDTV 0ms16ms 10ms fixed Slot

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 20 Harmonize Slot times QoS (+) CF Poll Frame sent by HC At the beginning of the Slot, QAP sets bit 7 The suggested procedure (see next slide) 1.At the beginning of the Slot, the QAP A sets bit 7. This could be included in the first TXOP or, if there is no TXOP at that time then the QAP simply sends a QoS Poll to itself. 2.QAP B waits the maximum duration of the TXOPs sequence Period indicated in the Allocated Scheduled field in the Q LOAD element for QAP A 3.QAP B starts its Slot time and TXOPs Simple and straightforward

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 21 Service Interval Harmonization

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 22 OBSS Proposed Procedure Summary 1.Before seeking a channel, a QAP sets its CHP to 1 in the Q LOAD element. 2.QSTAs send their expected TSPECs as they associate, with Inactivity Period set to 0, and the QAP calculates its values for the Q LOAD Element 3.A QAP should try to find a channel that has no other QAP present, by first listening for another Beacon, and then issuing a standard Beacon Request (see figure). An extension to this is that the Beacon Request and resulting Probe Request is tailored to seek out the Q Load Element. 4.If no other QAP is reported, then the QAP may choose that channel. 5.If another QAP is reported, then the respective Q LOADs are examined and a decision made as to share or not. 6.If the decision is to share, then the CHP is set to 0. 7.If the QAPs are not hidden then the condition of sharing is recognized (CHP 0 and 1) and each QAP calculates its available schedule time based on Simple Proportion. 8.If the QAPs are hidden then the OBSS Beacon Request /Report is used such that each QAP knows the Q LOAD of the other and of the decision to share (CHP 0 and 1) EDCA Admission Control QAPs can now proceed

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 23 OBSS Proposed Procedure Summary HCCA QAPs need to harmonize their SIs. 9.Each HCCA QAP indicates its start of the Slot Time by setting bit 7 in the QoS CF Poll. 10.If QAPs are not hidden, the Slot Times are harmonized using the Start of Slot Time indication and the Allocated Scheduled information in the Q LOAD. Proposal for Hidden APs (to be discussed) If QAPs are hidden, if they experience scheduling problems to specific QSTAs, they adjust their respective Slot Times (TSF Timer), at DTIM intervals, by 0.5ms in a positive or negative direction as per the CHP setting.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 24 Beacon Report Exchanges OBSS Beacon Request Provides other QAP the Q Load element Informs CHP

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 25 OBSS Summary Two HCCA networks could share Two EDCA Admission Control networks could share An HCCA and an EDCA Admission Control Network could share An EDCA Admission Control and an EDCA network would still not share. Proposed additions to the Standard are : “Q LOAD Element” for HCCA and EDCA Admission Control QAPs “OBSS” Beacon Request Report Fixed 10ms Slot time Use of bit 7 in QoS CF Poll to indicate start of Slot Time We now consider “Hidden –AP”

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 26 Hidden QAPs If QAP stays after Beacon Report, set CHP to 0 and sends OBSS Beacon Request QAP B now knows of QAP A and its Q Load QAP ‘A’ and QAP ‘B’ calculate their maximum allocated bandwidth, based upon their Q Loads and the SPNB method. QAP A and QAP B must now harmonize their Scheduled Allocations

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 27 Harmonizing SI – Direct Method Direct Method (as per non-hidden QAPs) Could be possible using a common STA BUT The QSTA may be in power save mode If the first TXOP has been granted then the QSTA is prevented from transmitting, so sending the timer onto the other QAP is not possible The only legitimate transmission from a STA to an AP outside its network, is the Probe Request It is not advisable, or even allowed to change a scheduled time by too much.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 28 Harmonizing SI – Indirect Method QAP A CHP = 0; QAP B CHP = 1 QAP A determines that a scheduled stream to a particular QSTA is blocked and suspects that it is due to scheduling from the QAP B. In this case, QAP A shifts its TSF timer, at DTIM, in the positive direction by 5% of the slot time, i.e. 500us. Similarly, QAP B determines that a scheduled stream to a QSTA is blocked and suspects that it is due to scheduling from the QAP A. In this case, QAP B shifts its TSF timer, at DTIM, in the negative direction by 5% of the slot time, i.e. 500us.

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide n - 40MHz OBSS 40MHz Channels –Easy/intuitive to see how two 40MHz overlapping networks will be less efficient than separate, independent 20MHz channels. MUST use the OBSS proposals to: –Try to find clear channel –If not clear, look for 20MHz channel MUST introduce procedures for preventing or controlling OBSS and usage of 40MHz channels The same procedures as previously described can be used

doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 30 Recommendations Recommendations: –“Q LOAD Element” for HCCA and EDCA Admission Control QAPs –“OBSS” Beacon Request Report –Fixed 10ms Slot time for HCCA –Use of bit 7 in QoS CF Poll to indicate start of Slot Time –Addition of recommended practices for OBSS Note: Wi-Fi Alliance could then devise tests to certify the behavior (this is important) –What to do about TPC? Treat as a separate subject? Support for this approach? –Should we go ahead to write normative text based on this approach?