Submission Note: BEGIN Lists of Comments Affected by This Document

November 2006 doc.: IEEE 802.11-06/1345r810

IEEE P802.11 Wireless LANs

LB84-CID-1264-text-proposal

Date: 11 November 2006

Author(s): Name Company Address Phone email Matthew 190 Mathilda Place, Sunnyvale, Broadcom 1 408 543 3370 mfischer@broadcom. Fischer CA 94086 com Solomon POB 1659, Haifa 31015, Israel +97248655738 solomon.trainin Intel Corporation Trainin @intel.com Leonid Metalink Yakum Business Park, 60972, +972 9 960 5442 leonide@metalin Epstein Israel kbb.com

Abstract This document includes proposed text for modification of the TGn 1.05 draft. The text is intended to provide a resolution for CID 3423, 3831, 2449, 5834, 8960, 11513, 11973, 1274, 8246, 1288, 1275, 1276, 1278, 1279, 1280, 6777, 6779, 6778, 1264, 1269 and 1273 from LB84. CID 1264 raises questions regarding the equivalence and maintainence of the Winstart variable within the RX reordering buffer function and the Winstart variable within the block ack bitmap function, generally discussed within subclauses 9.10.7. Many of the other comments express similar questions regarding the arrangement, completeness and meaning of 9.10.7. In addition, adoption of this document will modify the previously adopted resolutions of the following technical comments: 2468, 5853, 8979, 11527, 3827, 4765, 3830, 1286, 1289, 2470, 5855, 8981, 11531, 778 and the previously adopted resolutions of the following editorial comments: 1262, 2448, 5833, 8959, 11520, 1263, 1270, 2465, 5850, 8976, 11526, 2477, 5862, 8988, 11534, 5851, 8977, 11525, 2467, 5852, 8978, 11524, 78, 2471, 5856, 8982, 11532, 2478, 5863, 8989, 11538, 2472, 5857, 8983, 11530, 11972, 9987, 10179, 2474, 5859, 8985, 11535, 862, 1766, 2475, 4304, 4323, 5860, 8986, 9986, 10178, 11533, 12237, 3829, 7257, 853, 74, 2445, 2446, 5830, 5831, 8956, 8957, 11516, 11523, 1260, 1261, 2447, 5832, 8958, 11517, 79, 2476, 5861, 8987, 11537, 81, 2481, 5866, 8992, 11542, 854, 3824

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 , 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at . Submission page 1 Matthew Fischer, Broadcom November 2006 doc.: IEEE 802.11-06/1345r810

Submission Note: BEGIN lists of comments affected by this document.

Technical comments whose previously adopted resolutions are modified by the adoption of this document:

In page, clause, line order: 2468, 5853, 8979, 11527, 3827, 4765, 3830, 1286, 1289, 2470, 5855, 8981, 11531, 778

In CID order: 778, 1286, 1289, 2468, 2470, 3827, 3830, 4765, 5853, 5855, 8979, 8981, 11527, 11531

Technical comments that had a resolution status of deferred, that are resolved by the adoption of this document:

In page, clause, line order: 3423, 3831, 2449, 5834, 8960, 11513, 11973, 1274, 8246, 1288, 1275, 1276, 1278, 1279, 1280, 6777, 6779, 6778, 1264, 1269, 1273

In CID order: 1264, 1269, 1273, 1274, 1275, 1276, 1278, 1279, 1280, 1288, 2449, 3423, 3831, 5834, 6777, 6778, 6779, 8246, 8960, 11513, 11973

Editorial comments whose previously adopted resolutions are modified by the adoption of this document:

In page, clause, line order: 1262, 2448, 5833, 8959, 11520, 1263, 1270, 2465, 5850, 8976, 11526, 2477, 5862, 8988, 11534, 5851, 8977, 11525, 2467, 5852, 8978, 11524, 78, 2471, 5856, 8982, 11532, 2478, 5863, 8989, 11538, 2472, 5857, 8983, 11530, 11972, 9987, 10179, 2474, 5859, 8985, 11535, 862, 1766, 2475, 4304, 4323, 5860, 8986, 9986, 10178, 11533, 12237, 3829, 7257, 853, 74, 2445, 2446, 5830, 5831, 8956, 8957, 11516, 11523, 1260, 1261, 2447, 5832, 8958, 11517, 79, 2476, 5861, 8987, 11537, 81, 2481, 5866, 8992, 11542, 854, 3824

In CID order: 74, 78, 79, 81, 853, 854, 862, 1260, 1261, 1262, 1263, 1270, 1766, 2445, 2446, 2447, 2448, 2465, 2467, 2471, 2472, 2474, 2475, 2476, 2477, 2478, 2481, 3824, 3829, 4304, 4323, 5830, 5831, 5832, 5833, 5850, 5851, 5852, 5856, 5857, 5859, 5860, 5861, 5862, 5863, 5866, 7257, 8956, 8957, 8958, 8959, 8976, 8977, 8978, 8982, 8983, 8985, 8986, 8987, 8988, 8989, 8992, 9986, 9987, 10178, 10179, 11516, 11517, 11520, 11523, 11524, 11525, 11526, 11530, 11532, 11533, 11534, 11535, 11537, 11538, 11542, 11972, 12237

DOCUMENT 11-06-1649-01-000n-lb84-resolutions-per-doc-11-06-1345.xls CONTAINS THE PROPOSED RESOLUTIONS FOR EACH OF THE ABOVE COMMENTS.

Submission Note: END a lists of comments affected by this document.

Submission page 2 Matthew Fischer, Broadcom November 2006 doc.: IEEE 802.11-06/1345r810

CID 2449 (C), 3423 (C)

The proposed resolution for each of these two comments is:

The text of this subclause has been modified and there currently are no normative statements (i.e. statements containing any of the normative words “shall,” “should,” or “may,”) and therefore, it is clear that the subclause is informative. CID 1264 (A), 1269 (A), 6777 (A), 1272 (A), 6778 (C), 11973 (A), 1274 (A), 1273 (A), 1275 (A), 1276 (A), 1278 (A), 3831 (A), 1279 (A), 6779 (C), 1280 (A), 1288 (A)

TGn Editor: Insert, before the subclause heading “7.3.2 Information Elements” on page 38 at line 10 of TGn D1.05, the following editor instruction and text:

Change footnote 19 as follows:

19 For buffer size, the recipient of data advertises a single scalar number that is the number of maximum- size fragment buffers available for the BlockAck agreement that is being negotiated. Every buffered MPDU that is associated with this BlockAck agreement will consume one of these buffers regardless of whether the frame contains a whole MSDU, A-MSDU or a fragment of an MSDUthereof. In other words For example, ten maximum-sized unfragemented MSDUs will consume the same amount of buffer space at the recipient as ten small er fragments of a single MSDU of maximum size .

TGn Editor: Change the first non-editor instruction paragraph of 9.10.2 “Setup and modification of the Block Ack parameters”, on page 100, near line 54, of TGn D1.05, by changing the sentence within that paragraph which begins “When the STA accepts, it indicates the type of Block Ack”, and adding an additional sentence to immediately follow the cited one, as follows:

When the STA accepts, it indicates the type of Block Ack and the number of buffers that it shall allocate for the support of this Bblock Ack agreement within the ADDBA response frame. Each Block Ack agreement that is established by a STA may have a different buffer allocation.

TGn Editor: Insert, on page 100, near line 60, of TGn D1.05, before the text “9.10.4 Receive buffer operation” the following new subclause header, editor instruction and text:

9.10.3 Data and acknowledgement transfer

Insert, within subclause “9.10.3 Data and acknowledgement transfer”, after the paragraph which begins with “The BlockAck frame contains acknowledgements” and preceding the paragraph which begins with “A typical BlockAck frame exchange sequence” the following text as a new paragraph:

The Starting Sequence Number field of the BlockAck frame shall equal the value extracted from the Starting Sequence Number field from the BlockAckReq frame to which it is a response.

TGn Editor: Change the last sentence of the last paragraph of subclause “9.10.7.2 BlockAck extension architecture” on page 102 near line 54 of TGn D1.05 as follows:

Each received MPDU is analyzed by the scoreboard context control, as well as by the Rx reordering buffer control.

TGn Editor: Insert the following paragraph as the new last paragraph of subclause “9.10.7.2 BlockAck extension architecture” which begins on page 101 of TGn D1.05, with the insertion occurring near the end of page 102 of TGn D1.05.

Each HT-immediate BlockAck agreement is uniquely identified by a tuple of Address1, Address2 and TID from the ADDBA response frame that successfully established the HT-immediate BlockAck agreement. The STA that corresponds to Address1 of the ADDBA response frame is the originator. The STA that corresponds to Address2 of the ADDBA response frame is the recipient. Data MPDUs which contain the same values for Address1, Address2 and TID as a successful ADDBA response frame are related with the HT-immediate BlockAck agreement which was established by the successful receipt of that ADDBA response frame provided that the HT-immediate BlockAck agreement is still active.

TGn Editor: Change each occurrence of “WinStart” to “WinStart_O” within text of subclause “9.10.7.2 BlockAck extension architecture” which begins on page 101 of TGn D1.05.

TGn Editor: Change each occurrence of “WinSize” to “WinSize_O” within subclause “9.10.7.2 BlockAck extension architecture” which begins on page 101 of TGn D1.05.

TGn Editor: Change in the Figure n35 HT-immediate BlockAck architecture within subclause “9.10.7.2 BlockAck extension architecture” which begins on page 101 of TGn D1.05 “Tx Buffers Control per RA/TID (WinStart, WinSize)” to “Tx Buffers Control per RA/TID (WinStart_O, WinSize_O)”and “Rx Reodering Buffer Control per TA/TID (WinStart, WinSize)” to “Rx Reodering Buffer Control per TA/TID (WinStart_B, WinSize_B)”, and “Scoreboard Context Control (WinStart, WinSize)”to “Scoreboard Context Control (WinStart_R, WinSize_R)”

TGn Editor: Change the text beginning with “For HT-immediate BlockAck agreements, the recipient” which occurs on page 102 at about line 44, within subclause “9.10.7.2 BlockAck extension architecture” of TGn D1.05 as follows:

For each HT-immediate BlockAck agreements, the recipient chooses either full state or partial state operation (this is known only to the recipient). A STA may simultaneously use full state operation for some agreements and partial state operation for other agreements. The Scoreboard Context Control stores an acknowledgement bitmap plus the current context of the bitmap for eachper established HT-immediate BlockAck agreement under full state operation or the current

Submission page 4 Matthew Fischer, Broadcom November 2006 doc.: IEEE 802.11-06/1345r810 context of the acknowledgement bitmap under partial state operation. This entity provides the bitmap and the value for the Sstarting Ssequence Nnumber (SSN) field to be sent in BlockAck responses to the Originator.

TGn Editor: Delete all of the text of subclause “9.10.7.3 Scoreboard context control in full state” which begins on page 102 of TGn D1.05 and change the header to appear as follows:

9.10.7.3 Scoreboard context control in during full state operation

TGn Editor: Insert the following text to appear as the new text for subclause “9.10.7.3 Scoreboard context control during full state operation” beginning on page 102 of TGn D1.05:

For each HT-immediate BlockAck agreement that uses full state operation, a recipient STA shall maintain a block acknowledgement record as defined in 9.10.3. This record includes a bitmap, indexed by sequence number (SN), a 12-bit unsigned integer starting sequence number WinStart_R representing the lowest SN position in the bitmap, a variable WinEnd_R and the maximum Transmission Window size, WinSize_R, which is set to the value of the Buffer Size subfield of the associated ADDBA response frame that established the BlockAck agreement. WinEnd_R is defined as the highest SN in the current Transmission Window. A STA implementing full state operation for an HT-immediate BlockAck agreement shall maintain the block acknowledgement record for that agreement according to the following rules:

At HT-immediate BlockAck agreement establishment:

WinStart_R = SSN from the ADDBA request frame that elicited the ADDBA response frame that established the HT-immediate BlockAck agreement WinEnd_R = WinStart_R + WinSize_R -1.

For each received data MPDU that is related with a specific full-state operation HT-immediate BlockAck agreement, the block acknowledgement record for that agreement is modified as follows, where SN is the value of the Sequence Number field of the received data MPDU:

— If WinStart_R <= SN <= WinEnd_R o set to one the bit in position SN within the bitmap

— If WinEnd_R < SN < WinStart_R + 2^11 o reset to zero bits corresponding to MPDUs with Sequence Number field values from WinEnd_R+1 to SN - 1 o set WinStart_R = SN - WinSize_R + 1 o set WinEnd_R = SN o set to one, the bit at position SN in the bitmap

— If WinStart_R + 2^11 <= SN < WinStart_R o Make no changes to the record

Note that a later-arriving data MPDU may validly contain a SN that is lower than an earlier- arriving one. This can happen because the transmitter may choose to send data MPDUs in a non- sequential SN order or because a previous data MPDU transmission with lower SN is not successful and is being retransmitted. Submission page 5 Matthew Fischer, Broadcom November 2006 doc.: IEEE 802.11-06/1345r810

For each received Block Ack Request frame that is related with a specific full-state operation HT-immediate BlockAck agreement, the block acknowledgement record for that agreement is modified as follows, where SSN is the value from the Starting Sequence Number field of the received Block Ack Request frame:

— If WinStart_R <= SSN <= WinEnd_R o set WinStart_R = SSN o reset to zero bits corresponding to MPDUs with Sequence Number field values from WinEnd_R + 1 through WinStart_R + WinSize_R – 1 inclusive o set WinEnd_R = WinStart_R + WinSize_R – 1.

— If WinEnd_R < SSN < WinStart_R + 2^11 o set WinStart_R = SSN o set WinEnd_R = WinStart_R + WinSize_R - 1 o reset to zero bits corresponding to MPDU with Sequence Number field values from WinStart_R to WinEnd_R

— If WinStart_R + 2^11 <= SSN < WinStart_R o Make no changes to the record

Comparisons in the above inequalities are circular modulo 2^12.

TGn Editor: Delete all of the text of subclause “9.10.7.4 Scoreboard context control in partial state” which begins on page 103, near line 16 of TGn D1.05 but leave the header.

TGn Editor: Change the header of subclause “9.10.7.4 Scoreboard context control in partial state” which begins on page 103 near line 16 of TGn D1.05 as follows:

9.10.7.4 Scoreboard context control in during partial state operation

TGn Editor: Insert into subclause “9.10.7.4 Scoreboard context control in partial state” which begins on page 103 near line 16 of TGn D1.05 the following text:

For an HT-immediate BlockAck agreement that uses partial state operation, a recipient STA shall maintain a temporary block acknowledgement record as defined in 9.10.3. This temporary record includes a bitmap, indexed by sequence number (SN), a 12-bit unsigned integer starting sequence number WinStart_R (the lowest SN represented in the bitmap), a variable WinEnd_R (the highest SN in the bitmap), the originator address, TID and the maximum Transmission Window size, WinSize_R, which is set to the value of the Buffer Size subfield of the associated ADDBA Response frame that established the BlockAck agreement. During partial state operation of scoreboard context control the recipient retains the current record for an HT- immediate BlockAck agreement at least as long as it receives data from the same originator. If a frame for an HT-immediate BlockAck agreement from a different originator is received, then the temporary record may be discarded if the resources that its existence requires are needed to store the temporary record corresponding to the newly arriving frame. Memory management is made easier if all Block Ack agreements use the same Buffer Size because the memory allocated for one Block Ack agreement that uses partial state operation might be re-used for a different Block Submission page 6 Matthew Fischer, Broadcom November 2006 doc.: IEEE 802.11-06/1345r810

Ack agreement at a later time, however, there are no restrictions on the Buffer Size allocation for different Block Ack agreements.

A STA implementing partial state operation for an HT-immediate BlockAck agreement shall maintain the temporary block acknowledgement record for that agreement according to the following rules:

During partial state operation, WinStart_R is determined by the Sequence Number field value (SN) of received data MPDUs and by the Starting Sequence Number field value (SSN) of received Block Ack Request frames as described below.

For each received data MPDU that is related with a specific partial-state operation HT- immediate BlockAck agreement, when no temporary record for the agreement related with the received data MPDU exists at the time of receipt of the data MPDU, a temporary block acknowledgement record is created as follows, where SN is the value of the Sequence Number field of the received data MPDU:

- WinEnd_R = SN from the received data MPDU. - WinStart_R = WinEnd_R - WinSize_R + 1. - Create a bitmap of size WinSize_R, with the first bit corresponding to sequence number WinStart_R and the last bit corresponding to sequence number WinEnd_R, setting all bits in the bitmap to “0” - Set to one the bit in the position in the bitmap which corresponds to SN.

For each received data MPDU that is related with a specific partial-state operation HT- immediate BlockAck agreement, when a temporary record for the agreement related with the received data MPDU exists at the time of receipt of the data MPDU, the temporary block acknowledgement record for that agreement is modified in the same manner as the acknowledgement record for a full-state agreement described in subclause 9.10.7.3 Scoreboard context control during full-state operation.

For each received Block Ack Request frame that is related with a specific partial-state operation HT-immediate BlockAck agreement, when no temporary record for the agreement related with the received frame exists at the time of receipt of the frame, a temporary block acknowledgement record is created as follows, where SSN is the starting value of the Sequence Number field of the received BlockAckReq frame:

- WinStart_R = SSN from the received BlockAckReq frame - WinEnd_R = WinStart_R + WinSize_R -1. - Create a bitmap of size WinSize_R, setting all bits in the bitmap to “0”

For each received BlockAckReq frame that is related with a specific partial-state operation HT- immediate BlockAck agreement, when a temporary record for the agreement related with the received frame exists at the time of receipt of the frame, the temporary block acknowledgement record for that agreement is modified in the same manner as the acknowledgement record for a full-state agreement described in subclause 9.10.7.3 Scoreboard context control during full-state operation.

TGn Editor: Change, on page 103, near line 50, the title of subclause “9.10.7.5 Scoreboard context control of BlockAck” of TGn D1.05 to “9.10.7.5 Generation and transmission of BlockAck during partial-state operation and full-state operation”

TGn Editor: Delete, on page 103, near line 56, the sentence: “Insert the following new subclause” and delete the subclause header “9.10.7.6 Scoreboard context control of BlockAckReq” of TGn D1.05, adjusting the subsequent heading numbering as appropriate.

TGn Editor: Change, on page 103, near line 50, subclause “9.10.7.5 Scoreboard context control of BlockAck” now renamed to “9.10.7.5 Generation and transmission of BlockAck during partial-state operation and full-state operation” of TGn D1.05, the text as follows:

The WinStart is used as The Starting Sequence Number field of the Block Ack Starting Sequence Control field of a BlockAck frame that is sent inthe SSN when it is necessary to transmit a BlockAck as response to an A-MPDU containing one or more QoS Data MPDUs with Ack-Policy = set to the value “Normal ACK” shall be set to any circular modulo 2^12 value in range from (WinEnd - 64) to WinStart_R inclusive..

TGn Editor: Insert, on page 104, near line 1, within subclause “9.10.7.5 Scoreboard context control of BlockAck” now renamed to “9.10.7.5 Generation and transmission of BlockAck during partial-state operation and full-state operation” of TGn D1.05, after the first paragraph of this subclause, which begins with “Under HT-immediate BlockAck”, the following paragraph:

When responding with a BlockAck frame to a received BlockAckReq frame during either full-state operation or partial state operation, any adjustment to the value of WinStart_R according to the procedures defined within 9.10.7.3 Scoreboard context control in full state and 9.10.7.4 Scoreboard context control in partial state shall be performed before the generation and transmission of the response BlockAck frame. The Starting Sequence Number of the Block Ack Starting Sequence Control field of the BlockAck frame shall be set to the Starting Sequence Number of the received BlockAckReq frame. Within the Block Ack frame, the reported status of MPDUs with sequence numbers greater than or equal to the adjusted value of WinStart_R shall be copied from the recipient’s bitmap record of status of MPDUs for both full-state operation and partial-state operation.

TGn Editor: Change, on page 104, near line 1, within subclause “9.10.7.5 Scoreboard context control of BlockAck” now renamed to “9.10.7.5 Generation and transmission of BlockAck during partial-state operation and full-state operation” of TGn D1.05, the second paragraph of this subclause, which begins with “The status of MPDUs that are lower than WinStart” to appear as follows:

When responding with a BlockAck frame to a received BlockAckReq frame during either full-state or partial-state operation, if the adjusted value of WinStart_R is greater than the value of the SSN of the BlockAckReq frame, then within the bitmap of the BlockAck frame, tThe status of MPDUs that are lower with sequence numbers that are less than the adjusted value of WinStart_R (using a circular modulo 2^12 comparison) shall be reported as successfully received (i.e., the corresponding bit in the bitmap shall be set to 1).

TGn Editor: Insert, on page 104, near line 1, within subclause “9.10.7.5 Scoreboard context control of BlockAck” now renamed to “9.10.7.5 Generation and transmission of BlockAck during partial-state operation and full-state operation” of TGn D1.05, before the third paragraph of this subclause, which begins with “WinStart is set to the SSN” the following text:

When responding with a BlockAck frame to a received A-MPDU with ACK Policy set to Normal Ack (i.e. implicit Block Ack request) during either full-state operation or partial-state operation, the Starting Sequence Number of the Block Ack Starting Sequence Control field of the BlockAck frame shall be set to WinStart_R. The status of MPDUs for which the Sequence Number field value is less than the value of WinStart_R (using a circular modulo 2^12 comparison) are not reported in the BlockAck frame. The values in the recipient’s bitmap record of status of MPDUs beginning with the MPDU for which the Sequence Number field value is equal to WinStart_R shall be used to generate the entire bitmap of the BlockAck frame.

TGn Editor: Delete, on page 104, near line 5, of TGn D1.05, the text “WinStart is set to the SSN from BlockAckReq.”

TGn Editor: Delete, on page 104, near line 16, all of the contents of subclause “9.10.7.7. Rx reordering buffer control” of TGn D1.05.

TGn Editor: Insert, on page 104, near line 16, the following text to become the new contents of subclause “9.10.7.7. Rx reordering buffer control” of TGn D1.05, as shown:

The following behavior applies to STA which use either partial state operation or full state operation for an HT-immediate BlockAck agreement.

An RX reordering buffer shall be maintained for each HT-immediate BlockAck agreement. Each RX reordering buffer includes a record comprising:

1. buffered MSDUs which have been received, but not yet passed up the MAC artchitecture stack 2. a WinStart_B parameter, indicating the value of the Sequence Number field (SN) of the next-in-sequence expected-but-not-yet-received MSDU 3. a WinEnd_B parameter, indicating the highest SN expected to be received in the current reception window 4. a WinSize_B parameter, indicating the size of the reception window

WinStart_B is initialized to the Starting Sequence Number field value (SSN) of the ADDBA request frame that elicited the ADDBA response frame that established the HT-immediate BlockAck agreement.

WinEnd_B is initialized to WinStart_B + WinSize_B – 1, where WinSize_B is set to the value of the Buffer Size subfield of the ADDBA Response frame that established the BlockAck agreement.

For each received data MPDU that is related with a specific HT-immediate BlockAck agreement, the RX reordering buffer record is modified as follows, where SN is the value of the Sequence Number field of the received MPDU:

— If WinStart_B <= SN <= WinEnd_B o Store the received MPDU in the buffer o Pass MSDUs up the MAC architecture stack that are stored in the buffer in order of increasing value of the Sequence Number field starting with the MSDU that has SN=WinStart_B and proceeding sequentially until there is no buffered MSDU for the next sequential value of the Sequence Number field. o Set WinStart_B to the value of the Sequence Number field of the last MSDU that was passed up the MAC architecture stack plus one o Set WinEnd_B = WinStart_B + WinSize – 1

— If WinEnd_B < SN < WinStart_B + 2^11 o Store the received MPDU in the buffer o set WinEnd_B = SN o set WinStart_B = WinEnd_B – WinSize_B + 1 o Any complete MSDUs stored in the buffer with Sequence Number field values that are lower than the new value of WinStart_B are passed up the MAC architecture stack in order of increasing Sequence Number field value. Gaps may exist in the Sequence Number field values of the MSDUs that are passed up the MAC architecture stack. o MSDUs stored in the buffer shall be passed up the MAC architecture stack in order of increasing value of the Sequence Number field starting with SN=WinStart_B and proceeding sequentially until there is no buffered MSDU for the next sequential Sequence Number field value o Set WinStart_B to the Sequence Number field value (SN) of the last MSDU that was passed up the MAC architecture stack plus one o Set WinEnd_B = WinStart_B + WinSize_B – 1

— If WinStart_B + 2^11 <= SN < WinStart_B o Discard the MPDU, do not store the MPDU in the buffer, do not pass the MSDU up the MAC architecture stack

For each received Block Ack Request frame that is related with a specific HT-immediate BlockAck agreement, the RX reordering buffer record is modified as follows, where SSN is the Starting Sequence Number field value of the received Block Ack Request frame:

— If WinStart_B < SSN < WinStart_B + 2^11 o set WinStart_B = SSN o set WinEnd_B = WinStart_B + WinSize_B - 1 o Any complete MSDUs stored in the buffer with Sequence Number field values that are lower than the new value of WinStart_B shall be passed up the MAC architecture stack in order of increasing Sequence Number field value. Gaps may exist in the Sequence Number field values of the MSDUs that are passed up the MAC architecture stack. o MSDUs stored in the buffer shall be passed up the MAC architecture stack in order of increasing Sequence Number field value starting with SN=WinStart_B and proceeding sequentially until there is no buffered MSDU for the next sequential Sequence Number field value.

o Set WinStart_B to the Sequence Number field value (SN) of the last MSDU that was passed up the MAC architecture stack plus one o Set WinEnd_B = WinStart_B + WinSize_B – 1

— If WinStart_B + 2^11 <= SSN < WinStart_B o Do not make any changes to the RX reordering buffer record

Any MSDU that has been passed up the MAC architecture stack shall be deleted from the RX reordering buffer.

The recipient shall always pass MSDUs up the MAC architecture stack in order of increasing Sequence Number field value.

TGn Editor: Change on page 104, near line 47, subclause “9.10.7.8 Originator’s behavior” of TGn D1.05, the phrase “makes it through” to “is received without error.”

TGn Editor: Change on page 104, near line 54, subclause “9.10.7.8 Originator’s behavior” of TGn D1.05, the phrase “solicit immediate” to “solicit an immediate”

TGn Editor: Change on page 104, near line 60, subclause “9.10.7.8 Originator’s behavior” of TGn D1.05, the phrase “is to shift” to “in this case, is to shift”

TGn Editor: Insert on page 105, near line 5, subclause “9.10.7.8 Originator’s behavior” of TGn D1.05, at the end of the subclause,” after the paragraph that begins with “All frames within an A-MPDU shall”, the following text as three new paragraphs:

The originator may transmit any MPDU within the current transmission window in any order. However, except for retransmissions, the originator should attempt to maintain a sequentially increasing Sequence Number field value (SN) order of MPDUs for transmission. The originator may transmit an MPDU with an SN that is beyond the current transmission window (SN > WinEnd_O), in which case the orginator’s transmission window (and the recipient’s window) will be moved forward. The originator should not transmit MPDUs which are “lower” than (SN < WinStart_O) the current transmission window.

The originator should may send a BlockAckReq when a data MPDU that was previously transmitted within an A-MPDU that had the Ack Policy field set to Normal Ack is discarded due to exhausted MSDULifetime. The purpose of this BlockAckReq is to shift the recipient’s WinStart_B value past the hole in the SN space that is created by the discarded data MPDU and to thereby allow the earliest possible forwarding of buffered frames up the MAC protocol stack.

Comparisons in the above paragraph are circular modulo 2^12.

TGn Editor: Change on page 105, near line 17, subclause “9.10.7.9 Maintaining the BlockAck state at the originator” of TGn D1.05, the sentence that begins with “Not update the status of MPDUs with sequence numbers” as follows:

Not update the status of MPDUs with Ssequence Nnumber field values between WinStart_O and SSN of the received BlockAck. Note that it is possible for the Starting Sequence Number field value (SSN) of the received BlockAck to be greater than WinStart_O because of the failed reception of a non-zero number of MPDUs beginning with the MPDU with Sequence Number field value equal to WinStart_O at a recipient STA which is using partial state operation.

TGn Editor: Change on page 105, near line 24, the contents and header of subclause “9.10.7.10 Originator’s spport of recipient’s partial state” as follows:

9.10.7.10 Originator’s support of recipient STAs’s partial state operation

A recipient may choose to employ either full state operation or partial state operation for each individual Block Ack agreement. An originator is unaware of the recipient STA’s choice of full state or partial state operation. In order to maximize the throughput when communicating with STAs that have chosen to employ partial state operation, tThe originator should solicit a BlockAck as the last activity associated with that Block Ack agreement in the current TXOP.

References:

Submission page 13 Matthew Fischer, Broadcom