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 …… 此处隐藏：12216字，全部文档内容请下载后查看。喜欢就下载吧 ……