RSTA and Other Terms

March 2005doc.: IEEE 802.11-05/0228r0

IEEE P802.11
Wireless LANs

RSTA and other terms

An RSTA is a roaming enabled STA. In this write up we assume that an RSTA is also a QSTA per dot11e. In case when RSTA is not a QSTA, the following procedures do not apply.

Also, note that when the PIQ contains the “optional” bit, we consider the STA to be making a “query”. When the “mandatory” bit is on, the PIQ is considered to have been a “reservation message”

The message will contain a Resource Information Container, RIC, described below. For now, the RIC contains TSPECS although it may contain other resource types in the future.

Resource Information Container

Requests and queries for resources and subsequent responses from the AP are encapsulated in a Resource Information Container (RIC). The RIC may be very simple, such as containing a single TSPEC or may be structured to ensure that a particular set of resources is available. It comprises a series of Information Elements called Resource Nodes (RNode) each with similar structure: a node header and an optional payload. The RNode header includes index numbers and control bits which may be used to reference and group resource requests.

Three types of RNodes are defined: root, group and leaf. Leaf RNodes may include request information such as a TSPEC. Group RNodes describe groups of Leaf RNodes. The root node is always present in the RIC.

Request messages comprise a root node and at least one leaf nodes defining a requested resource. Optionally group nodes may be included to indicate that a set of resources should be allocated together.

Each RNode contains a “mandatory” bit that can be used to indicate to the target AP how resources should be assigned:

-A “mandatory RIC” is defined by setting the mandatory bit in the root node. In this case all resources in the RIC must be available at the target AP (or the entire request must be rejected),

-otherwise, if the mandatory bit in a group node is set then all resources in that group must be available

-If a resource is not part of a mandatory RIC or mandatory group then the setting of the mandatory bit in the leaf RNode determines how the resource request should be handled.

Each leaf RNode has an index number assigned incrementally starting at ‘1’. A group RNode contains the start and end indexes of the leaf RNodes in the group. The Root node contains the highest index indicating the total number of TSPECS contained in the RIC.

Group and Leaf RNode may include a “More” bit indicating that the AP may choose the best allocation from a list of choices.

QoS procedures at the non-AP QSTA

The following procedures apply to a non-AP RSTA that is also a QSTA.

A non-AP RSTA may choose to initiate the ASSOCIATION mechanism when it deems fit. When sending the Re-association Req message the RSTA has the following options:

1)Omit the RIC if it does not require QoS related resources at the point of association

2)Include a RIC that confirms resources previously reserved using a PIQ message prior to the re-association attempt. In this case the payload part of the leaf RNodes is omitted and the leaf index numbers identify state already held at the access point

3)Include a fully specified RIC (payload included in all leaf RNodes) containing a new resource request. If a prior reservation had been made then all the state for that reservation is discarded before processing the RIC.

In the simplest case, an STA may choose to initiate a ASSOCIATION without any prior query or reservation phase. In that case, if the STA needs to negotiate the QoS with the new AP, it must send the RIC in the Re-association message. This would indicate to the AP that the STA wants the QoS as specified in the TSPEC IEs/RIC.

A re-association request with TSPECS to a non-RAP AP is not defined. The response to such request is beyond the scope of this document.

If the AP is able to meet the resource request included (or implied) by a RIC in the re-association request, and assuming the re-association is successful, then it shall include a RIC in the re-association response. If this is confirmation of previously reserved resources then this can be just a single root node. If any updated information for TSPECs is required then this may be included as leaf payload in the RIC.

If the AP is unable to meet the resource request then it must fail the re-association request with a status code of RESOURCES_UNAVAILABLE.

In case where the STA had sent a query request before invoking the ASSOCIATION mechanism, and the query context timer sent by the AP during the query has not expired, the STA may associate requesting the same resources as the query by including a RIC where the payload of leaf nodes is omitted. Alternatively, the STA may send all the TSPECs that it wants to the AP to consider, regardless of what the results of the query were.

In case where the STA had sent a RIC in the reservation request prior to invoking the ASSOCIATION mechanism, there are two possibilities:

1. The reservation request was successful AND the STA invoked ASSOCIATION within a specified time.
2. The reservation request failed OR the reservation request succeeded but STA did not invoke ASSOCIATION within a specified time.

In the first case, ASSOCIATION need not send TSPECs in the association message. The TSPECs sent previously would be used to admit the streams defined in TSPECs. If , however, the STA still sends TSPECs in the reassociation, the AP shall consider the new set to replace all those in the previous reservation.

In the second case, the STA must insert the TSPECS in the reassociation message if it desires QoS resources to be allocated during association.

If the AP is unable to meet the requirements of the RIC then it shall reject the re-association request and assign no new resources. If the status code is one of the following QoS failiure codes, the AP may include a RIC in the response indicating a set of TSPECs as a suggestion. This set of suggested TSPECS may include one or more original TSPECS sent in the reassociation message. The STA should expect to receive the suggested set of TSPECS (which could be just a replica of the original set, from a Roaming Enabled AP) but is not required to act on the information.

• Invalid TSPECs
• QoS resources not available

Pre-reserved resources shall remain until the expiry time indicated upon issue.

QoS procedures at the RAP

The procedures below apply to a RAP that is also a QAP.

The behavior of the RAP may very depending upon whether the STA invoked a reservation procedure prior to invoking ASSOCIATION. If the STA had sent TSPECS in the reservation request prior to invoking the ASSOCIATION mechanism, there are two possibilities:

1. The reservation request was successful AND the STA invoked ASSOCIATION within a specified time.
2. The reservation request failed OR (the reservation request succeeded but STA did not invoke ASSOCIATION within a specified time).

In the first case, if the RIC of the association request does not contain any TSPECS, the resources that were “accepted” in the reservation phase are deemed “admitted”. The AP relates previously allocated resources/schedules to the association of the STA using the index numbers in the RIC. If however, the association message contains a fully specified RIC with TSPECS, the AP treats the request as a new request and deletes prior reservations (as an implementation optimization the AP may “transfer” resources from the reservation to the new request but this is transparent to the STA.)

In the second case, the AP tries to allocate resources for the TSPECs in the RIC. The admission is considered successful if the requirements of the RIC are met by the AP. Otherwise, the admission is considered a failure.

If the admission of TSPECS succeeds and there is no other association related error the AP shall send an association response message with a status code of SUCCESS. The response shall contain a RIC. If it is necessary to provide updated information about TSPECS then the payload of the leaf RNodes in the RIC shall contain such updated TSPECS indicating, for example, the parameters of the TS that the AP has admitted. The response TSPECS may contain information like Medium Time, Service Period etc.

If the requirements of the RIC fail, the ASSOCIATION mechanism would fail with one of the following status codes in the association response:

• Invalid TSPECs
• QoS resources not available

In case of such failures, the AP may suggest certain TSPECS that it is likely to accept for each TSID. If the AP does not have a suggestion for a TSID, it must include the original TSPEC in response.

An AP that is not RAP should ignore any RIC in an association request message.

In case where the reassociation request fails for reasons other than TSPEC admission failure, the status code for the other reason will supersede.

Query before Association

QoS procedures at the non-AP RSTA

The procedure below applies to a non-AP RSTA that is also a QSTA.

A non-AP RSTA may choose to initiate the query mechanism when it deems fit. A RSTA may only initiate a query if it knows that the new AP it intends to raom to is a RAP and that the AP supports the query mechanism as advertised in the capability field.

A query to a non-RAP AP is not defined. The response to such query is beyond the scope of this document.

The intent of the query is to ask the new AP if it can admit a set of TSPECs. The TSPECs in the query need not belong to only active TSIDs. The STA can send TSPECs for any TSIDs that it intends to use after the transition.

If a RSTA receives a negative response for the query, it does not mean that RSTA has been denied service. The RSTA may still attempt to associate with new AP and request resources via the association request message.

A “YES” response to the query indicates that the AP believes it could have allocated the resources had they been included in a re-association message at the time of the query. A response to the query is considered “NO” if the status code is equal any of the following QoS Failure codes:

• Invalid TSPECs
• QoS resources not available

It is possible that the response may contain a special status code “Come back later”. The response with this status code will also contain the time after which the STA can expect to get a “YES” or “NO” response. This status code suggests that the STA should retry the query after the specified time

The STA may choose to ignore the “come back later” response and query other APs instead.

A STA may initiate multiple queries to the same AP within a single RIC. It is then up to the STA to manage the context and contents of the queries.

The AP may save the RIC corresponding to the last successful query result for a limited period of time (the Query Context Time) which is informed to the station with the “YES” response. If the AP chooses not to save the RIC it shall return a Query Context Time of zero. If the AP saves the RIC, the STA may take advantage of this by using an abbreviated RIC in a subsequent re-association. The AP shall only ever save the last query result for any given STA. A new query shall delete any saved state from a prior query.

It is possible that a re-query after the specified time (specified in the “come back later” response ) may generate yet another “come back later” response. This may happen if the AP was unable to get the answer to the original query yet, or the STA re-queried so late that the context of the original query was cleared at the AP.

For any other non-zero status codes, the authentication req is considered a failure for reasons other than the query failure.

QoS procedures at the RAP

These procedures assume that a RAP is also a QAP.

{{{A RAP shall consider a set of TSPECs in the Auth message to be part of the query. An AP that is not RAP should drop TSPECs.}}}

{NOTE: this needs updating as the merger proceeds}

Upon receiving the TSPECs the HC MAC on the RAP (which is also a QAP) shall parse the TSPECs. The MAC may consult the scheduler to determine if the TSPECs can be accepted, given the current schedule. The algorithm to determine the answer is beyond the scope. The HC MAC may use this answer from the scheduler as a direct input to prepare a response of the query. Alternatively, the HC MAC may send a MLME event to the SME, for further consultation. This query event may contain the TSPECs sent in the query from the STA. The SME may in turn consult another entity, like LPS, and get the response. The response will then be passed down the HC MAC in an MLME response event. It may use the answer in the response event to prepare a response to the query.

A response to the query must include a copy of the RIC when the query returns with a “YES” answer however this RIC need not include the payload in the leaf RNodes. This is to indicate to the STA that the TSPECs were considered by the AP before returning a response. Please note that since we are overloading the Auth Req message a successful Auth Resp message could be sent by a non-RAP because it dropped the TSPECs.

A response to the query should only be YES, if all the requirements of the RIC can be accommodated with a high probability. A YES, is not a guarantee that eventually all the TSPECs will be accommodated by the RAP.

A “NO” response to a query will be sent if the RAP can not fulfill the requirements of the RIC it received in the query. A “NO” response may contain a RIC which includes TSPECS as payload to the leaf RNodes. These TSPECS are considered “suggestions” for the STA. It is up to the STA to consider the suggested TSPECS. If the STA concludes the suggestions are acceptable is may proceed to association and the AP shall store the modified request for the specified time. If the STA concludes the suggestions are not acceptable it may initiate another query or proceed to association with a fully specified new RIC.

“NO” to an STA does not bar the STA from associating with the AP. It is not considered an indication of denial of service.

A RAP may respond to a query with the status code of “come back later”. The RAP is indicating to the STA that it does not have an answer to the query yet and the STA should requery it after a specified amount of time. The RAP shall maintain the context for the query for some time for the STA to come back and re-query it.

It is possible that a RAP may receive multiple independent queries from the same STA contained within a single RIC. The order of preference will be the order of occurrence in the RIC. The RAP shall reply with the first “YES” result possible for each of the choices in order of preference and return a RIC containing only the “winning” query. In the event that none of the options are possible the AP shall respond with a “NO” result and may include a RIC with suggested alternative TSPECS.

A “come back later” response to an STA does not bar the STA from associating with the AP. It is not considered an indication of denial of service.

In case an Authentication request fails because of reasons other than QoS Failuire reasons, the other reasons shall supersede in the status code.

Reservation before Association

QoS Procedures at the non-AP RSTA

An STA may initiate resource reservation as it deems fit. A QSTA may only initiate a resource reservation if it knows that the new AP it intends to roam to is a RAP and that the AP supports the reservation mechanism as advertised in the capability field.

A reservation request to a non-RAP AP (be it new or old AP ) is not defined. The response to such request is beyond the scope of this document.

The intent of the resource reservation request is to ask the new AP to reserve the resources for specified TSPECs. The TSPECs in the request need not belong to only active TSIDs. The STA can send TSPECs for any TSIDs that it intends to use after the transition. It is the responsibility of the STA to initiate a ASSOCIATION session to associate with the new STA within a specific time of a resource reservation response.

If a QSTA receives a negative response for the resource reservation, it does not mean that QSTA has been denied service. The QSTA may still attempt to associate with new AP using the ASSOCIATION mechanism or using the vanilla association mechanism.