Considerations for OBSS Sharing using QLoad Element

Slides:



Advertisements
Similar presentations
Doc.: IEEE /936r0 Submission July 2012 Xavier Perez Costa, NECSlide 1 Review of Overlapping Networks (OBSS) Status and IEEE Solutions.
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 /0717r1 Submission July 2008 Graham Smith, DSP GroupSlide Packets and MPEG Frames Background to Graceful degradation of audio.
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 /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 /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 /0415r0 Submission April mc CIDs 1136,1118,1458 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”
July 2008 doc.: IEEE yy/xxxxr0 July 2008
Performance Evaluation for 11ac
TG ax DSC Summary Date: Authors: July 2015 April 2013
Implementation for Intra-AC Differentiated Services
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
Consideration on Interference Management in OBSS
Overlapping BSS Proposed Solution
Outline of Proposed Overlapping BSS Solution
Consideration on Interference Management in OBSS
EDCF Issues and Suggestions
MAPID for User Plane Support
Considerations for OBSS Sharing using QLoad Element
HCCAOP Scheme, Efficiency and Sharing
Synchronization of HCCA APs in OBSS
Consideration on Interference Management in OBSS
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
Increased Network Throughput with Channel Width Related CCA and Rules
Interworking with 802.1Qat Stream Reservation Protocol
Proposed Overlapping BSS Solution
Proposed Overlapping BSS Solution
Applicability of 11s MCCA to HCCA OBSS
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Recommendation for EDCA Bandwidth Factor
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
QoS Metrics Date: Authors: January 2005 Month Year
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
AP Shut Out Neighborhood Effect
OBSS Requirements Date: Authors: July 2008 July 2008
Admissions Control and Scheduling Behaviours for Scheduled EDCA
Presentation transcript:

Considerations for OBSS Sharing using QLoad Element Apr 2009 doc.: IEEE 802.11-08/0xxx Apr 2009 Considerations for OBSS Sharing using QLoad Element Date: 2009, April 30 Authors: Graham Smith, DSP Group Graham Smith, DSP Group

Apr 2009 doc.: IEEE 802.11-08/0xxx Apr 2009 Abstract The proposed QLoad Element (as per 09/0496r0) contains information on the traffic of each QAP in the OBSS graph. This presentation discusses the basics of how the data could be used in a sharing scheme. Graham Smith, DSP Group Graham Smith, DSP Group

Proposed Extended QLoad Element Apr 2009 Proposed Extended QLoad Element Graham Smith, DSP Group

QLoad Element Fields Apr 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 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 Visible Bit If the QAP that corresponds to ID, MEAN and STDEV values is directly visible to the QAP Self, then this is set to 1 Visibility bit set to 1 for Self Channel Priority Used only if QAP is operating with HCCA, indicates HCCA Supervisor QAP Priority Streams Number of streams on ACs 2 and 3 per QAP. Used so that the contention overhead can be estimated. Graham Smith, DSP Group

Traffic Information Apr 2009 Every QAP knows the traffic requirements of every other QAP in the OBSS Graph, even those that are not directly visible Total Traffic can be calculated: MEAN µtot = ΣMEANi STDEV σtot = sqrt(Σσi2) Total Traffic Requirement can be estimated: MAX traffic = µtot + 2 σtot 90% Traffic = µtot + 1.3 σtot 80% Traffic = µtot + 0.83σtot Other? Total Traffic Requirement limit is also affected by EDCA Overhead Contention overhead reduces the total traffic bandwidth. Important as number of streams increases HCCA Allocation Limit Need to allow bandwidth for non-QoS traffic, say only 90% of total bandwidth should be reserved Graham Smith, DSP Group

EDCA Overhead – Capacity drops with # streams Apr 2009 EDCA Overhead – Capacity drops with # streams As number of video streams increases, the contention also increases. In order to keep latency low the capacity of the Channel is decreased. Maximum throughput on (shared) channel decreases as number of video streams increases Limits to ensure low loss: 1 stream @ 33Mbps 4 Streams, 27.5Mbps total 8 Streams 23.3Mbps total HENCE: Total Allocation MUST take account of the number of streams Note: This is also for Admission Control on each QAP NOTE: Above graph is for independent streams. Downlink streams from QAP may be better due to queuing at the AP Graham Smith, DSP Group

EDCA Bandwidth Overhead Apr 2009 EDCA Bandwidth Overhead Due to contention, the required bandwidth for EDCA is larger than the sum of the streams Approximation based upon example on previous slide: EDCA Bandwidth Factor = 1 + 0.05 N (approx; keep it simple) Where N = Number of streams 4 streams Effective Bandwidth Factor = 1.2 Therefore four 5.5Mbps streams will require 1.2 x 4 x 5.5 = 26.5Mbps NOTES: This is only true if traffic is near saturation point; but with overlaps it may be always safe to assume it is If all traffic is downlink contention may be less as AP controls the queue; but as traffic is coming from the overlapping networks, again it may be safer to assume this formula. (The formula for EDCA Overhead may need to be looked at further) Graham Smith, DSP Group

EDCA and HCCA Sharing Considerations Apr 2009 EDCA and HCCA Sharing Considerations When considering defined methods or recommendations for Sharing to ensure quality of service, the following points apply: EDCA Contention based scheme, requires certain overhead to ensure throughput and latency requirement EDCA Admission Control does attempt to provide a “guarantee” of QoS Used bandwidth is always related to the required bandwidth HCCA Scheduled scheme, sharing requires knowledge of required durations of TXOPs for each QAP for partitioning of time slots HCCA attempts to “guarantee” QoS. TXOPs are terminated as soon as traffic sent for that slot, i.e. unused bandwidth is returned Graham Smith, DSP Group

Basic General Sharing Considerations Apr 2009 Basic General Sharing Considerations Total Traffic Requirement of all the sharing QAPs can be determined Calculate Total Traffic 100%, 90%, 80%, Other? EDCA contention should be estimated Based upon QLoads of QAPs that are “Visible”, i.e. directly competing for the air time Allocation limit Definitely required for HCCA. E.g. Do not allocation over, say, 90% to allow for other traffic For EDCA, lower priority traffic should still get bandwidth but could increase the EDCA Bandwidth Factor Graham Smith, DSP Group

Apr 2009 Number of Sharing QAPs How many sharing QAPs need to be assumed in order to evaluate a proposed Sharing Scheme? (see 08/1470r4) Detached, Terraced and Town House scenarios (12, 16, 24 APs in range respectively) Limited to just 1 overlap, or 2 sharing QAPs for 9 Channels Single Apartment Blocks (28 APs in range) 98.3% Prob of OBSS length <= 2 for 9 Channels 98.8% Prob of OBSS length <= 2 for 11 Channels OBSS length <= 2 for 17 Channels Double Apartment Blocks (53 APs in range) If 20/40MHz selection scheme adopted, then OBSSlength<=2 Graham Smith, DSP Group

Sharing Scenario Apr 2009 The typical case is no or just 1 overlaps The typical “Worse case” scenario for an Overlap = 2 is shown below QAP A (If HCCA CHP = 1) Overlap = 2, QAPs B and C are “Visible” QAP B Overlap = 1, QAPs A is “Visible” QAP C Overlap = 1, QAP A is “Visible” Graham Smith, DSP Group

EXAMPLE - 11n Apr 2009 Basic Video Data Rates Codec SDTV DVD HDTV MPEG2 1-5Mbps 8Mbps 15-23Mbps MPEG4 1-2Mbps 2-3Mbps 8-12Mbps Basic Video Data Rates, in Mbps, for MPEG2 MEAN MAX STDEV DVD 5 8 1.5 SDTV 3 1 HDTV 15 20 2.5 Basic Video Data Rates, fraction of bandwidth for 80Mbps Bandwidth (11n) MPEG 2 MEAN MAX STDEV DVD 0.0625 0.1 0.01875 SDTV 0.0375 0.0125 HDTV 0.1875 0.25 0.03125 Graham Smith, DSP Group

Example - EDCA Apr 2009 Example QLoads for each QAP QAP # Streams Mean STDEV Visibility COMMENTS A B C 3 0.31 0.04 1 2 DVD, 1 HDTVstreams 0.11 0.02 3 SDTV Streams 0.29 1 HDTV 1 DVD 1SDTV TOTAL 0.71 0.06 EDCA Total Traffic Requirements QAP Streams EDCA O/H 100% 90% 80% A 9 1.45 1.21 1.15 1.11 B 6 1.3 1.08 1.03 0.99 C Now what? OK if 80% Traffic is <1? Graham Smith, DSP Group

(Peak) Allocation per QAP Apr 2009 Example - HCCA HCCA Total Traffic Requirements QAP HCCA O/H 100% 90% 80% A 1.1 0.92 0.87 0.84 B C All are OK, But should still have a “Rule” If Total Traffic less than 1 Then OK for QAP A to allocate TXOPs based on 100%, 90% 80% for each QAP? Traffic Requirement per QAP QAP Mean STDEV (Peak) Allocation per QAP 100% 90% 80% A 0.31 0.04 0.39 0.37 0.35 B 0.11 0.02 0.16 0.14 0.13 C 0.29 0.36 0.34 0.32 Totals 91% 84% Needs further explanation Graham Smith, DSP Group

Apr 2009 HCCA Time Allocation Note that in example the sum of the allocated time (TXOPs) is 91%. This contradicts the requirement that at least 10% of the bandwidth is not scheduled. The 1.1 factor was applied in order to check if the sharing was OK but this is based upon the total traffic whereas the sum of the individual QAP traffic is not the statistical sum, but a linear sum. Hence, in practice, each QAP needs to adjust its TXOP allocation to keep the sum not more than 90%. They can do this because they know all the details. In this particular case they can calculate the individual and total time allocations, and then reduce their TXOP allocation to comply. This procedure needs to be included in the specification. Graham Smith, DSP Group

Apr 2009 Results In example shown, if either the 90% or 80% service is considered acceptable then traffic can be allocated without any “Sharing Rule” except for QAP A If 90% or 80% is acceptable, then simple Sharing rule could be Example “Rule”: “If QAP calculates that the calculated 80% Total Bandwidth Requirement is >1 then each QAP must reduce its bandwidth allocation so that the Total 80% Bandwidth Requirement is <=1” In our example, only QAP A is more affected Problem is that this actually means dropping a video, not good. If QAP A goes ahead as is, will it adversely affect the others? Why should QAP A be punished? Is the idea of EDCA Overhead correct? Real Answer is that QAPs will select partners based upon QLoads in addition to value of Overlap Need a set of rules, however, just to play safe Graham Smith, DSP Group

Apr 2009 Conclusions QLoad element provides information to allow each QAP to calculate EDCA Overhead Need to establish acceptable formula to estimate this Total Traffic Requirement Any point on the CDF curve, e.g. 100%, 90% and 80% Need to Choose “Acceptable” Service, e.g. 90% or 80%? Need to establish Recommended Sharing Rules HCCA QAPs can determine their total TXOP time to ensure less than 90% of time is allocated Need to include text to explain how this can be done Graham Smith, DSP Group