1. Month Year
doc.: IEEE yy/xxxxr0
May 2006
Addressing comments for QoS Resource construction and behavior in FT Protocol
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Sood, Kumar, Montemurro
John Doe, Some Company

2. Month Year
doc.: IEEE 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

3. Month Year
doc.: IEEE 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

4. MDIE Policy Advertisement
Month Year
doc.: IEEE 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

5. Resource allocation treated as “Optional” in FT
Month Year
doc.: IEEE 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

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

7. RIC Behavior in Base Mechanism (4-Message) Flow
Month Year
doc.: IEEE 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

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

9. RIC Behavior in Reservation (6-Message) Flow
Month Year
doc.: IEEE 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

10. Streamline IE’s in RIC Construction
Month Year
doc.: IEEE 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

11. Single QoS Resource per RDIE
Month Year
doc.: IEEE 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

12. QoS Resource Request (Example 1)
Month Year
doc.: IEEE 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

13. QoS Resource Response (Example 1)
Month Year
doc.: IEEE 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

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

15. Summary Clarified FT policy advertisement.
Month Year
doc.: IEEE 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