Presentation on theme: "Doc.: IEEE 802.11-08/0818r2 Submission July 2008 Jing Zhu, Intel CorporationSlide 1 Managed Contention Access – A technique to improve Video Streaming."— Presentation transcript:
doc.: IEEE 802.11-08/0818r2 Submission July 2008 Jing Zhu, Intel CorporationSlide 1 Managed Contention Access – A technique to improve Video Streaming Performance Date: 2008-07-16 Authors:
doc.: IEEE 802.11-08/0818r2 Submission July 2008 Jing Zhu, Intel CorporationSlide 2 Abstract This submission describes Managed Contention Access (MCA), a technique that enables semi-deterministic access to 802.11 wireless medium.
doc.: IEEE 802.11-08/0818r2 Submission What is the problem? Intermittent Channel Access caused by unsaturated / real-time traffic (video, voice, multimedia, etc.) power saving & multi-radio Contending STAs with saturate traffic increased channel access time / jitter reduced sensitivity and increased collisions EDCA/HCCA does not work well in OBSS
doc.: IEEE 802.11-08/0818r2 Submission Problem Statement: Increased Delay and Jitter Maximum MSDU size: 2304 bytes (at 1Mbps) 18ms 1500 bytes (at 1Mbps) 12ms DataACK STA1 (FTP) STA2 (Video) DataACK Arrival Delay (up to ~18ms) General Mouse Hi precision Mouse KeyboardVoice Quality Headset CD Quality headphones Aggregate Throughput < 8kbps 256 kbps384kbps Latency< 10ms< 3ms< 50ms< 30ms< 100ms Delay SensitiveThroughput Sensitive
doc.: IEEE 802.11-08/0818r2 Submission Problem Statement (contd): Reduced Sensitivity in Post-Absence Channel Access Absence (power save, etc.) Transmission STA DataACK DataACK PLCP #2: CCA without preamble detection may not be sensitive enough to detect Neighboring STA DataACK #1 and #2 will cause the performance degradation of the whole BSS –Energy Detection Threshold = -62dBm –Preamble Detection = -82dBm 20dB loss of CCA sensitivity 90% CCA sensing rage reduction with path loss exponent = 2 #1: ACK may be out of range of preamble detection (hidden) DIFS + BO
doc.: IEEE 802.11-08/0818r2 Submission How to manage contention access ?
doc.: IEEE 802.11-08/0818r2 Submission State of the Art: EDCA Admission Control Admissible ParametersDescriptionG.711 (UDP)Data (TCP) Nominal MSDU Sizeoctets200 (inter-arrival time:20ms)1500 Minimum Service Intervalus (minimum interval between two sucessive SPs)20ms Maximum Service Intervalus (maximum interval between two successive SPs) Inactivity Intervalus (minimum inactive time between successive Tx or Rx activities before the TS being deleted from HC) Suspension Interval (< Inactivity Interval) us (minimum inactive time between successive Tx or Rx activities before the polling for this TS being stopped Minimum Data Ratebps (lowest data rate for transport of MSDU) Mean Data Ratebps (average data rate for transport of MSDU)64Kbps (<10% duty cycle) 100Kbps (10% duty cycle) Burst SizeOctets (maximum bytes of the MSDUs arriving at the peak data rate) Minimum PHY Ratedesired minimum PHY rate11Mbps1 Mbps Peak Data RateMaximum allowable data rate Delay Boundus (maximum time for a MSDU spent at the MAC layer) 50ms Surplus Bandwidth Allowance1.X (how much more bandwidth is allowed to be used for the TS) 1.3 (30% retransmissions)1.3 (30% retransmission) Medium Time32us/s (the amount of time admitted to access the medium) HC output
doc.: IEEE 802.11-08/0818r2 Submission How Medium Time is used in EDCA admission control ? Two state variables: admitted_time and used_time Two parameters: medium_time and dot11EDCAAveragePeriod Algorithm: a) At dot11EDCAAveragingPeriod (default = 5) second intervals –used_time = max((used_time – admitted_time), 0) b) After each successful or unsuccessful MPDU (re)transmission attempt, –used_time = used_time + MPDUExchangeTime c) On receipt of a TSPEC element contained in a ADDTS Response frame indicating that the request has been accepted –admitted_time = admitted_time + dot11EDCAAveragingPeriod * (medium time of TSPEC).
doc.: IEEE 802.11-08/0818r2 Submission Limitations of EDCA-AC It is recommended that admission control not be required for the access categories AC_BE and AC_BK. (IEEE 802.11-2007) Medium Time (32us/s) usually too long to limit per-packet transmission time TCP duty cycle =10% and dot11EDCAAveragingPeriod = 5 seconds, retransmission = 30% (Surplus Bandwidth Allowance = 1.3) medium time / sec = ceiling(10% x 10 6 / 32) = 4000 adimitted_time / period = 4000 x 5 x 32 (us) = 640 ms Difficult to choose TXOP limit to trade between MAC efficiency and latency: 10ms? or 1ms? No restriction on OBSS traffic No restriction on actual timing need something that can be controlled by AP but with minimal restrictions on AC_BE and AC_BK
doc.: IEEE 802.11-08/0818r2 Submission Basic Idea: MCA-Aware Channel Access MCA-aware channel access shall both start after the end of a MCA slot and end before the start of a MCA slot MCA slot MCA interval DIFSBack-Off Slots DataACK SIFS STA
doc.: IEEE 802.11-08/0818r2 Submission Managed Contention Access (Contd), Intel CorporationSlide 11 Beacon Interval MCA Zone Legacy Zone CTS- to-Self MCA- Allowed SIFS MCA slot MCA interval Start Time MCA Period NAV MCA-Unaware STA MCA-Aware STA NAV MCA Duration
doc.: IEEE 802.11-08/0818r2 Submission Managed Contention Access MCA Zone is divided into multiple MCA intervals started with a MCA slot with fixed duration MCA slot is a short Guard Interval providing re-sychronization point for STAs contending the channel At the start of a MCA Zone, the AP transmits a CTS-to-Self (to protect the following MCA Zone) Waits for SIFS period and a MCA-Allowed frame The CTS-to-Self shuts off legacy STAs The MCA-Allowed permits the MCA-capable STAs to contend the channel despite of CTS-to-Self, Intel CorporationSlide 12
doc.: IEEE 802.11-08/0818r2 Submission Example: Mixed VoIP and Data 30ms (MCA Zone) 22.4ms (Legacy Zone) 102.4ms (Beacon Interval) 1ms … MCA Configurations: start time = 22.4ms, MCA period = 50ms MCA duration = 30ms MCA interval = 1ms 30ms (MCA Zone) 20ms (Legacy Zone) 60 MCA slots, one TX per slot, 30% rTX ~20 VoIP (bidirectional) connections
doc.: IEEE 802.11-08/0818r2 Submission MCA-Aware OBSS –MCA-slot schedule shall not be created (owned) by BSS that does not have AC_VI or AC_VO STAs to reduce the number of different MCA-slot schedules in OBSS –OBSS MCA-Aware APs shall copy each others MCA-slot schedule AP may reuse the existing MCA-slot schedule by other OBSS as much as possible Owner: AP that generates a MCA-slot schedule Follower: AP that copies other APs MCA-slot schedule, and needs to update when such information is changed over time due to clock drift. –STA may report MCA schedule of other OBSS if such information is not included in the Beacon. OBSS APs may not be in each others range
doc.: IEEE 802.11-08/0818r2 Submission MCA-Aware OBSS (contd) It is recommended that MCA-Aware OBSS use the same duration of MCA slot, and synchronize / align with each other as much as possible, i.e., d T-d BSS1 BSS2 OBSS T (BSS2 MCA interval) T (BSS1 MCA interval)d d (OBSS MCA interval)T – d (OBSS MCA interval)
doc.: IEEE 802.11-08/0818r2 Submission MCA-Unaware OBSS CTS-to-Self will prevent MCA-Unaware OBSS to contend with MCA-aware STAs
doc.: IEEE 802.11-08/0818r2 Submission MCA Violation Problem: –OBSS STA may still violate MCA rules unconsciously due to not receiving beacon or CTS-to-Self (collision, PS, etc.) Recommendation: –detection: AP may detect it by counting the number of MCA slots being overlapped by transmissions. STA may also help detect it and report such event to AP –action: AP may modify MCA slot schedule or reduce / remove MCA zones completely.
doc.: IEEE 802.11-08/0818r2 Submission Summary Main Changes to IEEE 802.11 Standard MCA-slot Aware Channel Access MCA-Allowed Control Frame New MCA IE in Beacon Frame Benefit: reliability, power efficiency, latency/ duty-cycle OBSS/legacy support Cost: efficiency (total network throughput) loss complexity
doc.: IEEE 802.11-08/0818r2 Submission Questions How to support Legacy without using CTS-to-Self? –to disable MCA whenever detecting a legacy STA Simulation to show benefit and cost?