Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Addressing comments for QoS Resource construction and behavior in FT Protocol Date: 2006-05-15 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Sood, Kumar, Montemurro John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Goal This submission proposes resolution to TGr LB comments addressing QoS Resource IEs construction and RIC behavior with FT protocol. Sood, Kumar, Montemurro John Doe, Some Company

Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Overview The purpose of this presentation is to streamline the TGr reservation mechanism in the following areas: MDIE Policy Bit – FT Protocol Option Bit Resource allocation treated as “Optional” in FT Streamline IE Usage in Resource construction Single QoS Resource per RDIE (remove the implicit “OR” operation in interpretation of the RDIE) Sood, Kumar, Montemurro John Doe, Some Company

MDIE Policy Advertisement Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 MDIE Policy Advertisement Clarification to the MDIE Policy Advertisement: MDIE Policy Bit B3: “Reserve Option” bit renamed to “FT Protocol Option” bit 1: Indicates that the STA shall use 6-message (FT Reservation Protocol) flow 0: Indicates that STA can choose to use either 4-message (Base Mechanism) or 6-message (FT Reservation Protocol) flow Sood, Kumar, Montemurro John Doe, Some Company

Resource allocation treated as “Optional” in FT Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Resource allocation treated as “Optional” in FT The purpose is to align TSPEC resource requests/response construction and behavior with that of ADDTS Remove the Mandatory/Optional Bits in the RDIE If a reservation is not granted by the target AP, the STA can: Begin an FT reservation process with another target AP May continue to complete the FT and issue an updated TSPEC in an ADDTS with the current AP after a reassociation Sood, Kumar, Montemurro John Doe, Some Company

RIC Behavior in Base Mechanism (4-message) Flow Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 RIC Behavior in Base Mechanism (4-message) Flow Sood, Kumar, Montemurro John Doe, Some Company

RIC Behavior in Base Mechanism (4-Message) Flow Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 RIC Behavior in Base Mechanism (4-Message) Flow Resource transaction may be done using Message #3 (Reassociation Req) and Message #4 (Reassociation Resp) Failure of TSPEC allocation by an AP shall not cause the Reassociation to fail STA may reassociate with the AP even if TSPEC(s) are not allocated Badly formed TSPEC Requests shall cause Msg# 4 failure AP may not allocate any resources requested in Msg# 3, and send suggested Resources back in Msg# 4 If desired resources were not allocated: STA sends ADDTS after reassociation to reassert its new (AP suggested or others) requests (just like in TGe) If Reassociation Response indicates failure, then STA shall go back to execute the complete 4-message handshake again Sood, Kumar, Montemurro John Doe, Some Company

RIC Behavior in Reservation (6-message) Flow Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 RIC Behavior in Reservation (6-message) Flow Sood, Kumar, Montemurro John Doe, Some Company

RIC Behavior in Reservation (6-Message) Flow Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 RIC Behavior in Reservation (6-Message) Flow Resource transaction may be done only using Messages #3 (Auth Confirm) and Message #4 (Auth Ack) Failure of TSPEC allocation by an AP shall not cause the Authentication Ack to fail STA may execute reassociation (msg #5) even if its requested QoS resources were not allocated. STA may do ADDTS after reassociation using new or AP suggested QoS resources. STA may re-execute the entire Reservation Flow again Badly formed TSPEC Requests shall cause Msg# 4 failure AP may send suggested Resources back in Msg# 4 In all cases (Resources allocated or not): STA sends Msg# 5 (Reassociation Request) with no TSPECs. AP knows which resources have been allocated for each STA. If Msg# 4 fails, then STA shall go back to execute the complete 6-message handshake again Sood, Kumar, Montemurro John Doe, Some Company

Streamline IE’s in RIC Construction Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Streamline IE’s in RIC Construction Remove the RIC Root IE (RRIE) The RIC Data IE (RDIE) structure will be as follows Sood, Kumar, Montemurro John Doe, Some Company

Single QoS Resource per RDIE Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Single QoS Resource per RDIE A QoS Resource is a combination of TSPEC IEs and any associated TCLAS and TCLAS Processing IEs. Each QoS Resource Request has 1 RDIE Sending multiple TSPECs for same stream (say, in canonical voice application) during FT is not useful - A STA has to use higher layer signaling to update streams (e.g. the negotiation of voice codecs) Stream negotiation can occur after reassociation. The STA would likely request resources that it is currently using Sood, Kumar, Montemurro John Doe, Some Company

QoS Resource Request (Example 1) Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 QoS Resource Request (Example 1) A QoS Resource Request for single stream is sent by a STA Sood, Kumar, Montemurro John Doe, Some Company

QoS Resource Response (Example 1) Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 QoS Resource Response (Example 1) A QoS Resource Response is either (A) MDIE indicating the resource from Resource Request that is allocated by AP, OR, (B) No MDIE indicates no resources were allocated, OR, (C) RDIE followed by suggested resources Sood, Kumar, Montemurro John Doe, Some Company

QoS Resource Request-Response (Example 2) Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 QoS Resource Request-Response (Example 2) Sood, Kumar, Montemurro John Doe, Some Company

Summary Clarified FT policy advertisement. Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2006 Summary Clarified FT policy advertisement. Simplified the error handling when resource reservations fail. Aligned the QoS Resource construction and behavior with that of ADDTS Addressed complexity of RIC construction and processing. Sood, Kumar, Montemurro John Doe, Some Company