This chapter is from the book
This chapter is from the book
This chapter is from the book
Enhanced SCS
Around the time frame when the 802.11be amendment was being developed, adoption of some existing applications accelerated and some new applications and use cases began emerging across different vertical segments (enterprise, home, industrial) that demanded more predictable and lower latency and improved reliability. Use of video collaboration applications across enterprises exploded during the COVID pandemic and post-COVID era, adding requirements for more consistent latency and jitter so that users could achieve better productivity during these sessions. Industrial IoT applications of robotics saw increasing growth at warehouses and factories—for example, with automated guided vehicles (AGVs) and autonomous mobile robot (AMR) devices, which required more determinism. The emergence of extended reality (XR) devices and experiences—including virtual reality (VR), augmented reality (AR), and mixed reality (MR) capabilities—required end-to-end low latency of approximately 20 ms to meet the target motion-to-photon latency for VR experiences and avoid VR-induced sickness. In many environments, requirements for these applications could not be met with the existing QoS mechanism adopted from 802.11e with four access categories (AC_VO, AC_VI, AC_BE, and AC_BK). See Chapter 4, “The Main Ideas in 802.11be and Wi-Fi 7,” for more details on the challenges related to meeting QoS for these existing and emerging applications.
One of the goals of the EHT project in IEEE 802.11 was to define at least one mode of operation that offered improved latency and jitter, so as to address the QoS requirements for applications that demanded improved QoS. The 802.11be designers started by evaluating the existing protocols and mechanisms that could be leveraged to achieve improved QoS. Previously, the 802.11e amendment had defined a TSPEC (traffic specification) element7 that provided a way for a STA to signal traffic requirements for its flows to the AP using the ADDTS request/response exchange. The flow classification was done using one or more TCLAS elements in the ADDTS exchange that specified the admission control for these flows. Although this mechanism was defined in 802.11e in 2005, the use of TSPEC to signal the traffic flow requirements was never widely adopted by Wi-Fi STAs because of the complicated set of parameters that had to be provided in the TSPEC element. All the parameters shown in Figure 7-7 were required to be provided in a TSPEC element, and it was extremely hard (if not impossible) for an application to characterize all these parameters for its flow. Due to the complexity involved, the TSPEC and ADDTS request/response mechanism was not much used outside single-function devices.
)
FIGURE 7-7 TSPEC Element Definition
Well aware of these limitations and challenges faced by the TSPEC and ADDTS mechanisms in the past, the 802.11be designers sought to develop a new scheme for QoS improvements that would be much simpler to implement and, therefore, would have a higher chance of being adopted for Wi-Fi devices. After the 802.11e amendment, the IEEE 802.11 group had proposed some further enhancements to improve multimedia streaming performance as part of the 802.11aa amendment. This included defining intra-access category prioritization and the stream classification service (SCS) to enable prioritization of DL flows at the AP. SCS turned out to be a good fit for adding QoS-related enhancements in 802.11be, as you will learn next.
SCS to Prioritize DL Flows (Pre-802.11be)
The 802.11aa amendment defined two new features for QoS-based prioritization (see Chapter 2, “Reaching the Limits of Traditional Wi-Fi,” for the background context). The first feature was intra-access category prioritization (IACP), which provided a way to differentiate between audio/video streams within the same AC category for AC_VO and AC_VI. One of the main use cases envisioned for this enhancement was differentiating between a video-conferencing flow and a streaming flow, where both could be using the AC_VI category. The IACP feature enabled differentiation of traffic streams within the same AC for voice and video by splitting the transmit queue for each of these ACs into two queues—a primary queue and an alternate queue—leading to a total of six transmit queues (Figure 7-8). The alternate queues were tagged as A_VO or A_VI. The six queues were still mapped to four EDCA functions (EDCAF), just as before, for the four ACs. An implementation-specific scheduler was used to select packets from the primary or alternate queue to pass to the EDCA function. This scheduler was configured to select frames from the primary queue with higher probability than the frames from the alternate queue.
)
FIGURE 7-8 Intra-Access Category Priority
The 802.11 standard defines mapping of user priority (UP) received from the upper layer to ACs and the two transmit queues (primary and alternate), as shown in Table 7-2. For VI, UP 4 is mapped to the alternate queue (A_VI) and UP 5 is mapped to the primary queue (VI). Frames with UP 5 are served with higher probability than frames with UP 4, which made sense in terms of low to high priority order for UPs. However, for VO, the mapping is reversed; that is, the lower UP 6 is mapped to the primary queue and the higher UP 7 (used for network control traffic per the 802.1D designation) is mapped to the alternate queue. Hence, for VO, frames with UP 6 are served with higher probability than frames with UP 7. This seems counterintuitive, but there was a good reason for mapping them this way. Given that UP 7 in 802.1D is used for network control traffic (e.g., switch-to-switch traffic) and such traffic is rarely sent over Wi-Fi, UP 7 is hardly used but was kept in 802.11. The most frequently occurring voice traffic is mapped to UP 6, so it made sense to use the primary voice queue to prioritize the most prevalent voice traffic. In fact, no differentiation can be provided for voice traffic with the alternate A_VO queue because the common voice traffic is not mapped to UP 7. This was a limitation of the alternate queuing scheme (see Chapter 2 for more details).
TABLE 7-2 UP-to-AC-to-Tx Queue Mapping
Priority |
UP |
AC |
Tx Queue |
Tx Queue with IACP |
Designation |
|---|---|---|---|---|---|
Lowest |
1 |
AC_BK |
BK |
BK |
Background |
|
2 |
AC_BK |
BK |
BK |
Background |
|
0 |
AC_BE |
BE |
BE |
Best effort |
|
3 |
AC_BE |
BE |
BE |
Best effort |
|
4 |
AC_VI |
VI |
A_VI |
Video (alternate) |
|
5 |
AC_VI |
VI |
VI |
Video (primary) |
|
6 |
AC_VO |
VO |
VO |
Voice (primary) |
Highest |
7 |
AC_VO |
VO |
A_VO |
Voice (alternate) |
Supporting two alternate queues required hardware changes in most Wi-Fi devices, adding to their costs. The QoS differentiation benefits provided by having two alternate queues did not prove to be strong enough to ensure wide market adoption of this feature, mainly due to the cost impact and additional complexity added.
The second QoS feature defined in the 802.11aa amendment was the stream classification service (SCS). The main functionality provided by this feature was to enable STAs to request specific QoS treatment from the AP for downlink flows. This allows a STA to indicate to the AP that certain application flows desire specific QoS mapping in the downlink to meet their QoS requirements. For an application, it is desirable to retain the QoS markings (e.g., DSCP in the IP header) as the packets traverse the Internet, so that prioritization can happen on each network node along the way. To achieve equivalent prioritization within Wi-Fi, the AP needs to have the correct QoS marking when packets arrive from the DS. However, one of the challenges for achieving end-to-end QoS was that the DSCP QoS marking was typically reset by routers along the way (due to trust reasons), resulting in packets being marked as “best effort.” Hence, when the packets reach the Wi-Fi AP, their DSCP markings are typically not intact (as intended by the application), so the packets are delivered using the AC_BE category over Wi-Fi. SCS signaling from the STA addressed this issue. For example, a STA could request marking of a video-conferencing flow in DL to the UP 5 (AC_VI) category, independent of how the packets coming from the DS for that flow are tagged.
The SCS feature defines the SCS request/response exchange for negotiating the DL QoS classification and matching the QoS treatment to application flows. A STA can request a specific UP, drop eligibility, and/or transmit queue (primary or alternate) selection for flows (or streams) that match the indicated classification. The stream/flow classification is indicated by using one or more TCLAS elements, which can specify the IP-level classification for packets (e.g., a 5-tuple frame classifier based on the IP header). If multiple TCLAS elements are included, then a TCLAS Processing element is also included to indicate how multiple TCLAS elements need to be processed for classifying the packets (e.g., ANDed or ORed). An Inter-Access Category Priority element was defined to indicate the access policy for the desired QoS treatment for the matching flow.
As shown in Figure 7-9, the SCS Request frame includes one or more SCS Descriptor elements,8 each requesting specific DL QoS treatment for a traffic flow. The key information provided in the SCS Descriptor element includes the SCS ID (assigned by the STA; identifies the SCS stream), the Request Type (for Adding, Changing, or Removing an SCS stream), the Intra-Access Category Priority element, one or more TCLAS elements, and optionally a TCLAS Processing element. The Intra-Access Category Priority element9 specifies the user priority (UP) to be used for mapping the DL frames for the specific SCS stream. The Alternate Queue field indicates whether the primary or alternate queue should be used for the SCS stream. The Drop Eligibility field, when set to 1, indicates that, in case of insufficient resources, the packets for this stream can be dropped in preference to other SCS streams that have their Drop Eligibility field set to 0. An AP can accept or reject a request for each SCS stream based on its policy, resources, and/or identification of the SCS stream. For example, an enterprise AP might have a network policy to accept only SCS requests for DL QoS mapping for flows that are considered high priority/critical in that given deployment. The AP then indicates the accept or reject status for each request, identified by its SCS ID, in the SCS Response frame, as shown in Figure 7-9.
)
FIGURE 7-9 SCS Request and Response Frames
If an SCS stream is accepted by the AP, the AP processes the matching MSDUs (per-flow classification of that stream based on TCLAS) and assigns them to the signaled UP in the Intra-Access Category Priority element. It uses the Alternate Queue and Drop Eligibility values (if indicated) to process the matching MSDUs accordingly.
Figure 7-10 illustrates an SCS request/response exchange between a STA and an AP. In this example, the STA sends an SCS Request frame to request classification and QoS treatment for a DL application flow. The AP, per its policy, accepts this request from the STA and sends an SCS Response frame to signal Success status to the STA. After the successful SCS Request and SCS Response frames exchange, the AP processes downlink MSDUs that match the flow classification and applies the access policy specified in the Intra-Access Category Priority element.
)
FIGURE 7-10 SCS Request/Response Exchange
The SCS protocol also provides flexibility by allowing either endpoint (the AP or the STA) to terminate an already established SCS stream. For example, a STA should remove an SCS stream if the application flow is no longer active, and an AP may terminate an SCS stream if its policy changes so that it no longer prioritizes that particular traffic flow. To remove an SCS stream, either the AP or the STA can send an SCS Request frame with a “Remove” request type for that SCS ID. This terminates the flow classification and special QoS treatment for the DL flow.
As you might expect, the SCS feature for DL traffic classification and prioritization is an optional feature in the 802.11 standard for both the AP and the STA. The Wi-Fi Alliance’s QoS Management (Release 2) certification program also includes this feature as an optional feature, which enhances the market visibility and adoption opportunities for this feature, particularly in the enterprise AP market segments.
Although the SCS feature from 802.11aa was a promising direction for providing prioritized treatment for DL traffic, some challenges remained unaddressed. Specifically, the SCS did not address the issue of differentiating between flows that fall into the same UP/AC but require different treatments based on their unique traffic characteristics (e.g., latency, data rate, burst size). Also, Wi-Fi 6 introduced trigger-based scheduling for the UL. The AP had to perform BSR polling (BSRP) to learn BSR information from STAs to determine how to schedule STAs for the UL using UL OFDMA. Constant BSRP/BSR exchanges added overhead to the network. It became clear that the SCS mechanism defined in 802.11aa needed to be enhanced to address these issues.
SCS with QoS Characteristics (802.11be)
While working on QoS-specific enhancements, the 802.11be designers naturally sought to leverage and extend the existing mechanisms. As explained in the previous section, the SCS mechanism was a great step toward solving QoS challenges, and it made sense to build on top of that success. The key issue that needed to be addressed was how a STA can request resources by providing a simple set of traffic characteristics at finer granularity, which can then be used by the AP for better QoS-based scheduling. Any solution should enable better scheduling for QoS flows not only in the downlink, but also for the uplink, to ensure QoS-based scheduling prioritization can be enforced in both directions for the desired end-to-end experience. The solution should also accommodate the reality that the QoS requirements of an application can be different in DL and UL. For example, for an XR application with distributed rendering, the DL flow to an XR device or head-mounted display (HMD) delivers rendered video. This rendered video has different characteristics for delay, throughput, and periodicity as compared to the UL flow, which delivers pose and/or IMU (inertial measurement unit) data that has a much shorter delay and periodicity needs and requires generally lower throughput.
Recall that the 802.11e-defined TSPEC proved to be extremely difficult to implement, because it mandated use of a large set of traffic parameters (see Figure 7-7) and applications could not supply that information. Given that challenge, the goal in 802.11be was to define a minimal set of QoS parameters to be provided that could adequately specify the application’s QoS needs for better scheduling in the DL and UL. This led to the definition of a new QoS Characteristics (QC) element10 in 802.11be (Figure 7-11). The QC element requires only four parameters related to traffic characteristics to define the scheduling needs for the flow—a major simplification from the TSPEC, which required 15 parameters for the traffic characteristics. In the QC element, the STA indicates the periodicity of its traffic flow using the Minimum Service Interval and the Maximum Service Interval parameters. The two other required traffic characteristics are the Minimum Data Rate and Delay Bound requirements for the flow. The QC element is delivered as part of SCS request/response exchange, as described later in this section.
)
FIGURE 7-11 QoS Characteristics Element
The Control Info field includes key control information. This field specifies the direction for the flow and indicates whether the flow is uplink, downlink, or direct link (for peer-to-peer [P2P] flows). The TID and User Priority fields are set to indicate the TID and UP of the data frames for the flow, respectively. (The TID field is set to the same value as the User Priority field in the 802.11be amendment.) The presence of optional traffic parameters in the QC element is signaled using the Presence Bitmap field. Also, when the QC element is specified for a direct link, the link ID indicates the link of the AP MLD upon which the direct link transmission will happen.
The four required traffic parameters of the QC element are as follows:
Minimum Service Interval: Specifies the minimal interval, in microseconds, between the start of two consecutive service periods allocated for the uplink, downlink, or direct-link frame exchanges for the traffic flow. For a downlink, this parameter may be unspecified by setting the value to 0.
Maximum Service Interval11: Specifies the maximum interval, in microseconds, between the start of two consecutive service periods allocated for the uplink, downlink, or direct-link frame exchange for the traffic flow. For a downlink, this parameter may be unspecified by setting the value to 0.
Minimum Data Rate: Specifies the lowest data rate at the MAC SAP, in kilobits per second (kbps), for the traffic flow. For a direct link, this parameter may be unspecified by setting the value to 0.
Delay Bound: Specifies the maximum amount of time, in microseconds, targeted to transport an MSDU/A-MSDU for the traffic flow. For an uplink or direct link, this parameter may be unspecified by setting the value to 0.
The QC element also includes eight optional traffic parameters. A STA may provide none, some, or all of these parameters for an application flow, based on its knowledge of the application. These parameters are as follows:
Maximum MSDU Size: Specifies the maximum size, in octets, of an MSDU belonging to the traffic flow.
Service Start Time: Specifies the anticipated start time, in microseconds, when the traffic is expected to start for the traffic flow. It is expressed as the four lower octets of the TSF timer of the link indicated by the Service Start Time Link ID.
Service Start Time Link ID: Indicates the link identifier of the link for which the TSF timer is used to indicate the Service Start Time.
Mean Data Rate: Specifies the average data rate at the MAC SAP, in kbps, for the traffic flow.
Delay Bounded Burst Size: Specifies the maximum burst, in octets, of the MSDUs/A-MSDUs belonging to the traffic flow that arrives at the MAC SAP within any time duration equal to the value indicated in the Delay Bound field.
MSDU Lifetime: Specifies the maximum amount of time, in milliseconds, since the arrival of the MSDU at the MAC SAP beyond which the MSDU is not useful, and hence can be discarded. The value of this field is larger than the Delay Bound.
MSDU Delivery Info: Specifies the MSDU delivery information in two subfields: MSDU Delivery Ratio and MSDU Count Exponent. The MSDU Delivery Ratio indicates the percentage of MSDUs that are expected to be delivered successfully (ranging from 95% to 99.9999%) within the Delay Bound, computed over the set of MSDUs determined based on the MSDU Count Exponent field. The number of MSDUs used for computing the MSDU delivery ratio is equal to 10MSDU Count Exponent.
Medium Time: Specifies the average medium time, in units of 256 μs, needed by the STA every second for direct-link frame exchanges for the traffic flow. This field is used only for direct links.
The 802.11be task group chose to enhance the existing SCS request/response exchange by including the QoS Characteristics element, which provides traffic characteristics for applications flows. This enabled a STA to request resources for DL and UL traffic flows from the AP; that, in turn, enabled better QoS scheduling at the AP. The SCS Descriptor element was enhanced to include a QoS Characteristics element,12 as shown in Figure 7-12. Both the AP and the STA indicate support for transmitting and receiving an SCS Descriptor element that contains a QoS Characteristics element through the SCS Traffic Description Support field in the EHT Capabilities element. The QoS Characteristics element can specify the traffic characteristics of a DL flow, a UL flow, or a direct-link/P2P flow, using the Direction field as described earlier in this section. A STA can also send a single SCS Request frame indicating traffic characteristics for both the DL and UL flows of an application; this frame includes two SCS Descriptor elements, each one containing a QC element for the traffic flow in a particular direction (UL or DL). Each SCS stream created (identified by its SCS ID) for which traffic characteristics were provided using the QC element, now has the corresponding QC element maintained with the SCS stream.
)
FIGURE 7-12 SCS Descriptor with QoS Characteristics Element
For a DL SCS stream (with a QC element for downlink), the DL traffic flow continues to be identified using the TCLAS element(s) (and optionally TCLAS Processing element) as was defined in 802.11aa. However, the use of SCS for indicating the requirements for an UL traffic flow, by signaling a QC element for the uplink, was introduced in 802.11be for the first time. For an UL SCS stream, the 802.11be amendment mandates that no TCLAS element(s) are provided in the SCS Request frame. This means that the AP cannot identify the traffic flows (and corresponding application) for which STA is requesting UL resources in the SCS Request frame. This limitation made it difficult to apply the network policy at the AP to the UL SCS streams. This was recognized as a gap in the 802.11be TG, but the group did not reach consensus on supporting TCLAS element(s) for UL SCS streams.
The AP’s scheduling behavior differs for DL versus UL traffic flows. For a DL traffic flow, an SCS exchange based on the QoS Characteristics element is illustrated in Figure 7-13. The SCS Request frame requests an SCS stream for one or more flows, each with a DL TCLAS element (or DL TCLAS elements + TCLAS Processing element) and a QC element with its Direction field set to downlink. At a minimum, the following set of traffic characteristics must be provided: the minimum and maximum service interval, minimum data rate, and delay bound. Note that the minimum and maximum service interval parameters are not required for DL scheduling and can be set to unspecified. The AP decides whether to accept or reject the SCS request based on its policy and resource availability.13 In the example, AP accepts the request and sends an SCS Response frame with Success status. The AP then processes the matching DL MSDUs for that traffic flow, taking into account the DL traffic characteristics indicated in the QC element. For example, the AP’s DL scheduling logic attempts to meet the delay bound and minimum data rate requirements specified for the DL flow.
)
FIGURE 7-13 SCS Exchange with QoS Characteristics for DL Traffic Flow
For an UL traffic flow, an SCS exchange based on the QoS Characteristics element is illustrated in Figure 7-14. The SCS Request frame includes a QC element with its Direction field set to uplink and includes, at a minimum, the following set of traffic characteristics: the minimum and maximum service intervals, minimum data rate, and delay bound. The delay bound may be unspecified, as it is not required for UL scheduling at the AP. Note that the TCLAS elements, TCLAS Processing element, and Intra-Access Category Priority element are not included. The AP decides to accept or reject the SCS request based on its policy and resource availability. In this UL flow example, the AP accepts the request and sends an SCS Response frame with Success status. The AP then periodically schedules UL trigger frames while taking into account the UL traffic characteristics indicated in the QC element. For example, the AP’s UL scheduling logic attempts to schedule trigger frames at an interval that falls within the minimum and maximum service intervals and attempts to meet the minimum data rate for the UL flow.
)
FIGURE 7-14 SCS Exchange with QoS Characteristics for UL Traffic Flow
A STA can send a single SCS Request frame with two SCS Descriptor elements to request resources for both the downlink and uplink flows. Thus, the SCS exchanges depicted in Figure 7-13 and Figure 7-14 can also be performed via a single SCS request/response exchange.
Another important aspect of the SCS feature in 802.11be is that it is defined at the multi-link device (MLD) level, rather than at the individual link level. As a result, a traffic flow corresponding to a DL SCS stream can be scheduled on any enabled link where the TID corresponding to the flow is mapped in the downlink (see the “TID-to-Link Mapping” section in Chapter 6), so as to meet the flow traffic characteristics specified in the QC element. Similarly, an AP can send triggers for an UL SCS stream on any link where the corresponding TID is mapped in the uplink and STA is not in power save mode. This provides scheduling flexibility to the AP for UL and DL SCS streams, improving the chances that the AP will be able to meet the QoS requirements for the flows.
Overall, the SCS protocol, as enhanced by the QoS Characteristics element in 802.11be, solves the key issue of providing traffic characteristics for flows at finer granularity to the AP, thereby facilitating better QoS-based scheduling in DL and UL. This feature shows promise in addressing the QoS requirements of existing and emerging applications such as video-conferencing collaboration, XR apps on HMD devices with remote rendering, and robotics applications in the industrial IoT arena. The SCS with QoS Characteristics element feature is an optional feature in 802.11be for both the AP and the STA. The Wi-Fi Alliance’s QoS Management (Release 3) certification program also included this feature as an optional feature, opening up opportunities for this feature to be adopted more widely by AP and STA devices across a variety of market segments (e.g., enterprise, residential, and industrial).