Novembe r 2009 Graha m Smi th, D Slide 1 doc.: IEEE 802.11-09/1138-01aa Submission Outline of Proposed Overlapping BSS Solution Date: 2009, November 9 N am e A ffiliations A ddress Phone em ail G raham Smith D SP G roup 2491 Sunrise Blvd, #100, Rancho Cordova, C A 95742 916 851 9191 X209 Graham.sm ith@ dspg.com Alex A shley ND S Ltd O ne London Road, Staines,M iddlesex, TW 18 4EX,U K +44 1784 848770 aashley@ nds.com Ed R euss Plantronics [email protected]m G anesh V enkatesan Intel Corporation 2111N E 25 th Ave, Hillsboro,O R 97124 503 334 6720 Ganesh.venlatesan@intel. com JoeEpstein Meru N etw orks jepstein@ merunetworks.c om D avid H unter Panasonic [email protected]nic.com Authors:
Transcript
November 2009
Graham Smith, DSP Group
Slide 1
doc.: IEEE 802.11-09/1138-01aa
Submission
Outline of Proposed Overlapping BSS Solution
Date: 2009, November 9
Name Affiliations Address Phone email Graham Smith DSP Group 2491 Sunrise Blvd,
AbstractThis presentation presents the proposed solution for OBSS, with options08/0457r4 and 08/1260r1 examined the OBSS problem and outlined possible
solutions – “QLoad” introduced08/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 fields09/0660r3 examined using 11s MCCA for HCCA OBSS09/0662r2 introduced OBSS Sharing with Access Fraction09/0666r2 considered HCCAOP Advertisement Element for sharing and
TXOP avoidance09/0931r0 looked at Stray and Overlapping STAs09/1136r0 Examined the Hidden AP situation and AP Shut Out problem09/1137r0 Examined EDCA Bandwidth Factor
November 2009
Graham Smith, DSP Group
Slide 3
doc.: IEEE 802.11-09/1138-01aa
Submission
Objectives of OBSS Proposal
Provide the means for:1. Meaningful Channel Selection2. 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.
November 2009
Graham Smith, DSP Group
Slide 4
doc.: IEEE 802.11-09/1138-01aa
Submission
Outline of Proposal1. Qload Report Element
– QLoad Report Request Action Frame– QLoad Report Public Action Frame– Optionally in Beacon
2. New entries in Extended Capabilities – QLoad Report (AP)– TSPEC Requirement Request (non-AP STA)
3. New Action Frame “TSPEC Requirement Request” • Sent by QAP to STA to indicate or confirm their TSPECs
4. New IE “HCCA TXOP Advertisement Element”• Used by HCCA QAPs to avoid the TXOPs of overlapping QAPs
5. 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
QLoad, Allocated Traffic Self, and Allocated Traffic Shared Fields
Integral Fraction
Bits 2 6
Access Factor Field and HCCA Access Factor field
Element ID
Length QLoadAllocatedTraffic
Self
Allocated Traffic Shared
Access Factor
HCCA Peak
HCCA Access Factor
Overlap
octets 1 1 5 5 5 1 2 1 1
Octet 2 2 1
Mean Stdev ReservedAC3
StreamsAC2
Streams
Bits 16 14 2 4 4
November 2009
Graham Smith, DSP Group
Slide 6
doc.: IEEE 802.11-09/1138-01aa
Submission
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
November 2009
Graham Smith, DSP Group
Slide 7
doc.: IEEE 802.11-09/1138-01aa
Submission
HCCA Advertisement Element
Element ID Length Number of Reported
TXOP Reservations
TXOPReservation
1
TXOP Reservation
n
octets 1 1 1 4 4
The HCCA TXOP Advertisement element is used by an AP to advertise its TXOP state to its overlapping APs
Duration Service Interval Start time
Octets
1 1 2
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
November 2009
Graham Smith, DSP Group
Slide 8
doc.: IEEE 802.11-09/1138-01aa
Submission
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
November 2009
Graham Smith, DSP Group
Slide 9
doc.: IEEE 802.11-09/1138-01aa
Submission
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.
November 2009
Graham Smith, DSP Group
Slide 10
doc.: IEEE 802.11-09/1138-01aa
Submission
Values in QLoad Element
The values in the QLoad Field shall be derived by one or more of three methods:1. Send TSPEC Requirements Request (if STA supports)2. STA sends TSPEC with Inactivity Period set to 1 3. 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 trafficare 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)
November 2009
Graham Smith, DSP Group
Slide 11
doc.: IEEE 802.11-09/1138-01aa
Submission
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/1136r0, 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.
November 2009
Graham Smith, DSP Group
Slide 12
doc.: IEEE 802.11-09/1138-01aa
Submission
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.
November 2009
Graham Smith, DSP Group
Slide 13
doc.: IEEE 802.11-09/1138-01aa
Submission
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)
November 2009
Graham Smith, DSP Group
Slide 14
doc.: IEEE 802.11-09/1138-01aa
Submission
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.
November 2009
Graham Smith, DSP Group
Slide 15
doc.: IEEE 802.11-09/1138-01aa
Submission
Annex aa - Informative
Recommendations on:
• How to calculate values in QLoad fields
• Channel Selection
• Sharing– Proportional
– On-Demand
November 2009
Graham Smith, DSP Group
Slide 16
doc.: IEEE 802.11-09/1138-01aa
Submission
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 = MEANiand the standard deviation, σ, is:
σi = 0.25 sqrt{(MAXi – MINi)2} or, if the MIN value is not provided
σi = (MAXi – MEANi)/2Note that if neither the MAXi nor the MINi values are provided, then σi = 0The 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
November 2009
Graham Smith, DSP Group
Slide 17
doc.: IEEE 802.11-09/1138-01aa
Submission
EDCA BW FactorThe 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
Number of Streams
EDCA BW Factor
VI or VOonly,
one VO plusVI
2 or moreVO plus
VI
1 - -
2 1.40 -
3 1.50 1.55
4+ 1.55 1.60
November 2009
Graham Smith, DSP Group
Slide 18
doc.: IEEE 802.11-09/1138-01aa
Submission
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)
November 2009
Graham Smith, DSP Group
Slide 19
doc.: IEEE 802.11-09/1138-01aa
Submission
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/1136r0
November 2009
Graham Smith, DSP Group
Slide 20
doc.: IEEE 802.11-09/1138-01aa
Submission
Access FactorThe 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/1136r0 and is used in the Proportional Sharing scheme
November 2009
Graham Smith, DSP Group
Slide 21
doc.: IEEE 802.11-09/1138-01aa
Submission
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
November 2009
Graham Smith, DSP Group
Slide 22
doc.: IEEE 802.11-09/1138-01aa
Submission
Channel Selection
Channel Selection recommended in the following procedure:
1. Check if the APs that are advertising Admission Control and/or HCCA support, i.e. QAPs
2. Select the channel(s) with the least number of QAPs
3. If more than one channel, send out QLoad Requests
4. Select channel with least Overlaps
5. If more than one channel, select channel with lowest QLoads
November 2009
Graham Smith, DSP Group
Slide 23
doc.: IEEE 802.11-09/1138-01aa
Submission
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
November 2009
Graham Smith, DSP Group
Slide 24
doc.: IEEE 802.11-09/1138-01aa
Submission
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:1. Calculate the peak traffic value of the Qload, using:
– Peak = MEAN + 2 STDEV2. Divide this value by the maximum Access Factor. This is termed the maximum allowable Qload
traffic3. 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
4. If the resulting peak value, calculated in step 3 is less than the maximum allowable QLoad traffic, OK
5. 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
November 2009
Graham Smith, DSP Group
Slide 25
doc.: IEEE 802.11-09/1138-01aa
Submission
On-Demand Sharing
1. 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.
2. The AP also notes the number of AC2 and AC3 streams in this maximum Allocated Traffic Shared Field.
3. The AP adds the requested new stream (new) to the selected maximum Allocated Traffic Shared value (max) determined in step 1, using:
4. The AP then calculates the peak value for the new composite stream calculated in step 3 , using:
• Peak = MEAN + 2 STDEV
5. 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
6. Multiply the peak value calculated in step 4 by the EDCA BW Factor, determined in step 5. This is the new Peak Traffic requirement
7. If new ‘peak value” <=1 then OK8. If new stream is HCCA TSPEC then AP needs to check HCCA Access Factor and
schedule using the HCCA TXOP Advertisement
November 2009
Graham Smith, DSP Group
Slide 26
doc.: IEEE 802.11-09/1138-01aa
Submission
Major outstanding Comments included here.Other Comments resulted in changes to the original text and also in the decision to add Annex aa
November 2009
Graham Smith, DSP Group
Slide 27
doc.: IEEE 802.11-09/1138-01aa
Submission
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.
November 2009
Graham Smith, DSP Group
Slide 28
doc.: IEEE 802.11-09/1138-01aa
Submission
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.
November 2009
Graham Smith, DSP Group
Slide 29
doc.: IEEE 802.11-09/1138-01aa
Submission
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
November 2009
Graham Smith, DSP Group
Slide 30
doc.: IEEE 802.11-09/1138-01aa
Submission
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
November 2009
Graham Smith, DSP Group
Slide 31
doc.: IEEE 802.11-09/1138-01aa
Submission
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
November 2009
Graham Smith, DSP Group
Slide 32
doc.: IEEE 802.11-09/1138-01aa
Submission
EDCA Bandwidth FactorComment:• 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?
November 2009
Graham Smith, DSP Group
Slide 33
doc.: IEEE 802.11-09/1138-01aa
Submission
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 two spare bits in the QLoad Element that could be used.– E.g. “Proportional”, “On-Demand”, “Don’t Care”?
