1 / 27

Applicability of 11s MCCA to HCCA OBSS

Applicability of 11s MCCA to HCCA OBSS. Authors:. Date: 2009-05-18. 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

annot
Télécharger la présentation

Applicability of 11s MCCA to HCCA OBSS

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Applicability of 11s MCCA to HCCA OBSS Authors: Date: 2009-05-18 Graham Smith, DSP Group

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

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

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

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

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

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

  8. Graham Smith, DSP Group

  9. Applicability to OBSS Graham Smith, DSP Group

  10. Graham Smith, DSP Group

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

  12. QLoad Element Fields • 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

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

  14. HCCAOP Advertisement Element • HCCA Access Fraction (HAF)HAF = Sum of TXOPs in 32us/sec • HCCA Access Fraction FieldCurrent value of HAF at the QAP rounded down (floor) to the nearest multiple of (1/256). • HCCA Access Fraction Limit fieldMaximum 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 ReservationNote: 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

  15. Comments on this Scheduling Scheme • First-Come-First-Served • QAP cannot allocate a TXOP if time not availableNo 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

  16. 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 maybe useful for EDCA Admission Control and hence should go into the QLoad Element Graham Smith, DSP Group

  17. Access Fraction Limit The procedure when an HCCA QAP C joins an OBSS of QAP A and B, and causes over-allocation, would be along the lines of: Initial Condition: • QAP A and QAP B requirements as per QLoad Elements • If total is <100%, then for both QAPA and QAPBAccess Fraction Limit = Sum of [Mean + X*STDEV] (X= 2 or 1.3 or .83)Access Fraction = Sum of Actual allocations (do we need this? Check on cheats?) • HCCA allocations can take place • QAP C Joins QLoad Elements show requirement >100%, say 120% • For each QAPAccess Fraction Limit = Sum [Mean + X*STDEV] * 100/120Access Fraction = Sum of Actual allocations • HCCA QAPs may now only schedule times up to their HAF Limit • Need to “Grandfather in” existing streams Graham Smith, DSP Group

  18. Access Fraction Field in QLoad Element • Add 1 octet to QLoad Element • Access Fraction: 4 bitsTotal actual admitted time and/or scheduled time • expressed as a fraction of 32us/sec rounded down to 1/16 • Access Fraction Limit: 4 bitsMaximum admitted time and/or scheduled time that this QAP may allocate • expressed as a fraction of 32us/sec rounded down to 1/16 • 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

  19. New Field added Graham Smith, DSP Group

  20. Clock Drift Mitigation? • Two Options • Let it happen • When say TXOP A finishes late, next TXOP B just get delayedDelay 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

  21. Before comparison - Refresher on CHP scheme Graham Smith, DSP Group

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

  23. AP to 2 APs Graham Smith, DSP Group

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

  25. WDS QoS CF Polls To Supervisor from QAP with CHP=0 From Supervisor QAP with CHP=1 Graham Smith, DSP Group

  26. Quick Summary • CHP 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

  27. 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. • Also need to confirm ideas on Access Fraction for HCCAOP and how to use it Separate presentation, this one is already long enough!! Graham Smith, DSP Group

More Related