August 2004 doc.: IEEE 802.11-04/0897r0doc.: IEEE 802.11-04/xxxr0
IEEE P802.11
Wireless LANs
ST Microelectronics Media Access Control (MAC) Proposal for IEEE 802.11 TGn High Troughput Standard
Date: August 15, 2004
Authors: Liwen Chu, Valerio FilauroGabriella Convertino, Mike Moreton, Andrea Palmieri, Vincenzo Scarpa, Antonio Vilei and George Vlantis
STMicroelectronics, N.V.
Headquarters: 39, Chemin du Champs des Filles, 1228 Plan-les-Ouates, Geneva, Switzerland San Jose Office: 1060 East Brokaw Road, San Jose, CA 95131-2309
Phone: +1 (408) 451 8109
Fax: +1 (408) 451 0278
e-Mail: {Lliwen.Cchu, Ggabriella.Cconvertino, mike.moreton, andrea.palmieri,Valerio.Filauro, Fabio.Osnato, Massimiliano.Siti, Vvincenzo.Sscarpa, antonio.vilei, Ggeorge.Vvlantis}@STst.com
Abstract
Mandatory and optional enhancements to the IEEE Std. 802.11-1999 (Reaff 2003) as amended by 802.11e (draft 9.0) are provided to describe 802.11n MAC operation in 5 key areas:
§ Mandatory EDCA, Block ACK with optional HCCA and DLP.
§ Enhanced Block Acknowledgement (EBA) with reduced or zero IFS MSDU frame aggregation
§ Enhanced Block Acknowledge with reduced IFSMSDU frame aggregation
§ TxOP Piggybacking
§ Low-Collision EDCA (AP-coordinated “super-frame” mode and distributed “neighbor-list mode)
N.1 MAC Enhancements
N.1.1 802.11e Features
To meet the QOS requirements of the Usage Models [2] and to satisfy the 100Mbps minimal goodput at the MAC SAP in the Functional Requirements [3], we propose to use many 802.11e features in the 802.11n MAC. The features which shall be mandatory are Enhanced Distributed Channel Access (EDCA) and Block Acknowledge. The Direct Link Protocol (DLP) and Hybrid Coordination Channel Access (HCCA) features shall be optional. Reference [1] gives the definitions of these features.
N.1.1.1 EDCA
EDCA provides differentiated, distributed access to the Wireless Medium (WM) for STAs using 8 User Priorities (UPs) and four Access Categories (ACs). This differentiation is achieved through varying the amount of time a STA senses the channel to be idle before backoff or transmission, varying the length of the contention window (CW) to be used for the backoff, and/or varying the duration a station may transmit after it acquires channel access.
Reference [1] 7.3.2.14 gives the definitions of the EDCA Parameter Set element. definition. Reference [1] 9.9.1 defines the EDCA operation procedure. EDCA is mandatory.
N.1.1.2 Direct Link Protocol (DLP)
The DLP mechanism provides direct communication between two non-AP STAs in an infrastructure BSS without an AP’s relay. The DLP negotiation process is required to make sure the receiver is not in power saving mode and to exchange necessary information (rate etc.) between sender and receiver. Figure 28 and figure 29 illustrate the DLP set-up and teardown processes. DLP is optional.
Reference [1] 7.3.1.13 gives the definition of DLP Timeout Value. Reference [1] 7.4.3 gives the definitions of DLP action frames which include DLP request, DLP response and DLP Teardown. Reference [1] 10.3.12 defines the DLP service provided by MLME to SME to manage DLP. These include MLME-DLP.request, MLME-DLP.confirm, MLME-DLP.indication, MLME-DLP.teardown.request, MLME-DLP.teardown.confirm, and MLME-DLP.teardown.indication. Reference [1] 11.7 defines the DLP operation procedure.
N.1.1.1.2 Enhanced Block Acknowledgement (EBA) (i.e. block ack with reduced or zero IFS)
Reference [1] 7.2.1.7 and 7.2.1.8 give the definitions of BlockAckReq and BlockAck frames. Reference [1] 7.3.1.14, 7.3.1.15 and 7.3.1.16 give the definitions of Block Ack Parameter Set field, Block Ack Timeout Value and DELBA Parameter Set field. Reference [1] 7.4.4 gives the definitions of Block Ack action frames which include ADDBA request, ADDBA response and DELBA. Reference [1] 9.10 defines the Block Ack MAC layer function. Reference [1] 10.3.14 defines the Block Ack service provided by the MAC sublayer management entity (MLME) to the STA management entity (SME) to manage Block Ack. These include MLME-ADDBA.request, MLME-ADDBA.confirm, MLME-ADDBA.indication, MLME-ADDBA.response, MLME-DELBA.request, MLME-DELBA.confirm, and MLME-DELBA.indication. Reference [1] 11.7 defines the DELBA operation procedure.
Figure 24 illustrates the Block Ack set-up process. Figure 25 illustrates the Block Ack teardown process.
There are two kinds of Block Ack policies: Immediate Ack and Delayed Ack.
N.1.2.1 Immediate ACK
Figure 26 illustrates a typical immediate Ack frame exchange sequence. The recipient shall respond to a BlockAckReq frame with a BlockAck frame if the immediate Block Ack policy is used.
N.1.2.2 Delayed ACK
Figure 27 illustrates a typical delayed Ack frame exchange sequence. If the delayed Block Ack policy is used, the recipient shall respond to a BlockAckReq frame with an Ack frame. The recipient shall then send its BlockAck frame in a subsequently obtained TXOP after this frame has been configured. The originator shall respond with an ACK frame upon receipt of the BlockAck frame.
9.2.3 Interframe Space (IFS)
Change the text in clause 9.2.3(.11e) as follows
The time interval between frames is called the IFS. A STA shall determine that the medium is idle through the use of the carrier sense function for the interval specified. Two interframe spaces, ZIFS and RIFS, are defined for use between frames in a burst transmission, and another five IFSs are defined to provide priority levels for access to the wireless media. To obtain access to the medium, a STA shall determine that the medium is idle through the use of the carrier sense function for the interval specified. Five different IFSs are defined to provide priority levels for access to the wireless media; they The interframe spaces are listed in order, from the shortest to the longest except for AIFS. Figure 49 shows some of these relationships.
a) ZIFS Zero Interframe Space
b) RIFS Reduced Interframe Space
c) Short Interframe Space
d) PIFS Point Coordination Function (PCF) Interframe Space
e) DIFS Distributed Coordination Function (DCF) Interframe Space
f) AIFS Arbitration Interframe Space (used by the QoS facility)
g) EIFS Extended Interframe Space
Insert the following subclauses after clause 9.2.3(.11e) and renumber existing subclauses 9.2.3.1(.11e) through 9.2.3.5(.11e) to be subclauses 9.2.3.3 through 9.2.3.7.
9.2.3.1 ZIFS
The ZIFS may be used for the second or subsequent MPDU of a burst transmission if the frame will be transmitted at the same power as the immediately previous frame, and the ack policy is either block ack or no ack.
9.2.3.2 RIFS
The RIFS may be used for the second or subsequent MPDU of a burst transmission if the frame will be transmitted at a different power than the immediately previous frame, and the ack policy is either block ack or no ack.
9.10.1 Introduction (Informative)
Change the first paragraph of subclause 9.9.10.1(.11e) as follows
The Block Acknowledgement (Block Ack) mechanism allows a block of QoS Data MPDUs to be transmitted between two QSTAs without intervening ACK frames each separated by a SIFS period, between two QSTAs. The mechanism is for improving the channel efficiency by aggregating several acknowledgements into one frame. There are two types of Block Ack mechanisms: immediate and delayed. Immediate Block Ack is suitable for high-bandwidth, low latency traffic while the delayed Block Ack is suitable for applications that tolerate moderate latency. In this clause, the QSTA with data to send using the Block Ack mechanism is referred to as the originator and the receiver of that data as the recipient.
9.10.3 Data and acknowledgement transfer
Change the first paragraph of subclause 9.9.10.1(.11e) as follows
After setting up for the Block exchange following the procedure in 9.10.2, the originator may transmit a Block of QoS data type frames separated by SIFS ZIFS/RIFS/SIFS period, with the total number of frames not exceeding the Buffer Size subfield in the associated ADDBA response frame. Each of the frames shall have the Ack policy subfield in the QoS Control set to "Block Acknowledgement". The RA field of the frames shall be the recipient's unicast address. The originator requests acknowledgement of outstanding QoS Data type frames by sending a BlockAckReq frame. The recipient shall maintain a Block Ack record for the block.
9.12 Frame exchange sequences
Edit Table 22.1(.11e) <HCF sequence> and replace all “=” with”-“.
Remove definiton 36 from the end of Table 22.4(.11e) (no PIFS spacing defined anymore).
Replace the last sentence of the text in subclause 9.12 as follows(.11e) with:
Individual frames within each of these sequences are separated by a SIFS are separated by a ZIFS/RIFS, according to the rules in sections 9.2.3.1 and 9.2.3.2, if they are part of a burst transmission and they originate from the same transmitter, otherwise a SIFS separation is used, unless an “=” sign appears between frames in the table, in which case, PIFS is used.
Liwen Chu will cite appropriate sections of Draft Standard.
Figure 24 illustrates the Block Ack set-up process. Figure 25 illustrates the Block Ack teardown process.
There are two kinds of Block Ack policies: Immediate Ack and Delayed Ack.
N.1.2.1 Immediate ACK
Figure 26 illustrates a typical immediate Ack frame exchange sequence. The recipient shall respond to a BlockAckReq frame with a BlockAck frame if the immediate Block Ack policy is used.
Liwen Chu will cite appropriate sections of Draft Standard.
N.1.1.2 Delayed ACK
Figure 27 illustrates a typical delayed Ack frame exchange sequence. If the delayed Block Ack policy is used, the recipient shall respond to a BlockAckReq frame with an Ack frame. The recipient shall then send its BlockAck frame in a subsequently obtained TXOP after this frame has been configured. The originator shall respond with an ACK frame upon receipt of the BlockAck frame.
Liwen Chu will cite appropriate sections of Draft Standard.
N.1.1.3 Direct Link Protocol (DLP)
The DLP mechanism provides direct communication between two non-AP STAs in an infrastructure BSS without an AP’s relay. The DLP negotiation process is required to make sure the receiver is not in power saving mode and to exchange necessary information (rate etc.) between sender and receiver. Figure 28 and figure 29 illustrateThe following figures describe the DLP set-up and teardown processes.
Reference [1] 7.3.1.13 gives the definition of DLP Timeout Value. Reference [1] 7.4.3 gives the definitions of DLP action frames which include DLP request, DLP response and DLP Teardown. Reference [1] 10.3.12 defines the DLP service provided by MLME to SME to manage DLP. These include MLME-DLP.request, MLME-DLP.confirm, MLME-DLP.indication, MLME-DLP.teardown.request, MLME-DLP.teardown.confirm, and MLME-DLP.teardown.indication. Reference [1] 11.7 defines the DLP operation procedure.
N.1.2 Enhanced Block Acknowledgment (EBA) with reduced IFS
Vincenzo ScarpaLiwen Chu will cite appropriate sections of Draft Standard.
N.1.3 MSDU Frame Aggregation
N.1.3.1 MSDU Aggregation
Copy this section from the WWiSE Draft.
N.1.34 Piggybacking
In general, STAs are allowed to send QoS Data frames either using the contention-based channel access (i.e. obtaining an EDCA TXOP, as defined in Reference [1] 9.9.1.3), or using the controlled channel access (i.e. HCCA TXOP). If an HCCA TXOP is obtained due to a QoS (+)CF-Poll from the HC, the TXOP is defined as a polled TXOP.
Piggybacking allows the possibility to overload a frame of type QoS Data with an acknowledgement of a previously received Mac Protocol Data Unit (MPDU) to the station to which the frame is directed.
Piggybacked frames are allowed in the CP, only in the case where the received frame is of type either QoS Data or DataAck and the ack policy is set to normal ack.
Piggybacked frames shall not be allowed after receiving any control frames, management frames, and data frames with the ack policy set to block ack or no ack.
In this clause, the QSTA which wins the TXOP and that starts the first transmission is referred to as the originator. Each QSTA receiving a piggybackable QoS Data or DataAck frame from the originator is referred as the recipient.
N.1.3.1 Modifications to [1]
3. Definitions
Insert the following new definition at the indicated location:
3.81 TXOP owner: it indicates the last QSTAs (including the HC) obtaining either an EDCA or an HCCA TXOP.
7.1.3.1.2 Type and Subtype fields
Change Table 1 – “Valid type and subtype combinations”, to include the CTSn and DataAck types, as follows:
Type value b3 b2 / Type description / Subtype value b7 b6 b5 b4 / Subtype description01 / Control / 0001 / CTSn
11 / Reserved / 0000-1111 / Reserved
11 / Data / 1001 / DataAck
11 / Reserved / 0000-1000 / Reserved
11 / Reserved / 1010-1111 / Reserved
7.1.3.5 QoS Control field
Change Table 3.1: An entry defining the usage of the previously reserved bit 7 and the usage of bits 8-15 will be added -“QoS Control Field”:
Applicable Frame (sub) Types / Bits 0-3 / Bit 4 / Bits 5-6 / Bit 7 / Bits 8-15QoS (+)CF-Poll frames sent by HC / TID / EOSP / Ack Policy / Reserved 0 / TXOP limit
QoS Data, QoS Null, QoS CF-Ack and QoS Data+CF-Ack frames sent by HC / TID / EOSP / Ack Policy / Reserved 0 / QAP PS Buffer State
QoS Data type frames sent by non-AP QSTA / TID / 0 / Ack Policy / Reserved 0 / TXOP duration requested
TID / 1 / Ack Policy / Reserved 0 / Queue size
DataAck and QoS data type frames sent by the TXOP owner with ack policy set to normal ack / TID / either 0 or 1 / 00 (Normal Ack) / PB Policy / PB Duration
DataAck frames sent by a non-TXOP owner / TID / either 0 or 1 / Ack Policy / 1 / PB request
7.1.3.5.7 PB Policy field
If the PB Policy field (bit 7 in the QoS Control field) is set to 1, it indicates that Bits 8-15 will be interpreted as PB Duration field. A value of zero in the PB policy field indicates that the piggybacking mechanism is not allowed at the recipeint side. Legacy stations will ignore this field.
7.1.3.5.8 PB Duration field
The PB Duration field is an 8-bit field that indicates the time limit granted to the recipient to send a DataAck type frame, including any resulting acknowledgement frame from the transmitter (if expected).
This value is set by the originator, sending either a Data or DataAck type frame, in a way to not exceed the TXOP limit (see section 5.5.3).
The granted time begins one SIFS period after this frame is received and lasts no longer than the number of 32-microsecond periods specified in the PB Duration field. For the values 1 to 255, the range of time values is 32 to 8160 microseconds. A value of zero indicates that the piggyback mechanism is disallowed for the recipient, but in this case the PB policy bit shouldn’t be set to one either. The PB duration shall include PHY overhead.