Doc.: IEEE802.11-02/248r0 Submission Bobby JoseSlide 1 February 2002 Contention Free TXOP Request and Allocation Issues Bobby Jose,

Slides:



Advertisements
Similar presentations
Doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 1 H²CF: Hiperlan2 Hybrid Coordination Function; Ideas on coexistence.
Advertisements

Doc: IEEE /705ar0 Submission Javier del Prado et. al November 2002 Slide 1 Mandatory TSPEC Parameters and Reference Design of a Simple Scheduler.
Doc.:IEEE /525Ar0 Submission September 2002 Mathilde Benveniste, Avaya Labs Slide 1 Simplifying Polling Mathilde Benveniste
Doc. :IEEE /314r0 Submission Sai Shankar et al., Philips ResearchSlide 1 May 2002 TXOP Request: in Time vs. in Queue Size? Sai Shankar, Javier.
January 2002 Khaled Turki et. al, Texas InstrumentsSlide 1 doc.: IEEE /022r0 Submission TID Field Usage in QoS CF-Poll Khaled Turki and Matthew.
Doc.: IEEE /289r0 Submission Bobby Jose,Slide 1 March 2002 CC/RR Alternatives HCF Adhoc Discussion Work Sheet V00.04 Bobby Jose, et.al
Doc.: IEEE /879r3 Submission August 2004 Abel Dasylva, Nortel NetworksSlide 1 Class-based Contention Periods (CCP) for the n MAC A. Dasylva,
1 Medium Access Control Enhancements for Quality of Service IEEE Std e TM November 2005.
Ncue-csie1 A QoS Guaranteed Multipolling Scheme for Voice Traffic in IEEE Wireless LANs Der-Jiunn Deng 、 Chong-Shuo Fan 、 Chao-Yang Lin Speaker:
1 QoS Schemes for IEEE Wireless LAN – An Evaluation by Anders Lindgren, Andreas Almquist and Olov Schelen Presented by Tony Sung, 10 th Feburary.
802.11g & e Presenter : Milk. Outline g  Overview of g  g & b co-exist QoS Limitations of e  Overview of.
1 Medium Access Control Enhancements for Quality of Service IEEE Std e TM November 2005.
Doc.: IEEE /678r1 Submission January 2003 Mark Bilstad, Cisco SystemsSlide 1 Uniform e Admissions Control Signaling for HCF and EDCF Bob.
Doc.: IEEE /1120r0 Submission Buffer Status Report Slide 1 Date: Authors: Alfred Asterjadhi, et. al. September 2015.
doc.: IEEE /560r1 Submission John Kowalski, Sharp November 2001 Adding Rate Parameter to the TSPEC /Queue State Element John Kowalski Sharp.
Doc.: IEEE /601r0 Submission Harada Yasuo, Matsushita Electric Ind. Slide 1 November20 01 Delayed Acknowledgement v.s. Normal Acknowledgement.
An Energy Efficient MAC Protocol for Wireless LANs, E.-S. Jung and N.H. Vaidya, INFOCOM 2002, June 2002 吳豐州.
Doc.: IEEE /452 Submission December, 2000 Michael Fischer, Intersil Slide 1 A Hybrid Coordination Function for QoS Michael Fischer Intersil Corporation.
Quality of Service Schemes for IEEE Wireless LANs-An Evaluation 主講人 : 黃政偉.
Doc.: IEEE /0079r0 Submission Interference Signalling Enhancements Date: xx Mar 2010 Allan Thomson, Cisco SystemsSlide 1 Authors:
Doc.: IEEE /494r0 Submission July 2001 Michael Fischer, Intersil (TGe Editor)Slide 1 Provisional Tge Ballot Comment Resolutions from the May,
Doc: IEEE /625r1 Submission Amjad Soomro et. al September 2002 Slide 1 TGe ‘Fast track’ proposed Draft Normative Text Changes Sai Shankar, Javier.
Resolutions to Static RTS CTS Comments
Doc.: IEEE /0126r1 Submission January mc HEMM Date: Authors: Graham Smith, DSP GroupSlide 1.
Doc.: IEEE /361 Submission October 2000 Wim Diepstraten, LucentSlide 1 Distributed QoS resolution Greg Chesson-Altheros Wim Diepstraten- Lucent.
November 2000 Jin-Meng Ho, Texas InstrumentsSlide 1 doc.: IEEE /367 Submission p-DCF for Prioritized MAC Service Jin-Meng Ho, Sid Schrum, and.
Doc.: IEEE /0370r0 Submission January 2012 Haiguang Wang et. al, I2R, SingaporeSlide 1 TIM Compression Date: Authors:
Doc.: IEEE /1121r0 Submission HE A-Control field Slide 1 Date: Authors: Alfred Asterjadhi, et. al. September 2015.
Submission doc.: IEEE /1204r2November 2004 Emily Qi, Intel CorporationSlide 1 QoS Metrics for Traffic Category/Stream Emily H. Qi Intel Corporation.
Doc.: IEEE /577r0 Submission July 2003 Qiang NI, Pierre Ansel, Thierry Turletti, INRIASlide 1 A Fair Scheduling Scheme for HCF Qiang Ni, Pierre.
Doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 1 Some Clarifications to IEEE e, Draft 3.2, August 2002 H.L. Truong and G. Vannuccini.
Doc.:IEEE /566r2 Submission November 2001 S. Choi, Philips & M.M. Wentink, Intersil Slide 1 Multiple Frame Exchanges during EDCF TXOP Sunghyun.
Delayed Acknowledgement v.s. Normal Acknowledgement
How to collect STAs’ Tx demands for UL MU
IEEE : Wireless LANs ALOHA, Slotted ALOHA
AP Service Load: Improved Definition
EDCF TXOP Bursting Simulation Results
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Asymmetric beamforming training procedure enhancements
An alternative mechanism to provide parameterized QoS
Questions on Queue State Element
Hybrid Coordination Function (HCF) Frame Exchange and NAV Details
Use of EDCA Access During HCF Polling
Burst Transmission and Acknowledgment
EDCF Issues and Suggestions
Terminology Corrections and Improvements for the TGe Draft
QoS Poll Modifications Allowing Priority
Uniform e Admissions Control Signaling for HCF and EDCF
Group Polling for DCF Based Reservation Request
MAC Partial Proposal for TGn
An alternative mechanism to provide parameterized QoS
Suggested changes to Tge D3.3
Delayed Acknowledgement v.s. Normal Acknowledgement
Acknowledgement for Multicast Streams
A Fair Scheduling Scheme for HCF
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Uniform e Admissions Control Signaling for HCF and EDCF
Suggested changes to Tge D3.3
Delayed Acknowledgement v.s. Normal Acknowledgement
HCCA TXOP handling difficulties
Interference Signalling Enhancements
Scheduled Peer Power Save Mode for TDLS
QoS Metrics Date: Authors: January 2005 Month Year
HCF Channel Access And Inter-BSS Channel Sharing
Burst Transmission and Acknowledgment
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Use of More Data Field Date: Authors: Jan 2006 Jan 2006
TXOP Request: in Time vs. in Queue Size?
Presentation transcript:

doc.: IEEE /248r0 Submission Bobby JoseSlide 1 February 2002 Contention Free TXOP Request and Allocation Issues Bobby Jose,

doc.: IEEE /248r0 Submission Bobby JoseSlide 2 February 2002 Outline Qos Flows Request Per Terminal and Request Per Flow Grant Per Terminal and Grant Per Flow Queue size Vs TXOP Duration request. CC/RR TXOP Requests- How Often ?

doc.: IEEE /248r0 Submission Bobby JoseSlide 3 February 2002 Qos Flows Parameterized Flow –Connection oriented, created through explicit signaling, (Streams). –Has a Tspec bound to it, the HC can calculate profile of TXOP requirement, TXOP requests are used for dynamic variation. Prioritized Flow –Includes connection less traffic (Access Traffic Categories (TC)) –Need not have a Tspec bound to it, TXOP only based on TXOP request. –Has the notion of priority wrt other flows, need to differentiate between QSTA requirements.

doc.: IEEE /248r0 Submission Bobby JoseSlide 4 February 2002 Request Per Terminal QSTA provides only the aggregated traffic requirements of each Terminal. The allocated TXOP may be used by any traffic. In current draft, it would mean use the TID of the highest priority ? But include all the traffic in the queue size information. Not sufficient to support prioritized services. Parameterized requirements are clear from tspec, perhaps workable without detail for dynamic variation per stream.

doc.: IEEE /248r0 Submission Bobby JoseSlide 5 February 2002 Request per Flow The QSTA sends TXOP request for each traffic flow for which it has data to transmit. The QSTA agrees not to use any more TXOP per flow on the average than what was requested by it. Allows the HC to differentiate priorities across QSTAs. Note that the HC may allocate TXOP per terminal or per flow.

doc.: IEEE /248r0 Submission Bobby JoseSlide 6 February 2002 Grant Per Terminal The TXOP is allocated by the HC on a terminal basis. Each QSTA may use the TXOP to transmit traffic belonging to any traffic category. Allows for smart local packet scheduling schemes at the QSTA, that is efficiently handles local variations, significantly optimizing TXOP utilization. Depending on txop request mechanism, HC may consider per stream requirements to calculate the txop grant. There is an implicit agreement by the QSTA not to use on the average more TXOP per TID than what was requested by it.

doc.: IEEE /248r0 Submission Bobby JoseSlide 7 February 2002 Grant Per Flow The HC explicitly allocates TXOP to each flow on the QSTA. The QSTA may transmit only traffic belonging to that flow. Allows for a light weight QSTA implementation, where QSTA does not have to do complex scheduling. HC does per flow scheduling, including handle dynamic variations.

doc.: IEEE /248r0 Submission Bobby JoseSlide 8 February 2002 Usage RPT is not sufficient to differentiate priorities between stations, and its used with GPT RPF and GPT is currently supported. RPF, GPF ( it would be good to support GPT, and allow the QSTA to request GPT mode during association, light weight stations). RPF, (GPF + GPT) can co-exist, and maybe useful in certain cases [3].

doc.: IEEE /248r0 Submission Bobby JoseSlide 9 February 2002 Comments HC currently supports only GPT, (The TID for cfpoll (no data) undefined ?). Clarify if (when) RPT or RPF is used in the current draft, and distinguish between the two. Specify that with RPF the QSTA agrees not to statistically use any more TXOP per flow than what was requested by it (Metric TBD).

doc.: IEEE /248r0 Submission Bobby JoseSlide 10 February 2002 TXOP Request Mechanisms QOS Control Field (in qos data packets destined to HC, including Qos Null) –Queue Size –TXOP Duration requested Do we need both these ? CC/RR Is it worth the overhead ?

doc.: IEEE /248r0 Submission Bobby JoseSlide 11 February 2002 TXOP Calculation Ideally what do you need ? Total Packet Size in Queue Per traffic category Total framing overhead (significant on 11b/g) Ack policy,Overhead for burst ack Rate at which the packets will be transmitted. Channel Errors for each stream

doc.: IEEE /248r0 Submission Bobby JoseSlide 12 February 2002 Queue Size TC Queue Size is the total size of all MSDUs buffered at a QSTA. In situations where the packet size is variable, because of significant phy preamble overhead the actual TXOP that is required to transmit these packets depends on the packet size distribution. This difference is significant for 11b and 11g with long preamble. Depending on scheduling scheme at the HC the queue size information could be used to estimate the instaneous arrival rate compared to specified tspec parameters. for this using MSDU size could be useful.

doc.: IEEE /248r0 Submission Bobby JoseSlide 13 February 2002 Framing Overhead Significant However TC Queue Size is not sufficient because each queue contains various packet sizes, i.e., the txop needed depends on the packet size distribution. For example using 11b, 4, 1500 byte packets would take ms while 40, 150 byte packets would take ms of TXOP. Both have the same queue size but the required TXOPs are so drastically different. Imagine how inaccurate the bandwith estimation would be for a traffic with variable traffic type. To efficiently calculate the TXOP what is required is queue size calculated using MPDU size including equivalent size for phy overhead, thereby making the TXQueueSize relevant, independent of packet size.

doc.: IEEE /248r0 Submission Bobby JoseSlide 14 February 2002 Uniform Qos Control Field Make the definition of Bits 0-8 the same for QOSdata (non null), Qos Null, and RR i.e., the last three rows. Allows QoS data frames sent by WSTA to also request TXOP duration.

doc.: IEEE /248r0 Submission Bobby JoseSlide 15 February 2002 Include Framing Overhead in Queue size? Change the definition of TC Queue Size to be the total size of all packets buffered at the QSTA including mac header size and an equivalent overhead to cover the phy overhead. The size must also be appropriately scaled depending on the expected transmission rate!. Do we really need queue size ? Remove Queue Size in Bytes, just use TXOP duration requested.

doc.: IEEE /248r0 Submission Bobby JoseSlide 16 February 2002 TXOP Request Types TXOP Duration Requested include the TXOP duration requested for all the packets in the Queue. Need not distinguish between this request and the request for which the TXOP request is just for the next allocation.

doc.: IEEE /248r0 Submission Bobby JoseSlide 17 February 2002 CC/RR Overhead Transmitting one frame just to send the queue size information of one traffic class is too high, it would be better to have a mechanism that allows the queue size/txop duration requested information for all traffic categories in one frame format. Reserving a minimal CCOP (as required in the current draft )every DTIM period, is too high. For both the above calculate for 11b/g.

doc.: IEEE /248r0 Submission Bobby JoseSlide 18 February 2002 Implementation Complexity Efficient implementation of CC/RR requires implementation in hardware, to respond to the first CCOP in SIFS time. Does CC/RR implementation give you enough advantage to invest in the implementation of a whole new access scheme (in hardware)?

doc.: IEEE /248r0 Submission Bobby JoseSlide 19 February 2002 Request for Changes to CC/RR Support Multiple traffic per RR (accepted by adhoc group). Allow RR to be transmitted during any TXOP, –As a response to CC –During a Polled TXOP –During EDCF TXOP As a compromise to removing CC/RR and specifying a new frame for reservation request ?

doc.: IEEE /248r0 Submission Bobby JoseSlide 20 February 2002 RR transmission in any TXOP Does RR need an acknowledgement when transmitted without a CC ? Current RR frame does not contain TA, would need to include TA so that the HC does not have to lookup AID to generate RA for the ACK. Requiring Ack for RR transmitted as a response to the CC is a waste as the next CC provides sufficient feedback.

doc.: IEEE /248r0 Submission Bobby JoseSlide 21 February 2002 Decouple CC and RR Simple solution would be not to require an ack for RR. The CC contains feedback for all RRs received including those received in polled and EDCF txop. Moreover the allocation of the requested TXOP is sufficient indirect acknowledgement for the TXOP Request.

doc.: IEEE /248r0 Submission Bobby JoseSlide 22 February 2002 Extending qos-null to support this optimization (multiple traffic per packet) is not clean. Could have a new frame just to send txop request during any TXOP and have an ack as immediate response. Would prefer one uniform frame for reservation requests, use the RR frame if cc/rr remains in the draft. If RR can only be an immediate response to CC, to get the benefit of aggregated txop requests its required to implement cc/rr or have a new frame format for txop request.

doc.: IEEE /248r0 Submission Bobby JoseSlide 23 February 2002 Min CCOP Min required CCOP per DTIM is now a MIB variable which may be set to zero (From Adhoc Group) This means that a CCOP need be allocated only when there is (E)DCF load, and the HC estimates that RRs are expected.

doc.: IEEE /248r0 Submission Bobby JoseSlide 24 February 2002 Do we really need CC/RR ? it is not clear if using CC/RR provides a corresponding improvement in the efficiency of TXOP allocation compared to using EDCF even for variable rate traffic[4]. Note that EDCF need be used for reservation requests only if no (or insufficient) tx op is allocated during which the request may be transmitted.

doc.: IEEE /248r0 Submission Bobby JoseSlide 25 February 2002 CC/RR Slotted Aloha Vs EDCF How good is the slotted aloha access mechanism that follows cc compared to using (E)DCF as the access scheme for contention among RR’s in the controlled contention period ? Note that the above allows a EDCF based Controlled Contention Period in CFP, signaled by a CC frame. More work...

doc.: IEEE /248r0 Submission Bobby JoseSlide 26 February 2002 How often should a TXOP request be received at the HC for a given flow? Depends on the traffic type and TSPEC (if any). Depends on the TXOP allocation algorithm at the HC (Scheduling). Should the HC the flexibility of being able to specify that for each flow in the QBSS ? Is it sufficient that each QSTA estimates that based on the txop it has received ? Just - > aNumMinStrmRR (Number of TBTT per RR per traffic stream with VBR, such a limit is not meaningful for other flows).

doc.: IEEE /248r0 Submission Bobby JoseSlide 27 February 2002 References 1.Various Comments to Ballot 30, TGE 2.02/130, Questions on Queue State Element, Shugong Xu, Sharp Labs. 3.02/022, TID Field Usage in Qos+Cf Poll, Khled Turki, and Matthew Shoemake,TI. 4.01/151,CC/RR Model and Simulations,Wei Lin, Mathew Sherman,AT&T.