An alternative mechanism to provide parameterized QoS

1. An alternative mechanism to provide parameterized QoS Srinivas Kandala, John M. Kowalski, Yoshihiro Ohtani, Shugong Xu, Wataru Gohda Srinivas Kandala, John Kowalski et al. Sharp Labs

2. Outline • How we got to this proposal • What it is • Why it’s good • Comparison with TSPEC • Objections to this proposal answered • Conclusion Srinivas Kandala, John Kowalski et al. Sharp Labs

3. How we got to this proposal (1) • This proposal has a long history behind it: • 802.11-00/138 “Suggested-802.11 PCF-Enhancements and Contention Free Bursts,” from May 2000, by Maarten Hoeben of No Wires Needed (Now Intersil) • 802.11-01/597r1 “’Guaranteed’ channel access: Queue State Element and Express Traffic” by Peter Johanssen • 802.11-02/383 “Description of Requirements for Scheduler Behavior & Suggested Modifications to TSPEC,” by John Kowalski • These proposals all center around a simple time-based polling scheme that can provide parameterized QoS. • No need for mucking around with TSPECs drawn from other technologies that have no reason to be on the 11e air interface. • Unlike the TSPEC, time-based parameterized QoS can exhibit normative behavior- meaning a given stimulus yields a predictable response- that means interoperability is possible. Srinivas Kandala, John Kowalski et al. Sharp Labs

4. How we got to this proposal (1) • The original No Wires Needed Proposal lacked power management • The Queue State Element lacked an admission control mechanism • The proposal in 383r0 was not voted on separately, was not well understood, still had a connection oriented paradigm, and needed to be improved to address power management issues. • The current proposal fixes all these problems, has a SAP that addresses all vendors’ needs AND is simple. Srinivas Kandala, John Kowalski et al. Sharp Labs

5. What it is: Overview • This method allows stations to request scheduling by the HC when implemented in the AP. • Stations and not applications initiate the request for scheduled TXOPs. • Applications do not need to know about the TXOP reservation facility. It is up to the MAC, based on the queue flow/service and will initiate the service. (Initiates it autonomously). • To allow application specific devices to use polling feature all the time, primitives are provided which can be used by higher layers. (Over-rides the autonomous feature when the application is aware of the SAP.) • Details, of course, are in the draft. Srinivas Kandala, John Kowalski et al. Sharp Labs

6. What it is (1): TXOP Reservation(TR) Request/Response • Stations send the TR QoS Poll Request action frame to the HC. • HC responds with the QoS Poll Response action frame indicating whether it is rejected or accepted the request. • If the request is accepted, the HC shall schedule the first TXOP after TXOP activation delay. • Subsequent TXOPs shall be scheduled after Inter-TXOP Interval within a jitter bound. • Stations shall refresh or renegotiate the request after every dot11PollStateDuration. • If the station does not refresh or renegotiate the HC shall not poll the station. • Station can use this mechanism to renegotiate if its needs change. There will be no queue information piggybacked into the QoS Data frame. Srinivas Kandala, John Kowalski et al. Sharp Labs

7. TR QoS Action frame • A new set of action frames – request/response pair. • Frame Format • Number of TRS can be 1 or 2 – to allow bidirectional flows to be reserved at the same time. • TRS element described in the next slide. • TCLAS element same as the one in current draft to allow differentiation of “controlled” and “uncontrolled” flows with the same user priority. Srinivas Kandala, John Kowalski et al. Sharp Labs

8. TR Specification (TRS) Element • A new element. • Frame Format: • Direction can be sidelink/uplink or downlink. • User priority is the lowest user priority of the MPDUs that will be delivered during the scheduled TXOP. • If TCLAS is used then the elements in TCLAS will be combined with the user priority. Srinivas Kandala, John Kowalski et al. Sharp Labs

9. TRS Parameters • TR Activation delay – duration after which the TR should be activated. • Inter-TXOP Interval – Duration between each scheduled TXOP • Minimum TXOP duration • Nominal TXOP duration • Maximum TXOP duration • TXOP Jitter bound Srinivas Kandala, John Kowalski et al. Sharp Labs

10. HC Negotiation • HC processes a TR QoS Action request frame and produce the following status codes that are sent to the WSTA through a TR QOS Action response frame. Srinivas Kandala, John Kowalski et al. Sharp Labs

11. TR Lifecycle Srinivas Kandala, John Kowalski et al. Sharp Labs

12. TR Setup Srinivas Kandala, John Kowalski et al. Sharp Labs

13. Soft state & Classification • The reservation is maintained based on “soft state”. • WSTAs refresh the reservation by sending the TR QoS Action request frame at least once in every dot11TRStateDuration. • HC will delete the reservation if it does not receive the frame in dot11TRStateDuration. • No explicit feedback. Any changes in the scheduling should be re-negotiated by sending a new QoS Action request frame. • The classifier will match RA, user priority and will deliver frames in the scheduled TXOPs. Srinivas Kandala, John Kowalski et al. Sharp Labs

14. Soft State Maintenance Srinivas Kandala, John Kowalski et al. Sharp Labs

15. Why it’s good • It’s simple. • It enable power save between TXOPs • It’s testable by using a sniffer. • It allows current applications to use it. • It requires no changes in itself to work with AWMA. • It lets the HC remain in control of admitting polled streams. • It’s adaptive based on soft state & re-negotiation. Srinivas Kandala, John Kowalski et al. Sharp Labs

16. Comparison with TSPEC Srinivas Kandala, John Kowalski et al. Sharp Labs

17. Objections: Answered • “You can’t handle VBR Streams” Answer: You can with the combined polling function and E-DCF. And the “Soft State” and re-negotiation allow for updating the parameters quickly. But: Is there any commercially used VBR applications? Not in any consumer AV equipment. • “You need frequent re-negotiation.” Answer: The frames are small. The state machine is small. The scheduler is small. The problem with the TSPEC is worse! Srinivas Kandala, John Kowalski et al. Sharp Labs

18. Objections: Answered (cont.) • “If the number of WSTAs increases it gives rise to scalability issues.” Answer: You have the same problem with the TSPEC! At least we can provide normative behavior for how the system acts as the number of STAs grows! • “You need higher-layer communication to do the re-negotiation” Answer: The 802.11 PHYs transmit at variable rates today, and don’t need to communicate with the higher layers. How the TSPEC will do this is a mystery. Srinivas Kandala, John Kowalski et al. Sharp Labs

19. Objections: Answered (cont.) • “Without knowledge of the PHY the API has to make assumptions about the PHY and channel conditions” Answer: The SAP interface can accommodate rate based parameters. OTOH, the HC needs to be aware of rates & application error rate requirements, even though, in general it is completely agnostic to them! • “What happens if someone ‘cheats’ and makes overly conservative estimates?” Answer: That’s why we need interoperability testing. The TSPEC has the same problem! • Objections: You can’t do multiple flows! • Answer: Give me a real, sellable application where multiple flows are REALLY required in a client device in the next 5-7 years. Just one! Please! The installed base can’t do multiple flows, either- so if you can solve that problem... Srinivas Kandala, John Kowalski et al. Sharp Labs

20. Objections: Answered (cont.) • Scheduling is too restrictive. Answer: We have included parameters to restrict the scheduling for mobile devices to use power-save. This does not require, in general, frequent beacons. The TSPEC provides, as of this writing NO way to do this! • Scheduling streams with disparate parameters is an NP complete problem. Answer: True for both methods. • Scheduling is not “optimal.” Answer: Neither is the TSPEC: the AP is not omniscient. Srinivas Kandala, John Kowalski et al. Sharp Labs

21. Objections: Answered (cont.) • “Sharp wants this because they have IPR on it!” Answer: Most of the companies that have been doing 802.11e have IPR that is not guaranteed to be royalty-free. Sharp is not even sure what IPR we have here at this time (which may be on both proposals). Sharp’s interest is to enable wireless AV for 802.11 - and that means we want every 802.11 system to be enabled to manage AV transmissions. We developed a parameterized QoS access method that is simple enough to be implemented by all vendors and meets the needs of AV & Voice over IP. Do you honestly think we would develop a method that everyone could use and then encumber it so that no one could use it? Srinivas Kandala, John Kowalski et al. Sharp Labs

22. Conclusions • Meets all applications’ & implementers’ requirements. • No open issues! • Objections to this method are either the same ones for the TSPEC, or are agnostic to the complexity and design issues of a mobile packet radio. • Simple enough that companies can implement and bring to market in timely manner. Srinivas Kandala, John Kowalski et al. Sharp Labs