Section1 Overview of MAC services
6.1.1 Data service
This service provides peer LLC entities with the ability to exchange MSDUs. To support this service, the local MAC uses the underlying PHY-level services to transport an MSDU to a peer MAC entity, where it will be delivered to the peer LLC. Such asynchronous MSDU transport is performed on a connectionless basis. By default, MSDU transport is on a best-effort basis. However, the QoS facility uses a traffic identifier (TID) to specify differentiated services on a per-MSDU basis. The QoS facility also permits more synchronous behavior to be supported on a connection-oriented basis using TSPECs. There are no guarantees that the submitted MSDU will be delivered successfully. Broadcast and multicast transport is part of the data service provided by the MAC. Due to the characteristics of the WM, broadcast and multicast MSDUs may experience a lower QoS, compared to that of unicast MSDUs. All STAs will support the data service, but only QoS STAs in a QoS BSS differentiate their MSDU delivery according to the designated traffic category or traffic stream (TS) of individual MSDUs.
Because operation of certain functions of the MAC may cause reordering of some MSDUs, as discussed in more detail below, in non-QoS STAs, there are two service classes within the data service. By selecting the desired service class, each LLC entity initiating the transfer of MSDUs is able to control whether MAC entities are or are not allowed to reorder those MSDUs.
There are two service classes available in a QoS STA: QoSAck and QoSNoAck. The service classes are used to signal if the MSDU is to be transmitted with or without using the MAC-level acknowledgment.
In QoS STAs either associated in a BSS or having membership in an IBSS, the MAC uses a set of rules that tends to cause higher UP MSDUs in a BSS to be sent before lower UP MSDUs in the BSS. The MAC sublayer entities determine the UPs for MSDUs based on the TID values provided with those MSDUs. If a TSPEC has been provided for a TS, via the MAC sublayer management entity, the MAC attempts to deliver MSDUs belonging to that TS in accordance with the QoS parameter values contained in the TSPEC. In a BSS with some STAs supporting the QoS facility and others not supporting the QoS facility, in delivering an MSDU to a non-QoS STA, the QoS STA uses the access category (AC) corresponding to the UP of the MSDU.
6.1.1.1 Determination of UP
The QoS facility supports eight priority values, referred to as UPs. The values a UP may take are the integer values from 0 to 7 and are identical to the IEEE 802.1D priority tags. An MSDU with a particular UP is said to belong to a traffic category (TC) with that UP. The UP is provided with each MSDU at the medium access control service access point (MAC_SAP) either directly, in the UP parameter, or indirectly, in a TSPEC designated by the UP parameter.
6.1.1.1.1 Determination of UP of received frames at the AP sent by other STAs in the BSS
The received unicast frames at the AP may be as follows:
a) Non-QoS subtypes, in which case the AP shall assign to them a priority of Contention, if they are
received during the contention period (CP), or ContentionFree, if they are received during the
contention-free period (CFP).
b) QoS subtypes, in which case the AP shall infer the UP value from the TID in the QoS Control field
directly for TID values between 0 and 7. For TID values between 8 and 15, the AP shall extract the
UP value in the UP subfield of the TS Info field in the associated TSPEC or from the UP field in the
associated TCLAS (traffic classification) element, as applicable.
QoS APs deliver the UP with the received MSDUs to the DS.
6.1.1.2 Interpretation of priority parameter in MAC service primitives
The value of the priority parameter in the MAC service primitives (see 6.2) may be a non-integer value of either Contention or ContentionFree or may be any integer value in the range 0 through 15.
When the priority parameter has an integer value, it is used in the TID subfields that appear in certain frames that are used to deliver and to control the delivery of QoS data across the WM.
Priority parameter and TID subfield values 0 through 7 are interpreted as UPs for the MSDUs. Outgoing MSDUs with UP values 0 through 7 are handled by MAC entities at STAs in accordance with the UP.
Priority parameter and TID subfield values 8 through 15 specify TIDs that are also TS identifiers (TSIDs) and select the TSPEC for the TS designated by the TID. Outgoing MSDUs with priority parameter values 8 through 15 are handled by MAC entities at STAs in accordance with the UP value determined from the UP subfield as well as other parameter values in the selected TSPEC. When an MSDU arrives with a priority value between 8 and 15 and for which there is no TSPEC defined, then the MSDU shall be sent with priority parameter set to 0.
The non-integer values of the priority parameter are allowed at all non-QoS STAs. The use of priority value of ContentionFree is deprecated at QoS STAs. The integer values of the priority parameter (i.e., TID) are supported only at QoS STAs that are either associated in a QoS BSS or members of a QoS IBSS. A range of 0 through 15 is supported by QoS STAs associated in a QoS BSS; whereas a range of 0 through 7 is supported by QoS STAs that are members of a QoS IBSS. If a QoS STA is associated in a non-QoS BSS, the STA is functioning as a non-QoS STA, so the priority value is always Contention or ContentionFree.
At QoS STAs associated in a QoS BSS, MSDUs with a priority of Contention are considered equivalent to MSDUs with TID 0, and those with a priority of ContentionFree are delivered using the contention-free delivery if a point coordinator (PC) is present in the AP. If a PC is not present, MSDUs with a priority of ContentionFree shall be delivered using an UP of 0. At STAs associated in a non-QoS BSS, all MSDUs with an integer priority are considered equivalent to MSDUs with a priority of Contention.
If a STA is associated in a QoS BSS, the MSDUs it receives in QoS data frames are reported with the TID value contained in the MAC header of that frame. The MSDUs such a STA receives in non-QoS data frames are reported to LLC with a priority of Contention, if they are received during the CP, or ContentionFree, if they are received during the CFP.
6.1.1.3 Interpretation of service class parameter in MAC service primitives in a STA
In QoS STAs, the value of the service class parameter in the MAC service primitive (see 6.2) may be a noninteger value of QoSAck or QoSNoAck.
When an MSDU is received from the MAC_SAP and the recipient STA is a QoS STA with the service class set to
— QoSAck, the MSDU is transmitted using a QoS data frame with the Ack Policy subfield in the QoS
Control field set to either Normal Acknowledgment (Normal Ack) or Block Ack.
— QoSNoAck, the MSDU is transmitted using a QoS data frame with the Ack Policy subfield in the
QoS Control field set to No Acknowledgment (No Ack). If the sender STA is an AP and the frame
has a multicast/broadcast DA, then the MSDU is buffered for transmission and is also sent to
the DS.
When an MSDU is received from the MAC_SAP and the recipient STA is not a QoS STA, the MSDU is
transmitted using a non-QoS data frame.
When a QoS data frame is received from another STA, the service class parameter in MA-UNITDATA.indication primitive is set to
— QoSAck, if the frame is a QoS data frame with the Ack Policy subfield in the QoS Control field set
to either Normal Ack or Block Ack.
— QoSNoAck, if the frame is a QoS data frame with the Ack Policy subfield in the QoS Control field
set to No Ack. This service class is also used where the DA parameter is a broadcast/multicast
address.
When a non-QoS data frame is received from a STA, the service class parameter in MA-UNITDATA.indication primitive is set to
— QoSAck, if the frame is a unicast frame and is acknowledged by the STA.
— QoSNoAck, if the frame is a broadcast/multicast frame and is not acknowledged by the STA.
Note that the broadcast/multicast frames sent by a non-QoS STA are not acknowledged regardless of the service class parameter in MA-UNITDATA.indication primitive.
6.1.2 Security services
Security services in IEEE Std 802.11 are provided by the authentication service and the TKIP and CCMP mechanisms. The scope of the security services provided is limited to station-to-station data exchange. The data confidentiality service offered by an IEEE 802.11 TKIP and CCMP implementation is the protection of the MSDU. For the purposes of this standard, TKIP and CCMP are viewed as logical services located within the MAC sublayer as shown in the reference model, Figure 5-10 (in 5.7). Actual implementations of the TKIP and CCMP services are transparent to the LLC and other layers above the MAC sublayer.
The security services provided by TKIP and CCMP in IEEE Std 802.11 are as follows:
a) Data Confidentiality;
b) Authentication; and
c) Access control in conjunction with layer management.
During the authentication exchange, both parties exchange authentication information as described in
Clause 8.
The MAC sublayer security services provided by TKIP and CCMP rely on information from nonlayer-2
management or system entities. Management entities communicate information to TKIP and CCMP through a set of MAC sublayer management entity (MLME) interfaces and MIB attributes; in particular, the decision tree for TKIP and CCMP defined in 8.7 is driven by MIB attributes.
The use of WEP for confidentiality, authentication, or access control is deprecated. The WEP algorithm is unsuitable for the purposes of this standard.
6.1.3 MSDU ordering
The services provided by the MAC sublayer permit, and may in certain cases require, the reordering of
MSDUs.
In a non-QoS STA, the MAC does not intentionally reorder MSDUs except as may be necessary to improve the likelihood of successful delivery based on the current operational (“power management”) mode of the designated recipient STA(s). The sole effect of this reordering (if any), for the set of MSDUs received at the MAC service interface of any single STA, is a change in the delivery order of broadcast and multicast MSDUs, relative to directed MSDUs, originating from a single source STA address. If a higher layer protocol using the data service cannot tolerate this possible reordering, the optional StrictlyOrdered service class should be used. MSDUs transferred between any pair of STAs using the StrictlyOrdered service class are not subject to the relative reordering that is possible when the ReorderableMulticast service class is used. However, the desire to receive MSDUs sent using the StrictlyOrdered service class at a STA precludes simultaneous use of the MAC power management facilities at that STA.
In QoS STAs operating in a BSS, there are two service classes, designated as QoSAck and QoSNoAck (see 6.1.1.3 for more information). The MSDUs are reordered, not only to improve the likelihood of successful delivery based on the current operational mode of the designated recipient STA(s), but also to honor the priority parameters, specified in the MA-UNITDATA.request primitive, of the individual MSDUs. The effects of this reordering (if any), for the set of MSDUs received at the MAC service interface of any single STA, are
a) A change in the delivery order of broadcast and multicast MSDUs, relative to unicast MSDUs,
b) The reordering of MSDUs with different TID values, originating from a single source STA address, and
c) The reordering of broadcast and multicast MSDUs with the same TID but different service classes.
There shall be no reordering of unicast MSDUs with the same TID value and addressed to the same
destination.
STAs operating in a non-QoS BSS shall follow the reordering rules as defined for a non-QoS STA.
In order for the MAC to operate properly, the DS must meet the requirements of ISO/IEC 15802-1:1995.
Operational restrictions that ensure the appropriate ordering of MSDUs are specified in 9.8.
6.1.4 MSDU format
This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B13]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a non-AP STA.
6.1.5 MAC data service architecture
The MAC data plane architecture (i.e., processes that involve transport of all or part of an MSDU) is shown in Figure 6-1. During transmission, an MSDU goes through some or all of the following processes: frame delivery deferral during power save mode, sequence number assignment, fragmentation, encryption, integrity protection, and frame formatting. IEEE Std 802.1X-2004 may block the MSDU at the Controlled Port. At some point, the data frames that contain all or part of the MSDU are queued per AC/TS. This queuing may be at any of the three points indicated in Figure 6-1.
During reception, a received data frame goes through processes of MPDU header and cyclic redundancy code (CRC) validation, duplicate removal, possible reordering if the Block Ack mechanism is used, decryption, defragmentation, integrity checking, and replay detection. After replay detection (or
defragmentation if security is used), the MSDU is delivered to the MAC_SAP or to the DS. The
IEEE 802.1X Controlled/Uncontrolled Ports discard the MSDU if the Controlled Port is not enabled and if the MSDU does not represent an IEEE 802.1X frame. TKIP and CCMP MPDU frame order enforcement occurs after decryption, but prior to MSDU defragmentation; therefore, defragmentation will fail if MPDUs arrive out of order.
This service provides peer LLC entities with the ability to exchange MSDUs. To support this service, the local MAC uses the underlying PHY-level services to transport an MSDU to a peer MAC entity, where it will be delivered to the peer LLC. Such asynchronous MSDU transport is performed on a connectionless basis. By default, MSDU transport is on a best-effort basis. However, the QoS facility uses a traffic identifier (TID) to specify differentiated services on a per-MSDU basis. The QoS facility also permits more synchronous behavior to be supported on a connection-oriented basis using TSPECs. There are no guarantees that the submitted MSDU will be delivered successfully. Broadcast and multicast transport is part of the data service provided by the MAC. Due to the characteristics of the WM, broadcast and multicast MSDUs may experience a lower QoS, compared to that of unicast MSDUs. All STAs will support the data service, but only QoS STAs in a QoS BSS differentiate their MSDU delivery according to the designated traffic category or traffic stream (TS) of individual MSDUs.
Because operation of certain functions of the MAC may cause reordering of some MSDUs, as discussed in more detail below, in non-QoS STAs, there are two service classes within the data service. By selecting the desired service class, each LLC entity initiating the transfer of MSDUs is able to control whether MAC entities are or are not allowed to reorder those MSDUs.
There are two service classes available in a QoS STA: QoSAck and QoSNoAck. The service classes are used to signal if the MSDU is to be transmitted with or without using the MAC-level acknowledgment.
In QoS STAs either associated in a BSS or having membership in an IBSS, the MAC uses a set of rules that tends to cause higher UP MSDUs in a BSS to be sent before lower UP MSDUs in the BSS. The MAC sublayer entities determine the UPs for MSDUs based on the TID values provided with those MSDUs. If a TSPEC has been provided for a TS, via the MAC sublayer management entity, the MAC attempts to deliver MSDUs belonging to that TS in accordance with the QoS parameter values contained in the TSPEC. In a BSS with some STAs supporting the QoS facility and others not supporting the QoS facility, in delivering an MSDU to a non-QoS STA, the QoS STA uses the access category (AC) corresponding to the UP of the MSDU.
6.1.1.1 Determination of UP
The QoS facility supports eight priority values, referred to as UPs. The values a UP may take are the integer values from 0 to 7 and are identical to the IEEE 802.1D priority tags. An MSDU with a particular UP is said to belong to a traffic category (TC) with that UP. The UP is provided with each MSDU at the medium access control service access point (MAC_SAP) either directly, in the UP parameter, or indirectly, in a TSPEC designated by the UP parameter.
6.1.1.1.1 Determination of UP of received frames at the AP sent by other STAs in the BSS
The received unicast frames at the AP may be as follows:
a) Non-QoS subtypes, in which case the AP shall assign to them a priority of Contention, if they are
received during the contention period (CP), or ContentionFree, if they are received during the
contention-free period (CFP).
b) QoS subtypes, in which case the AP shall infer the UP value from the TID in the QoS Control field
directly for TID values between 0 and 7. For TID values between 8 and 15, the AP shall extract the
UP value in the UP subfield of the TS Info field in the associated TSPEC or from the UP field in the
associated TCLAS (traffic classification) element, as applicable.
QoS APs deliver the UP with the received MSDUs to the DS.
6.1.1.2 Interpretation of priority parameter in MAC service primitives
The value of the priority parameter in the MAC service primitives (see 6.2) may be a non-integer value of either Contention or ContentionFree or may be any integer value in the range 0 through 15.
When the priority parameter has an integer value, it is used in the TID subfields that appear in certain frames that are used to deliver and to control the delivery of QoS data across the WM.
Priority parameter and TID subfield values 0 through 7 are interpreted as UPs for the MSDUs. Outgoing MSDUs with UP values 0 through 7 are handled by MAC entities at STAs in accordance with the UP.
Priority parameter and TID subfield values 8 through 15 specify TIDs that are also TS identifiers (TSIDs) and select the TSPEC for the TS designated by the TID. Outgoing MSDUs with priority parameter values 8 through 15 are handled by MAC entities at STAs in accordance with the UP value determined from the UP subfield as well as other parameter values in the selected TSPEC. When an MSDU arrives with a priority value between 8 and 15 and for which there is no TSPEC defined, then the MSDU shall be sent with priority parameter set to 0.
The non-integer values of the priority parameter are allowed at all non-QoS STAs. The use of priority value of ContentionFree is deprecated at QoS STAs. The integer values of the priority parameter (i.e., TID) are supported only at QoS STAs that are either associated in a QoS BSS or members of a QoS IBSS. A range of 0 through 15 is supported by QoS STAs associated in a QoS BSS; whereas a range of 0 through 7 is supported by QoS STAs that are members of a QoS IBSS. If a QoS STA is associated in a non-QoS BSS, the STA is functioning as a non-QoS STA, so the priority value is always Contention or ContentionFree.
At QoS STAs associated in a QoS BSS, MSDUs with a priority of Contention are considered equivalent to MSDUs with TID 0, and those with a priority of ContentionFree are delivered using the contention-free delivery if a point coordinator (PC) is present in the AP. If a PC is not present, MSDUs with a priority of ContentionFree shall be delivered using an UP of 0. At STAs associated in a non-QoS BSS, all MSDUs with an integer priority are considered equivalent to MSDUs with a priority of Contention.
If a STA is associated in a QoS BSS, the MSDUs it receives in QoS data frames are reported with the TID value contained in the MAC header of that frame. The MSDUs such a STA receives in non-QoS data frames are reported to LLC with a priority of Contention, if they are received during the CP, or ContentionFree, if they are received during the CFP.
6.1.1.3 Interpretation of service class parameter in MAC service primitives in a STA
In QoS STAs, the value of the service class parameter in the MAC service primitive (see 6.2) may be a noninteger value of QoSAck or QoSNoAck.
When an MSDU is received from the MAC_SAP and the recipient STA is a QoS STA with the service class set to
— QoSAck, the MSDU is transmitted using a QoS data frame with the Ack Policy subfield in the QoS
Control field set to either Normal Acknowledgment (Normal Ack) or Block Ack.
— QoSNoAck, the MSDU is transmitted using a QoS data frame with the Ack Policy subfield in the
QoS Control field set to No Acknowledgment (No Ack). If the sender STA is an AP and the frame
has a multicast/broadcast DA, then the MSDU is buffered for transmission and is also sent to
the DS.
When an MSDU is received from the MAC_SAP and the recipient STA is not a QoS STA, the MSDU is
transmitted using a non-QoS data frame.
When a QoS data frame is received from another STA, the service class parameter in MA-UNITDATA.indication primitive is set to
— QoSAck, if the frame is a QoS data frame with the Ack Policy subfield in the QoS Control field set
to either Normal Ack or Block Ack.
— QoSNoAck, if the frame is a QoS data frame with the Ack Policy subfield in the QoS Control field
set to No Ack. This service class is also used where the DA parameter is a broadcast/multicast
address.
When a non-QoS data frame is received from a STA, the service class parameter in MA-UNITDATA.indication primitive is set to
— QoSAck, if the frame is a unicast frame and is acknowledged by the STA.
— QoSNoAck, if the frame is a broadcast/multicast frame and is not acknowledged by the STA.
Note that the broadcast/multicast frames sent by a non-QoS STA are not acknowledged regardless of the service class parameter in MA-UNITDATA.indication primitive.
6.1.2 Security services
Security services in IEEE Std 802.11 are provided by the authentication service and the TKIP and CCMP mechanisms. The scope of the security services provided is limited to station-to-station data exchange. The data confidentiality service offered by an IEEE 802.11 TKIP and CCMP implementation is the protection of the MSDU. For the purposes of this standard, TKIP and CCMP are viewed as logical services located within the MAC sublayer as shown in the reference model, Figure 5-10 (in 5.7). Actual implementations of the TKIP and CCMP services are transparent to the LLC and other layers above the MAC sublayer.
The security services provided by TKIP and CCMP in IEEE Std 802.11 are as follows:
a) Data Confidentiality;
b) Authentication; and
c) Access control in conjunction with layer management.
During the authentication exchange, both parties exchange authentication information as described in
Clause 8.
The MAC sublayer security services provided by TKIP and CCMP rely on information from nonlayer-2
management or system entities. Management entities communicate information to TKIP and CCMP through a set of MAC sublayer management entity (MLME) interfaces and MIB attributes; in particular, the decision tree for TKIP and CCMP defined in 8.7 is driven by MIB attributes.
The use of WEP for confidentiality, authentication, or access control is deprecated. The WEP algorithm is unsuitable for the purposes of this standard.
6.1.3 MSDU ordering
The services provided by the MAC sublayer permit, and may in certain cases require, the reordering of
MSDUs.
In a non-QoS STA, the MAC does not intentionally reorder MSDUs except as may be necessary to improve the likelihood of successful delivery based on the current operational (“power management”) mode of the designated recipient STA(s). The sole effect of this reordering (if any), for the set of MSDUs received at the MAC service interface of any single STA, is a change in the delivery order of broadcast and multicast MSDUs, relative to directed MSDUs, originating from a single source STA address. If a higher layer protocol using the data service cannot tolerate this possible reordering, the optional StrictlyOrdered service class should be used. MSDUs transferred between any pair of STAs using the StrictlyOrdered service class are not subject to the relative reordering that is possible when the ReorderableMulticast service class is used. However, the desire to receive MSDUs sent using the StrictlyOrdered service class at a STA precludes simultaneous use of the MAC power management facilities at that STA.
In QoS STAs operating in a BSS, there are two service classes, designated as QoSAck and QoSNoAck (see 6.1.1.3 for more information). The MSDUs are reordered, not only to improve the likelihood of successful delivery based on the current operational mode of the designated recipient STA(s), but also to honor the priority parameters, specified in the MA-UNITDATA.request primitive, of the individual MSDUs. The effects of this reordering (if any), for the set of MSDUs received at the MAC service interface of any single STA, are
a) A change in the delivery order of broadcast and multicast MSDUs, relative to unicast MSDUs,
b) The reordering of MSDUs with different TID values, originating from a single source STA address, and
c) The reordering of broadcast and multicast MSDUs with the same TID but different service classes.
There shall be no reordering of unicast MSDUs with the same TID value and addressed to the same
destination.
STAs operating in a non-QoS BSS shall follow the reordering rules as defined for a non-QoS STA.
In order for the MAC to operate properly, the DS must meet the requirements of ISO/IEC 15802-1:1995.
Operational restrictions that ensure the appropriate ordering of MSDUs are specified in 9.8.
6.1.4 MSDU format
This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B13]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a non-AP STA.
6.1.5 MAC data service architecture
The MAC data plane architecture (i.e., processes that involve transport of all or part of an MSDU) is shown in Figure 6-1. During transmission, an MSDU goes through some or all of the following processes: frame delivery deferral during power save mode, sequence number assignment, fragmentation, encryption, integrity protection, and frame formatting. IEEE Std 802.1X-2004 may block the MSDU at the Controlled Port. At some point, the data frames that contain all or part of the MSDU are queued per AC/TS. This queuing may be at any of the three points indicated in Figure 6-1.
During reception, a received data frame goes through processes of MPDU header and cyclic redundancy code (CRC) validation, duplicate removal, possible reordering if the Block Ack mechanism is used, decryption, defragmentation, integrity checking, and replay detection. After replay detection (or
defragmentation if security is used), the MSDU is delivered to the MAC_SAP or to the DS. The
IEEE 802.1X Controlled/Uncontrolled Ports discard the MSDU if the Controlled Port is not enabled and if the MSDU does not represent an IEEE 802.1X frame. TKIP and CCMP MPDU frame order enforcement occurs after decryption, but prior to MSDU defragmentation; therefore, defragmentation will fail if MPDUs arrive out of order.
