TID-BASED COMMUNICATION METHOD AND MULTILINK APPARATUS USING STREAM CLASSIFICATION SERVICES FOR DELAY-SENSITIVE STREAMS - Patent application

The stream classification service method maps low-latency traffic to a dedicated TID in multilink wireless communications, addressing head-of-line blocking and sequence numbering issues, enhancing latency and reliability for low-end devices.

JP2025500731AActive Publication Date: 2025-01-15CANON KK
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024523826
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2021-12-17
Filing Date
2022-12-16
Publication Date
2025-01-15
Estimated Expiration
2042-12-16

AI Technical Summary

Technical Problem

Existing solutions for managing low-latency data streams in multilink wireless communications, such as those defined in IEEE 802.11be, are inadequate for low-end devices, leading to issues like head-of-line blocking and sequence numbering problems due to the need for additional processing to separate low-latency data from regular data within the same traffic class.

Method used

A communication method that uses a stream classification service (SCS) to map low-latency traffic streams to a dedicated target TID, with affected user priorities remapped to a fallback TID, allowing low-end devices to manage low-latency traffic efficiently without global remapping across the network.

Benefits of technology

This approach enables effective management of low-latency traffic in low-end devices by avoiding sequence numbering issues and ensuring proper communication of low-latency data streams, improving latency and reliability in multilink wireless networks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025500731000001_ABST
    Figure 2025500731000001_ABST
Patent Text Reader

Abstract

To facilitate triggering by the AP MLD of uplink communication of low-latency streams from non-AP MLDs, the present invention proposes that local traffic streams are identified using a stream classification service (SCS). The local SCS traffic streams are mapped to the target TIDs previously mapped in the affected UP. The local SCS streams are preferably assigned to alternative queues of the AC. The affected UPs are also mapped to fallback TIDs corresponding to the primary queues of the same AC. The SCS streams are advertised to the AP using SCS Request frames. Conventional fields can be used. A trigger frame from an affiliated AP in the AP MLD can then grant resource units to the affiliated non-AP stations dedicated to the target TID and thus specific to the low-latency SCS stream.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates generally to wireless communications, and more particularly to multi-link (ML) communications. [Background technology]

[0002] With the development of delay-sensitive applications such as online gaming, real-time video streaming, virtual reality, drone or robot remote control, better throughput, low latency and robustness requirements and issues need to be taken into consideration. Such issues are currently being considered by the IEEE 802.11 Working Group as the primary objective for issuing the next major 802.11 release, known as 802.11be or Extremely High Throughput (EHT).

[0003] Low-Latency and Reliable Service (LLRS) is defined as such a primary objective target: a service provided to higher layer traffic streams that prioritizes and delivers MSDUs (Data Units) within a worst-case delay budget with a given reliability / packet delivery ratio (PDR) and low jitter.

[0004] The IEEE P802.11be / D1.3 version (before November 2021, "D1.3 standard") introduces Multi-Link (ML) Operation (MLO), which improves data throughput by enabling communication between stations over multiple simultaneous and non-continuous communication links.

[0005] Multi-link operation allows a non-AP (Access Point) MLD (ML Device) to register with an AP MLD, i.e., discover, authenticate, associate, and set up multiple links with the AP MLD. Each link allows channel access and frame exchange between the non-AP MLD and the AP MLD based on supported capabilities exchanged during association.

[0006] An MLD is a logical entity with multiple affiliated stations (APs or non-APs) and a single Medium Access Control (MAC) Service Access Point (SAP) for a Logical Link Control (LLC) containing one MAC data service. An AP MLD is thus made up of multiple affiliated APs, while a non-AP MLD is made up of multiple affiliated non-AP stations. Affiliated stations in both AP MLD and non-AP-MLD can communicate with affiliated stations in another MLD via each of multiple communication links that are set up using 802.11 mechanisms.

[0007] During ML discovery, the non-AP MLD discovers various wireless links available through the AP MLD through its various affiliated APs. From the discovered links (affiliated APs), the non-AP MLD builds a set of candidate links that associate the affiliated APs with the affiliated non-AP stations. During ML setup, the non-AP MLD cooperates with the AP MLD to set up links used for data exchange between the non-AP MLD and the AP MLD.

[0008] To meet the low latency requirements in EHT as well as to increase the efficiency of UL MU operation, the Stream Classification Service (SCS) mechanism, originally defined in the IEEE / 802.11aa standard, is included in the D1.3 standard with some adaptations. The SCS mechanism for multilink allows a non-AP MLD to define and advertise an AP MLD for local traffic streams, identified by the SCS identifier SCSID.

[0009] Co-pending application GB 2108299.5 provides for an expanded use of the SCSID identifier in both trigger frames (for UL MU operation) and service periods (e.g., target wake-up time periods (TWT)) dedicated to low-latency flow delivery. Local traffic streams with SCSIDs can be defined for low-latency flows and advertised to the AP MLD. The AP MLD can then allocate resources specific to one or more of those low-latency traffic streams based on the received advertisements.

[0010] However, the proposed solutions are not entirely satisfactory.

[0011] Dedicated behavior is required in non-AP stations to finely separate low latency data (forming SCS traffic streams) from normal data belonging to the same traffic class, i.e. with the same traffic identifier (TID) priority. For example, a specific labeling of data in the AC queue can be implemented. Low-end stations may not be adapted to such additional processes.

[0012] In addition, during triggered UL MU operation or service periods dedicated to SCS low latency traffic streams, normal data with the same TID in the AC queue is not transmitted, which creates problems with managing sequence numbering for block acknowledgments by the AP. In particular, head-of-line blocking may occur. Summary of the Invention

[0013] A broad object of the present invention is to overcome some of the problems mentioned above. An improved SCS mechanism may be used to allow non-AP MLD to reserve local TID queues associated with low latency streams.

[0014] The present invention relates to a communication method in a wireless network, the method comprising the steps of: The present invention relates to a communication method that includes performing communication with an AP MLD based on a traffic identifier (TID), which may relate to, for example, triggered UL MU operation or a service period directly targeted to a particular TID or another class (e.g., access category) corresponding to the TID.

[0015] According to the present invention, the method in non-AP MLD further comprises: The method includes identifying a local traffic stream using a stream classification service (SCS), mapping the local traffic stream to a target TID previously mapped with an affected user priority, and mapping the affected user priority (UP) to a fallback TID, which is distinct from the target TID.

[0016] The mapping may be temporary as long as the SCS local traffic stream is being generated. Thus, data with affected UP is remapped from the target TID (initial mapping) to the fallback TID. This applies to both data already stored in the queue identified by the target TID and new data arriving at the classifier that maps the data to the AC.

[0017] In the present invention, a specific TID, the target TID, is dedicated to the local SCS stream. Then, communication of this specific SCS stream with the AP MLD can be performed using the specific target TID, while the conventional UP is still mapped on other TIDs for proper communication. In particular, the AP MLD can then easily trigger uplink communication from a non-AP MLD that is dedicated only to the local SCS stream using the target TID.

[0018] Advantageously, the present invention avoids sequence numbering issues and additional mechanisms for identifying local SCS streams within the stored data having said target TID, and therefore low latency traffic management can be implemented in low end devices.

[0019] Furthermore, the present invention allows each registered non-AP MLD to individually declare its local SCS streams on demand (i.e., only when needed) and adjust the TID-to-UP mapping accordingly with the AP MLD. There is no need to provide a global remapping that affects all non-AP MLDs in the wireless network.

[0020] From the viewpoint of AP MLD, the communication method in a wireless network is as follows: The method includes performing communication with one or more non-AP MLDs based on a traffic identifier (TID).

[0021] According to the present invention, the method in AP MLD further comprises: Receive a Stream Classification Service (SCS) request frame from the non-AP MLD to add a local traffic stream to the non-AP MLD, and in response to receiving it, map the local traffic stream to a target TID previously mapped with the affected user priority and map the affected user priority (UP) to a fallback TID. These mappings apply only to communications with that non-AP MLD and not to the entire BSS. The AP MLD, as a gateway to other networks, now uses the mappings to correctly forward SCS data (if any) via the target TID and data with the affected UP via the fallback TID.

[0022] In some embodiments, the method in the non-AP MLD further includes sending a stream classification service (SCS) request frame to the AP MLD that adds the local traffic stream. This allows the AP MLD to configure itself with the new mapping in response. The request may specify a target TID to be used for the mapping, or may simply specify an access category (usually consisting of two TIDs), and may specify whether a primary queue (i.e., TID) or an alternate queue (i.e., a separate TID) should be used.

[0023] In some embodiments, the SCS request frame includes an SCS identifier of a local traffic stream, which signals the target TID to be mapped and / or the affected UP to which the target TID was previously mapped.

[0024] In some embodiments, the SCS request frame includes an SCS descriptor, the SCS descriptor comprising: Identifying local traffic streams using an SCS Identifier (SCSID), signaling the target TID and / or the affected UP; In accordance with IEEE P802.11be / D1.3, an Alternate Queue field is included within the Intra-AC Priority element, which specifies whether a primary queue or an alternate queue within the same access category is dedicated to store the local traffic stream. This advantageously conforms to the conventional format of the SCS descriptor, and the Intra-AC Priority element is mandatory for the signaling of the present invention.

[0025] In some embodiments, an access category includes queues identified by a target TID or an affected UP. For example, if the target TID or corresponding affected UP is 4, then the AC is a video (VI) that manages a queue with TID=4 and a queue with TID=5.

[0026] In other embodiments, the target TID is signaled in a TID field provided in the Control Info field of the QoS Characteristics element according to IEEE P802.11be / D1.3 in the SCS Descriptor and / or the affected UP is signaled in a User Priority field provided in the Alternate Queue field.

[0027] In some embodiments, the target TID identifies an alternate queue of a pair of primary and alternate queues that form an 802.11 access category. The queues are implemented at the Medium Access Control (MAC) level.

[0028] In some embodiments, the fallback TID identifies the primary queue, which ensures that data with the affected UP is still transmitted using the same EDCA parameters (through the corresponding AC), and therefore they maintain the same priority level.

[0029] In some embodiments, mapping the affected UP to a fallback TID includes moving data with the affected UP from a queue identified by the target TID to another queue identified by the fallback TID, and the sequence number of the data is adapted (updated) to the other queue when it is moved to the other queue. The same may be applied in AP MLD.

[0030] The sequence number (SN) updates attempt to maintain SN continuity within each TID, i.e., across the affected UP and all data corresponding to the UP already mapped onto the fallback TID. As an example, when UP=4 is mapped to TID=5, data in the queue identified by TID=4 is moved to the queue identified by TID=5 and their SNs are modified to provide continuity with the SNs of the data in the queue identified by TID=5.

[0031] In some embodiments, the method further includes sending an SCS request frame to the AP MLD or receiving from the non-AP MLD to remove the local traffic stream, and in response to receiving, unmapping the local traffic stream from the target TID.

[0032] The target TID thus becomes available to be used for another SCS stream, in which case a new SCS request frame adding the new local traffic stream is sent mapped onto the target TID.

[0033] The target TID also becomes available to receive back data with the affected UP currently stored in the fallback queue, in which case the method may further comprise mapping the affected UP back to the target TID. The sequence number of the data moved back to the corresponding queue may also be updated.

[0034] Control over whether data with the affected UP should be mapped back to the target UP may be implemented in the non-AP MLD. For example, the SCS removal request frame may signal whether the affected UP should be mapped back onto the target TID. For example, such signaling is conveyed in the Alternate Queue field of the Intra-AC Priority element of the SCS Descriptor according to IEEE P802.11be / D1.3 in the SCS removal request frame.

[0035] The present invention also relates to a method of communication in a wireless network, comprising: The present invention relates to a communication method, which includes transmitting, to an AP MLD, a stream classification service (SCS) request frame, the SCS request frame including an Intra-Access Category Priority element and a QoS Characteristics element, wherein a User Priority subfield included in the Intra-Access Category Priority element and a User Priority subfield included in the QoS Characteristics element are set to the same value.

[0036] The present invention also relates to a Stream Classification Service (SCS) request frame for communication in a wireless network, the SCS request frame including an Intra-Access Category Priority element and a QoS Characteristics element, wherein a User Priority subfield included in the Intra-Access Category Priority element and a User Priority subfield included in the QoS Characteristics element are set to the same value.

[0037] The present invention also provides a wireless communication device comprising at least one microprocessor configured to perform the steps of any of the above methods. The wireless communication device may be either non-AP MLD or AP MLD.

[0038] The wireless communication device further comprises one or more access categories AC having one primary queue and one alternate queue, where the target TID to which the local traffic stream is mapped identifies an alternate queue of an AC and the fallback TID identifies a primary queue of that AC.

[0039] Another aspect of the invention relates to a non-transitory computer readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any of the methods defined above.

[0040] At least some of the methods according to the invention may be computer-implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

[0041] Since the present invention can be implemented in software, the present invention can be implemented as computer readable code for provision to a programmable device on any suitable carrier medium. A tangible non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device, or a solid-state memory device. A transient carrier medium may include a signal such as an electric signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal, or an electromagnetic signal, e.g., a microwave or RF signal. [Brief description of the drawings]

[0042] Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings, in which: [Figure 1] FIG. 1 shows an example of a multi-link arrangement according to 802.11be. [Figure 2A] Figure 2a shows an example of a reference model for an 802.11be multilink device, and Figure 2b shows an IEEE 802.11e EDCA device with four access categories when deployed on multiple links. [Figure 2B] FIG. 2B shows an example of mapping between eight priorities of traffic classes and four EDCA ACs. [Diagram 3] FIG. 3 shows the QoS Map element according to IEEE802.11be D1.3. [Figure 4A] FIG. 4A shows the stream classification service mechanism proposed in IEEE 802.11be D1.3. [Figure 4B] FIG. 4B shows the stream classification service mechanism proposed in IEEE 802.11be D1.3. [Diagram 5] FIG. 5 illustrates, using a flowchart, an exemplary method for non-AP MLD and AP MLD, respectively, according to an embodiment of the present invention. [Figure 6]FIG. 6 illustrates, using a flowchart, an exemplary method for non-AP MLD and AP MLD, respectively, according to an embodiment of the present invention. [Figure 7] FIG. 7 illustrates a modified SCS descriptor according to an embodiment of the present invention. [Figure 8] FIG. 8 illustrates an architectural concept of inter-queue priority mapping according to an embodiment of the present invention. [Figure 9] FIG. 9 illustrates, using a flowchart, an exemplary embodiment of the present invention implemented in a QoS classifier entity of a non-AP MLD. [Figure 10A] FIG. 10A shows an example mapping between eight priorities of traffic classes and various SCS streams going to eight EDCA ACs. [Figure 10B] FIG. 10B shows an example mapping between eight priorities of traffic classes and various SCS streams going to eight EDCA ACs. [Figure 11A] FIG. 11A illustrates the hardware and software architecture of a multi-link communication device in accordance with at least one embodiment of the present invention. [Figure 11B] FIG. 11B illustrates the hardware and software architecture of a multi-link communication device in accordance with at least one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0043] The techniques described herein may be used for various broadband wireless communication systems, including communication systems based on orthogonal multiplexing schemes. Examples of such communication systems include spatial division multiple access (SDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and single carrier frequency division multiple access (SC-FDMA) systems. SDMA systems may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e., wireless devices or stations. TDMA systems may allow multiple user terminals to share the same frequency channel by dividing a transmission signal into different time slots or resource units, with each time slot being assigned to a different user terminal. OFDMA systems utilize orthogonal frequency division multiplexing (OFDM), which is a modulation scheme that divides the entire system bandwidth into multiple orthogonal subcarriers or resource units. These subcarriers may also be referred to as tones, bins, etc. In OFDM, each subcarrier may be independently modulated with data. An SC-FDMA system may utilize Interleaved FDMA (IFDMA) to transmit on subcarriers distributed across the system bandwidth, utilize Localized FDMA (LFDMA) to transmit on blocks of adjacent subcarriers, or utilize Evolved FDMA (EFDMA) to transmit on multiple blocks of adjacent subcarriers.

[0044] The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatus (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (so-called AP) or a non-access point (so-called non-AP station or STA).

[0045] It should be noted that it is not excluded that a device may operate as an AP of one wireless network and at the same time belong to another (neighboring) wireless network as a STA. This may occur in the context of multi-AP technology, which consists in enabling a degree of cooperation between neighboring APs in order to have a more efficient use of limited time, frequency and available spatial resources. In such technology, two neighboring APs can share resources in terms of frequency or time, thus preventing interference. APs that cooperate to share resources are called cooperative APs. Furthermore, data transmissions established by cooperative APs are called multi-AP transmissions.

[0046] Although the examples are described in the context of a WiFi (RTM) network, the invention may be used in any type of wireless network, such as, for example, a mobile phone cellular network, which implements very similar mechanisms.

[0047] A non-AP station may comprise, be implemented as, or be known as a subscriber station, subscriber device, mobile station (MS), remote station, remote terminal, user terminal (UT), user agent, user device, user equipment (UE), user station, or some other terminology. In some implementations, a STA may comprise a cellular telephone, a cordless telephone, a session initiation protocol ("SIP") telephone, a wireless local loop ("WLL") station, a personal digital assistant ("PDA"), a portable device with wireless connectivity, or some other suitable processing device connected to a wireless modem. Thus, one or more aspects taught herein may be incorporated into a telephone (e.g., a mobile phone or smartphone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device configured to communicate via a wireless or wired medium. In some aspects, a non-AP station may be a wireless node. Such a wireless node may, for example, provide connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link.

[0048] An AP manages a set of stations that collectively organize their access to the wireless medium for communication purposes. The stations (including the AP) form a service set, hereafter referred to as a basic service set, BSS (although other terms may be used). The same physical station acting as an access point may manage more than one BSS (and thus corresponding WLANs), each BSS being therefore uniquely identified by a specific basic service set identification, BSSID, and managed by a separate virtual AP implemented within the physical AP.

[0049] The 802.11 family of standards defines various medium access control (MAC) mechanisms for driving access to the wireless medium.

[0050] With regard to MAC layer operation, current discussions in Task Group 802.11be, as outlined in the November 2021 draft IEEE P802.11be / D1.3, will introduce multilink operation (MLO), which allows a multilink device to establish or set up multiple links and operate them simultaneously.

[0051] A Multi-Link Device (MLD) is a logical entity that has two or more associated (AP or non-AP) stations (STAs) and has a single Medium Access Control (MAC) Service Access Point (SAP) for a Logical Link Control (LLC) that contains one MAC data service. Additionally, the MLD also has a single address associated with the interface that can be used to communicate over a distributed system medium (DSM).

[0052] Stations forming the same MLD may be partially or entirely co-located within the same device, or may be geographically distributed.

[0053] An access point multilink device (AP MLD) corresponds to an MLD in which each station (STA) belonging to the MLD is an AP, and is hereinafter referred to as an "affiliate AP."

[0054] A non-access point multilink device (non-AP MLD) corresponds to an MLD in which each station (STA) associated with the MLD is a non-AP station, hereinafter referred to as an "associated non-AP station."

[0055] When referring hereinafter to either an AP MLD or a non-AP MLD, the general term "Station MLD" may be used.

[0056] In some contexts, the terms "multilink device", "ML device (MLD)", "multilink logical entity", "ML logical entity (MLE)", "multilink set", and "ML set" are synonyms for designating the same type of ML device.

[0057] An example of two MLDs, an AP MLD 10 and a non-AP MLD 11, establishing a multi-link communication session for exchanging data units according to 802.11be is shown in FIG.

[0058] As shown, AP MLD 10 comprises three participating APs 100-x, 100-y, and 100-z, and non-AP MLD 11 comprises three participating non-AP STAs 110-x, 110-y, and 110-z. Although the illustrated MLD is made up of three participating non-AP stations or APs, MLDs having other numbers of participating non-AP stations or APs can be contemplated using the same teachings.

[0059] Each station 100-x, 110-x, 100-y, 110-y, 100-z, or 110-z is a logical entity that is a single, addressable instance of a medium access control (MAC) and physical layer (PHY) interface to the wireless medium.

[0060] Multiple affiliated non-AP stations in the non-AP MLD can then set up communication links with multiple associated APs in the AP MLD, thus forming a multi-link channel.

[0061] As shown in Fig. 1, the communication links 15-x, 15-y, and 15-z are physical paths that can be used to transfer MAC service data units (MSDUs) between the relevant non-AP stations and the relevant APs. Thus, the communication link 15-x is a communication channel established between the AP 100-x and the non-AP STA 110-x. Similarly, the communication links 15-y and 15-z correspond to communication channels established between the AP 100-y and the non-AP STA 110-y and between the AP 100-z and the non-AP STA 110-z, respectively.

[0062] Thus, a communication link or “link” corresponds to a given channel (e.g., 20 MHz, 40 MHz, etc.) in a given frequency band (e.g., 2.4 GHz, 5 GHz, 6 GHz) between APs 100-x, 100-y, 100-y associated with the AP MLD 10 and non-AP STAs 110-x, 110-y, 110-z associated with the non-AP MLD 11.

[0063] As shown in Figure 1, AP 100-x and non-AP STA 110-x, AP 100-y and non-AP STA 110-y, and AP 100-z and non-AP STA 110-z operate in the following frequency bands, x GHz, y GHz, and z GHz, respectively. These frequency bands may be different from each other, such that corresponding communication links 15-x, 15-y, 15-z belong to the respective frequency bands, x GHz, y GHz, and z GHz. Alternatively, the links may belong to the same frequency band, i.e., the STAs may use the same frequency band.

[0064] Preferably, the links established for MLD are considered to be completely independent, meaning that channel access procedures (to the communication medium) and communications are performed independently on each link. Thus, different links may have different data rates (e.g., due to different bandwidths, number of antennas, etc.) and may be used to communicate different types of information (each over a particular link).

[0065] Affiliated AP and non-AP stations may operate on their respective channels in accordance with one or more of the IEEE 802.11 standards (a / b / g / n / ac / ad / af / ah / aj / ay / ax / be) or other wireless communication standards.

[0066] Thanks to multi-link aggregation, traffic associated with a single MLD can be transmitted across multiple parallel communication links, thereby increasing network capacity and maximizing utilization of available resources.

[0067] The terms "traffic" and / or "traffic stream," as used herein, are defined as data flows and / or streams between wireless devices.

[0068] Although FIG. 1 shows an ML AP device and an ML non-AP device establishing an ML communication session, two non-AP MLDs may also establish such an ML communication session for DirectLink (or peer-to-peer) communication.

[0069] FIG. 2A shows an exemplary 802.11be multilink reference model for MLD, which may be an AP MLD (eg, as AP MLD 10 in FIG. 1) or a non-AP MLD (eg, as non-AP MLD 11 in FIG. 1).

[0070] The MLD comprises a PHY layer 200, a MAC layer 220, a Logical Link Control (LLC) sublayer 240, and higher layers 260.

[0071] The upper layers 260 may include applications that generate traffic data or use received traffic data.

[0072] The transmission and reception of traffic data is handled by the MAC 220 and PHY 200 layers. Such transmission and reception of traffic data may occur over multiple links, such as the ones 15-x, 15-y, 15-z introduced with reference to FIG.

[0073] Traffic data is provided by higher layers as a sequence of data frames, i.e., a "traffic stream". Each traffic stream, and therefore each data frame, is associated with an Access Category (AC), as defined in the EDCA mechanism (Figure 2a (Figure 2b)). This mapping between streams or data frames and ACs is performed by classifier 213.

[0074] Recall that 802.11 stations (AP and non-AP stations) maintain four Access Categories (ACs), each with one or more corresponding transmit buffers or queues. The four ACs are conventionally defined as follows: - AC1 and AC0 are reserved for best effort and background traffic. They have the second lowest priority and the lowest priority, respectively.

[0075] - AC3 and AC2 are usually reserved for real-time applications (eg, voice or video transmission). They have the highest and second highest priority, respectively.

[0076] Data frames arriving from higher layers of the protocol stack, also known as MAC Service Data Units (MSDUs), are mapped by the classifier 213 to one of the four ACs and thus entered into the queue of the mapped AC. The mapping is based on the traffic class of the MSDU, which is deduced from the so-called DSCP field (described below) in the data unit. Thus, 802.11 stations support a traffic prioritization similar to DiffServ (Differentiated Services), where the mapping is performed between one of eight priorities of the traffic class (also known as User Priority or UP) of the incoming MSDU to the corresponding one of the four ACs according to predefined mapping rules.

[0077] 2B shows an example mapping between eight UPs (values ​​between 0 and 7 according to IEEE 802.1d) and four ACs. This designation is an indication of general usage and guidance according to Table 10-1-UP-AC mapping of the 802.11-2020 standard.

[0078] The traffic class or UP is indicated within the MSDU using a traffic identifier (TID) that ranges from 0 to 7, often the same value as the UP. Each MSDU therefore includes an indication as to the type of data it contains, i.e. an indication reflecting the access category or priority level. This mapping is conventionally managed by the AP for its entire BSS and provided to non-APs upon association. Other mappings different from the example of FIG. 2B can be implemented.

[0079] Figure 2a (Figure 2b) shows an implementation model with four transmit queues (flat lines), one for each access category.

[0080] Other implementations, such as those provided in the IEEE / 802.11aa standard, add two queues for the two ACs: one alternate video queue (A_VI) for AC VI and one alternate voice queue (A_VO) for AC VO. Each alternate queue shares the same EDCA function (EDCAF) as the other (named "primary") transmit queue of the same AC (VI or VO). The alternate queues are shown diagrammatically by the dotted lines (AAC2 and AAC3) in Figure 2A (Figure 2b). In practice, the two UPs (and therefore the two TIDs) of the same AC are associated with the alternate and primary queues of that AC, respectively.

[0081] Since the same EDCAF is used for both the primary and alternate queues of the same AC, the scheduling function above the EDCAF implements a selection mechanism to select an MSDU from either the primary or alternate queue when transmitting data. In particular, a queue with a higher UP is selected with a higher probability than a queue with a lower UP.

[0082] In an implementation, a transmit queue may be provided per UP (versus per AC), resulting in eight transmit queues forming four pairs (one for each AC) of primary and alternate queues (one for each UP or TID belonging to the AC).

[0083] The 802.11be multilink reference model reflects the fact that MLD may transmit using several links, particularly at the MAC layer 220 and PHY layer levels.

[0084] The MAC layer 220 includes a Unified Upper MAC (UMAC) layer 230. The UMAC 230 is responsible for link-agnostic MAC procedures such as sequence number allocation, MAC Protocol Data Unit (MPDU) encryption / decryption, and acknowledgment scoreboarding procedures. Sequence number allocation consists of the UMAC 230 appending an increasing sequence number to each MSDU with the same UP (and therefore the same TID). This helps to track the order of the MSDUs while allowing block acknowledgments.

[0085] Thus, each data unit MSDU arriving at the MAC layer 220 from the upper layer 260 (e.g., link layer) with a type of traffic (UP, hence TID) priority is mapped to one of the ACs according to the mapping rules in the UMAC layer 230. Then, still in the UMAC layer 230, the data unit MSDU is given the next available sequence number and stored in the queue corresponding to its TID (or UP) within the AC to which it is mapped.

[0086] As shown in FIG. 2A (Figure 2b), each AC also has its own set of queue contention (EDCA and / or MU-EDCA according to IEEE 802.11ax-2021) parameters for each link (e.g., 220-x, 220-y, 220-z), associated with a priority value and thus defining the higher or lower priority traffic of the MSDU. Thus, there are multiple traffic queues for serving data traffic with different priorities for a given link. The contention window CW and backoff values ​​are known as EDCA variables and are specific to each link 15-x, 15-y, or 15-z shown in FIG. 1.

[0087] That means that each AC acts as an independent DCF contention entity on a given link, including its respective queue backoff engine 211. Thus, each queue backoff engine 211 uses the queue contention parameters and derives a backoff value (from the CW) associated with a respective traffic queue 210 to initialize a respective queue backoff counter specialized per AC and per link. The backoff counters are used to contend for access to link 15-x (15-y, 15-z) to transmit the data stored in the queue of the AC.

[0088] Each traffic queue 210 is associated with at least a set of respective queue backoff engines 211, one for each active link.

[0089] When access to the wireless medium is granted for an AC on a link (e.g., any of 15-x, 15-y, or 15-z), the MSDUs stored for that AC are sent to the physical (PHY) layer 200 for transmission over the link.

[0090] Due to the specialization of the EDCAF per link, the MAC layer and PHY layer structures are adapted accordingly, as shown in Figure 2a.

[0091] The MLD MAC layer 220 comprises a number of blocks called Lower MACs (LMACs) 220-x, 220-y, 220-z for each of the plurality of links 15-x, 15-y, 15-z.

[0092] The MLD PHY layer 200 similarly comprises a number of PHY blocks 200-x, 200-y, 200-z, each dedicated to a respective one of the multiple links 15-x, 15-y, 15-z.

[0093] The UMAC layer then further provides a UMAC interface with link specific blocks 220-x, 220-y, 220-z, providing UMAC Service Access Points (SAPs) to the LLC 240 and upper 260 layers.

[0094] Of course, the number of blocks depends on the number of links the MLD can manage.

[0095] In this example, LMAC layer 220-x is associated with link 15-x via PHY layer 200-x, LMAC layer 220-y is associated with link 15-y via PHY layer 200-y, and LMAC layer 220-z is associated with link 15-z via PHY layer 200-z. In other words, each link 15x / y / z may have an associated LMAC layer 200-x / y / z that implements link-specific features such as channel, e.g., link access.

[0096] To access the wireless medium, such as link 15-x, affiliated stations (non-AP stations and APs) active on that link 15-x compete using Enhanced Distributed Channel Access (EDCA) contention to be granted a transmission opportunity (TXOP). Then, during the TXOP, the affiliated station that has gained access may transmit (single-user (SU)) data frames over the link. Note that legacy devices (i.e., not associated with MLD) may operate simultaneously on any one of the links.

[0097] As an alternative to SU transmission, the involved stations may also use a multi-user (MU) scheme to access the wireless medium, for example, link 15-x. In the MU scheme, a single involved station, for example, AP 100-x, active on link 15-x is able to schedule MU transmissions, i.e., multiple simultaneous transmissions (in so-called resource units) with other involved non-AP stations active on the same link. One implementation of such a MU scheme is adopted, for example, in the IEEE 802.11ax amendment standard as a multi-user uplink and downlink OFDMA (MU UL and DL OFDMA) procedure. Thanks to the MU function, the involved non-AP stations have the opportunity to gain access to the wireless medium via two access schemes, namely, the MU scheme and the SU scheme (via conventional EDCA).

[0098] During an MU downlink (DL) transmission on an allowed communication channel, e.g., link 15-x, the serving AP 100-x may perform multiple simultaneous elementary transmissions to various serving non-AP stations via so-called resource units (RUs). As an example, the resource units may divide the link 15-x of the wireless network in the frequency domain, e.g., based on orthogonal frequency division multiple access (OFDMA) technology. The allocation of RUs to the affiliated non-AP stations is signaled at the beginning of the MU downlink frame by providing the associated identifier (AID) of the affiliated non-AP station for each RU defined in the transmission opportunity. The AID is obtained individually by each affiliated non-AP station of the non-AP MLD during the association procedure between the non-AP MLD and the AP MLD. Thus, the AID uniquely identifies the associated MLD station (and thus the affiliated non-AP station of the MLD on the link 15-x on which the MU frame is transmitted) and may be, e.g., a 16-bit value.

[0099] During a MU uplink (UL) transmission, various affiliated non-AP stations simultaneously transmit data to AP 100-x via resource units forming links 15-x.

[0100] To control the MU UL transmissions of the affiliated non-AP stations, the affiliated AP 100-x may transmit a control frame known as a trigger frame (TF) in advance. The TF may be used by the affiliated AP 100-x to allocate resource units to the affiliated non-AP stations of the same BSS using their AIDs assigned to them during the association procedure to the AP 100-x and / or using reserved AIDs that specify a group of affiliated non-AP stations. The TF may also define the initiation of MU UL transmissions by specific non-AP stations, the type of traffic (TID or AC) that they are allowed to transmit (if any, it is up to the station to decide otherwise), and their length.

[0101] Here, the focus is on QoS (Quality of Service) implemented in such wireless networks based on AC.

[0102] Indeed, maintaining proper end-to-end QoS is a key factor in providing interworking services because external networks may use different network layer (Layer 3) QoS practices. For example, the use of a particular Differentiated Services Code Point (DSCP) for a given service may vary between different networks. To provide proper QoS over the air in an IEEE 802.11 infrastructure, the DSCP-to-UP mapping for the corresponding network needs to be identified and made known to non-AP stations.

[0103] In IP packets, QoS marking is provided in the Type of Service (TOS) byte in a field called DSCP.

[0104] Although no explicit guidance is provided on mapping (6-bit) Layer 3 DSCP values ​​to (3-bit) Layer 2 markings (such as IEEE 802.1D, 802.1p, or 802.11e), common practice in the networking industry is to map them using a default DSCP-to-UP mapping, where the three Most Significant Bits (MSBs) of the DSCP are used as the corresponding L2 marking.

[0105] For 802.11, QoS capabilities are further limited with only four different access categories (voice, video, best effort, and background). When a QoS-enabled non-AP station / AP transmits an MSDU, a QoS control field is provided in the frame header along with the TID field to classify the MSDU. Three bits of the TID field, known as the User Priority (or UP) value, determine the priority the frame gets over the air. Since 802.11 has four different traffic classes, two UP values ​​are mapped to each access category.

[0106] The QoS Map distribution mechanism defined in IEEE 802.11-2020 11.22.9 provides a means for communicating mapping information from APs to non-AP stations.

[0107] Enterprise networks use a mapping based on application classes defined in IETF RFC 4594 and the recommended mapping to IEEE 802.11 UP defined in IETF RFC 8325.

[0108] A QoS Map element 30 that defines the DSCP-to-UP mapping is shown in Figure 3. This element is provided to non-AP stations in the Association Response or Reassociation Response frames exchanged during the association procedure with the AP.

[0109] The QoS Map element 30 maps upper layer priorities from the DSCP field used in the Internet Protocol to user priorities (UP).

[0110] The mapping between DSCP and UP can be done using the exception field 31 or the range 32. To that end, the QoS Map element contains two main components: 1) A set of eight "UP x DSCP Range" fields 32 (where x is from 0 to 7), each of which defines a range of DSCP values ​​that correspond to a UP value x; 2) The "DSCP Exception List" field 31 allows defining up to 21 exceptions from these range-based DSCP-UP mapping associations, each of which can map a specific DSCP to a UP.

[0111] The DSCP range in each field 32 is defined by a DSCP Low Value and a DSCP High Value.

[0112] The DSCP value ranges from 0 to 63. The DSCP range of each UP does not overlap with other UPs. The DSCP High Value is greater than or equal to the DSCP Low Value. If the DSCP Range High Value and Low Value are both equal to 255, it means the corresponding UP is not used.

[0113] When the Management Entity of the AP detects a change in the QoS mapping information, it can update all non-AP STAs with the new QoS Map Element 30. However, in practice this update is accomplished very infrequently, and most of the time never during the duration of the association.

[0114] The QoS Map 30 is a single exchanged piece of information that is common to all links (15-x, 15-y, 15-z) used by the AP MLD, since the same classification applies on the links. This means that the QoS mapping is managed at the MLD level. Therefore, modifying the QoS Map is no longer practical, since maintaining proper end-to-end QoS is a key factor in providing interworking services.

[0115] The QoS information exchanged between AP and non-AP stations also includes EDCA parameters that drive the backoff mechanism in Figure 2A (Figure 2b). In the ML architecture, the AP MLD provides such EDCA parameters in the Beacon frame, as well as in all Probe Response and (Re)Association Response frames. The EDCA parameters are specified in the so-called EDCA Parameter Set element. The AP can change the EDCA parameters over time by modifying the EDCA Parameter Set element in the Beacon, Probe Response and (Re)Association Response frames. However, in practice, the AP rarely changes them. The EDCA parameters are a piece of information specific to each AC and are local to a given link 15-x (15-y, 15-z) on which the BSS is running.

[0116] Once a multi-link association is established between the non-AP MLD and the AP MLD provided with the QoS Map 30 and EDCA parameters, multi-link communication can be set up over the link.

[0117] The MSDU may then be transmitted over multiple links, for example, using MPDU aggregation and channel access. The MU and SU schemes may be used independently for data transmission to multiple links over a given link. In particular, one of the MU schemes adopted in the IEEE / 802.11ax-2021 standard may be implemented independently on each link.

[0118] Thus, through multi-link aggregation, MPDUs belonging to the same TID can be transmitted on multiple links, and their transmission is generally independent from one link to another in terms of timing and resource allocation. By default, all TIDs are mapped to all setup links for both UL and DL directions, and non-AP MLD can use any link in the set of enabled links to transmit frames carrying MSDUs or A-MSDUs with that TID.

[0119] Optionally, the MSDUs may be subject to a TID-to-Link mapping. The TID-to-Link mapping may be negotiated between MLD entities during link setup and is intended to indicate the links over which the MSDUs belonging to each TID may be exchanged. As a result, the TID-to-Link mapping is a management function in charge of piloting the access of data to links 15-x, 15-y, and 15-z in both the UL and DL directions.

[0120] In order to meet the low latency requirements in EHT as well as to improve the efficiency of UL MU operation, the Stream Classification Service (SCS) mechanism originally defined in the IEEE / 802.11aa standard has been proposed to be used as a lightweight mechanism for non-AP stations to inform the AP of their QoS requirements, especially for low latency traffic.

[0121] Low-Delay Reliable Service, LLRS, is a service provided to higher layer traffic streams that prioritizes and delivers MSDUs within a worst-case delay budget with a given reliability / packet delivery ratio (PDR) and low jitter. Traffic that may be of interest to LLRS includes delay-sensitive data, i.e., data from applications such as gaming, media streaming, augmented reality, virtual reality, etc.

[0122] Initially, the SCS mechanism used TCLAS processing to enable the establishment of traffic streams, including higher layer signaling of packet drop eligibility (e.g., allowing some packets in a traffic stream to be tagged as drop eligible), and classification of the traffic streams into access categories.

[0123] A typical scenario for using SCS is to use a local traffic stream, after which the SCS mechanism provides signaling to select some packets in the traffic stream (drop eligible packets) with a view to discarding them in case of insufficient channel capacity. In short, the SCS mechanism aims to distinguish between distinct traffic streams within the same access category or same TID, covering the need to allow graceful degradation of a traffic stream in case of bandwidth shortage.

[0124] The SCS mechanism has recently been modified to fit the ML context: As specified in the D1.3 standard, a multi-link SCS procedure is provided in the context of robust audio-video streaming.

[0125] Similar to IEEE 802.11aa, the Multi-Link SCS procedure provides SCS Request frames and corresponding SCS Response frames to create / add, modify or delete SCS streams. SCS streams are defined in these SCS Request frames via so-called SCS Descriptors and identified by SCS Identifiers (SCSIDs) in SCS Response frames.

[0126] The SCS Descriptor has been modified with respect to the EHT Standard as shown in FIG. 4A to include a Traffic Specification called QoS Characteristic element 425 as a set of QoS characteristics, QoS parameters that describe the traffic characteristics and QoS expectations of the traffic flows belonging to the SCS Stream described by the SCS Descriptor.

[0127] The other fields in the SCS descriptor 400 retain their meaning.

[0128] Each traffic stream is assigned an ID by the affiliated non-AP station requesting classification. This ID, called an SCSID, is managed at the MLD level and is therefore unique across non-AP MLDs.

[0129] The Request Type field 421 is a number that identifies the type of SCS request: add, delete, or modify.

[0130] The optional Intra-Access Category Priority element 422 provides information to the AP MLD regarding the relative priority of SCS traffic streams within the AC. This corresponds to the optional introduction of two alternate queues proposed by the IEEE 802.11aa standard compared to the four primary queues of EDCA.

[0131] The TCLAS element 423 and the TCLAS Processing element 424, if present, describe the criteria for traffic classification that the non-AP MLD is required to apply to identify the data or MSDUs that form the corresponding SCS stream. These elements are mandatory for the downlink direction (traffic from the AP MLD to the non-AP MLD) but are prohibited in the current standard for the other direction (UL or direct link).

[0132] The recently introduced QoS Characteristics element field 425 contains zero or one QoS Characteristics element to describe the traffic characteristics and QoS expectations of the traffic flows belonging to this SCS traffic stream.

[0133] The recently introduced SCS mechanism introduced for the EHT standard remains a lightweight protocol for non-AP MLDs to signal their QoS requirements to AP MLDs.

[0134] As shown in FIG. 4B, the setup of an SCS stream uses non-AP MLD MAC Sublayer Management Entity (MLME) primitives (generated by the local Station Management Entity (SME) according to the 802.11 management architecture) and results in two sets of network frames: - An SCS Request frame 430 sent by a non-AP STA associated with a non-AP MLD towards the corresponding affiliated AP of the AP MLD. The SCS Request frame includes a QoS Characteristics element 425 with the Direction subfield set to uplink or downlink or bidirectional link. The SCS Request frame is interpreted as a request to create (or delete or modify depending on the value of the Request Type element 421) a traffic stream that is applied at the MLD level for low latency traffic.

[0135] - Upon receiving an SCS Request frame 430 from an associated non-AP STA, the associated AP responds with a corresponding SCS Response frame 431, whose format is much simpler (SCSID+status field).

[0136] Although the SCS mechanism allows SCS streams to be defined for low-delay traffic, the mechanism is still insufficient to properly handle such delay-sensitive streams.

[0137] Specifically, the SCS mechanism defines an SCS stream within an AC and within a TID, while each AC and each TID may contain two or more local, low-latency or not traffic streams (local applications). Therefore, it is not an easy task to manage an SCS stream separately from other streams of the same AC or same TID.

[0138] Also, the SCS mechanism focuses on DL traffic and does not address devices that are delay-sensitive data producers (e.g., head-mounted displays). In the current SCS mechanism, the AP MLD classifies MSDUs it receives from a distribution system (typically the Internet) based on SCS parameters (TCLAS) provided by the non-AP MLD via an SCS Request frame. For uplink traffic (i.e., MSDUs generated by non-AP MLDs), the TCLASS is not allowed to be specified, i.e., the AP does not have information useful for scheduling delay-sensitive data pending in the transmission queue (AC) of the non-AP MLD. Such scheduling for medium access may include trigger-based UL transmission or TWT service periods.

[0139] Co-pending application GB 2108299.5 provides for an extended use of the SCSID identifier in both trigger frames (UL MU operation) and Service Periods (e.g., Target Wake-up Periods (TWT)) dedicated to low-latency flow delivery. The TWT agreement for low-latency service periods is primarily a Broadcast TWT that specifies the characteristics of the SCS streams, and refers to the Restricted TWT (rTWT) in the D1.3 standard. These mechanisms allow the AP MLD to allocate specific resources (based on the received SCS descriptor) to one or more SCS traffic streams previously declared in an SCS Request frame. Such identification of low-latency traffic using the SCS mechanism provides better efficiency and finer granularity for delay-sensitive traffic.

[0140] Nevertheless, the proposed mechanism requires additional behavior in non-AP MLD to finely separate low-latency MSDUs (belonging to SCS streams) from other MSDUs in the transmission queue of an AC. Indeed, in case of the above mentioned trigger-based or TWT service period opportunities, only low-latency MSDUs (corresponding to traffic identified by SCSID) need to be retrieved and selected, and not other MSDUs of the same AC or same TID that are not low-latency. Marking of MSDUs in the transmission queue is optional.

[0141] Also, such a selection of subparts (SCS streams) of an MSDU with the same TID may have strong impacts on device implementations. For example, the continuity of sequence numbers within an MSDU may be lost since some MSDUs are prioritized in transport. This may affect the block acknowledgement mechanism (for acknowledging MSDUs) and thus increase the risk of head-of-line blocking for LL data.

[0142] In other words, SCSID-based low-latency traffic differentiation, unlike AP MLD, requires high-end devices that are often not available for non-AP MLD. In fact, non-AP MLD is often limited to low-end devices that are then limited to consider less satisfactory TID-based low-latency traffic differentiation (the less efficient transmission of low-latency MSDUs and non-low-latency MSDUs belonging to the same TID).

[0143] The present invention addresses this issue using the SCS mechanism to enable low-end EHT non-AP MLDs to manage low-latency traffic. The AP MLD is preferably considered a high-end device, in order to improve communication of low-latency traffic with the AP MLD based on TID (e.g., trigger-based or TWT service period opportunities to transmit as scheduled by the AP MLD).

[0144] There are two overlapping proposals.

[0145] First, local traffic streams are identified using a stream classification service (SCS). A stream classification service adapted for multilink devices is used to allow each non-AP MLD to report the specifications of a given (low-latency) traffic stream waiting to be transmitted with a first TID, selected locally and reserved by the non-AP MLD for the given traffic stream. The non-AP MLD still expects this TID to be scheduled by the AP MLD (through a trigger-based mechanism or TWT service period) for the transmission of its low-latency SCS stream.

[0146] Such a TID intended to be used for a local SCS stream is referred to below as a "target TID." Of course, when several local SCS streams are managed according to the present invention, multiple target TIDs are used, e.g., one for each local SCS stream. Also, in some embodiments, to implement the present invention, multiple SCS streams may be assigned to the same target TID, and thus the AP MLD schedules transmissions for those multiple SCS streams when using the target TID in schedule triggering.

[0147] Secondly, the local SCS traffic stream is mapped to the target TID. However, due to the conventional mechanism, the target TID may already be in use since it was previously mapped with the first user priority, so it is provided that the first user priority UP is also mapped to another TID. The second mapping ensures that the target TID is fully reserved and dedicated to the local SCS traffic stream.

[0148] The first UP is hereinafter referred to as the "affected UP" and the other TID is referred to as the "fallback TID".

[0149] Non-AP MLD may implement one additional queue in one or more ACs (up to 4) to have a pair of primary and alternate queues, each identified by two TIDs of the AC. Thanks to the mapping, one of the two queues (the one with the target TID) becomes reserved for the SCS traffic stream (with the SCSID) as soon as the corresponding SCS request (addition) is accepted. In order for the MSDUs with the affected UP to maintain their QoS, the MSDUs already stored in the alternate queue (associated with the target TID due to the initial mapping) may be forwarded to the other queue of the same AC (therefore, the one with the fallback TID).

[0150] For ease of explanation, in the following description, the queue dedicated to the SCS stream according to the invention is considered to be an alternate queue identified by a target TID, while the primary queue of the AC is used as a fallback queue for MSDUs initially stored in the alternate queue when a new SCS stream is added. The primary queue is therefore identified by a fallback TID. Of course, other implementations are conceivable (e.g., it may be contemplated to reverse the roles of the alternate and primary queues).

[0151] When an AP MLD receives an SCS request frame from a non-AP MLD, adding local SCS traffic, the AP MLD can recognize the new local SCS traffic stream. The target TID may be predefined (e.g., a single TID is available in each MLD, or several TIDs are available that are selected in a predefined order), but the SCS request frame may include the SCS identifier of the local traffic stream and signal the target TID to which the local traffic stream is mapped and / or the affected UP to which the target TID was pre-mapped. In fact, as described below, the target TID and the affected UP are intimately linked due to the initial UP-to-TID mapping, and one of them is sufficient to infer the other one. In the following description, the target TID is used as the main parameter to determine the AC, primary, or alternate queue to be replaced. The use and replacement of the affected UP can also be implemented as an alternative.

[0152] Upon receiving such an SCS description, the AP MLD recognizes the target TID that identifies the SCS stream, and can then use such target TID to accurately schedule subsequent UL transmissions (in SU or MU mode, or for a limited duration) for the low-latency SCS stream so defined.

[0153] By allowing non-AP MLD to specify a unique TID (target TID) for transmission of each identified low-latency traffic (SCS stream), the chances of being scheduled by AP MLD for low-latency traffic streams and having them respect low-latency constraints are improved.

[0154] 5 and 6 respectively show, using a flowchart, exemplary steps of a communication method in non-AP and AP MLDs according to an embodiment of the present invention. The two MLDs negotiate an SCS stream for a locally generated traffic stream in the non-AP MLD, which is then mapped solely onto a target TID to provide the AP MLD with the ability to schedule without other traffic streams. As mentioned above, this approach can be advantageously used to schedule low latency traffic.

[0155] In these flowcharts, it is assumed that the non-AP MLD has been preregistered with the AP MLD. Thus, multiple links are active between their respective affiliated non-AP stations and the AP. One of these links is selected by the MLD that initiates the process (here, mainly the non-AP MLD) and can carry the management frames used to negotiate the SCS stream.

[0156] Additionally, a non-AP MLD may declare its capability to implement the present invention. This can be done in the Capability element exchanged during registration. For example, an affiliated non-AP station sets a new control variable as an extension called dot11AlternateLLQoSMappingActivated. If dot11AlternateLLQoSMappingActivated is set to true (i.e., implementation of the present invention), then dot11SCSAActivated (already defined in D1.3) becomes true and dot11AlternateEDCAActivated (already defined) becomes true.

[0157] 5, a trigger event is detected in a non-AP MLD that identifies a local traffic stream to be treated as an SCS stream according to the present invention at step 510. Such a local traffic stream generated by a higher layer is, for example, low latency traffic.

[0158] For example, an MLME-SCS.request primitive is received locally from an upper application (SME of an affiliated non-AP station) requesting the associated MLME to send an SCS Request frame to the corresponding affiliated AP. A set of parameters required to identify this SCS stream are included in the primitive. They may therefore be stored locally so that further mapping to a target TID may be performed for that particular stream. For example, these parameters may be stored in the format of a TCLAS element 423, a TCLAS Processing element 424, and a QoS Characteristics element 425.

[0159] By way of step 510, local traffic streams are identified using a stream classification service (SCS).

[0160] Next, the non-AP MLD determines one available priority queue that can be assigned to the incoming requested SCS stream in step 511. A queue is said to be available when it is eligible and is not already associated with or assigned to an SCS stream.

[0161] Only one or some of the AC cues may be eligible for association with an SCS stream, meaning that only a subset of the AC cues may be used. For example, there may be unique eligible cues among ACs. Alternatively, one cue may be eligible for one or more (possibly each) ACs.

[0162] Preferably, only the alternative cues within an AC are eligible cues. For example, Figure 2A (Figure 2b) shows two eligible cues AAC2 and AAC3, which may or may not be available at a given time. In the example of Figure 8 described below, there are four eligible cues, i.e., each alternative (AAC) cue within each AC. Of course, three alternative cues (one for each of the three ACs) may also be contemplated.

[0163] In a variant, only the primary queue is eligible.

[0164] An eligible queue is not an SCS stream and is not yet associated or assigned to an SCS stream when mapped to user priority UP. While multiple eligible queues are simultaneously available, multiple eligible queues may be currently assigned to an SCS stream in accordance with the present invention.

[0165] For example, in a conventional QoS mapping, each UP 0-7 is mapped to each TID 0-7, respectively. When alternate queues are implemented in an AC, two TIDs in the AC are used to separately identify each of the primary and alternate queues. Thus, each queue is identified by at least one TID and corresponds to at least one UP in the default mapping. In this mapping, the SCS stream does not yet have an alternate queue associated or assigned to it. Modification of this mapping (as described below) may lead to having alternate queues that are not available.

[0166] Once the non-AP MLD identifies one or more queues that are eligible and available for association with the SCS stream, the non-AP MLD selects one of them, whose identifying TID is the target TID.

[0167] If a single queue is available, it is selected and its identification TID is retrieved. Optionally, the selection is made only if the queue belongs to the same AC (i.e., data type) as the local traffic stream. Membership may be evaluated based on the DSCP applied to the local traffic stream. For example, if the local traffic stream is video, only alternative queues in AC_VI may be selected (if available).

[0168] If multiple queues are available, a random selection may be made, or it may follow a predefined order (e.g., along the priority of the corresponding AC, or along the queue numbering order). Alternatively, the selection is made with an available queue, preferably belonging to the same AC as the local traffic stream, selected if no other available queue is selected.

[0169] If no queues are available (all eligible queues are currently being used for SCS streams), the process terminates, which means that there are too many SCS streams and therefore no new SCS streams can be processed in accordance with the present invention.

[0170] Alternatively, in some embodiments, a queue is said to be available when it is eligible and is not already associated with an SCS stream or is not already associated with one or more SCS streams (up to a predetermined number of times) that share common QoS characteristics with the new SCS stream being processed. This allows several SCS streams that share common QoS characteristics (e.g., having a common service interval) to be assigned and then traverse on the same eligible queue.

[0171] At the end of step 511, the target queue with the corresponding target TID has been identified and selected. For the original (actually current) UP-TID mapping, the affected UP (often, but not necessarily, equal to the target TID) is also obtained.

[0172] Next, in step 512, the non-AP MLD constructs an SCS Request frame 430 to negotiate with the AP MLD to add the local traffic stream as an SCS stream. Also in step 512, the SCS Request frame is sent by the affiliated non-AP station to the AP MLD.

[0173] The SCS Request frame 430 contains an SCS Descriptor element with the Request Type field set to "Add" or "Change", which contains the SCS classification (derived from the TCLAS element), contains the SCS Identifier (SCSID) of the local traffic stream, and signals the target TID to which the local traffic stream is mapped and / or the affected UP to which the target TID was previously mapped. The target TID is assigned to each MSDU that matches the SCS classification, unless the SCS stream is terminated.

[0174] The SCS descriptor also signals the transmission direction of the SCS stream (typically uplink in this case) in a dedicated Direction subfield.

[0175] More specifically, FIG. 7 illustrates an exemplary modified SCS Descriptor that may be used in a ML SCS service according to an embodiment of the present invention.

[0176] As shown in this embodiment, the Intra-Access Category Priority element 422 (FIG. 4A(a)) is mandatory within the SCS Descriptor of the SCS Request frame 430. This mandatory element references the Intra-Access Category Priority element 722. It is present when the Request Type field 421 is equal to "Add", "Change" or "Remove" (typically only present for "Add" or "Change" requests).

[0177] The other fields of the SCS Descriptor retain their legacy format as defined in the D1.3 standard, however the meaning and use of some of these other fields are slightly adapted to the present invention.

[0178] When dot11AlternateLLQoSMappingActivated is true (in the capability declaration), the Intra-Access Category Priority element 722 is defined as follows: - The User Priority subfield 730 indicates, in the context of the SCS Descriptor, the UP affected by the MSDU or A-MSDU of the SCS stream to which this Intra-Access Category Priority element 722 relates. Indirectly (by the current UP to TID mapping), this target UP identifies the target AC. It is recalled that the affected UP and the target TID are linked by the current QoS mapping.

[0179] - The Alternate Queue subfield 731 indicates the intended primary or alternate EDCA queue to be used for the local SCS stream when dot11AlternateLLQoSMappingActivated is true. When the Alternate Queue subfield is equal to 0, the primary EDCA queue of the target AC is used for queuing the MSDUs of the local traffic stream identified by the SCS descriptor. When the Alternate Queue subfield is equal to 1, the alternate EDCA queue of the target AC is used for such queue.

[0180] Preferably, an Alternate Queue subfield = 0 may mean that the local SCS stream is declared according to the D1.3 approach, i.e. as an additional stream in an existing TID (i.e. possibly mixed with other streams). An Alternate Queue subfield = 1 may mean activation of the invention, where the target TID is fully dedicated to this single SCS stream (or multiple SCS streams sharing the same QoS Characteristics). In that case, when dot11AlternateLLQoSMappingActivated is true, the Intra-Access Category Priority element 722 contains an Alternate Queue subfield equal to 1 when the Request Type field is equal to "Add", "Change". This is to facilitate the use of an alternate queue for local SCS streams.

[0181] Optionally, activation of the present invention also explicitly depends on one bit of the Reserved subfield (B5-B7) being set to 1, so that when dot11AlternateLLQoSMappingActivated is true and this additional bit is true, for matching MSDUs that are part of the SCS stream, the Alternate Queue subfield of the Intra-Access Category Priority element is used to select whether the mechanism of the present invention (the alternate AC queue reserved for the local LL) is used for these MSDUs. When the one designed bit of the Reserved subfield (B5-B7) is set to 0, the Alternate Queue value 731 follows the legacy 802.11 approach, which indicates that the intended primary or alternate EDCA queue is used for the MSDU identified by the User Priority subfield 730.

[0182] Thus, in an SCS Request frame that adds or modifies an SCS stream, when the Alternate Queue subfield 731 of the Intra-Access Category Priority element 722 is set to 1, it indicates that the non-AP MLD intends to reserve an AC queue (with the target TID) for the local LL traffic specified in the SCS Descriptor.

[0183] The Intra-Access Category Priority element 722 may contain an Alternate Queue subfield equal to 0 when the Request Type field 421 is equal to "Change" or "Remove", deactivating the present invention.

[0184] Note that a non-AP MLD may indicate that the reservation of a TID for a local SCS stream is terminated (typically due to a "Remove" type request) when the Alternate Queue subfield is equal to 0. The inventive mechanism is then deactivated for the SCS stream, the mapping of the SCS stream onto the target TID is terminated, and the affected UPs, once released, are mapped onto the target TID.

[0185] In an embodiment, an Alternate Queue subfield equal to 1 (typically for a "Remove" type request) may signal that the mapping of the SCS stream onto the target TID is indeed stopped, but the initial mapping between the affected UP and the released target TID is not restored. The released target TID is kept available for the next SCS stream.

[0186] The Drop Eligibility subfield 732 is not used by the present invention.

[0187] The TCLAS Element field 423 contains zero or more TCLAS elements to specify how the received MSDU is classified as part of this SCS Stream.

[0188] The TCLAS Processing Element field 424 is present when multiple TCLAS elements are present in the TCLAS Element field and contains a TCLAS Processing element that defines how the multiple TCLAS elements are to be processed.

[0189] The Optional Subelement field contains zero subelements since the element is currently undefined.

[0190] The TCLAS and TCLAS Processing element fields, if present, generally describe the traffic classification that the non-AP MLD requests the AP MLD to apply to identify incoming MSDUs of the corresponding stream, and then transmit them to the non-AP MLD on the appropriate TID. For the uplink or direct link direction, the incoming data forming the MSDUs comes from a higher layer in the non-AP MLD, and therefore does not use this information, so the classification transmitted to the AP MLD is not mandatory.

[0191] The QoS Characteristics element 425 defines the traffic specifications for the local SCS stream. The AP MLD takes care to appropriately schedule the non-AP MLD to transmit the local SCS stream. As an example, the AP MLD can allow transmission of frames from the non-AP MLD at intervals that are between the requested minimum and maximum service intervals, and the AP MLD can meet the requested minimum data rate if the Direction subfield of the QoS Characteristics element indicates uplink or direct link. As shown in the figure, various fields are provided in the QoS Characteristics element 425 that define various QoS transmission parameters for the local SCS stream.

[0192] The Control Info field 740 in the QoS Characteristics element 425 is defined as follows: - The Direction subfield 541 specifies the direction of the data, i.e., Uplink, Downlink, Direct-link. As mentioned above, the present invention is highly interested in the uplink direction of the local SCS stream, allowing the AP MLD to schedule the non-AP MLD to transmit this SCS stream (the direct-link direction is different from the downlink direction, which does not require a specific identity of the emitter, AP, to transmit the SCS stream, and can also benefit from the present invention). - The TID subfield 742 contains the target TID value of MSDUs belonging to the local SCS stream (i.e., as described by the SCS Descriptor 700). It is this TID that the AP MLD can use to schedule the SCS stream (e.g., poll for buffer status reports and allocate resources in emitted trigger frames).

[0193] - the User Priority subfield 743 contains the affected UP (values ​​0 to 7); - The LinkID subfield 744 may contain the link identifier of the link for transmitting the local SCS stream and over which the QoS Characteristics defined as such apply.

[0194] The other subfields of the QoS Characteristics element 425 are not critical to the present invention and represent a set of parameters that define the characteristics and QoS expectations of the SCS stream.

[0195] In a preferred embodiment, the non-AP MLD sets the User Priority subfield 743 to the same value as the User Priority subfield 730 .

[0196] Referring now to FIG. 6, the AP MLD receives the Multilink SCS Request frame 430 in step 610 .

[0197] In response, the AP MLD sends a corresponding SCS Response frame 431 to the non-AP MLD in step 611. A value of SUCCESS is set in the corresponding Status field of the SCS Status in the SCS Response frame when the AP MLD accepts the ML-SCS Request for the requested SCSID. The Response frame does not include a traffic specification (i.e., a QoS Characteristics element).

[0198] The AP MLD then (at step 612) determines whether an update of its QoS mapping with the requesting non-AP MLD is required for the SCS stream indicated in the SCS Request frame 431. This may be done by checking the value of the Alternate Queue subfield 731 in the Intra-Access Category Priority element field 722 of the scriptor 700 at the SCS.

[0199] For example, when the Alternate Queue subfield 731 has a value of 1, it indicates activation of the present invention and indicates that the alternate queue of the target AC (identified by the target TID or affected UP referenced in the SCS Request frame 430) should be used for the SCS stream.

[0200] In a preferred embodiment, this determination 612 is performed only if the non-AP MLD indicated support for alternative mapping in its Capability (dot11AlternateLLQoSMappingActivated control variable is set to 1) during the association procedure. Optionally, this determination also depends on one bit (B5-B7) of the Reserved subfield in the Intra-Access Category Priority element field 722 of the SCS descriptor 700.

[0201] If test 612 is true, then an update of the QoS mapping for non-AP MLD is required, where the indicated target TID (subfield 742) is used for WLAN operations that reference the SCS stream (e.g., getting buffer status reports, triggering data, scheduling service periods, etc.). This is step 613.

[0202] Also, incoming streams with affected UP are routed to the fallback TID, i.e., other TIDs in the same AC as the target TID. The update of QoS mapping in the AP MLD can be done in a similar manner as described below, analogous to steps 514 / 515 in the non-AP MLD side.

[0203] However, when considering the AP MLD's perspective of QoS mapping, the AP MLD must store such a complete updated mapping for each non-AP STA MLD. At a minimum, the AP MLD maintains in memory the assignment of target TIDs to SCS streams (i.e., SCSIDs) and the mapping of affected UPs to fallback TIDs for each non-AP STA MLD that issued an SCS request.

[0204] If test 612 is negative, then the new SCS stream is only declared without reserving a TID for it, as proposed in the D1.3 standard. The AP MLD can therefore consider the indicated SCSID (subfield 420) as the identifier to be used for WLAN operations referring to the SCS stream. This is step 614.

[0205] Returning to FIG. 5, in step 513, the SCS Response frame 431 is received by the non-AP MLD.

[0206] If the requested SCS stream is accepted by the AP MLD, then the non-AP MLD must process subsequent incoming local MSDUs to determine whether they match the classification specified in the SCS Descriptor element in order to store them in the appropriate queue. To do so, two configuration steps are performed in the non-AP MLD to adjust the local QoS mapping.

[0207] First, in step 514, the non-AP MLD updates the local QoS mapping to include the local SCS stream with the appropriate TID. Specifically, the SCS stream is mapped to the target TID in the updated QoS mapping. This means, for example, that the MSDU of the SCS stream is routed to an alternate queue of the target AC.

[0208] In order to distinguish traffic belonging to delay-sensitive SCS streams from traffic belonging to non-delay-sensitive streams, non-AP MLD has therefore demonstrated the use of a target TID as an identification of the SCS stream corresponding to an SCSID value.

[0209] Next, in step 515, the non-AP MLD updates its local QoS mapping to avoid that MSDUs with the affected UP and originally mapped to the target TID are still routed to the target TID, in order to avoid mixing of the SCS stream with other MSDUs in the alternative queue. Therefore, the affected UP is mapped to a fallback TID (different from the target TID), preferably identifying a primary queue of an AC whose TID is the same as the target TID, in order to route these MSDUs to this primary queue.

[0210] Additionally, MSDUs with affected UPs already in the alternate queue identified by the target TID are moved to the primary queue identified by the fallback TID. Preferably, the sequence numbers of these MSDUs are adapted or updated in the primary queue when they are moved to that queue. In particular, their sequence numbers are modified to continue their current sequence numbering in the primary queue.

[0211] Note that these moved MSDUs may be triggered by the TID corresponding to the primary queue. Because the alternate and primary queues share the same backoff engine, the same priority is maintained for these MSDUs moved from the alternate to the primary queue.

[0212] Once the non-AP MLD is configured with the updated QoS mapping in steps 514 and 515, a proper inter-queue priority mapping of all incoming local MSDUs is required, which is explained with reference to Figure 8, which shows an example architectural concept of such inter-queue priority mapping.

[0213] In this example, the number of alternative (or AAC) cues is up to four, and each AAC cue corresponds to a primary cue belonging to the same AC.

[0214] Preferably, only one SCS stream is mapped to each AAC queue, but this is not limiting. This ensures that the AP MLD only triggers the SCS stream through the use of a target TID that identifies the AAC queue.

[0215] This design of the primary queue 210 and the AAC queue 810 is presented merely as an example: any implementation of cues by TID or UP rather than per AC can be envisioned when SCS streams are mapped to such TIDs or UPs according to the teachings of the present invention.

[0216] The QoS Classifier 813 (or QoS Mapper) contains a set of parameters necessary to identify different kinds of incoming MSDUs from higher layers in a non-AP STA that belong to a particular stream. In particular, it can identify an SCS stream (or multiple SCS streams) on the one hand, but also any other stream with a conventional UP on the other hand.

[0217] The implementation of the QoS classifier to maintain the QoS stream and flow mapping is outside the scope of this invention. As an example, the QoS classifier 813 may use a local TCLAS element to contain the set of parameters required to identify the incoming MSDU (which is a definition for each SCS stream) and consider using a QoS mapping based on the UP of the MSDU, or a specific Differentiated Services Code Point (DSCP) for a given service.

[0218] The QoS classifier 813 gets the default QoS mapping distributed by the AP MLD during association with that BSS (as shown in the QoS Map element disclosed in FIG. 3). The QoS classifier 813 locally updates the mapping with local modifications in accordance with the present invention.

[0219] Typically, the QoS mapping is modified to reserve the target TID for the incoming local SCS stream, and streams belonging to the affected UP that were previously mapped to this target TID are remapped towards the fallback TID, and MSDUs with the affected UP (and therefore stored in the alternate queue identified by the target TID) are moved to the primary queue.

[0220] In operation, the QoS classifier 813 processes incoming MSDUs from higher layers, as shown in FIG.

[0221] Upon receiving an incoming MSDU locally, the QoS classifier 813 analyzes the type of frame according to stored rules (QoS mappings, TCLAS elements stored in the classifier). Some MSDUs are identified as having a UP, while other MSDUs are identified as belonging to an SCS stream (if defined).

[0222] If the MSDU belongs to an accepted SCS stream that has a dedicated alternate queue (or target TID as indicated in the current QoS mapping), the classifier performs step 920 to determine the corresponding alternate queue.

[0223] Otherwise, the classifier relies on the conventional UP classification in step 930 and selects the queue that corresponds to the UP of the MSDU, given the current QoS mapping. It is envisioned that the present invention allows multiple UPs to be mapped to a single TID and therefore to a single queue.

[0224] SCS streams that do not have a dedicated queue / TID and are identified by their SCSID value are processed through this step using the UP associated with the SCS stream specified in field 743.

[0225] In step 940, the classifier identifies the TID that corresponds to the selected queue. This is the TID that is used over the air for the incoming MSDU. Thanks to the present invention, the target TID is advantageously used to reference the local SCS stream.

[0226] The sequence numbering of the identified TID is incremented in step 950 and inserted into the MSDU in the Sequence Number field of this MAC frame.

[0227] Note that the MSDU may be pre-inserted into an aggregated MSDU (A-MSDU) or may be a management MPDU (MMPDU). Each MSDU, A-MSDU, or MMPDU transmitted by a STA is assigned a sequence number according to the determined TID, and the sequence remains constant in all retransmissions of the MSDU, MMPDU, or their fragments.

[0228] In the case of a local SCS stream according to the invention, the target TID is entirely dedicated to the SCS stream only, so that the MSDUs are associated with a sequence number within the sequence that holds information about their order.

[0229] Next, in step 960, the incoming MSDU is stored in a selected queue, either the alternate queue 810 or the primary queue 210, associated with the respective AC for medium access.

[0230] Returning to Figures 5 and 6, based on the above updates of the QoS mapping, the non-AP MLD is ready for communication in step 516 based on the TID, in particular the target TID for triggering transmission of the local SCS stream.

[0231] On its side (FIG. 6), the AP MLD configured after step 613 or 614 is also ready to perform communication (steps 616, 617) with non-AP MLDs, based specifically on the target TID dedicated to the SCS stream.

[0232] As an example, the associated STAs of the non-AP MLD initiate a TWT negotiation with the AP MLD, i.e., a restricted TWT (rTWT) negotiation for LL traffic. The restricted TWT agreement for the target TID (and therefore the SCS stream identified by the SCSID) can be established using the same procedure used to set up the broadcast TWT agreement. Note that individual TWT agreements are also possible.

[0233] The AP MLD accepts the TWT agreement with the STA (step 615) and acknowledges the acceptance in a TWT response sent to the non-AP MLD. The AP MLD also includes a broadcast TWT element in its transmitted Beacon frame. Thus, the non-AP MLD can obtain the TWT parameter values ​​for the requested SCS stream from the most recently received TWT element carried in the Beacon frame, so that the non-AP MLD can be awakened when the TWT service period occurs.

[0234] The AP MLD can then schedule uplink transmission of MSDUs of the SCS stream from the non-AP MLD by issuing a Trigger frame (e.g., during an rTWT SP) (step 616). According to an embodiment, the Trigger frame is addressed to the non-AP MLD and includes at least one User Info field that triggers a PPDU related to the SCSID by specifying a target TID value (742). In a variant, the Trigger frame can be used without rTWT negotiation (step 615).

[0235] When a non-AP MLD is scheduled with a target TID via one of its associated STAs, this associated STA is responsible for selecting an alternate queue identified by the target TID (i.e., an MSDU in that queue that belongs to the SCS traffic stream identified by the SCSID) and for forming a TB PPDU with the retrieved MSDU as a response to the TF.

[0236] Preferably, only MSDUs related to the alternate queue identified by the target TID are allowed to be part of the TB PPDU. Optionally, if there is room, some MSDUs belonging to the primary queue of the same AC may also be included in the TB PPDU.

[0237] Note that by dedicating the target TID to the SCS stream, the sequence numbering and then the link mapping for the target TID applies only to the SCS stream. Thus, the block acknowledgement scheme or policy that is normally defined at the TID level is now dedicated only to the SCS stream (identified by the target TID), and thus there are no holes in the sequence numbers.

[0238] This is an important difference compared to known techniques where a TID is composed of various subparts, e.g., a low latency traffic stream belonging to a SCSID and other traffic streams sharing the same UP, and thus the sequence number is common to all streams of a TID, and the Block ACK mechanism often suffers from head-of-line blocking for SCS streams (LL data) when subparts of the TID (non-LL data MSDUs) are not triggered for transmission.

[0239] The mapping of an SCS stream to a target TID is typically temporary, as the SCS stream will terminate at some time (e.g., the higher layer application terminates). Upon detecting a termination event (e.g., MLME-SCS.request primitive), the non-AP MLD can terminate the SCS stream by sending an SCS Request frame 430 (Request Type=Remove) containing the SCSID. The AP MLD responds with an SCS Response frame 431 accepting the termination. The response includes the SCSID and the value "Terminate" or SUCCESS in the Status field of the SCS Status.

[0240] In this case, both non-AP MLD and AP MLD cease to apply classification rules associated with this SCSID, and therefore the target TID is freed by unmapping the SCS stream from this target TID.

[0241] For an MSDU with an affected UP (and therefore a TID that was originally mapped to a target and is now released), two options can be envisaged.

[0242] In an embodiment, there is no mapping back for the affected UP on the target TID in order to preserve the alternate queue and target TID for another SCS stream. For example, the non-AP MLD may know that a new SCS stream is coming that requires a dedicated TID. In that case, the lack of mapping back of the affected UP is signaled by the non-AP MLD in the Remove SCS Request frame 430, for example, by setting its Alternate Queue subfield 731 to 0.

[0243] In another embodiment, the affected target UPs are mapped onto the target TIDs in order to restore the initial QoS mapping. The latter are updated accordingly. Then, the MSDUs with the affected UPs currently stored in the primary queue are moved to the alternative queue corresponding to the target TID. As with other MSDUs that remain in the primary queue (identified by the fallback TID), the sequence numbers of these MSDUs are adjusted to ensure continuity in sequence numbering within each TID.

[0244] Thus, the non-AP MLD can choose between the two options by signaling its choice in the SCS Request frame. In other words, the removal SCS Request frame 430 may signal whether the affected UP should be mapped on the target TID. For example, such signaling is conveyed in the Alternate Queue field of the Intra-AC Priority element of the SCS Descriptor according to IEEE P802.11be / D1.3 in the removal SCS Request frame.

[0245] FIG. 10A illustrates an exemplary QoS mapping when implementing the present invention.

[0246] 2B shows an example of mapping between eight priorities of traffic classes when one SCS stream is requested by a non-AP STA according to an embodiment of the present invention. This local table has up to eight rows (as in FIG. 2B), and some UP classifications corresponding to higher layer MSDUs may be routed to separate priority rows for new incoming SCS streams.

[0247] In this example, a non-AP MLD has negotiated an SCS stream with a given SCSID value with the AP. This SCS stream is a video stream and is therefore assigned to an alternate video queue. This is shown in row 1000, where the SCSID is associated with target TID=4, which identifies an alternate queue for the video AC. The affected UP is 4, and therefore it is mapped to the primary queue for the video AC. This means that upper layer MSDUs with affected UPs will be routed to the primary queue of the same AC. This is shown in row 1010, where both UP=4 and UP=5 feed the primary queue identified with TID=5.

[0248] The SCS Request frame 430 (sent in step 512) adding an SCS stream includes a User Priority field 730 with the Intra-Access Category Priority element 722 set to the value of the affected UP, here 4, and an Alternate Queue subfield value set to 1. This indicates that row 1000 is reserved for the incoming SCS stream identified by the SCSID value.

[0249] Additionally, in Control Info field 740, the User Priority subfield 743 takes the same value 4 as in 730, and the TID subfield 742 indicates the target TID value (again 4) to be used for 802.11 networking operations.

[0250] Preferably, the alternate queues in the AC are those identified by TID values ​​2, 3, 4, 7 and correspond to the same AC priority. The alternate queue values ​​4, 7 correspond to those of 802.11aa (not SCSID according to the invention, but defined for other uses). In the preferred embodiment, alternate queue values ​​2, 3 are implemented to obtain a total of four alternate queues. Of course, other variations may be considered regarding the number and location of primary / alternate queues.

[0251] Figure 10B shows an eight-queue configuration with TID values ​​2, 3, 4, 7 that identify alternate queues. In this example, four SCS streams are mapped to four alternate queues. This is the maximum number of SCS streams that can be mapped in an independent manner to maintain a primary queue in each AC. This ensures compliance with EDCA medium access rules based on four AC queues.

[0252] This number of four SCS streams is sufficient in some situations and complies with typical scenarios for low latency devices (e.g., a head mounted display may require several flows for sound and right / left eye, etc.).

[0253] Backoff expiring for a given AC is intended to trigger one or both of the UPs and SCSs connected to the AC backoff. Typically, as shown in row 1050, backoff for AC_0 expiring on a given link allows data units from UP 1+2 and / or SCSID_0 to be sent. Similarly, backoff expiration for AC_2 allows data units from UP 4+5 and / or SCSID_2 to be sent (see row 1070).

[0254] Note that backoff expiring on one link is still subject to TID-to-Link mapping. However, when one TID (e.g., 2, 3, 4, 7) is reserved for an SCS stream, the TID-to-Link mapping (entity 814) can be updated such that a different link mapping policy is applied between non-AP STA MLD and AP MLD. This allows for allocation of a separate link for the SCS stream compared to the legacy UP flow.

[0255] Such a possibility can be supported by using the LinkID subfield 744, which can thus be considered as the first (also called anchor) link for the transport of the SCS stream. Other additional links (if any) can be negotiated with the existing TID-Link mapping negotiation mechanism.

[0256] 11A shows a schematic diagram of a communication device 1100, either a non-AP MLD incorporating multiple non-AP stations 110 or an AP MLD incorporating multiple APs 100, of a wireless network NETW, configured to implement at least one embodiment of the present invention. The communication device 1100 may be a device such as a microcomputer, a workstation, or a light portable device. The communication device 1100 may include: A central processing unit 1101 such as a processor called a CPU, A memory 1103 for storing a code capable of executing a method or steps of a method according to an embodiment of the invention, as well as registers adapted to record variables and parameters necessary for carrying out the method; At least one communication interface 1102 connected via a transmitting / receiving antenna 1104 to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards; are preferably connected to a communication bus 1113 .

[0257] Preferably, a communication bus provides communication and interoperability between the various elements included in or connected to the communications device 1100. The representation of a bus is not limiting, in particular a central processing unit is operable to communicate instructions to any element of the communications device 1100 directly or by another element of the communications device 1100.

[0258] The executable code may be stored in a memory, which may be either a read-only memory, a hard disk, or a removable digital medium, such as a disk. According to an optional variant, the executable code of the program may be received by the communication network via the interface 1102, to be stored in the memory of the communication device 1100 before being executed.

[0259] In one embodiment, the device is a programmable device that uses software to implement embodiments of the invention, however, alternatively, embodiments of the invention may be implemented wholly or partly in hardware (e.g., in the form of an application specific integrated circuit or ASIC).

[0260] 11B is a block diagram that illustrates a schematic architecture of a communication device 1100 adapted to at least partially implement the present invention. As shown, the device 1100 includes a physical (PHY) layer block 1123, a MAC layer block 1122, and an application layer block 1121.

[0261] The PHY layer block 1123 (here multiple 802.11 standardized PHY layer modules) formats, modulates or demodulates on any 20 MHz channel or composite channel, and thus transmits or receives frames on the wireless medium NETW, such as 802.11 frames, for example reserving transmission slots, MAC data and management frames based on a 20 MHz width, interacting with legacy 802.11 stations, and reserving OFDMA type MAC data frames having a width smaller than 20 MHz (typically 2 or 5 MHz) between the wireless medium.

[0262] The MAC layer block or controller 1122 preferably comprises an MLE MAC 802.11 layer 1124 which implements conventional 802.11 MAC operations, and additional blocks 1125 for at least partially carrying out embodiments of the present invention. The MAC layer block 1222 may optionally be implemented in software which is loaded into RAM 1003 and executed by CPU 1001. The MLE MAC 802.11 layer 1124 may implement upper MAC stack 230 with a series of lower MAC modules 220-x / z as introduced in Figure 2a.

[0263] Preferably, an additional block 1125 called multilink stream classification service management module for performing low latency service over multilink communication (from the perspective of station (non-AP MLD) or AP (AP MLD)) implements part of the embodiment of the present invention. This block performs the operations of Figures 5, 6, and 9 depending on the role of the communication device 1100, non-AP or AP MLD. This block includes an enhanced QoS classifier 813 and a TID-Link mapping entity 814.

[0264] The MAC 802.11 layer 1124 and the Multilink Stream Classification Service Management 1125 interact to establish and handle communications over OFDMA RUs between multiple non-AP MLD stations in accordance with an embodiment of the present invention.

[0265] At the top of Figure 11B, an application layer block 1121 executes applications that generate and receive data packets, e.g., video streams, etc. The application layer block 1121 represents all stack layers above the MAC layer, according to the ISO standard.

[0266] Although the present invention has been described with reference to specific embodiments, the present invention is not limited to those embodiments and modifications will be apparent to those skilled in the art that are within the scope of the present invention.

[0267] Many further modifications and variations will be suggested to those skilled in the art by reference to the exemplary embodiments described above, which are not intended to limit the scope of the invention, which is determined solely by the appended claims. In particular, different features from the various embodiments may be interchanged where appropriate.

[0268] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

Claims

1. A method for communication in a wireless network, comprising: performing communication with the AP MLD based on a traffic identifier (TID); The method in the non-AP MLD further comprises: Identifying local traffic streams using a stream classification service (SCS); Mapping the local traffic stream to a target TID previously mapped with an affected user priority and mapping the affected user priority (UP) to a fallback TID; A communication method comprising:

2. 2. The method of claim 1, further comprising: transmitting, in the non-AP MLD, a stream classification service (SCS) request frame to the AP MLD to add the local traffic stream.

3. A method for communication in a wireless network, comprising: performing communication with one or more non-AP MLDs based on a traffic identifier (TID); The method in the AP MLD further comprises: receiving a stream classification service (SCS) request frame from a non-AP MLD to add a local traffic stream to the non-AP MLD; in response to receiving, mapping the local traffic stream to a target TID previously mapped with an affected user priority and mapping the affected user priority (UP) to a fallback TID; A communication method comprising:

4. 4. The method of claim 2 or 3, wherein the SCS request frame includes an SCS identifier of the local traffic stream and signals the target TID to which the local traffic stream is mapped and / or the affected UP to which the target TID was previously mapped.

5. The SCS request frame includes an SCS descriptor, the SCS descriptor comprising: Identifying the local traffic stream using a SCSID; signaling the target TID and / or the affected UP; Include an Alternate Queue field in the Intra-AC Priority element in accordance with IEEE P802.11be / D1.3; The method of claim 2 or 3, wherein the Alternate Queue field specifies whether a primary queue or an alternate queue within the same access category is dedicated to store the local traffic stream.

6. The method of claim 5 , wherein the access category includes a queue identified by the target TID.

7. 6. The method of claim 5, wherein the target TID is signaled in a TID field provided in a Control Info field of a QoS Characteristics element according to IEEE P802.11be / D1.3 in the SCS descriptor, and the affected UP is signaled in a User Priority field provided in the Alternate Queue field.

8. The method of claim 1 or 3, wherein the target TID identifies an alternate queue of a pair of primary and alternate queues that form an 802.11 access category.

9. The method of claim 8 , wherein the fallback TID identifies the primary queue.

10. 2. The method of claim 1, wherein mapping the affected UP to the fallback TID includes moving data having the affected UP from a queue identified by the target TID to another queue identified by the fallback TID, wherein a sequence number of the data is adapted to the other queue when moved to the other queue.

11. 2. The method of claim 1, further comprising: sending an SCS request frame to the AP MLD to remove the local traffic stream; and unmapping the local traffic stream from the target TID.

12. 4. The method of claim 3, further comprising: receiving an SCS request frame from the non-AP MLD to remove the local traffic stream; and in response to said receiving, unmapping the local traffic stream from the target TID.

13. The method of claim 11 or 12, further comprising mapping the affected UP to the target TID.

14. 13. The method of claim 11 or 12, wherein the removing SCS request frame signals whether the affected UP should be mapped on the target TID, and such signaling is conveyed in an Alternate Queue field of an Intra-AC Priority element of an SCS Descriptor according to IEEE P802.11be / D1.3 in the removing SCS request frame.

15. A method for communication in a wireless network, comprising: sending a stream classification service (SCS) request frame to an AP MLD, the SCS request frame including an Intra-Access Category Priority element and a QoS characteristic element; A communication method, wherein a User Priority subfield included in an Intra-Access Category Priority element and a User Priority subfield included in a QoS characteristic element are set to the same value.

16. A stream classification service (SCS) request frame for communication in a wireless network, the SCS request frame including an Intra-Access Category Priority element and a QoS characteristics element, wherein a User Priority subfield included in the Intra-Access Category Priority element and a User Priority subfield included in the QoS characteristics element are set to the same value.

17. A wireless communication device comprising at least one microprocessor configured to carry out the steps of the method according to claim 1, 3 or 15.

18. 20. The wireless communication device of claim 17, further comprising one or more Access Categories (ACs) having a primary queue and an alternate queue, wherein the target TID to which the local traffic stream is mapped identifies the alternate queue of an AC and the fallback TID identifies the primary queue of that AC.

19. A non-transitory computer readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform the method of claim 1, 3 or 15.