11-11-0316-03-000m-proposed-resolution-of-cid-11001

March 2011 doc.: IEEE 802.11-11/0316r3

IEEE P802.11

Wireless LANs

Abstract

This submission contains a proposed resolution to CID 11001, which is assigned to the author for resolution.

R1: updated following 2011-03-14 TGmb meeting. Changes made during that meeting are highlighted thus.

R2: Added comment 11002

R3: Minor adjustments to exclude .11u unanswered questions from changes and tidy up for motioning, shown thus.

Submission page 1 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3 The Comments

Proposed resolution

Agree in principle. Make changes as indicated in document 11-11-0316r, which achieves the intent of the proposed change.

Discussion

The status code and reason code definitions could be improved:

?Some of them are defined using an explanatory paragraph, so an alternative form of representation is needed in Clause 6, where short names rather than essays are required for

enumeration lists.

?Sometimes the mapping between clause 6 names and clause 8 assignments is unclear.

?This lack of clarity resulted in mapping tables, such as in 10.4.4.

o This mapping table essentially provides a short name for a subset of Status Code values.

o The danger (realized multiple times) is that people don’t realize this is the same

namespace as (in this case) the Status Code values, and groups allocate themselves

values independently from the Status Code table.

o This happened recently, and even the ANA misunderstood what was happening and allowed independent allocations from this subset namespace.

I believe the following fixups are necessary:

?Add a ―name‖ column to status code and result c ode tables.

?Remove any (Clause 10) mapping tables of short name to Status Code or Reason Code by merging their name columns into the status code or result code tables.

?Ensure that each enumeration value used in Clause 6 maps exactly onto the name field of a Clause 8 Status/Reason code table entry, adding new codes as necessary, or adding names to

existing entries where there is a clear correspondence.

?Replace any recent additions in Clause 6 that use the ―essay form‖ to refer to one of these codes with a shorter name, and add names to status/reason codes to support this as necessary. Submission page 2 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3 Ensure consistency between .confirm and .response by making the enumerated list of the .confirm contain all the values in the .response.

The Changes

Changes are specified relative to D7.03.

Change Table 8-35 as follows:

Table 8-35—Reason codes

Submission page 3 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

Submission page 4 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

Change Table 8-36 as follows:

Submission page 5 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

Submission page 6 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

Submission page 7 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3 Editor: Request the following new status codes from the ANA and add to above table with specified

10.4.4 TS setup

Change para 14 of 10.4.4 as follows and delete table 10-2.

The (#2243)HC’s MLME(#4050) transmits an ADDTS Response frame containing this TSPEC and status. The encoding of the ResultCode values to Status Code field values is defined inTable 8-36.

Table 10-2—

Submission page 8 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

10.4.9 TS deletion

Change 10.4.9 as follows:

There are two types of TS deletion: non-AP STA-initiated and HC-initiated. In both cases, the SME entity above the MAC generates an MLME-DELTS.request primitive specifying the TSID and direction of the TS to be deleted and the reason for deleting the TS. This causes the MAC to send a DELTS Action frame. The encoding of ReasonCode values to Reason Code field (see 8.4.1.7 (Reason Code field)) values is defined in Table 8-35..

Table 10-3—

Also merge entries from list above into enumerations in .request/.confirm in MLME-DELTS primitives.

10.5.2.3 Procedure at the recipient

Change 10.5.2.3 as follows:

A recipient shall operate as follows in order to support Block Ack initialization and modification:

a)When an ADDBA Request frame is received from another STA, the MLME shall issue an MLME-

ADDBA.indication primitive.

b)Upon receipt of the MLME-ADDBA.response primitive, the STA shall respond by an ADDBA Response

frame with a result code as defined in 8.5.5.3 (ADDBA Response frame format).(Ed)

1)If the result code is SUCCESS, the Block Ack is considered to be established with the originator.

Contained in the frame are the type of Block Ack and the number of buffers that have been allocated

for the support of this block.

2)If the result code is REFUSED, the Block Ack is not considered to have been established. Submission page 9 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

The encoding of ResultCode values to Status Code field values is defined inTable 8-36.

Table 10-4—

Also remove TIMEOUT from ADDBA.response enumeration.

10.5.3.2 Procedure at the initiator of the Block Ack teardown

Change 10.5.3.2 as follows:

Upon receipt of an MLME-DELBA.request primitive, the (#2243)(#3098)(#3121)MLME shall tear down the Block Ack using the following procedure:

a)The MLME(#3121) shall transmit a DELBA frame.

b)Upon the receipt of an acknowledgment to the DELBA frame, the MLME issues an MLME-

DELBA.confirm primitive.

The encoding of ReasonCode values to Reason Code field (see 8.4.1.7 (Reason Code field)) values is defined in Table 8-35. Add TIMEOUT to enumeration in DELBA.request

10.7.2.3 Setup procedure at the AP

Change 10.7.2.3 as follows:

Upon receipt of the DLS Request frame (step 1a in 错误！未找到引用源。), the AP shall

—Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not Allowed in the BSS, if direct links are not allowed in the BSS (step 2b in 错误！未找到引用源。), or for the AP with dot11SSPNInterfaceActivated set to true(Ed) with a result code of Not Allowed by SSP if the dot11NonAPStationAuthDls MIB variable in either of the non-AP STA’s dot11InterworkingTable is false.(11u)

—Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not Present, if the destination STA is not present in the BSS (step 2b in 错误！未找到引用源。).

—Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not a QoS(#1519) STA, if the destination STA does not have QoS facility (step 2b in 错误！未找到引用源。). Submission page 10 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

—Send the DLS Request frame, with all fields having the same value as the DLS Request frame received by the AP, to the destination STA (step 1b in 错误！未找到引用源。), independently of whether the AP is capable of decoding all of the fields in the body of the frame.(11n)

Upon receipt of the DLS Response frame from a STA (step 2a in 错误！未找到引用源。), the AP shall send DLS Response frame to the source STA (step 2b in 错误！未找到引用源。).

The mapping of Status Code field values to ResultCode parameter values in an MLME-DLS.confirm primitive is defined in Table 8-36. Delete TIMEOUT from DLS.confirm enumeration.

10.7.4.2 STA-initiated DLS teardown procedure

Change 10.7.4.2 as follows:

Upon receipt of MLME-DLSTeardown.request primitive from the SME, the STA shall initiate the -teardown of the direct link by sending the DLS Teardown frame to the AP. The applicable values of ReasonCode defined in ReasonCode values for DLS -teardown. The encoding of the Reason Code field is defined in Table 8-35.

Table 10-8—ReasonCode values for DLS -teardown

Merge entries from list above into DLSTeardown.request/.indication primitives.

10.24.3.1.3 STA procedures to post a GAS Query to an Advertisement Server(11u)

Change 10.24.3.1.3 as follows:

Submission page 11 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3 Upon receipt of a GAS Initial Request frame, an MLME-GAS.indication primitive shall be issued to the STA’s SME. Upon receipt of an MLME-GAS.response primitive, the STA shall transmit a GAS Initial Response frame to the requesting STA according to the following procedures. If the requesting STA is in the associated state and in the power-save mode, the responding STA shall buffer the frame for transmission according to the procedures in 错误！未找到引用源。; otherwise the STA shall queue the frame for transmission.

a)If the Advertisement Protocol ID in the Advertisement Protocol element does not equal the value contained

in any dot11GASAdvertisementID MIB object, then the STA shall not post the query to an Advertisement Server. The STA shall transmit a directed GAS Initial Response frame to the requesting STA containing a dialog token whose value is identical to the dialog token in the GAS Initial Request frame, a Status Code equal to ―GAS Advertisement Protocol not supported‖ (see Table 8-36), an Advertisement Protocol element containing the Advertisement Protocol ID used in the GAS Initial Request frame and a Comeback Delay and Query Response Length both set to 0.

Table 10-15—

Merge entries from table above into GAS and PDGAS .response/.confirm primitives.

Change any now dangling references in primitives to refer to appropriate (Status Code / Reason Code) table.

Changes to Clause 6 interfaces

Note, document 11-11-0284r2 proposes removal of the following .confirms (ignore the **). These primitives were not checked for the purpose of the current work:

1.DEAUTHENTICATE**

2.DEASSOCIATE **

3.RESET

4.START **

5.MREQUEST **

Submission page 12 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

6.MREPORT **

7.SETKEYS

8.DELETEKEYS

9.

10.SETPROTECTION

11.DELTS **

12.HL-SYNC

13.DELBA **

14.SCHEDULE

15.NEIGHBORREPREQ

16.MLME-REMOTE-REQUEST

17.TIMING_ADVERTISEMENT

18.TDLSSETUP-REQUEST

19.TDLSSETUP-RESPONSE

20.TDLSSETUP-CONFIRM

21.TDLSTEARDOWN

22.EVLREQUEST

23.EVVLREPORT

24.DIAGREQUEST

25.DIAGREPORT

26.CLINTERFERENCE REQUEST

27.CLINTERFERENCE RESPONSE

28.CLINTERFERENCE REPORT

29.TIMINGMSMTRQ

30.WNMNOTIFICATIONREQUEST

31.WNMNOTIFICATIONRESPONSE

Note also that the same document proposes removal of some locally-generated ResultCodes. This is not shown in the changes below.

Note that the following primitives follow a ―three primitives‖ pattern, and are not included in the list above - i.e. they have .request/.confirm/.indication, but no response. It is unclear from these primitives which of the ResultCodes should be locally generated (i.e. not requiring a supporting Status Code) and which are

remotely generated. I have taken no action on these primitives.

?DLS

?DLSTeardown

?SYNC

?TIMING_ADVERTISEMENT

?TIMINGMSMT

6.3.

7.5 MLME-ASSOCIATE.response

6.3.

7.5.2 Semantics of the service primitive

Change ResultCode enumeration as follows:

SUCCESS,

REFUSED_REASON_UNSPECIFIED,

REFUSED_CAPABILITIES_MISMATCH,

REFUSED_EXTERNAL_REASON,

REFUSED_AP_OUT_OF_MEMORY,

REFUSED_BASIC_RATES_MISMATCH,

REJECTED_EMERGENCY_SERVICES_-

NOT_SUPPORTED,(11u)

Submission page 13 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3 REFUSED_TEMPORARILY

And make matching change to the .confirm

And make matching changes to the REASSOCIATE primitives.

6.3.29.5 MLME-ADDBA.response

6.3.29.5.2 Semantics of the service primitive

Change the ResultCode enumeration as follows:

SUCCESS, REFUSED, INVALID_PARAMETERS

6.3.38.4 MLME-DSETPC.response(11y)

6.3.38.4.2 Semantics of the service primitive(11y)

Modify the .confirm parameter as follows: SUCCESS, INVALID_PARAMETERS, TIMEOUT, REFUSED

8.5.8.10 DSE Power Constraint frame format(11y)

Change para6 and Table 8-206 of 8.5.8.10 as follows:

The Reason Result Code field is used to indicate the reason that a DSE Power Constraint frame was generated. The length of the Reason Result Code field is 1 octet. The reason result codes that have been allocated are shown in Reason Result Code field values.

Table 8-206—Reason Result Code field

values

Submission page 14 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

This is as far as the 2011-03-14 meeting got. We did start on 8.5.8.4, but then time ran out.

6.3.39.4 MLME-ENABLEMENT.response(11y)

6.3.39.4.2 Semantics of the service primitive(11y)

Modify the ResultCode enumeration as follows:

SUCCESS, REFUSED, INVALID_PARAMETERS, TOO_MANY_SIMULTANEOUS_REQUESTS

8.5.8.4 DSE Enablement frame format(11y)

Modify Table 8-204 as follows:

The Reason Result Code field is used to indicate the reason that a DSE Enablement frame was generated. The length of the Reason Result Code field is 1 octet. The reason result codes that have been allocated are shown in Reason Result Code field values.

Table 8-204—Reason Result Code

field values

Submission page 15 Adrian Stephens, Intel Corporation

March 2011 doc.: IEEE 802.11-11/0316r3

6.3.64.3 MLME-TIMBROADCAST.confirm(11v)

6.3.64.3.2 Semantics of the service primitive(11v)

Discussion: The TimBroadcast Response element contains a status value, so the only valid values for the ResultCode parameter should be locally-generated statuses. There are no references in the text to the deleted ResultCodes, (i.e. there’s no obvious local generation of these codes) and there’s nowhere for them OTA.

Change the ResultCode enumeration as follows:

SUCCESS, TRANSMISSION_FAILURE

The same logic applies also to the following:

Make matching changes to the DMS.confirm primitive.

6.3.71.2 MLME-GAS.confirm(11u)

6.3.71.2.2 Semantics of the service primitive(11u)

If this is a timeout between the AP and some external entity providing a GAS response, then having this as a ResultCode is perfectly reasonable. However, the name is overly general in this case, as it confuses with the locally-generated TIMEOUT on many .confirms. In R1, TIMEOUT was renamed GAS_QUERY_TIMEOUT.

However, if it is intended to reflect a locally generated status, then TIMOUT is appropriate, and the status code 62 should be released as this doesn’t appear on air.

Change the ResultCode enumeration as follows:

SUCCESS, GAS_QUERY_TIMEOUT,

UNSPECIFIED_FAILURE,

ADVERTISEMENT_PROTOCOL_NOT_SUPPORTED,

Submission page 16 Adrian Stephens, Intel Corporation

本文来源：https://www.bwwdw.com/article/jbdl.html