Applicability of 11s MCCA to HCCA OBSS

Slides:



Advertisements
Similar presentations
Submission doc.: IEEE /1357r3 Nov Slide 1 Dynamic TIM and Page Segmentation Date: Authors: Weiping Sun, Seoul National University.
Advertisements

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 / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Proposed Overlapping BSS Solution Date: 2009, July 15 Authors:
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 / 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 /0562r0 Submission May 2009 L. Chu et alSlide 1 MCF Issues Date: Authors:
Doc.: IEEE /0100r2 Submission January 2010 Kazuyuki Sakoda, Sony CorporationSlide 1 MAC beaconing sync comment resolution Date: Authors:
Doc.: IEEE /2684r1 Submission November 2007 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution Date: Authors:
Doc.: IEEE /0126r1 Submission January mc HEMM Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE / aa Submission Apr 2009 Graham Smith, DSP GroupSlide 1 Overlapping BSS Proposed Solution – “OSQAP” Date: 2009, April 17 Authors:
Synchronization of HCCA APs in OBSS
Overlapping BSS Proposed Solution – “OSQAP”
FILS Reduced Neighbor Report
2200 Mission College Blvd., Santa Clara, CA 95054, USA
Possible Approaches for HEW
How to collect STAs’ Tx demands for UL MU
Overlapping BSS Proposed Solution
QoS Tutorial Date: Authors: Nov 2008 Nov 2008
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
2200 Mission College Blvd., Santa Clara, CA 95054, USA
Overlapping BSS Proposed Solution
Peer Power Save Mode for TDLS
FILS Reduced Neighbor Report
Outline of Proposed Overlapping BSS Solution
Class-based Contention Periods (CCP) for the n MAC
2200 Mission College Blvd., Santa Clara, CA 95054, USA
Considerations for OBSS Sharing using QLoad Element
HCCAOP Scheme, Efficiency and Sharing
Synchronization of HCCA APs in OBSS
2200 Mission College Blvd., Santa Clara, CA 95054, USA
Peer Power Save Mode for TDLS
OBSS Sharing with Access Fraction
Empirical Formula for EDCA Bandwidth Factor
HCCAOP Scheme, Efficiency and Sharing
OBSS Sharing with Access Fraction
MCCA Comments Resolution 159 ppt
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
Setting of DTIM Interval for MCCA
Proposed Overlapping BSS Solution
Proposed Overlapping BSS Solution
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Considerations for OBSS Sharing using QLoad Element
VTS Robust Multicast/Broadcast Protocol
Peer Power Save Mode for TDLS
Synchronization related comment resolution
Schedule Element Synchronization and Simplification
Synchronization of Quiet Periods for Incumbent User Detection
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
MAC beaconing sync comment resolution
MBCA and Beacon Timing element clean up
Setting of DTIM Interval for MCCA
Dynamic TIM and Page Segmentation
Cooperative AP Discovery
Applicability of 11s MCCA to HCCA OBSS
802.11e QoS Tutorial Date: Authors: Oct 2008 Oct 2008
Overlapping BSS Proposed Solution
Presentation transcript:

Applicability of 11s MCCA to HCCA OBSS May 2009 doc.: IEEE 802.11-08/0xxx May 2009 Applicability of 11s MCCA to HCCA OBSS Date: 2009-05-21 Authors: Graham Smith, DSP Group Graham Smith, DSP Group

May 2009 doc.: IEEE 802.11-08/0xxx May 2009 Abstract This presentation looks at MCCAOPs as proposed in 11s and then discusses how a similar scheme could be used in the OBSS proposal for HCCA sharing. We then compare this scheme with the present OSQAP proposal Finally work areas proposed in order to decide if this scheme should be used. Graham Smith, DSP Group Graham Smith, DSP Group

May 2009 MCCAOP Basic Scheme Mesh STA scans channel for neighborhood mesh STAs supporting MCCA MCCA Advertisement Element includes Reservation Fields for Self and Interfering (Neighbor’s MCCAOPs that do not involve the STA itself) Build a map of neighborhood MCCAOP reservations by listening to the MCCA Advertisement Element Choose start and duration times so no overlaps with Neighbor or Interfering times Check that new MCCAOP does not exceed the maximum access fraction limit Graham Smith, DSP Group

MCCAOP Reservations Time reservations are defined as Duration, May 2009 MCCAOP Reservations Time reservations are defined as Duration, Periodicity: Number of MCCAOPs in mesh DTIM interval (sub-Intervals) Offset: Beginning of MCCAOP relative to beginning of each sub-interval Graham Smith, DSP Group

TX-RX and Interfering Times Reports May 2009 TX-RX and Interfering Times Reports TX-RX Times Report MCCAOP Reservations for the mesh STA itself Interfering Times report A mesh STA reports MCCAOP Reservations that its neighbors have advertised in their TX-RX Reservation Reports in which it is not involved itself. The Interfering Times are directly derived from neighbor peer mesh STAs’ TX-RX Times Report. These times shall not be used for a new MCCAOP with the reporting mesh STA as they may experience interference Mesh STAs know the absolute timing from the TSF and TBTT of the neighbor mesh STAs Graham Smith, DSP Group

MCCAOP Advertisements Element May 2009 MCCAOP Advertisements Element Current value of MCCA access fraction at the mesh STA. Maximum MCCA access fraction allowed at the mesh STA. Graham Smith, DSP Group

Observations, Questions May 2009 Observations, Questions Periodicities must be in harmony to avoid clashes*: If Periodicities are 1, 2, 4, 8 etc. then STA can calculate times that will not interfere If Periodicities are, say, 1, 2, 3, 4, 5,etc. Then impossible to calculate times that will always be free. Scheme is “First-Come-First-Served” with “Access Limit” Time is reserved even if not used for actual traffic The Access Fraction and Access Fraction Limit is per STA but not clear if it is an agreed/imposed value for the neighborhood and interfering. Time reservations are for traffic between the STAs MCCAOP Times can be re-used after 4 hops (see example next slide) Relies on STAs scheduling OPs in an efficient order to produce good bandwidth usage – pick sequential if possible? No mention on this* STAs need to calculate the “Times” from neighbors with respect to their own timing Does a STA report the times in the Interfering Time Report in terms of its local time? Can’t see it in the Spec but must happen for it to work* STA needs to use TSF and TBTT information from neighbor to calculate actual Times *NOTE: Not sure if this is realized in 11s Graham Smith, DSP Group

May 2009 Graham Smith, DSP Group

May 2009 Applicability to OBSS Graham Smith, DSP Group

May 2009 Graham Smith, DSP Group

Q Load Element proposed in 09/0497r2 May 2009 Q Load Element proposed in 09/0497r2 DISTANCE > 2 Can be ignored Graham Smith, DSP Group

QLoad Element Fields May 2009 Overlap Number of APs that are sharing this channel and are overlapping QLoad MEAN and STDEV The mean and standard deviation of the total traffic presented to the QAP by TSPECs from STAs associated to that QAP (see 09/0496r2 and 09/0497r2) QAP ID First octet = random number (0 to 255) Second octet = octet 6 of MAC Address Once selected, QAP retains this ID Chosen so that it is still possible to know which specific QAP this is QAPs need recognize their own QLoad Distance Distance is set to 0 for Self QAP ID Directly visible to the QAP Self, then “Distance” is set to 1 Not directly visible to the QAP Self, then “Distance” is set to 1 plus the value reported for that QAP ID in the QAP that is directly visible Any QAP with Distance” > 2 is not recorded in QLoad Element Channel Priority Used only if QAP is operating with HCCA, indicates HCCA Supervisor Can we use MCCAOP Scheme In place of this? Graham Smith, DSP Group

HCCA Sharing based closely upon MCCAOP Scheme May 2009 HCCA Sharing based closely upon MCCAOP Scheme QAPs with Distance <3 in the QLoad Element are included in the Interfering Times Report QAPs allocate new TXOPs by inspecting the HCCAOP Advertisement Element, checking no overlap and does not exceed HCCA Access Limit Graham Smith, DSP Group

HCCAOP Advertisement Element May 2009 HCCAOP Advertisement Element HCCA Access Fraction (HAF) HAF = Sum of TXOPs in 32us/sec HCCA Access Fraction Field Current value of HAF at the QAP rounded down (floor) to the nearest multiple of (1/256). HCCA Access Fraction Limit field Maximum HAF expressed in units of (1/16) allowed at the QAP. This number is always a multiple of (1/16) Note: See more on this later. Interfering Times Report All QAPs that have a “Distance” of 1 and 2 in the QLoad Element TXOP Reservation Note: The HCCA Schedule Element is used for scheduled power save and hence not directly applicable Duration: In units of 32us Service Interval (may specify 10ms basic slot) Offset: Beginning of first TXOP after a Beacon, relative to beginning of each scheduled Beacon, in units of 32us NOTE: HCCA Advertisement Element informs ONLY TXOPs THAT ARE ACTIVE. Graham Smith, DSP Group

Comments on this Scheduling Scheme May 2009 Comments on this Scheduling Scheme First-Come-First-Served QAP cannot allocate a TXOP if time not available No concept of sharing No concept of efficiently allocating TXOPs, e.g. allocate in blocks and have a ‘common’ time slot idea Need to establish a procedure to set the HAF Limit so as to create a “Sharing” method? Clock Drift Clock drift between QAPs will cause clashes to occur. 11s uses Neighbor Offset Protocol and Beacon Timing Elements. Constant monitoring of Beacon timing. TSF timer is suspended to match. Scheme is basically designed to avoid Beacon clash. Graham Smith, DSP Group

Setting the Access Limit and Sharing May 2009 Setting the Access Limit and Sharing 09/0497r2 Sharing described how the summing of the individual streams can be achieved using the QLoad values. Based upon the QLoad it would be possible to set an “Access Limit” if there is over-allocation. This could then be translated into requirements for each QAP. By this means the HAF and HAF Limit could be calculated and advertised in the HCCA Advertisement. Also looks useful for EDCA Admission Control and hence should go into the QLoad Element Graham Smith, DSP Group

Access Fraction Field in QLoad Element May 2009 Access Fraction Field in QLoad Element Add 1 octet to QLoad Element Access Fraction: 4 bits Total actual admitted time and/or scheduled time expressed as a fraction of 32us/sec rounded down to 1/16 Access Fraction Limit: 4 bits Maximum admitted time and/or scheduled time that this QAP may allocate Calculated based upon: sum of MEAN and STDEV for ALL QAPs in QLoad Element EDCA only, include factor for number of Priority Streams for Distances 0 and 1 Scaled if result is greater than 100% Notes: HCCA Advertisement Element could repeat this or omit it Needs agreement that Sharing rules should apply, or at least be explained how to do it. Graham Smith, DSP Group

May 2009 New Field added Graham Smith, DSP Group

Clock Drift Mitigation? May 2009 Clock Drift Mitigation? Two Options Let it happen When say TXOP A finishes late, next TXOP B just get delayed Delay would build up in subsequent slots until they exchange positions and TXOP B occurs first No real problem but does introduce some inefficiency if scheduled power save is being used Synchronize Monitoring of TSF and TBTT possible for neighbors but complicated through the QAPs in the Interference Times Report. Beacon Timing Report Element only reports neighbors Conclusion - Let it happen Graham Smith, DSP Group

Before comparison - Refresher on CHP scheme May 2009 Before comparison - Refresher on CHP scheme Graham Smith, DSP Group

Harmonizing HCCA When sharing use Fixed Time Slot May 2009 Harmonizing HCCA When sharing use Fixed Time Slot Each AP (HC) knows how much of the Time Slot it can use: QLoad Self Supervisor AP (CHP=1) hands off to the other QAP(s) using Wireless DS QoS CF-Poll (Null Data) for AP-AP communication Supervisor QAP (CHP = 1) controls the 10ms slot timing Supervisor QAP sends message to other QAPs (CHP = 0) indicating time to start of their respective TXOP periods. Uses Wireless DS (AP to AP), QoS CF-Poll (null data) 09/0230r0 describes rules for when Supervisor QAP goes away and when two QAPs have CHP set to 1 “Supervisor Claim” and “Is Supervisor There” packets used. Graham Smith, DSP Group

May 2009 AP to 2 APs Graham Smith, DSP Group

Rules for Setting CHP bit and Sharing (per 09/230r0) May 2009 Rules for Setting CHP bit and Sharing (per 09/230r0) When a HCCA QAP is searching for a channel, it should do so in the following order: Set CHP (Channel Priority) to 0 If finds a clear Channel, set CHP to 1 If no clear channel, then may share with Any legacy AP: Set CHP to 1 An Admission Control QAP, overlap 0 or 1: Resulting HCCA QAP overlap being 1:1, or 1:2 Set CHP to 1 (see Note 1) An HCCA QAP with CHP = 1 CHP stays at 0 (see Notes 1 & 2) If an HCCA QAP cannot find a channel that meets the rules, it must fall back to Admission Control (see note 3) NOTES: If 3b) or 3c), check that “QLoad Total” is such that the two can share An HCCA QAP may not share with an HCCA QAP which has CHP = 0, unless it is also sharing directly with the corresponding HCCA QAP that has CHP = 1 Restriction on sharing with HCCA would not be applicable in practice if 17 or more channels are available. HCCA QAP should be able to find channel that meets requirement, See Slides 24 – 29. Graham Smith, DSP Group

May 2009 WDS QoS CF Polls To Supervisor from QAP with CHP=0 ACTION Bits 0-3 Bit 4 Bits 5-6 Bit 7 Bits 8-15 CHP is set to 0 0000 1 00 Is Supervisor There? 0010 From Supervisor QAP with CHP=1 ACTION Bits 0-3 Bit 4 Bits 5-6 Bit 7 Bits 8-15 Indication from Supervisor to another QAP of Time to start TXOP (HCCA sharing) 1111 1 10 Time to start of TXOP in units of 32us Supervisor Claim, CHP = 1 0001 00 Graham Smith, DSP Group

Quick Summary May 2009 CHP scheme HCCAOP scheme Supervisor controls the timing of a 10ms Slot and passes control over to each QAP in turn Uses the “total QLoad” to allocate time within a 10ms Slot. QAPs then free to allocate individually within that sub slot. Produces efficient use of the bandwidth. Idea of one network being ‘controlled’ by another, is unique within 802.11 Easy to comply with Sharing Rules (Access Fraction Limit) Has limitations with Supervisor visible to other QAPs. Does not cater for Distances > 1. HCCAOP scheme Each QAP determines its own TXOP schedules by looking for unused time between Beacons. Requires time conversion in order to determine the available slots Clock drift will cause delays in TXOPs, but not a big problem If common time slot concept used, together with QAPs allocating or reserving blocks based on “Total QLoad”, then can approach efficiency of CHP – is this practical? needs work Compliance with Sharing rules (Access Fraction Limit) needs more work Caters for “Distances” >1 Graham Smith, DSP Group

May 2009 Conclusion Before final decision, need to look at HCCAOP Scheme closely with respect to the sharing and efficient selection of TXOPs by the individual QAPs. Need to prepare submissions on: Access Fraction in QLoad Element How to use it for Sharing HCCAOP Advertisement Element Use of HCCA Access Fraction How to make it more efficient and compliant with HCCA scheduling Graham Smith, DSP Group