1 / 33

Outline of Proposed Overlapping BSS Solution

Outline of Proposed Overlapping BSS Solution. Authors:. Date: 2009, November 9. Abstract. This presentation presents the proposed solution for OBSS, with options 08/0457r4 and 08/1260r1 examined the OBSS problem and outlined possible solutions – “QLoad” introduced

mejiaj
Download Presentation

Outline of Proposed Overlapping BSS Solution

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. Outline of Proposed Overlapping BSS Solution Authors: Date: 2009, November 9 Graham Smith, DSP Group

  2. Abstract This presentation presents the proposed solution for OBSS, with options 08/0457r4 and 08/1260r1 examined the OBSS problem and outlined possible solutions – “QLoad” introduced 08/1250r0, 09/0285r0, and 08/1470r4 looked at the OBSS scenarios, estimated worse case overlaps and ran simulations using Channel Selection so as to size the problem. 09/0230r0 and 09/0476r1 gave the details of the revised OBSS proposal with use of CHP bit and HCCA Supervisor 09/0496r2 examined video stream statistics 09/0497r2 extended the video stream statistics to QLoad fields 09/0660r3 examined using 11s MCCA for HCCA OBSS 09/0662r2 introduced OBSS Sharing with Access Fraction 09/0666r2 considered HCCAOP Advertisement Element for sharing and TXOP avoidance 09/0931r0 looked at Stray and Overlapping STAs 09/1136r0 Examined the Hidden AP situation and AP Shut Out problem 09/1137r0 Examined EDCA Bandwidth Factor Graham Smith, DSP Group

  3. Objectives of OBSS Proposal Provide the means for: • Meaningful Channel Selection • Sharing in an OBSS Situation: • Co-operation between Admission Control QAPs • Co-operation between HCCA and Admission Control QAPs • Co-operation between HCCA QAPs • This proposal has some significant changes from previous and now includes the support for an On-Demand Sharing scheme in addition to a Proportional Sharing scheme. Graham Smith, DSP Group

  4. Outline of Proposal • Qload Report Element • QLoad Report Request Action Frame • QLoad Report Public Action Frame • Optionally in Beacon • New entries in Extended Capabilities • QLoad Report (AP) • TSPEC Requirement Request (non-AP STA) • New Action Frame “TSPEC Requirement Request” • Sent by QAP to STA to indicate or confirm their TSPECs • New IE “HCCA TXOP Advertisement Element” • Used by HCCA QAPs to avoid the TXOPs of overlapping QAPs • Annex (Informative) • Channel selection based upon information in the QLoad Element: • How to calculate the values in the QLoad Report • How to use the fields in the QLoad Element for Sharing and to prevent over-allocation • Proportional Sharing Scheme • On-Demand Sharing Scheme Graham Smith, DSP Group

  5. QLoad Report Element QLoad, Allocated Traffic Self, and Allocated Traffic Shared Fields Access Factor Field and HCCA Access Factor field Graham Smith, DSP Group

  6. QLoad Fields • QLoad • indicates the total potential QoS traffic for the AP and its BSS and is expressed as a Mean and Standard Deviation in units of 32µs. Also indicates the number of AC2 and AC3 EDCA streams that make up that composite stream • Allocated Traffic Self • indicates the total allocated QoS traffic, and is expressed as a Mean and Standard Deviation in units of 32µs. Also indicates the number of AC2 and AC3 EDCA streams that make up that composite stream • Allocated Traffic Shared • the composite sum of the Allocated Traffic Self values that can be received from overlapping APs, plus the Allocated Traffic Self value of the AP itself, and is expressed as a Mean and Standard Deviation in units of 32µs and number of AC2 and AC3 streams. • Access Factor • the composite sum of the QLoads that can be received from overlapping APs, plus the QLoad of the AP itself • HCCA Peak • the total peak HCCA TXOP requirement, over a period of one second, for the AP and BSS, for all the HCCA TSPECS that are included in the QLoad. HCCA Peak is expressed in multiples of 32µs. • HCCA Access Factor • the sum of the QLoads that can be received from overlapping APs, plus the QLoad of the AP itself • Overlap • indicates the number of other APs that are sharing the same channel and whose beacons can be detected Graham Smith, DSP Group

  7. HCCA Advertisement Element The HCCA TXOP Advertisement element is used by an AP to advertise its TXOP state to its overlapping APs TX OP Reservation field The Duration in multiples of 32µs. The Service Interval (SI) in multiples of 1ms The Start time is the lower order 2 octets of the TSF timer value at the start of the first SP Graham Smith, DSP Group

  8. TSPEC Requirements Request The TSPEC Requirements Request frame is used by an AP to direct a non-AP STA to send ADDTS Requests for all its potential TSPECs Category, Action, Dialog Token Graham Smith, DSP Group

  9. 11 MLME QLoad Element The QLoad element is contained in a public action frame that is provided by an AP and optionally, periodically in the Beacon. The QLoad Report public action frame is transmitted upon the receipt of a QLoad Report Request. Whenever there is a change in the contents of the QLoad Element, an unsolicited QLoad Action frame should be transmitted. Graham Smith, DSP Group

  10. Values in QLoad Element • The values in the QLoad Field shall be derived by one or more of three methods: • Send TSPEC Requirements Request (if STA supports) • STA sends TSPEC with Inactivity Period set to 1 • Noting TSPECs as they arise (AP decides whether to keep or not after DELTS) EDCA Priority Streams The number of AC2 and AC3 streams that make up the peak composite traffic are included in the QLoad. These are used to calculate the EDCA BW Factor As per 09/xxxxr0, allocated Medium Times do not include contention overhead. The number of streams is used to calculate the “EDCA Bandwidth Factor” The recommended formula is provided in Annex (Informative) Graham Smith, DSP Group

  11. Allocated Traffic Self and Shared • Allocated Traffic Self • The Allocated Traffic Self indicates the total allocated QoS traffic, and is expressed as a Mean and Standard Deviation in units of 32µs, plus the number of AC2 and AC3 streams. As the AP adds new streams, this field changes • Allocated Traffic Shared • The Allocated Traffic Shared is the sum of Allocated Traffic Self values for all overlapping APs including self As per 09/yyyyr0, the problem of an AP in the middle of two APs that are hidden from each other, requires that the AP in the middle needs to advertise the “shared” traffic value so as to avoid being shut out. The two fields are used to enable the On-Demand Sharing scheme. Graham Smith, DSP Group

  12. Access Factor • Access Factor • Total Traffic Requirement in 32us/sec. Expressed as a fraction that may be greater than 1. • Calculated as follows: • Sum, as a composite stream, the Self QLoads of itself and all QAPs that are directly visible • Calculate the EDCA Bandwidth Factor from the total number of Priority Streams in the QLoad of self and all the visible QAPs • Multiply the two to obtain the “Access Factor” This field is used to indicate the potential load, or overload of the OBSS, and is used in the Proportional Sharing scheme. Graham Smith, DSP Group

  13. HCCA Peak and Access Factor • “HCCA Peak” • The total HCCA TXOP requirement for the QAP, expressed in 32us/sec. • “HCCA Access Factor” • The sum of all the “HCCA Peak” values in the QLoad Elements of self and directly visible QAPs is the “HCCA Access Factor” • If HCCA Access Factor > 1sec then potential for TXOP over-allocation • HCCA TXOPs can sum to “1” independent of EDCA Medium Time allocations, (as TXOPs terminate immediately when no more data) Graham Smith, DSP Group

  14. HCCAOP Advertisement Scheme • HCCA QAPs need to schedule TXOPs that do not interfere with the other HCCA QAPs that are directly visible. • The HCCAOP Advertisement Element lists all the HCCA TXOPs that have been already scheduled by that QAP in the “Self Times Report” • An HCCA QAP looks at the TXOP Advertisement of direct neighbor QAPs in order to select a TXOP time that does not interfere with any TXOP being advertised in the “Self Times Report” • QAP must check that allocating a new TXOP will not cause the HCCA Access Factor (sum of HCCA Peak in the QLoad Report) to exceed 1 sec/sec. • All times in the HCCAOP Advertisement Element are expressed with respect to the TSF of the QAP that is transmitting the element • QAPs need to monitor the TSF of their neighbors so as to keep an up to date TSF Offset value. Graham Smith, DSP Group

  15. Annex aa - Informative Recommendations on: • How to calculate values in QLoad fields • Channel Selection • Sharing • Proportional • On-Demand Graham Smith, DSP Group

  16. MEAN and STDEV calculations As per 09/496r2 and 09/497r2, it is recommended that the mean (MEAN), maximum (MAX) and minimum (MIN) values of the Medium or HCCA Medium Times, are calculated using the values provided in the individual TSPECs, as follows: For a TSPEC for stream, i, the mean value, µ, is: µi = MEANi and the standard deviation, σ, is: σi = 0.25 sqrt{(MAXi – MINi)2} or, if the MIN value is not provided σi = (MAXi – MEANi)/2 Note that if neither the MAXi nor the MINi values are provided, then σi = 0 The values reported in the QLoad and Allocated Traffic fields represent the composite stream of all the individual streams and it is recommended that they are calculated as follows: MEAN µtot = ΣMEANi STDEV σtot = sqrt(Σσi2) The Peak value is calculated as: PEAK = Mean + 2 x STDEV Graham Smith, DSP Group

  17. EDCA BW Factor The Medium Time does not include the access time (SIFS, AIFSN, Contention Window)and for two or more streams, there is also the time when each packet is delayed while another stream is being transmitted. • The recommended EDCA Bandwidth overhead factor is subject of 09/xxxxr0 and is provided in Table aa1: • NOTE: As the factor does not increase for streams over four, 4 bits for each AC field is adequate in the QLoad and Allocated Traffic fields Graham Smith, DSP Group

  18. Allocated Traffic Self Allocated Traffic Self represents the total composite stream that the AP has allocated at any one time. It is recommended that as each stream is added or deleted, the AP should calculate the mean and standard deviation of the resulting composite stream. The field also includes the total number of EDCA streams that are now admitted for this AP. • It is recommended that the values of the mean and standard deviation placed in the Allocated Traffic Self field, for i allocated streams is calculated using: • MEAN = ΣMEANi • STDEV = sqrt(Σσi2) Graham Smith, DSP Group

  19. Allocated Traffic Shared • Allocated Traffic Shared is the sum of the values expressed in the Allocated Traffic Self field of all overlapping APs, including its own Allocated Traffic Self. It is recommended that the values of the mean and standard deviation, placed in the Allocated Traffic Shared field, for n overlapping APs is calculated using: • MEAN = ΣMEANn • STDEV = sqrt(Σσn2) • In addition, the sums of the AC2 and AC3 streams provided in the Allocated Traffic Self field of all overlapping APs, including its own Allocated Traffic Self, are included in this field. • Note: This field is required in order to overcome the “AP in the middle” problem as per 09/xxxxr Graham Smith, DSP Group

  20. Access Factor The Access Factor is the total traffic requirement for all the overlapping APs expressed as a fraction that may be greater than 1. It is recommended that the Access Factor be calculated from the addition of all the QLoads of the APs that are overlapping as follows: • First calculate the Overlap Traffic for all the overlapping APs. Each AP should note the reported QLoads for every overlapping AP, including the AP’s own QLoad, and calculate the maximum traffic of the composite stream, using the formula: • Overlap Traffic = µtot + 2 σtot • Where, for i QLoads, µtot = ΣMEANi and σtot = sqrt(Σσi2) • Add the number of AC_VO and AC-VI streams advertised in the EDCA Priority Fields and calculate the EDCA BW Factor • Multiply the Overlap Traffic by the EDCA BW Factor Note: This field also overcomes the “AP in the middle” problem as per 09/xxxxr0 and is used in the Proportional Sharing scheme Graham Smith, DSP Group

  21. Access Factor and HCCA Access Factor • QLoads, Medium Time and TXOPs are all measured in 32us/sec • Access Factor and HCCA Access Factor can be > 1 • To express in 1 octet (example provided in Annex aa) • 2 bits for Integral (whole number) • 6 bits for the decimal fraction, expressed as a fraction rounded down to 1/64 • Example: Sum = 74268 in 32us/sec = 2.376576 seconds • Hence, octet would be 10 01100 [2 and 24/64 = 2.375] • Maximum value would be 3.98 Graham Smith, DSP Group

  22. Channel Selection Channel Selection recommended in the following procedure: • Check if the APs that are advertising Admission Control and/or HCCA support, i.e. QAPs • Select the channel(s) with the least number of QAPs • If more than one channel, send out QLoad Requests • Select channel with least Overlaps • If more than one channel, select channel with lowest QLoads Graham Smith, DSP Group

  23. Sharing Basis • If the Access Factor is >1, then there is a potential over-allocation • Hopefully QAPs should avoid this in the Channel selection process • Two Recommended Sharing Schemes • Proportional Sharing • Uses Access Factor • On Demand Sharing • Uses Allocated Traffic Self and Shared fields Graham Smith, DSP Group

  24. Proportional Sharing • The AP examines the Access Factor in the QLoad Reports from each overlapping BSS, including its own QLoad, and determines the maximum Access Factor • Multiply this maximum value by the EDCA BW Factor determined from the sum of the AC2 and AC3 values in QLoad • If the maximum Access Factor is less than or equal to 1, an AP may allocate up to its advertised QLoad traffic. • If the maximum Access Factor is greater than unity, then the AP may only allocate up to a value of its QLoad divided by the maximum Access Factor. Steps if Access Factor >1: • Calculate the peak traffic value of the Qload, using: • Peak = MEAN + 2 STDEV • Divide this value by the maximum Access Factor. This is termed the maximum allowable Qload traffic • Calculate the resulting value of the Allocated Traffic Self if the new TSPEC is accepted, and then calculate the resulting peak value using • Peak = MEAN + 2 STDEV • If the resulting peak value, calculated in step 3 is less than the maximum allowable QLoad traffic, OK • If new stream is HCCA TSPEC then AP needs to check HCCA Access Factor and schedule using the HCCA TXOP Advertisement Note: The advertised Allocated Traffic Self could indicate if the AP is cheating Graham Smith, DSP Group

  25. On-Demand Sharing • Before allocating a new stream, the AP examines the Allocated Traffic Shared values in the QLoad Reports from each overlapping BSS, including its own QLoad, and selects the maximum Allocated Traffic Shared value which has the highest peak value, using: • Peak = MEAN + 2 STDEV. • The AP also notes the number of AC2 and AC3 streams in this maximum Allocated Traffic Shared Field. • The AP adds the requested new stream (new) to the selected maximum Allocated Traffic Shared value (max) determined in step 1, using: • MEAN = MEANnew + MEANmax • STDEV = sqrt(STDEV2new + STDEV2max) • The AP then calculates the peak value for the new composite stream calculated in step 3 , using: • Peak = MEAN + 2 STDEV • Using the values of the AC2 and AC3 streams noted in step 2, plus the new stream, the AP determines the new EDCA BW Factor • Multiply the peak value calculated in step 4 by the EDCA BW Factor, determined in step 5. This is the new Peak Traffic requirement • If new ‘peak value” <=1 then OK • If new stream is HCCA TSPEC then AP needs to check HCCA Access Factor and schedule using the HCCA TXOP Advertisement Graham Smith, DSP Group

  26. Responses to Comments Major outstanding Comments included here. Other Comments resulted in changes to the original text and also in the decision to add Annex aa Graham Smith, DSP Group

  27. HCCA TXOP Advertisement should not be limited to HCCA. MCCA was applied to EDCA. Response: • To mirror what MCCA does we would have to switch off networks in turn. To do this we need to keep all STAs in a network quiet to allow overlapping network to transmit. We could not see a way of doing this with legacy EDCA STAs, e.g. Quiet Periods, PCF, QoS CF Polls. Hence the Access Factor and EDCA Bandwidth factor are used to allow the EDCA to overlap. Graham Smith, DSP Group

  28. Building QLoad with TSPEC inactivity interval set to 1 Comment: This is a very poor idea. The non-AP STA can never undo/change such a TSPEC. Inactivity Interval needs to be set properly (e.g. to 24 hours), if after nearly 24 hours it is still applicable, the client should send it again with a new update. If it is no longer applicable, the client should send a DELTS. Otherwise the only way for an AP to maintain current information is to send a TSPEC Requirements Request to every client every few seconds (or faster?) Response: The basic idea is for STAs to have an opportunity to inform the AP as to what they are, and for the AP to advertise its peak or potential loading. This is a major part of this proposal and addresses an aspect of QoS not considered before. Previous QoS Elements only advertise their current condition, and this does not reflect the true loading. The AP can send the TSPEC Requirements Request whenever it wants, clearing the load. It can also interpret the Inactivity Period in any way it wants as it is an indication from the STA as to what it is. A DELTS from the STA could be used, but the AP would need to identify it as a TSPEC that is not actually active, though this should be OK. Also, it should be noted that for Admission Control the Inactivity Interval is not (normally) used, so this is not an entirely new concept. Graham Smith, DSP Group

  29. In TXOP Reservation , for video, given the 24 Hz and 60Hz sources, 1ms is actually a poor choice • Why not have 1ms if MSB is 0, but if MSB is 1, then 1/960 seconds. Or because I’ve just taken a bit, 2ms and 1/480 seconds? Responses: • In the TSPEC the SI fields are 4 octets long, specifying in units of 1us. In all the TSPECs that have/had been proposed in the WFA work for WMM Admission Control and WMM-SA, the SI fields were always a multiple of 1ms, actually units of 10ms would have worked – hence we chose 1ms to be frugal • The standards offer both 60 frames/sec plus 60 * 1000/1001 (about 59.94) frames/sec and 24 frames/sec plus 24 * 1000/1001 frames/sec (about  23.98) frames/sec. There is no common denominator that can cover all of these, except for the prime ratio of 1000/1001. Therefore, the choice of 1 ms is no worse than any other value. • Happy to discuss and be persuaded, but consider 1ms is adequate Graham Smith, DSP Group

  30. QLoad Report Request and QLoad Report are terrible names • Maybe QLoad Parameter Set or QLoad Information, or something similar is better. Response: • We thought we were following convention with similarly named exchanges from 11k and 11v. Did want to make clear that the QLoad Report used the QLoad element • Happy to discuss and be persuaded Graham Smith, DSP Group

  31. Access Fraction: Integer and fractional descriptions are always needlessly complicated. • Make it in units of 32us per second, and note that it may exceed 100%, up to ~390%. Then define the max number as indicating the max or higher. Response: • The idea proposed enables a fraction of 3.98 in one octet. Expressing same in multiples of 32us would require 3 octets. 2 octets provides maximum fraction of 2.10. Again just trying to be frugal and do it in 1 octet. • Happy to discuss and be persuaded Graham Smith, DSP Group

  32. EDCA Bandwidth Factor Comment: • MAC experts I’ve spoken to do not believe that a simple formula exists to characterise EDCA overheads. This is most likely a dead-end. Response: • This has been investigated in 09/1137r0, it is not that complicated, just that there are many cases and maybe the proposed formula is not 100% correct, but the need for it does exist and should be catered for. If it is omitted then there is a real danger that over allocation will occur as Medium Time does not include medium access overhead. We consider this is better than not having it. We moved the recommended values for EDCA BW Factor to the Annex so that an AP can use its own formulas, but it does highlight the need for an AP to take this into account. We also believe that the Table provided is pretty accurate and could be used with confidence. If necessary we could spend more time and produce a set of comprehensive tables covering all combinations, but doubt if any useful addition would result. The question arises as to whether APs performing Admission Control have considered this as they should be applying a correction now? Graham Smith, DSP Group

  33. Why Have Two Sharing Schemes? Comment • Do we need to support two sharing schemes? If so do we need a mechanism for APs to agree on the sharing? Response • So far we have included the hooks for two schemes. Both will protect the AP in the middle scenario and also prevent over allocation. If we had just On-Demand we could omit the Access Factor but would want to retain the QLoad field indicating potential loads to assist in channel selection. Each scheme has merits for ‘guaranteed’ QoS; proportional provides long term repeatability, while on-demand provides short term efficiency. Consideration could be given for an exchange to agree a sharing scheme – could introduce Action Frames for this, but need some ‘agreement’ procedure. There are also spare bits in the QLoad Element that could be used. • Happy to hear suggestions Graham Smith, DSP Group

More Related