September 2006
doc.: IEEE 802.11-06/1345r89
IEEE P802.11
Wireless LANs
LB84-CID-1264-text-proposal
Date: 9 November 2006
Author(s):
Name
Matthew
Fischer
Solomon
Trainin
Leonid
Epstein
Company
Broadcom
Intel Corporation
Metalink
Address
190 Mathilda Place, Sunnyvale,
CA 94086
POB 1659, Haifa 31015, Israel
Yakum Business Park, 60972,
Israel
Phone
email
1 408 543 3370
mfischer@broadcom.
com
+97248655738
solomon.trainin
@intel.com
leonide@metalin
kbb.com
+972 9 960 5442
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 <http://
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
<[email protected]> 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 <[email protected]>.
Submission
page 1
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
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-xxxx-00-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
September 2006
doc.: IEEE 802.11-06/1345r89
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 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. For example, ten
maximum-sized unfragemented MSDUs will consume the same amount of buffer space at the recipient as
ten smaller 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 Block 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
Submission
page 3
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
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 agreement, 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
each established HT-immediate BlockAck agreement under full state operation or the current
Submission
page 4
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
context of the acknowledgement bitmap under partial state operation. This entity provides the
bitmap and the value for the Starting Sequence Number (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 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 earlierarriving one. This can happen because the transmitter may choose to send data MPDUs in a nonsequential 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
September 2006
doc.: IEEE 802.11-06/1345r89
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 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 HTimmediate 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
September 2006
doc.: IEEE 802.11-06/1345r89
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 HTimmediate 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 HTimmediate 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 HTimmediate 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.
Comparisons in the above inequalities are circular modulo 2^12.
Submission
page 7
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
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 Starting Sequence Number field of the Block Ack Starting Sequence Control field of a BlockAck
frame that is sent in 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 WinStart_R.
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, the status of MPDUs 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:
Submission
page 8
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
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
Submission
page 9
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
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
Submission
page 10
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
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.
Comparisons in the above inequalities are circular modulo 2^12.
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 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 Sequence Number 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.
Submission
page 11
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
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, the originator should solicit a BlockAck
as the last activity associated with that Block Ack agreement in the current TXOP.
Submission
page 12
Matthew Fischer, Broadcom
September 2006
doc.: IEEE 802.11-06/1345r89
References:
Submission
page 13
Matthew Fischer, Broadcom