Contention Free TXOP Request and Allocation Issues

1. Contention Free TXOP Request and Allocation Issues Bobby Jose, bobby@ieee.org Bobby Jose

2. 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 ? Bobby Jose

3. 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. Bobby Jose

4. 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. Bobby Jose

5. 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. Bobby Jose

6. 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. Bobby Jose

7. 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. Bobby Jose

8. 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]. Bobby Jose

9. 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). Bobby Jose

10. 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 ? Bobby Jose

11. 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 Bobby Jose

12. 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. Bobby Jose

13. 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 5.131 ms while 40, 150 byte packets would take 12.04 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. Bobby Jose

14. 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. Bobby Jose

15. 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. Bobby Jose

16. 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. Bobby Jose

17. 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. Bobby Jose

18. 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)? Bobby Jose

19. 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 ? Bobby Jose

20. 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. Bobby Jose

21. 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. Bobby Jose

22. 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. Bobby Jose

23. 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. Bobby Jose

24. 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. Bobby Jose

25. 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 ... Bobby Jose

26. 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). Bobby Jose

27. References • Various Comments to Ballot 30, TGE • 02/130, Questions on Queue State Element , Shugong Xu, Sharp Labs. • 02/022, TID Field Usage in Qos+Cf Poll, Khled Turki, and Matthew Shoemake,TI. • 01/151,CC/RR Model and Simulations,Wei Lin, Mathew Sherman,AT&T. Bobby Jose