CN117461351A - Communication method of delay sensitive flow and multi-link device - Google Patents

Abstract

Known flow classification services (SCS) have been improved for multilink support. The low delay stream is identified with SCSID. The improved SCS mechanism may be used to allow stations to report link preferences associated with low latency flows. The adapted SCS may also be used to negotiate a set of links for transmitting low delay streams. The AP may schedule the low-delay flow using the modified trigger frame. It is also proposed to adapt a Target Wake Time (TWT) service period to allow a low latency dedicated TWT period suitable for transmitting streams identified with SCSIDs.

Description

Communication method of delay sensitive flow and multi-link device

Technical Field

The present invention relates generally to wireless communications, and more particularly to multi-link (ML) communications.

Background

With the development of delay sensitive applications such as online gaming, real-time video streaming, virtual reality, drone or robot remote control, etc., better throughput, low delay and stability requirements and problems need to be considered. The IEEE 802.11 working group is currently considering these problematic issues as the primary goal of issuing the next master 802.11 version, known as 802.11be or EHT for "very high throughput".

Low Latency Reliable Services (LLRs) have been defined as the goal of this major goal. LLRS is a service provided to higher-layer traffic flows that prioritizes processing and delivering MSDUs (data units) within a worst-case delay budget with a given reliability/packet transfer ratio (PDR) and low jitter.

The IEEE P802.11be/D1.0 version (month 5 of 2021) introduced multi-link (ML) operation (MLO). MLO improves data throughput by allowing communication between stations via multiple concurrent and discontinuous communication links.

The multi-link operation enables a non-AP (access point) MLD (ML device) to register with the AP MLD, i.e., discover, authenticate, associate and set up multiple links with the AP MLD. The individual links enable channel access and frame exchange between the non-AP MLD and the AP MLD based on the support capability exchanged during association.

MLD is a logical entity with more than one secondary station (AP or non-AP) and with a single Medium Access Control (MAC) Service Access Point (SAP) for Logical Link Control (LLC), which includes one MAC data service. Thus, an AP MLD is made up of multiple affiliated APs, while a non-AP MLD is made up of multiple affiliated non-AP stations. An affiliated station in both the AP MLD and the non-AP-MLD may communicate with an affiliated station of another MLD over each of the established plurality of communication links using an 802.11 mechanism.

During ML discovery, the non-AP MLD discovers the various wireless links available to the AP MLD through its various affiliated APs. The non-AP MLD establishes a set of candidate set links associating the accessory AP with the accessory non-AP station based on the discovered links (accessory APs). During ML setup, the non-AP MLD determines, in cooperation with the AP MLD, a set of candidate setup links to be used for data exchange between the non-AP MLD and the AP MLD.

The MLO device architecture still relies on a link agnostic MAC procedure to buffer data, where local traffic is queued in an Access Class (AC) corresponding to its traffic Type (TID) priority, and then all data for a given TID or AC class can be transferred over links capable of transmitting that class.

In trigger-based transmissions, the AP MLD gives one of the associated stations an uplink transmission opportunity, which is authorized by a trigger frame on a given link. However, when selecting a TID for uplink transmission, the AP MLD does not provide any guarantees regarding delay, reliability or jitter of the transmission for LLRS traffic (compared to another traffic of the same TID that is not delay sensitive).

Therefore, a more efficient multilink communication mechanism would be advantageous, particularly in view of providing Low Latency (LL) reliable services.

Disclosure of Invention

The inventors have found various alternatives to solve this particular problem. According to some aspects of the present invention, known flow classification services (SCS) have been improved for multilink support. The low delay stream is identified with SCSID. The improved SCS mechanism may be used to allow stations to report link preferences associated with low latency flows. The adapted SCS may also be used to negotiate a set of links for transmitting low delay streams. The modified trigger frame may be used by the AP to schedule low delay flows. It is also proposed to adapt a Target Wake Time (TWT) service period to allow a low latency dedicated TWT period suitable for transmitting streams identified with SCSIDs. All of these mechanisms may be used alone or together to improve management of low latency services in multi-link operation of a wireless network.

According to a first aspect of the present invention, a communication method in a wireless network is presented, the wireless network comprising a non-access point multi-link device, i.e. non-AP MLD, associated with an access point multi-link device, i.e. AP MLD:

-identifying the traffic flow with a flow classification service identifier, SCSID; and

-reporting one or more links to the AP MLD, wherein the identified traffic flow is expected to be transmitted on the one or more links.

In an embodiment, the one or more links are reported within a respective one or more traffic specification elements, i.e. TSPECs, in a flow classification service descriptor associated with the traffic flow.

In an embodiment, the traffic specification element includes an identifier of the link in a field designed to indicate a traffic flow identifier.

In an embodiment, the one or more links are reported within the flow classification service descriptor comprising a mapping element indicating the direction of the traffic and one or more links for which the traffic flow is expected to be transmitted.

In an embodiment, the flow classification service descriptor includes:

a common flow specification element including parameters for defining a flow; and

one or more link-specific traffic specification elements including link-specific parameters.

In an embodiment, the method comprises:

a trigger frame is received from the AP MLD for allocating resources for transmission of one or more identified traffic flows.

In an embodiment, a target wake time, TWT, is allocated for the transmission of the traffic flow.

In an embodiment, the trigger frame includes:

An element for indicating that the trigger frame includes a traffic flow identifier; and

an element for indicating the traffic flow identifier.

In an embodiment, the target wake time is described by an information element TWT IE comprising a parameter information element (820), the parameter information element (820) comprising a single individual TWT parameter field comprising an identifier of the traffic flow.

In an embodiment, the target wake time is described by an information element, TWT, IE, comprising a parameter information element (820), the parameter information element (820) comprising one or more broadcast TWT parameter fields, each broadcast TWT parameter field comprising an identifier of the traffic flow.

In an embodiment, the traffic stream is transmitted using data units comprising sequential sequence numbers.

According to another aspect of the invention, a computer program product for a programmable device is proposed, the computer program product comprising sequences of instructions for implementing the method of the invention when loaded into and executed by the programmable device.

According to another aspect of the invention, a computer readable storage medium is presented storing instructions of a computer program for implementing the method of the invention.

According to another aspect of the invention, a communication device in a wireless network is presented, the wireless network comprising a non-access point multi-link device, or non-AP MLD, associated with an access point multi-link device, or AP MLD, wherein the non-AP MLD comprises a processor configured to:

identifying traffic flows with flow class service identifiers, SCSIDs; and

reporting one or more links to the AP MLD, wherein the identified traffic flow is expected to be transmitted on the one or more links.

At least a part of the method 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, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," module, "or" system. Furthermore, the invention can take the form of a computer program product embodied in any tangible expression medium having computer-usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for providing to a programmable device on any suitable carrier medium. Tangible, non-transitory carrier media may include storage media such as floppy disks, CD-ROMs, hard drives, tape devices, or solid state memory devices, among others. The transient carrier medium may comprise a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal, or an electromagnetic signal (e.g., a microwave or RF signal).

Drawings

Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings in which:

fig. 1 illustrates an example of a multilink arrangement according to 802.11 be;

FIG. 2 illustrates an example of a reference model of an 802.11be multilink device;

FIG. 3 illustrates an exemplary 802.11be multilink reference model of an ML device;

figures 4a and 4b illustrate recently modified SCS mechanisms;

figure 5 illustrates a modified SCS descriptor that may be used in an ML SCS service according to an embodiment of the invention;

figure 6a illustrates SCS descriptors according to an embodiment of the invention;

figure 6b illustrates SCS descriptors according to other embodiments of the invention;

fig. 7a illustrates a MAC format of a trigger frame according to an embodiment of the present invention;

FIG. 7b illustrates a second MAC format of the trigger frame that replaces the format of FIG. 7a, in accordance with an embodiment of the present invention;

FIG. 8a illustrates reservation of service periods for low latency traffic flows in accordance with an embodiment of the present invention;

fig. 8b illustrates the format of a TWT IE according to an embodiment of the invention;

fig. 8c illustrates a format of a TWT IE that replaces the format of fig. 8b, according to an embodiment of the invention;

FIG. 9 illustrates a detailed architecture of an ML device according to an embodiment of the present invention;

FIGS. 10a, 10b, 10c and 10d illustrate exemplary embodiments of the invention implemented at an AP and a non-AP MLD using flowcharts; and

fig. 11a and 11b illustrate a multi-link communication device hardware and software architecture in accordance with at least one embodiment of the present invention.

Detailed Description

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 Space 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 the transmission signal into different time slots or resource units, each time slot being assigned to a different user terminal. OFDMA systems utilize Orthogonal Frequency Division Multiplexing (OFDM), a modulation technique that divides the overall system bandwidth into multiple orthogonal subcarriers or resource elements. These subcarriers may also be referred to as tones, bins, etc. With OFDM, each subcarrier can be modulated independently with data. SC-FDMA systems may utilize Interleaved FDMA (IFDMA) to transmit on subcarriers distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on blocks of adjacent subcarriers, or Enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent subcarriers.

The teachings herein may be incorporated into (e.g., implemented within or by) various devices (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may include an access point (so-called AP) or no access point (so-called non-AP station or STA).

Note that it is not excluded that a device may act as an AP of one wireless network and at the same time may belong to another (neighboring) wireless network as a STA. This may occur in the context of multi-AP technology, which consists in achieving a certain degree of cooperation between neighboring APs to more efficiently utilize the limited time, frequency and space resources available. Using this technique, two neighboring APs may share resources in frequency or time and in this way prevent interference. An AP that collaboratively shares resources is called a coordinator AP. Further, the data transmission established by the coordinating AP is referred to as a multi-AP transmission.

Although the examples are described in the context of a WiFi (RTM) network, the invention may be used with any type of wireless network, such as a cellular network of mobile phones implementing very similar mechanisms.

A non-AP station may include, be implemented as, or be known as a subscriber station, subscriber unit, 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, the STAs may include cellular telephones, cordless telephones, session initiation protocol ("SIP") phones, wireless local loop ("WLL") stations, personal digital assistants ("PDAs"), handheld devices with wireless connection capability, or some other suitable processing device connected to a wireless modem. Thus, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or a smart phone), a computer (e.g., a laptop), a tablet computer, 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 that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station may be a wireless node. Such wireless nodes may provide connectivity to or from a network (e.g., a wide area network such as the internet or a cellular network) via wired or wireless communication links, for example.

The AP manages a collection of stations that together organize their access to a wireless medium for communication purposes. Stations (including APs) form a service set, hereinafter referred to as a Basic Service Set (BSS) (although other terminology may be used). The same physical station that acts as an access point may manage two or more BSSs (and thus the corresponding WLANs): each BSS is thus uniquely identified by a specific Basic Service Set Identification (BSSID) and managed by a separate virtual AP implemented in the physical AP.

The 802.11 family of standards defines various Medium Access Control (MAC) mechanisms to drive access to wireless media.

As shown in draft IEEE p802.11be/D1.0, month 5 of 2021, the current discussion in task group 802.11be introduced multi-link operation (MLO) when it comes to MAC layer operation. MLO allows a multi-link device to establish or set up multiple links and operate them simultaneously.

A multi-link device (MLD) is a logical entity with more than one affiliated (AP or non-AP) Station (STA) and with a single Medium Access Control (MAC) Service Access Point (SAP) for Logical Link Control (LLC), which includes one MAC data service. The MLD further includes a single address associated with the interface that can be used to communicate on a Distribution System Medium (DSM).

Stations forming the same MLD may be partially or wholly configured within the same apparatus or geographically dispersed.

Then, an access point multi-link device (AP MLD) corresponds to an MLD in which each Station (STA) attached to the MLD is an AP (hereinafter referred to as "accessory AP").

A non-access point multi-link device (non-AP MLD) corresponds to an MLD in which individual Stations (STAs) attached to the MLD are non-AP stations (referred to as "attached non-AP stations").

When referring to AP MLD or non-AP MLD hereinafter, the general term "station MLD" may be used.

According to the literature, "multilink device", "ML device" (MLD), "multilink logical entity", "ML logical entity" (MLE), "multilink group", and "ML set" are synonyms for ML devices of the same type.

Fig. 1 illustrates an example of two MLDs (AP MLD 10 and non-AP MLD 11) establishing a multi-link communication session to exchange data units according to 802.11 be.

As can be seen, AP MLD 10 includes three affiliated APs 100-x, 100-y and 100-z, and non-AP MLD 11 includes three affiliated non-AP STAs 110-x, 110-y and 110-z. Although the illustrated MLD is comprised of three affiliated non-AP stations or APs, MLDs having other numbers of affiliated non-AP stations or APs are contemplated under the same teachings.

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 a wireless medium.

A plurality of affiliated non-AP stations of the non-AP MLD may then set up communication links with a plurality of affiliated APs of the AP MLD to form a multi-link channel.

As shown in fig. 1, communication links 15-x, 15-y, 15-z are physical paths that may be used to communicate MAC Service Data Units (MSDUs) between an accessory non-AP station and an accessory AP. Thus, communication link 15-x is a communication channel established between AP 100-x and non-AP STA 110-x. Similarly, communication links 15-y and 15-z correspond to communication channels established between AP 100-y and non-AP STA 110-y and AP 100-z and non-AP STA 110-z, respectively.

Thus, a communication link or "link" corresponds to a given channel (e.g., 20MHz, 40MHz, etc.) in a given frequency band (e.g., 2.4GHz, 5GHz, 6 GHz) between an AP 100-x, 100-y attached to AP MLD 10 and a non-AP STA110-x, 110-y, 110-z attached to non-AP MLD 11.

As shown in fig. 1, AP 100-x and non-AP STA110-x, AP 100-y and non-AP STA 110-y, and AP 100-z and non-AP STA 110-z operate in the following bands, respectively: x GHz, y GHz and z GHz. These frequency bands may be different from each other such that the respective communication links 15-x, 15-y, 15-z have respective frequency bands x GHz, y GHz, and z GHz. Alternatively, the links may have the same frequency band, i.e., STAs may use the same frequency band.

Preferably, the links established for the MLD are considered to be completely independent, meaning that the channel access procedure (to the communication medium) and the communication take place independently on the respective links. Thus, different links may have different data rates (e.g., due to different bandwidths, number of antennas) and may be used to communicate different types of information (each type of information passing through a particular link).

The accessory 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.

Due to the multilink aggregation, traffic associated with a single MLD may be transmitted across multiple parallel communication links, thereby increasing network capacity and maximizing utilization of available resources.

The terms "traffic" and/or "traffic flow" as used herein are defined as data flows and/or streams between wireless devices.

Although fig. 1 shows an ML AP device and an ML non-AP device that establish an ML communication session, two non-AP MLDs may also establish such an ML communication session.

Fig. 2 illustrates an exemplary 802.11be multilink reference model for an MLD (AP MLD (e.g., AP MLD 10 as in fig. 1) or a non-AP MLD (e.g., non-AP MLD 11 as in fig. 1)), which may be an initiator MLD (i.e., a device transmitting data) or a recipient MLD (i.e., a device receiving data from the initiator MLD).

The MLD includes a PHY layer 200, a MAC layer 220, a Logical Link Control (LLC) sub-layer 240, and an upper layer 260.

The upper layer 260 may include applications that generate traffic data or use received traffic data.

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 be performed over a plurality of links, such as links 15-x, 15-y, 15-z described with reference to fig. 1.

The traffic data is provided as a sequence of data frames known as MAC Service Data Units (MSDUs). Each MSDU is associated with an Access Class (AC) defined in the EDCA mechanism.

Recall that the 802.11 stations (AP and non-AP stations) maintain four Access Categories (ACs) and thus four corresponding transmit buffers (or transmit/traffic queues or buffers). Each AC has its own traffic queue/buffer to store the corresponding data frames to be transmitted over the network. Four ACs are generally defined as follows:

AC1 and AC0 are reserved for best effort and background traffic. They have the second lowest priority and lowest priority, respectively.

AC3 and AC2 are typically reserved for real-time applications (e.g., voice or video transmission). They have the highest priority and the second highest priority, respectively.

Data frames (i.e., MSDUs) incoming from an upper layer of the protocol stack are mapped onto one of the four AC queues/buffers and thus input into the mapped AC buffer. Thus, the 802.11 station supports traffic priorities similar to DiffServ (differentiated services) and maps between one of the eight priorities of the traffic classes of the incoming MSDUs to a corresponding one of the four ACs according to predefined mapping rules. Traffic classes are indicated using a Traffic Identifier (TID) that takes a value in the range of 0 to 7.

Thus, each MSDU contains an indication related to the data type, i.e. an indication reflecting the access class, in other words the priority level.

The 802.11be multilink reference model reflects the fact that MLD can use several links for transmission, especially at the MAC layer 220 and PHY layer level.

The MAC layer 220 includes a unified Upper MAC (UMAC) layer 230.UMAC 230 is responsible for link agnostic MAC procedures such as sequence number assignment, MAC Protocol Data Unit (MPDU) encryption/decryption, acknowledgement scoring procedures, etc.

Thus, each data unit (MSDU) with traffic Type (TID) priority arriving at MAC layer 220 from upper layer 260 (e.g., link layer) is mapped to one of the ACs according to the mapping rules of UMAC layer 230. Then, still at UMAC layer 230, the data units (MSDUs) are then stored in a buffer corresponding to the mapped AC.

When access to the wireless medium is granted, the data unit is transferred to a Physical (PHY) layer 200 for transmission onto the wireless communication network.

As previously described, any of the communication links 15-x, 15-y, or 15-z shown in FIG. 1 may be used for transmission.

Accordingly, the structures of the MAC layer and the PHY layer are adapted accordingly.

As shown in FIG. 2, the MAC layer 220 of the MLD also includes a plurality of blocks (referred to as lower Level MAC (LMAC) 220-x, 220-y, 220-z) for a corresponding plurality of links 15-x, 15-y, 15-z.

The PHY layer 200 of the MLD also includes a plurality of PHY blocks 200-x, 200-y, 200-z, each PHY block dedicated to a corresponding plurality of links 15-x, 15-y, 15-z.

The UMAC layer then also provides a UMAC interface with link specific blocks 220-x, 220-y, 220-z (forming the lower MAC sublayer, hence the name LMAC), and provides a UMAC Service Access Point (SAP) for LLC 240 and upper layer 260.

Of course, the number of blocks depends on the number of links that the MLD can manage.

In this example, LMAC layer 220-x may be associated with link 15-x via PHY layer 200-x; LMAC layer 220-y may be associated with link 15-y via PHY layer 200-y; and LMAC layer 220-z may be associated with link 15-z via PHY layer 200-z. In other words, each link 15x/y/z may have an LMAC layer 200-x/y/z associated with link-specific features such as channel (e.g., link) access.

To access the wireless medium, i.e., links 15-x, 15-y, 15-z, non-AP stations and APs active on a given link may contend using EDCA (enhanced distributed channel access) contention to be granted a transmission opportunity (TXOP). Then, during the TXOP, the station may transmit (single user (SU)) data frames. It should be noted that legacy devices (i.e., not MLDs) may operate on either link.

Alternatively, the station may also use a multi-user (MU) scheme to access the wireless medium, i.e., links 15-x, 15-y, 15-z. In the MU scheme, a single station (typically APs 100-x, 100-y, and 100-z) is allowed to schedule MU transmissions, i.e., multiple simultaneous transmissions with respect to other non-AP stations. For example, one implementation of such MU schemes has been adopted in the IEEE 802.11ax revised standard as multi-user uplink and downlink OFDMA (MU UL and DL OFDMA) procedures. Due to the MU feature, the non-AP station has an opportunity to gain access to the wireless medium via two access schemes, the MU scheme and the conventional Enhanced Distributed Channel Access (EDCA) scheme (SU scheme).

During MU DL transmissions on an authorized communication channel (i.e., link 15-x), the AP 100-x may make multiple simultaneous basic transmissions to various non-AP stations through a so-called Resource Unit (RU). As an example, the resource units may split links 15-x of the wireless network in the frequency domain based on, for example, orthogonal Frequency Division Multiple Access (OFDMA) techniques. The RU allocation to the non-AP station is signaled at the beginning of the MU downlink frame by providing an Association Identifier (AID) of the non-AP station to each RU defined in the transmission opportunity. The AID is obtained by each MLD station alone in its association with the AP 100-x. Thus, the AID uniquely identifies the associated MLD station (and thus the affiliated station of the MLD on the current link transmitting the MU frame), and may be, for example, a 16-bit value.

During MU UL transmissions, various non-AP stations may simultaneously transmit data to AP 100-x via the resource elements forming link 15-x.

To control MU UL transmissions by non-APs, the AP 100-x may send a control frame (known as a Trigger Frame (TF)) in advance. The TF may be used by the AP 100-x to assign resource units to non-AP stations of the same BSS by using AIDs assigned to non-AP stations of the same BSS during association with the AP 100-x and/or using reserved AIDs that specify a set of non-AP stations. The TF may also define the start of MU UL transmissions for the non-AP stations 110/170-x, the type of traffic requested (TID) (if any specific is present, otherwise determined by the station), and its length.

When stations involved in data transmission are affiliated with MLDs, such as affiliated AP 100-x (in the case of MLD 10) and affiliated non-AP stations 110-x (in the case of MLD 11, see fig. 1), the MLD as the initiator or the receiver implements a protocol stack introduced in the 802.11be specification as described previously.

To better understand the functionality of the various layers and blocks of the 802.11be multilink reference model of fig. 2, multilink operation (MLO), i.e., data transmission at the AP or non-AP MLD 300 and data reception at the AP or non-AP MLD 350, is now described with reference to fig. 3.

This figure illustrates the ML data transfer between the initiator MLD 300 and the receiver MLD 350. For simplicity, the PHY layer is not shown.

Both the initiator and the recipient MLD may be non-AP MLD 11 or AP MLD 10, or one may be non-AP MLD 10 and the other may be non-AP MLD 11.

Any MLD may include the blocks shown at the initiator MLD 300 for transmission operations and the blocks at the receiver MLD 350 for reception operations. In the example shown, MLDs 300 and 350 share two links 15-x, 15-y. Of course, depending on the number of shared links between MLDs, the number of block LMACs (txlmacs and rxlmacs) may be adapted accordingly.

For multilink communication, each non-AP MLD establishes a multilink association with an AP MLD. For association purposes, the association framework allows non-AP MLDs to exchange frames with AP-MLDs.

In practice, the non-AP MLD may use one of the links (i.e., one of the accessory stations of the non-AP MLD) to associate with the AP MLD (through the corresponding accessory AP station of the AP MLD). The link may be considered a "primary link" or an "anchor link". A discovery process may then be implemented to discover other links that may be established between the same non-AP MLD and AP MLD.

The information exchanged during the association procedure may include BSS configuration, AP information about each link (i.e., information about affiliated stations of the non-AP MLD associated with each link), non-AP STA information about each link (i.e., information about affiliated AP stations of the AP MLD associated with each link), capabilities of each link, tx/Rx constraints of the multiple links.

A multilink communication session is established whenever an MLD needs to exchange data with another associated MLD.

The multilink communication session first includes a setup phase. During the setup phase, the initiator MLD may exchange information and negotiate policies of multiple links of the ML communication session. Further, one or more links may be established at a particular time: establishing a link means that each MLD has all information that enables data operations (transmission or reception) with another MLD sharing the link.

The negotiated policy may include an acknowledgement (ack) scheme, particularly an agreement on terms and capabilities of a Block Acknowledgement (BA) procedure.

The BA procedure proposes to acknowledge the reception of data transmitted using links 15-x or 15-y for each link during a BA session, for example with the aid of an add BA (ADDBA) request and response procedure.

When negotiating about the BA procedure, the negotiating MLD may exchange capability information such as BA size (scoreboard bitmap size), buffer size, window size (e.g., sliding window), sequence number interval to be used, and/or policy, and then agree on common parameters to be used. The obtained BA agreement may be later canceled (e.g., using a delete BA (DELBA) request).

For a given traffic, e.g., for a given TID value, the BA agreement is negotiated at the UMAC level 330, 380 and this is independent of the one or more links used for the transmission of that traffic. In practice, due to the multi-link scheme, data units belonging to the same TID may be transmitted simultaneously on multiple links.

For each BA agreement (i.e., in the case of several TIDs transmitted in parallel), there is an associated reorder buffer at the recipient MLD.

The BA procedure may be better understood by the illustrated transmission from the initiator MLD 300 to the recipient MLD 350.

The UMAC 330 of the initiator MLD 300 receives the application data 30 as input to be transmitted to the recipient MLD 350. The application data may be in the form of several MSDUs. Based on the received MSDU, the UMAC may form an individual MPDU associated with the received MSDU or an A-MSDU aggregated from the A-MSDU.

The data units are then stored in a transmission queue or buffer 332 and associated with sequence numbers to maintain information about their order.

For example, UMAC 330 appends a Sequence Number (SN) to MPDUs at block 331 and assigns the MPDUs to common transmit queue 332. The sequence number is determined using the starting sequence number and a sequence number interval, which is the difference between two consecutive sequence numbers. Information related to the sequence number is shared between the initiator MLD 300 and the receiver MLD 350.

Alternatively, common transmit queue 332 may store MSDUs (rather than MPDUs) directly, each MSDU being associated with an SN by UMAC. In this case, the sequence number is chosen to ensure that the SN of the MSDU frame corresponds to a given MPDU encapsulation.

The common transmit queue 332 is a single transmit queue for all four ACs (i.e., all traffic). According to some embodiments, multiple transmit queues may be used, each transmit queue being associated with a respective AC.

The stored data units may then be routed from the transmit queue 332 to the Tx LMAC 320-x or one of the Tx LMAC 320-y layers (i.e., to one of its secondary stations), typically depending on the allocation of data units (MPDUs) to the multiple links 15-x, 15-y by the UMAC 330. For example, if link 15-x provides communication resources for MLD initiator 300, the data units are routed to the Tx LMAC 320-x layer.

The data units may then be transmitted over multiple links, for example using MPDU aggregation and channel access.

The MU scheme and SU scheme may be used for data transmission on a given link independent of multiple links. In particular, one of the MU schemes employed by IEEE in the 802.11ax-2021 standard may be implemented independently on each link.

The receiving MLD 350 then receives the transmitted data units via its multiple secondary stations, i.e., via its multiple Rx LMAC 370-x, 370-y layers, according to the links 15-x, 15-y over which the data units were transmitted by the initiator.

At the recipient MLD 350, block Acknowledgements (BAs) may be made independently for each link.

To do this, a scoreboard (blocks 371-x and 371-y) may be constructed that lists the received data units. Then, upon receiving a request (i.e., BA request) from the MLD initiator, or upon receiving a plurality of data units, the scoreboard may be sent as a BA frame over the corresponding link to the initiator MLD.

For example, during a TXOP session on one of links 15-x and 15-y, recipient MLD 350 sends BA frames to close the de-communication according to an "immediate block Ack" policy that specifies that BA frames should be received during the TXOP session.

Each link scoreboard 370-x, 370-y may be a BA bitmap including bits associated with a respective sequence number (from an agreed upon Starting Sequence Number (SSN)). The bits may each take a value of 0 if a data unit with a corresponding sequence number has not been correctly received over the associated link when the bitmap was constructed, or a value of 1 if a data unit has been correctly received. The BA bitmap may be generated for a particular traffic (e.g., based on TID values).

According to some embodiments, each link scoreboard 370-x, 370-y may be implemented as a partial state of reception.

The BA mechanism aggregates several acknowledgements into one frame, which improves channel efficiency.

The received and decoded data units are forwarded by the respective Rx LMAC 370 layers to the UMAC 380 layer for storage in a common reorder buffer 381 (i.e., a common receive queue). In this manner, UMAC layer 380 may combine data units arriving over multiple links for BA scoring, MPDU reordering, and the like. Further, a shared common reorder buffer 381 may be used for four EDCA ACs, or multiple reorder buffers may be used.

As shown, the recipient MLD 350 may also maintain a common scoreboard 382 to maintain a long-term record of received data units for a given TID's multilink data transmission, and thus is not limited by the TXOP.

The common scoreboard 382 may be implemented as a full state. The common scoreboard 382 may be updated periodically with the contents of each link scoreboard 370-x, 370-y. For example, the common scoreboard is updated each time each link scoreboard is updated, or at least at the end of the TXOP for each link. The common scoreboard is thus of a larger size than each of the link scoreboards 370-x, 370-y. Still, a common scoreboard is generated for a given TID.

The common scoreboard 382 is used by the BA generation block 383 to generate BA frames.

The BA frame is transmitted to the initiator MLD 300 using one or more of the plurality of links 15-x, 15-y. Preferably, upon receiving the BA request from the initiator MLD 300, a single BA may be sent back for multiple links 15.

Typically, the recipient MLD 350 may send bitmaps of several BA sessions long after the associated TXOP session ends. Thus, this implementation allows for a "delay block Ack" and also supports an "immediate block Ack" policy if the MLD 350 is sufficiently responsive.

The received BA frames and/or each link scoreboard 370-x, 370-y (also BA frames) are used by the initiator MLD 300 to manage the transmission buffer 332, and in particular to remove acknowledged data units (MPDUs and corresponding encapsulated MSDUs) from the transmission buffer 332 based on acknowledgements of data units by the receiver.

On the receiver side, the received data units are reordered upon reaching UMAC layer 380 and then stored in the original order in reorder buffer 381. The receive reorder buffer operation is based on sequence number intervals shared between the two MLDs 300, 350.

The data units are then provided (arrow 39) consecutively to the upper layer 260 (fig. 2) in the original order, which means that the previous data unit (according to the sequence number) has to be transferred before the next correctly received data unit is transferred to the upper layer.

Thus, MPDUs belonging to the same TID may be transmitted over multiple links through multilink aggregation. Even if the BA agreement is established for each TID, it means that all links for a given TID have the same ACK policy, and transmissions are typically independent between links in terms of timing and resource allocation. By default, all TIDs map to all set links for both UL and DL directions, and the non-AP MLD may use any link within the set of enabled links to transmit frames carrying MSDUs or a-MSDUs with that TID.

Optionally, data traffic (or a portion thereof) from an upper layer may be subject to TID-to-link mapping (at both non-AP and AP MLD, as referenced by TID-to-link mapping module 334). TID-to-link mapping features are negotiated between MLD entities during link setup and are intended to indicate links that can exchange frames belonging to individual TIDs. As a result, with respect to this figure, TID-to-link mapping 334 is the management module responsible for directing the access of data to links 320-x and 320-y in both the UL and DL directions.

As previously described, the transmissions on the respective links 15-x, 15-y may be made according to SU or MU schemes. The MU scheme is more efficient and the use of MLO with the MU scheme can increase the peak/average throughput of the MLD.

As defined in the 802.11 network protocol, MU scheme-based data transmission is a scheduled transmission based on the transmission requirements (typically using Buffer Status Reports (BSRs)) declared by the non-AP stations to the AP.

In the case of the BSR mechanism, the non-AP station reports to the AP the amount of data held in the transmit buffer ready for transmission to the AP, i.e., the amount of buffered Uplink (UL) traffic. Accordingly, the BSR mechanism is adapted to report the amount of data held in the transmit buffer corresponding to a given TID.

The information contained in the received BSR enables the AP to schedule MU UL transmissions. The scheduling includes selecting non-AP stations to which to provide MU UL transmissions and determining UL resource units (in terms of bandwidth and duration) to allocate to each selected non-AP station. Thus, each non-AP station having data to transmit is provided with radio resources suitable for transmission.

This mechanism can ensure that non-AP stations with data to be transmitted get the opportunity to make transmissions of such data. Based on knowledge of the amount of data waiting to be transmitted at each non-AP station, the AP manages scheduling to efficiently use the available radio resources.

In the multi-link device context, scheduling is performed by one affiliated AP station of the AP MLD. The affiliated AP of the AP MLD performs scheduling for each link based on a BSR report containing information about a common transmission buffer 332, the common transmission buffer 332 being common to all set links and common to all types of traffic.

In order to meet low latency requirements in EHTs and to increase the efficiency of UL MU operation, a flow classification service (SCS) mechanism is proposed (and recently adapted) to serve as a lightweight mechanism for STAs to inform the AP of their QoS requirements, especially for low latency traffic.

Initially, SCS was proposed by the 802.11aa standard and allowed for higher layer flows to be established with signaling packet drop eligibility (e.g., allowing some packets in the flow to be marked as drop eligibility) and for flows to be classified into access categories (based on TCLAS processing).

A typical scenario using SCS is to process admitted traffic streams, where the SCS then provides a selection of some packets in the audio video stream to discard when the channel capacity is insufficient.

In short, SCS aims to distinguish between different flows within the same access class or for a given TID and covers the need to allow graceful degradation of flows in case of bandwidth shortage (graceful degradation).

According to the document 11-21-0340-11, in the context of multilink, the latest modification of SCS is proposed in the EHT standard.

As reflected in 400 in fig. 4a, the SCS descriptor (the element transmitted in the SCS request and response frames) has been modified such that it directly contains the Traffic Specification (TSPEC) as a set of QoS parameters for describing TS (traffic flow) elements in addition to the existing subfields 420 to 424. The purpose is that the non-AP EHT MLD can directly describe its traffic characteristics.

Each traffic stream is assigned an ID (SCSID, 420) by non-AP STA request classification (managed at the MLD level).

The request type element 421 is a number that identifies the SCS request (add/delete/change) type.

The in-access class priority element 422 provides information from non-AP STAs to the AP regarding the relative priority of traffic flows within the AC. It corresponds to the optional introduction of a surrogate queue (as proposed by the 802.11aa standard) as compared to the four master queues of EDCA.

TCLAS element 423 and processing element 424 (if present) describe traffic classification that the non-AP STA requests the AP to apply to the corresponding flow. These elements are mandatory for the downlink direction (traffic from AP MLD to non-AP MLD) but forbidden for other directions (UL or direct link).

Recently introduced TSPEC element field 425 contains zero or one TSPEC element to describe the traffic characteristics and QoS expectations of the traffic flow belonging to the traffic flow.

TSPEC elements may have other names, which are referred to in some documents as QoS characteristics. In this description, these two names are considered equivalent.

According to fig. 4b, the recently introduced SCS mechanism is still a lightweight protocol for STAs to inform the AP of their QoS requirements. The setting of the SCS uses MAC sublayer management entity (MLME) primitives (generated by the local Station Management Entity (SME) according to the 802.11 management architecture) to generate a set of two network frames:

SCS request frame sent by a non-AP STA attached to a non-AP MLD to an AP of the AP MLD and containing TSPEC elements (within SCS descriptor) with the direction subfield set to uplink or downlink or bi-directional link is interpreted as a request to create (or delete or change according to the value of request type element 421) a traffic flow applied to low latency traffic at the MLD level.

Upon receiving an SCS request frame from an associated non-AP STA, the AP should respond with a corresponding SCS response frame.

However, the recently modified SCS mechanisms are still insufficient to handle delay sensitive flows.

First, SCS mechanisms are intended to specify the characteristics of flows within an AC, but this specification of traffic transmission cannot be related to all data of a given AC. It may be noted that a single STA may support more than one traffic (local application) for a given traffic type (which means that several traffic flows (LLs) may or may not be filled in the same AC queue).

Second, the proposal focuses on DL traffic and does not handle devices that are delay sensitive data generators (e.g., head mounted displays). In SCS, the AP classifies incoming individually addressed MSDUs from a distribution system (typically the internet) based on parameters provided by non-AP STAs. For uplink traffic (content generated by non-AP STAs), TCLASS is not allowed to be specified: the AP does not have information useful for scheduling delay sensitive data pending in the transmission buffer (AC) of the non-AP STA. Traffic specification appears to be provided but no medium access means for accurate delivery is provided.

Third, while modified within the scope of the 802.11be/EHT standard that introduces multilink usage, the SCS mechanisms proposed in the art do not provide any guarantees regarding delay, reliability, or jitter of transmissions over the multilink.

Low Latency Reliable Services (LLRs) are services provided to higher layer traffic flows that prioritize and deliver MSDUs (data units of the traffic flow) within a worst case delay budget with a given reliability/packet transfer ratio (PDR) and low jitter. Traffic that may be of interest to the LLR includes delay sensitive data, i.e., data from applications such as games, media streams, augmented reality, virtual reality, etc.

Thus, the AP MLD, which considers only contention between stations, gives stations an uplink transmission opportunity without considering different available links.

Thus, there is a need to improve MU UL transmissions in an MLD context, in particular in order to improve the transmission reliability of uplink traffic, while ensuring low latency.

The present invention seeks to improve scheduling of radio resources for multi-user transmissions in the presence of an MLO context for the 802.11be standard.

In fact, the non-AP MLD is aware of its traffic resource requirements such that it knows that some radio links are experiencing interference or have limitations in terms of bandwidth, and is in a better position to determine the best link for data transmission at a given time. Typically, a non-AP MLD may seek to use one link for a portion of the traffic flow (e.g., reliability), while other portions of the traffic flow may be less important.

According to a first aspect, the present invention proposes to use a specific flow classification service for a multi-link device, which is based on a legacy SCS but is adapted for a multi-link SCS (ML-SCS), such that each non-AP MLD is able to report a specification of data waiting to be transmitted for all traffic flows or for a given traffic flow together with a link identified by the non-AP MLD on which the non-AP MLD is intended to be scheduled for transmission.

Upon receiving such ML-SCS description, the AP MLD then possesses additional information about the links that the non-AP deems more suitable for subsequent scheduling of UL transmissions in SU or MU mode (fig. 7a and 7 b) or in restricted periods (fig. 8a to 8 c).

In practice, the AP MLD schedules the non-AP MLD in consideration of both contention between stations and the link that the non-AP selects according to the LL traffic specification.

The core of the present invention is thus aimed at enabling a non-AP MLD to provide, together with (in the ML-SCS descriptor further disclosed) traffic specifications reported by the station, a relevant indication about the links that the station expects to schedule by the AP according to the respective traffic specifications. By allowing the MLD to specify the most efficient link for transmitting low latency traffic, the opportunity to have low latency traffic flows that adhere to low latency constraints is improved.

Embodiments of the present invention are generally applicable to any MLD non-AP or AP whose resources are to be scheduled by the AP MLD. According to an embodiment of the invention, the MLD (which may also be referred to as a scheduled MLD) may then provide information about its traffic specification requirements and link constraints to the scheduling station.

For example, in the case of setting up a P2P link between MLDs of a P2P group of stations, a coordinator station acting as a scheduling station of the P2P group (e.g., a group owner, or a device acting as a software AP according to the Wi-Fi Direct protocol) must know real-time information of other stations of the group.

Figure 5 illustrates a modified SCS descriptor that may be used in an ML SCS service according to an embodiment of the invention. The principle is to insert a link_id in the descriptor, typically as a replacement for the TSID field in the TSPEC, since this field is no longer used. Different alternative embodiments are described by means of fig. 6a and 6 b.

As previously described, the traffic specification is described by TSPEC elements (each element beginning with TS information field 540), but any other similar information element (e.g., qoS profile element beginning with control information field) is contemplated.

The proposed format 500 is an adaptation of the format 400, including one or more TSPEC subfields, each TSPEC being associated with traffic specifications on a given link established between a non-AP STAMLD requester and its AP MLD.

In some embodiments, TSPEC 525 (and 526 (if present)) follows a legacy 802.11TSPEC element format of 57 bytes length (530).

TSPEC element 530 contains a set of parameters that define the characteristics of LL traffic flows and QoS expectations in the context of a particular STA of the present invention. The fields following the TS information field are set to 0 for any unspecified parameter value, unless otherwise specified. The STA sets any parameter to unspecified (if the STA does not have information for setting the parameter).

The structure of the TS information field is redefined. Since the legacy TSID subfield (initially at location 550) contains the TSID value when the TSPEC element is included within the ADDTS response frame, this subfield is no longer significant in the SCS (or ML-SCS) descriptor. That is why the invention intends to refresh this subfield within the scope of informing the link to be used for the LL traffic specification. Subfield 550 is now embedded with a link ID that is still 4 bits long. Thus, one TSPEC is associated with one link.

Of course, the link ID information may be substituted with a location, for example, within reserved bits B17 through B23.

The link ID subfield 550 specifies a value that uniquely identifies the link on which the STA is reporting traffic specifications.

Preferably, link ID subfield 550 is set to 15 if the amount of data reported is global and no part is requested to be transmitted on a given link, or if the reporting device does not have this information. This provides compatibility with SCS descriptors where TSID has no meaning.

The link ID is the current information of the AP, which simply and efficiently provides information for scheduling the next communication slot for the indicated link. It should be noted that "AP ID" may also be used instead of "link ID" to identify a link.

In practice, the term "link" is generally used to designate an entity that connects two endpoints (i.e., an affiliated station of a non-AP MLD and an affiliated AP of an MLD). From this perspective, in some embodiments, the accessory AP may terminate several links, making the AP ID more suitable as a link ID. The following embodiments are described below with reference to link IDs.

Among the subfields of the TS information 540, the direction subfield 551 specifies the direction of data carried by a specified flow (uplink, downlink or bi-directional link (equivalent to a downlink request plus an uplink request, each direction having the same parameters), other subfields (access policy subfield, aggregation subfield, APSD subfield, UP subfield, TS information acknowledgement policy, scheduling subfield) are less important in the context of SCS and may be set to be reserved.

In some embodiments, several TSPECs 525, 526, etc. specify respective traffic specifications for dedicated links, such as those provided by non-AP STAs. Thus, the link ID 550 of the TS information subfield of each TSPEC is different from the latter(s). Of course, when a field in a TSPEC element specifies a resource for a single direction (rather than bi-directional), there may be dual-specified TSPEC resources with the same link ID to support both flow directions.

As disclosed in the figure, the TSPEC with the link ID set to 15 is referred to as a common TSPEC (common to all links), and is followed by other TSPECs 526 that refine the specifications of individual links. In this case, the direction subfield 551 is reserved.

For example, the nominal MSDU size and maximum MSDU size values are common for a given LL traffic flow, so this information may appear in common TSPEC subfield 525. On the other hand, the minimum service interval and maximum service interval fields may be link-specific for each link, so it is important that they appear in the link-specific TSPEC element 526.

For fields following the TS information field, when a link-specific TSPCE element is present in the ML-SCS, the non-AP STA should specify all parameter values specific to the link. If any parameter in a link-specific TSPEC element has an unspecified value, then the corresponding value is the parameter value (inheritance) of the common TSPEC element 525.

In a preferred embodiment, the non-AP STA sets the minimum service interval and maximum service interval fields in any link-specific TSPEC element (or at least in the common TSPEC if no link-specific exists) transmitted in the ML-SCS descriptor element. These indications relate to minimum and maximum intervals in microseconds, respectively, for which requests are scheduled for UL traffic (if the direction subfield in the TSPEC element is equal to 0) or direct link traffic (if the direction subfield in the TSPEC element is equal to 1).

When the non-AP station informs of the traffic specification of DL traffic (if the direction subfield in the TSPEC element is equal to 2), the link ID field 550 may be used only for recommendation: since the transmitter of DL data is an AP MLD, it is still decided by itself on a better link for transmission.

In addition, format 500 includes an indication of the overall link that the station expects to be scheduled by the AP MLD. The non-AP MLD (i.e., secondary station) that knows the traffic to be communicated over the link provides an indication of the link to be considered for transmitting the traffic stream, e.g., SCSID referencing the current ML-SCS, within the ML-SCS descriptor through the set of TSPEC elements (525 and 526).

In a preferred embodiment, the link list generated by the TS information elements of each TSPCs 525 and 526 is adapted for TID-to-link mapping. Recall that TID-to-link mapping features are negotiated between MLD entities during link setup and are intended to indicate links that can exchange frames belonging to individual TIDs. As the SCS descriptor refines the classification of the LL stream that already corresponds to the TID (in other words, the LL stream is a sub-portion of the data content of the TID and stored in the non-AP STA MLD transmission buffer), it is envisaged that these links suitable for conveying the LL stream (identified by the SCSID) form a subset of the links identified by the TID-to-link mapping of the TID.

It may be noted that the use of ML-SCS descriptor formats may be extended to many implementation-specific algorithms for network resource allocation over multiple links.

Several examples of ML-SCS are now described in connection with fig. 6a and 6 b.

Indeed, still according to the first aspect of the invention, there is provided a frame comprising an ML-SCS format (430 or 431) as described hereinbefore.

Figure 6a illustrates the use of a new element (i.e., SCSID to link map element 600).

According to an aspect, it is proposed to use a specific flow classification service (ML-SCS) adapted to a multi-link device, such that each non-AP MLD is able to negotiate with its AP MLD a set of links that the non-AP MLD expects to be scheduled for transmission.

Thus, SCSID-to-link mapping element 600 indicates links that can exchange frames belonging to the individual traffic flows identified by the SCSID.

The direction subfield 601 is set to 0 (uplink) if the SCSID-to-link mapping element provides SCSID-to-link mapping information to a frame transmitted on the uplink. The direction subfield 601 is set to 1 (downlink) if the SCSID-to-link mapping element provides SCSID-to-link mapping information to a frame transmitted on the downlink. The direction subfield 601 is set to 2 (bi-directional link) if the SCSID-to-link mapping element provides SCSID-to-link mapping information to frames transmitted on both downlink and uplink. A value of 3 is reserved.

The "link map of SCSID" field 602 of the current SCS descriptor indicates the links that are allowed to transmit frames belonging to SCSID. A value of 1 in bit position i of the link map field indicates that the SCSID is mapped to the link associated with the link ID i of the direction specified in the direction subfield.

Thus, both the direction field value and the "link map of SCSID" field value indicate the maximum number of TSPECs that can be listed in the SCS descriptor.

If not all TSPEC elements are listed in the SCS descriptor as compared to the determined maximum number of elements, the missing TSPEC elements indicate that no requirement is required (in other words, transmission of LL traffic on a given link in a given direction is unspecified).

In some embodiments of the example shown in fig. 6b, TSPEC 525 (and 526 (if present)) has a format of reduced size, also known as TPSEC-Lite.

The common TSPEC element 625 contains a set of parameters defining the characteristics of the stream (MSDU size, etc.).

Link-specific TSPEC element 626 contains a set of parameters that define the characteristics of the stream to be transmitted onto a given link (as indicated by SCSID-to-link mapping element 600).

It may be noted that the ML-SCS format may be extended to many implementation-specific algorithms for network resource allocation over multiple links.

According to some embodiments, the non-AP MLD (scheduled station) passes the multi-link SCS descriptor to assist the AP MLD (scheduling station) in allocating UL MU resources or allocating links for UL transmissions.

The resulting trigger frame issued by the AP of the AP MLD is presently disclosed in connection with fig. 7 a.

Fig. 7a illustrates the MAC format of a trigger frame 330 according to the 802.11ax standard and adapted according to an embodiment of the invention. The use of SCSIDs in UL MU operation is illustrated. As will be described in connection with fig. 8a to 8c, adapted trigger frames for low delay traffic flows may be used to trigger a target wake-up period.

The trigger frame is used to allocate (random and/or scheduled) resource units for UL MU transmissions on the link of STAs that utilize the non-AP STA MLD. The trigger frames are replicated in each 20MHz of the target composite channel (or link) to preserve transmission opportunities on the composite channel. The trigger frame follows the legacy format of the control frame (no specific HT preamble).

TF 700 consists of a MAC header and additional fields. The MAC header includes the following fields that are common to all control frames: a frame control field 701, a duration field 702, a RA (receiver address) field 703, a TA (transmitter address) field 704. The trigger frame specific additional fields include a data portion formed by an information field (710 and 720) and a CRC/FCS (cyclic redundancy check, or frame check sequence, or also referred to as checksum) field. The CRC/FCS field may optionally precede a variable size padding field for consideration in the scope of the present invention.

The duration field 702 is set to an estimated time in microseconds required for a pending uplink transmission and is used to set the NAV of the node for which the RA field 703 is not intended. Thus, the duration field 702 sets the expected duration of the solicited transmission opportunity (TXOP).

The RA field 703 is set to the address of the receiving station. Since the trigger frame is intended for a group of station apparatuses (within a BSS on a link transmitting the trigger frame), a wild card MAC address (FF: FF) may be used as a broadcast indication.

The TA field 704 is set to the MAC address of the accessory AP of the AP MLD transmitting the trigger frame. When an AP hosts multiple virtual APs for multiple BSSs, the MAC address of the current BSS (i.e., the particular BSSID or MAC address of the associated virtual AP) is used for TA field 704.

A user information field 720 forming part of an additional field in TF 700 is now illustrated.

The user information field 720 defines the allocation of one or more resource elements to the node of the BSS addressed in the TA field 704. Multiple user information fields 720 are typically used to define the allocation of all resource units of a transmission opportunity.

The user identifier subfield 721 (also known as AID12 subfield 721) contains (for transmission of MPDUs in the uplink direction) 12 LSBs of the Association Identifier (AID) of the station to which the RU identified in the RU allocation field 722 is allocated. AID is a 16-bit unique value assigned to the non-AP MLD that is a common value for all dependent STAs of the non-AP MLD and is assigned by the AP MLD during an association handshake (i.e., during registration).

RU allocation subfield 722 indicates one or more RUs allocated to one or more stations identified in AID12 subfield 721.

The other fields of the user information field 720 are less important to the present invention.

The user information field 720 is illustrated in accordance with the HE format provided by the 802.11ax standard (the 802.11ax standard incorporates the specification of a high efficiency station or HE station). The EHT format envisaged by the 802.11be standard provides variations to the use of bits B25 and B39 (not important to the invention).

One particular field important to the present invention is trigger related user information 730, which follows the common format of HE and EHT.

The trigger related user information 730 is one octet long and is present in the basic variant trigger frame, i.e., the TF that triggers the trigger-based data (TB PPDU).

The MPDU MU interval factor subfield is not important to the present invention. According to the HE and EHT formats, the TID aggregation limit subfield 731 indicates the maximum number of TIDs allowed in a-MPDUs carried in the TB PPDU and aggregated by STAs in an aggregated MPDU (a-MPDU). The preferred AC subfield 733 indicates the lowest AC recommended for aggregating MPDUs among a-MPDUs contained in the HE TB PPDU transmitted as a response to the trigger frame.

According to some embodiments of the present invention, when bit B5 (732) is no longer reserved, i.e., when the value of B5 is "1", the relevant user information is triggered to adopt format 740. This is intended to indicate that flow class service identifier (SCSID) information is provided instead of TID information. As a result, the "SCSID part 1" field 741 and the "SCSID part 2" field 743 replace the fields 731 and 732, respectively, to obtain an SCSID value formed of 5 bits. In an option, only one of the fields 741 or 743 may be used, as there would not be so many SCSID values for each station, and the values could be encoded onto 2 or 3 bits.

The obtained SCSID is set to a non-zero value selected by the non-AP STA for identifying the SCS stream specified in the ML-SCS descriptor element. The SCSID indicates an LL stream recommended for aggregating MPDUs in an a-MPDU included in the HE TB PPDU transmitted as a response to the trigger frame. The SCSID field is set to the value of the SCSID field in the ML-SCS descriptor element received in the SCS request frame 430.

The formats presented herein are for illustration only, and any other combination of presence bits 732 and/or variants for encoding SCSID values (preferably for each user information field) may be envisaged within the trigger frame format.

The adapted trigger frame allows the AP MLD to allocate resources specific to one or more traffic flows. The allocation is based on preferences received from the non-AP MLD for the mapping of traffic flows to links.

Fig. 7b illustrates a second MAC format of a trigger frame 330 according to the 802.11ax standard and adapted according to an embodiment of the invention. Both the use of SCSID and TID in UL MU operation are illustrated.

As previously described, SCSID-based low-latency traffic differentiation mechanisms provide optimal efficiency and finer granularity for latency sensitive traffic. However, this implies an additional act of the station finely separating the low-latency data from the normal data, such that only selected low-latency data is transmitted during the triggered mechanism or reserved service period (as shown in fig. 8 a-8 c). Selecting a sub-portion of the data passing through the TID may affect the implementation of the device, i.e., the management of the sequence number (since some MSDUs will take precedence in the transmission). In other words, the SCSID-based low-latency traffic differentiation provided by the present invention may be considered by the high-end station device, while the low-end device may be limited to consider TID-based low-latency traffic differentiation (less efficient, triggering TID means that low-latency data within the TID may be transmitted with everything within the TID).

This embodiment aims to handle both high-end station devices and low-end station devices.

Thus, fig. 7b provides a MAC format of a trigger frame adapted to indicate which differentiation mechanism is requested by the AP (TID or SCSID).

The user information field addressed to the non-AP STA is either the HE variant or the EHT variant.

Basically, only the "trigger related user information" field is modified:

format 750 is "trigger related user information" (e.g., 740) conforming to the HE station, also referred to as HE variant format. It may be noted that even if low latency services are reserved to EHT stations (not known by the HE device), the format of such EHT stations for triggering the present invention may follow the HE (802.11 ax) format (thus the TB PPDU is an HE TB PPDU)

The format 760 illustrates a possible modification to the EHT "trigger related user information" field (which may be referred to as an EHT variant) and is therefore limited to an EHT station (that is, this format 760 is used when the user information field 720 is addressed to an EHT STA and the TB PPDU format complies with the EHT TB PPDU format). The illustration of 760 provides consistency in size with the HE variation, but this may be modified if all of the user information fields in the user information list field of the trigger frame are prohibited from having the same length.

Returning to the HE variant (format 750), the trigger-related user information fields in the trigger frame are interpreted differently by the HE device and the EHT device. If B5 in the trigger-related user information field is equal to 1, the EHT STA according to the present invention interprets the trigger-related user information field as an EHT variant; the requested differentiation mechanism is then interpreted according to the trigger correlation type subfield 751 (B2).

For example, trigger related type subfield 751 identifies the encoding of HE trigger related user information field variants:

trigger related type subfield value	EHT trigger related type variants
		0	The SCSID/TID subfields (part 1 and part 2) represent TID values
1	The SCSID/TID subfields (part 1 and part 2) represent SCSID values

Returning to the EHT modification (format 760), the trigger-related user information field in the trigger frame is directly interpreted as an EHT format, as only EHT devices may receive this type of information. Thus, the returnable compatible format (e.g., 730/730 with B5) is no longer needed. Thus, the subfields containing the SCSID/TID information may be larger, so that more SCSID values may be addressed within 5 bits. With regard to TID encoding, B3 is reserved (0) because TID remains encoded with 4 bits.

For example, trigger related type subfield 761 identifies the encoding of EHT trigger related user information field variants:

Trigger related type subfield value	EHT trigger related type variants
		0	SCSID/TID subfields (B4 to B7) represent TID values
1	SCSID/TID subfields (B3 to B7) represent SCSID values

To prioritize LLRS traffic over non-LLRS traffic within a BSS, a Service Period (SP) (also referred to as LL SP) may be reserved for LLRS traffic. Fig. 8a illustrates reservation of service periods for low latency traffic flows according to an embodiment of the present invention. Thus, the possibility is provided to prioritize LLRS traffic over non-LLRS traffic within the BSS.

In illustration, the affiliated AP of the AP MLD schedules reserved service periods 910 on one link. The AP may announce the start time and end time of the period. The reserved service period 910 may be entirely dedicated to LLRS traffic exchange or in variations may allow both LLRS traffic and non-LLRS traffic. In the figure, there is a reserved LLRS period.

The AP participates in LLRS traffic exchange for the reserved service period (transmitting 921 to the non-AP station and then receiving 922 from the non-AP station). However, this is not mandatory. The non-AP stations may instead use the reserved LLRS periods to directly exchange P2P LLRS traffic.

To illustrate SU communication, the non-AP station sta_3 wins access to the wireless medium and may begin transmitting non-LLRS traffic 920 before the reserved service period. The AP may then transmit LLRS traffic 921 to non-AP station sta_1 and then receive other LLRS traffic 922 from non-AP station sta_2.

Preferably, the communications 921 and 922 are MU communications, wherein the MU communication 921 comprises a TF issued by the AP and intended to trigger the MU communication 922.

However, measures need to be applied to ensure that the service period is limited to LLRS traffic transmission.

In an embodiment of the invention, the reserved service period is a protected Target Wake Time (TWT) service period (referred to as TWT SP or LL TWT SP).

The target wake-up time enables the device to determine when and how often to wake up to send or receive data. TWTs allow an AP to manage activity in the network to minimize medium contention between STAs and reduce the amount of time required for STAs on a link to wake up in a power save mode. Due to this mechanism, STAs other than the AP STA MLD can sleep (except during the TWT Service Period (SP) interval set on the link).

TWT SPs may be individually agreed upon or broadcast. An individual TWT SP is a specific time or set of times negotiated between an AP and a STA (one referred to as a TWT requesting station and the other as a TWT responding station) and at which time the STA is expected to wake to exchange frames with the AP. During negotiation, the AP and STA transmit a specific information element (TWT IE) to each other, which contains TWT parameters and may be interpreted as a request, suggestion, requirement, substitution, acceptance, dictation or rejection. The AP or STA may tear down the TWT by transmitting a TWT tear down frame. Broadcast TWTs are similar to individual TWTs (except that a particular time or set of times is not negotiated between stations, but is broadcast directly by an AP to multiple non-AP stations, e.g., using beacon frames). In this case, the AP uses another mechanism based on the Traffic Indication Map (TIM) element to indicate the set of STAs towards which the AP is to transmit (downlink Data (DL)) or to which the AP is to trigger for uplink traffic. If the STA is not indicated in the TIM element, this means that it will not be solicited in the next TWT SP.

Figure 8b illustrates a format suitable for a TWT IE associated with an ML-SCS service, according to an embodiment of the invention.

The TWT IE 800 is identified by an element ID 801 and includes a field 820 for transmitting TWT parameter information. The "control" field 810 (not illustrated) allows notification of whether the TWT is a broadcast TWT or an individual TWT agreement via the "negotiation type" field.

The TWT parameter information field 820 contains a single individual TWT parameter setting field (in the case of an individual TWT) having a format 830a, and one or more broadcast TWT parameter setting fields (in the case of a broadcast TWT) having a format 830 b.

Individual TWT

In accordance with the present invention, an SCSID subfield 831a is provided in the individual TWT parameter set field 830 a.

The SCSID field 831a is set to a non-zero value selected by the non-AP STA to identify the SCS stream specified in the ML-SCS descriptor element. SCSID indicates LL flows negotiated (or being negotiated) for transmission within the current TWT IE. The SCSID field is set to the value of the SCSID field in the ML-SCS descriptor element received in the previously exchanged SCS request frame 430.

Thus, individual TWTs are easily limited to LL traffic flows identified by SCSID values. The reserved SP 910 applies to the restricted individual TWT set for the LL stream identified by the SCSID value.

Another advantage of informing the SCSID is also that any link ID bitmap is avoided from being provided within the TWT IE, as this information is already provided by the ML-SCS descriptor.

Broadcast TWT

In accordance with the present invention, SCSID information is provided for broadcast TWTs such that reserved SPs 910 are applied to restricted broadcast TWTs set for LL streams identified by SCSID values.

In one embodiment, the SCSID is located directly within the "broadcast TWT info" field 832 that defines the TWT parameter set. Typically, the first 3 bits reserved according to 802.11be d1.0 may be used to support this field (841).

The various broadcast TWT information fields are identified by a "broadcast TWT ID" field 842, allowing the AP to schedule multiple sets of broadcast TWT SPs having different sets of TWT parameters. Thus, the broadcast TWT ID 842 indicates that the transmitting STA is providing a particular broadcast TWT of TWT parameters. The broadcast TWT persistence subfield indicates the number of Target Beacon Transmission Times (TBTTs) during which there are broadcast TWT SPs corresponding to the broadcast TWT parameter set. The broadcast TWT persistence subfield is incremented by 1 (except that a value of 255 indicates that the broadcast TWT SP exists until the SCS stream is explicitly terminated (e.g., an ML-SCS request or response frame with request type element 421 including a remove indication).

The SCSID field 841 is set to the value of the SCSID field in the SCS descriptor element received in the ML-SCS request frame.

Note that broadcast TWT ID values may be assigned to several non-AP STAs, thereby scheduling several STAs in the TWT LL SP, each STA for its particular SCSID SCS stream.

In an alternative embodiment, the SCSID is located in another field 833 following the "broadcast TWT information" field 832.

When the limited TWT traffic information present subfield 844 is set to 1, there is a limited TWT traffic information field 833. This value is mandatory when the broadcast TWT is associated with SCS LL streams (otherwise, the traffic information is associated with TID).

The limited TWT traffic information field 833 consists of a "traffic control information" field that indicates whether the following fields 851, 852, and 841b are valid.

The DL TID bitmap valid subfield 853 (accordingly, UL TID bitmap valid subfield 854) indicates whether the "limited TWT DL TID bitmap" field 851 (accordingly, the "limited TWT UL TID bitmap" field 852) has valid information. These fields are less important to the present invention because they identify TID as delay sensitive traffic.

The "SCSID valid" 855 subfield indicates whether SCSID field 841b has valid information. When this value is set to 0, it indicates that no SCS is identified as delay sensitive traffic for the current TWT IE and SCSID field 841b is reserved. A value of 1 indicates that the current TWT IE depends on the SCS stream identified by SCSID value 841 b.

When valid, SCSID field 841b in the limited TWT traffic information field is always set to a non-zero value.

SCSID field 841b is mutually exclusive with respect to TID bitmaps 851 and 852. That is, the current TWT IE refers to either TID stream or SCSID stream (not both).

Since the context of rtvt traffic information depends on broadcast TWTs, it can be considered to indicate the needs of various SCS streams. Thus, SCSID subfield 841b (not shown in the figure) may be composed of several SCSID fields (each 1 byte) to indicate that the length or number of the SCSID field to be followed indicates that the field is a prefix.

The TWT IE 800 including SCSID information may be included in the beacon frame to indicate a broadcast TWT SP during which the AP intends to send a trigger frame for the SCS stream identified by the SCSID.

The non-AP STA MLD may request to become a member of the broadcast/individual TWT by transmitting a TWT request frame to its associated AP MLD containing the TWT element 800.

Fig. 8c illustrates a format of a TWT IE that replaces the format of fig. 8b, according to an embodiment of the invention.

As previously described, the broadcast TWT addresses several EHT stations to provide a reserved service period common to these stations. Thus, the SP may specify only a global policy common to all scheduled STAs for low latency traffic discrimination:

The limited TWT DL TID bitmap 851 and limited TWT UL TID bitmap 852 subfields specify which TIDs are identified by the TWT scheduling AP or TWT by the scheduling STA as delay sensitive traffic flows in the downlink and uplink directions, respectively, but the specification is the same for all TWT stations.

SCSID subfield 841a or 841b (or in an alternative not illustrated in fig. 8b, several SCSID subfields) indicate values that can be used by several non-AP TWT stations. This is due to the fact that: the SCSID value is a non-zero value selected by the non-AP STA to identify the SCS stream specified in the SCS descriptor element passed by the non-AP station to its AP. This makes the SCSID value unique from the perspective of non-AP STAs, but not for the AP (several STAs may choose the same SCSID value starting from 0 to specify their own traffic flow).

Fig. 8c provides an updated format for the limited TWT traffic information field 833, where separate identification is supported: that is, the TWT scheduled STA may discover the flow identity for itself and is not misled by identities that depend on other stations. Thus, some stations may use TID-based identification of LL streams, while other stations may use SCSID-based identification during the same service period.

New format 833b contains a new field "individual ID information" 861b of variable size instead of 841b.

The "individual ID valid" subfield 865 indicates whether "individual ID information" 861b is valid. When valid, the "individual ID information" 861b in the limited TWT traffic information field 833b is always set to a non-zero value.

Preferably, the "individual ID information" 861b is mutually exclusive with respect to the TID bitmaps 851 and 852. That is, the current TWT IE refers to the global TID stream selection or to the individual ID stream of a given STA.

Alternatively, if both are present, the "individual ID information" 861b information takes precedence over TID bitmaps 851 and 852: that is, the TWT STAs that find the identification flow within the "individual ID information" 861b will therefore ignore TID bitmaps 851 and 852. This alternative embodiment enables the broadcast TWT SP to serve the streams of individual STAs with the same flexibility achieved by the individual TWTs (individual TWT parameter set field 830 a).

The "individual ID valid" 865 subfield is composed of:

- "number of SCSID tuples" subfield 870 indicates the number of tuples 875 in "individual ID information" field 861 b.

A series (preferably at least one) "ID tuple" fields 871, each field indicating a flow identification corresponding to a non-AP TWT STA.

The "ID tuple" field 871 is two bytes long and consists of:

an AID12 subfield equal to the 12 LSBs (typically set to a value between 1 and 2006) of the AID of the non-AP TWT scheduled STA;

-a type subfield 876 identifying the identification variant;

-SCSID/TID subfield 877, which is an identification value in the context of TWT non-AP scheduled STA, indicating TID or SCSID flow.

For example, the encoding of type subfield 876 is equivalent to trigger related type subfield 761 previously described in the context of a trigger frame according to an embodiment of the present invention.

Type subfield value	Tuple identification variants
		0	SCSID/TID subfields (B28 to B31) represent TID values
1	SCSID/TID subfields (B16 to B31) represent SCSID values

It should be noted that each ID tuple is independent: one may refer to the TID variant and the second may refer to the SCSID variant.

TWT IE 800 including such format 833b is preferably included in a beacon frame to indicate the individual identification of the streams intended to be scheduled during broadcast of the TWT SP. As a result, each TWT scheduled STA can be predetermined to be addressed to a particular low latency data traffic by the rtwts scheduled SP, as requested by the non-AP STA through the initial SCS request mechanism.

By providing accurate identification of low latency flows for each station, rTWT broadcast SP will be more efficient because only enough traffic is transmitted. This precise identification avoids misleading scheduled STAs in rtvt services. For example, false identification of a flow may cause the STA to wake up for rtvt SP to pass other traffic data or, worse, no traffic data.

Further, having similar identification in complementary mechanisms such as rTWT IE and trigger frame aims at simplifying and coordinating low delay traffic discrimination for each station so that both high-end station devices and low-end devices can be considered.

Fig. 9 illustrates an alternative detailed architecture of an ML device according to an embodiment of the present invention.

The figure is intended to describe the use of the same sequence numbers for data of traffic flows identified by SCSIDs rather than by equivalent Types (TIDs) in the AC. The sequence numbers of the incoming MSDUs remain ordered in the tx queue, but because delivery may be within a limited TWT period, the sequence is unordered in UMAC 380 to quickly deliver LL traffic 39.

According to the present invention, UMAC 430 needs to properly direct or route data units belonging to SCS flows according to SCSID-to-link mapping. The SCSID-to-link mapping module 350 performs this handoff.

All data traffic from the upper layers may be co-sequence numbered, followed by link mapping. Preferably, all traffic follows TID-to-link mapping followed by SCSID-to-link mapping. Thus, the SCSID-to-link mapping is formed by the subset of links allowed by the TID-to-link mapping. This provides a means for storing SCS data in the same AC as data of the same TID.

In a variant, the data traffic belonging to the set SCS may be SCSID-to-link mapped only. This provides a means of buffer differentiation at the transmitter side (that is, using a different queue to store SCS streams prior to transmission).

In a preferred embodiment, a block acknowledgement policy is established for both variants. In practice, the validation scheme or policy is typically defined at the TID level. This means that (e.g., low latency) sub-portions of TID (traffic flows belonging to SCSID) are exchanged on a particular link or links according to the same acknowledgement bitmap as the rest of TID data.

The received BA frame is used by the initiator ML device to remove the data unit (MPDU and thus the corresponding encapsulated MSDU) from the BA frame based on the acknowledgement sequence of the data unit (MPDU) by the recipient. In a multi-link context where at least two links are active, only the 1 value of the bit in the bitmap/scoreboard is important: indicating that the corresponding data unit has been received correctly. The value 0 is no longer important because it only indicates that the data unit has not been received yet, yet does not specify whether it is lost or not yet arrived (because it is transmitted over another link). This is in sharp contrast to conventional behavior (of the oldest IEEE 802.11 version), where each successive bit value in the BA bitmap defines the acknowledgement status of each successive data unit starting from the SSN (starting sequence number identified in the BA frame).

Therefore, even if data from the SCS stream is transmitted in advance with respect to the remaining data of the same TID, the 0 value in the ACK bitmap has no side effect.

Based on the BA bitmap/scoreboard received, the buffer update module 333 removes data units that were correctly received by the recipient (i.e., data units with bits in the BA bitmap having a value of 1). This operation frees up space in the transmission buffer 332 to allow new data 30 to fill the buffer to be transmitted.

Conventionally, on the receiver side, the received data units are reordered upon arrival at UMAC 380 and then stored in the original order in reorder buffer 381. The receive reorder buffer operation is based on a sequence number interval shared between two ML devices.

In accordance with some aspects of the present disclosure, low latency data units cannot be passed to upper layers in reorder buffer 381 as long as all previous data units (whether or not they are low latency data units and/or data units having a high level of reliability) have been correctly received and passed. This phenomenon is known as the head of line blocking problem in FIFO queues. It is well known that head-of-line blocking reduces the efficiency of the MAC protocol in terms of delay delivery.

In this context, it is desirable to facilitate the transmission of low latency data units of SCSIDs when performing multi-link operation for SCS streams. It is proposed that MSDUs belonging to SCS are not sent to upper layers by reordering buffer 381, but rather are sent to upper layers without waiting that all previous data units have been received correctly, thus improving the low delay quality of advanced applications.

In addition, the sequence number of the SCS data is still given to reorder buffer 381 so that the module will detect these pending MSDUs that can be delivered in sequence when a new sequence arrives. This also aims to inform vulnerabilities in sequence numbers of MSDUs belonging to an SCS stream, so that MSDUs that are not part of the SCS stream do not wait for missing SCS MSDUs that have been transferred.

Figure 10a illustrates an exemplary embodiment of the present invention implemented at a non-AP MLD using a flowchart intended to request SCS streaming communication according to an embodiment of the present invention.

The following operations are performed by the non-AP MLD and transmit a transmission of a management frame to the AP MLD on any link that is active (in other words, the non-AP MLD selects any of its active dependent STAs).

At step 1010, an MLME-scs.request primitive is received locally from the upper layer application and requests transmission of an SCS request frame to the AP.

The non-AP MLD requests the use of SCS (by using a designated dependent STA) by transmitting an SCS request frame including an ML-SCS descriptor element having a request type field set to "add" or "change". The SCS descriptor list field in the ML-SCS descriptor element identifies how the MSDUs are classified according to the local application provider and the priorities assigned to the MSDUs that match the classification.

The SCS descriptor also informs the direction of the data carried by the specified flow (in this case, typically the uplink) in a direction subfield 551.

If the requested SCS is accepted by the AP, the non-AP STA will process the subsequently incoming local MSDUs to determine if they match the classification specified in the SCS descriptor element.

In step 1012, the dependent STA of the non-AP MLD starts TWT negotiation with the AP MLD, i.e., limited TWT (rTWT) negotiation, as it involves LL traffic. The restricted TWT agreement may be established using the same procedure used to set up the broadcast TWT agreement. Note that individual TWT agreements are also possible. According to any variant of fig. 8b, the TWT request frame is transmitted with a TWT IE800 with SCSID specification.

After successfully completing negotiations, the non-AP MLD (acting as a TBTT scheduled STA) may enter a dormant state on some links (the links notified by the ML-SCS descriptor in TWT IE 800) until its Timing Synchronization Function (TSF) matches the next negotiated wakeup TBTT (assuming the STA is in power save mode and no other conditions require the dependent STA to stay awake on these negotiated TWT links). The TBTT is scheduled for the STA to be in an awake state to listen for beacon frames transmitted at the negotiated awake TBTT.

Fig. 10b illustrates, using a flowchart, an exemplary embodiment implemented at a scheduling AP MLD after the AP MLD receives a multi-link SCS request according to an embodiment of the invention.

Upon receiving the ML-SCS request frame from the associated non-AP MLD (step 1050), the AP will respond with a corresponding SCS response frame. When the AP MLD accepts the ML-SCS request for the requested SCSID, a success value should be set in the corresponding status field of the SCS status in the SCS response frame.

In step 1051, the AP MLD (acting as a TWT scheduling AP) receives a TWT request from a STA affiliated with the non-AP MLD.

The AP MLD accepts the TWT agreement with the STA and acknowledges the acceptance in the TWT response sent to the non-AP MLD. The scheduling AP MLD also includes a broadcast TWT element 800 in the beacon frame it transmits. Thus, the non-AP MLD may obtain the TWT parameter (update) value of the requested SCSID from the most recently received TWT element carried in the beacon frame.

Upon receiving a request to terminate a previously accepted traffic flow (not illustrated in the flowchart), the AP MLD will cease applying the classifier associated with the SCSID. The AP MLD should send an SCS response frame confirming termination of the traffic stream identified by the SCSID by including the SCSID and a "termination" value in the state field of the SCS state in the SCS response frame. Such SCS response frames should not contain any TSPEC elements.

The AP shall also tear down the TWT agreement by sending a TWT tear down frame.

As a result, negotiations to become, or terminate, rTWT members are performed by exchanging frames carrying TWT element 800.

The present example discloses a trigger-enabled rtvt agreement that schedules trigger frames for transmission for non-AP MLDs within individual TWT SPs of the rtvt agreement related to traffic flows (the trigger frames may be replaced by frames carrying TRS control subfields (assuming the frames are carried in DL MU PPDUs and the APs allocate sufficient resources for STAs in HE TB PPDUs)).

Fig. 10c and 10d illustrate using a flow chart embodiments of the invention implemented at a scheduled station (non-AP MLD) and at a scheduling station (AP MLD) during rTWT SP.

Recall that the non-AP MLD wakes up to receive the beacon frame to determine the broadcast rTWT.

The TWT scheduled STA (non-AP MLD) should be in an awake state on the indicated link and at the start time of the TWT where the STA has an agreement.

The AP MLD schedules transmission of trigger frames during rtvt SP. Delivery of individually addressed DL MSDUs may be scheduled. The trigger frame (step 1061) should contain at least one user information field addressed to the TWT scheduled non-AP MLD and triggering the PPDU associated with the SCSID. A trigger format 740 is used.

The non-AP MLD scheduled STA is responsible for selecting appropriate data (i.e., data belonging to the traffic stream identified by the SCSID) and forming a TB PPDU in response (steps 1021 and 1022).

Preferably, only data related to the traffic stream (identified by SCSID) is allowed to be part of the TB PPDU. This ensures fairness for all remaining non-LL data in the AC queues because no other Traffic (TID) utilizes medium access.

Alternatively, if the TSPEC information is not important enough to define the amount of pending data for the traffic flow of the current LL SP (e.g., a minimum service interval and a maximum service interval field are provided), the TWT scheduling AP may schedule a trigger frame for Buffer Status Report (BSRP) for transmission at the beginning of the LL TWT SP. Such BSRP TF has the same format as 700 except that the trigger type (within the common information field 710) is a BSR type value (value '4') and the trigger related user information subfield exists and complies with the format 740. Optionally, the BSRP TF follows a legacy format (i.e., there is a trigger related user information subfield), but the non-AP MLD scheduled STA may notify the pending data of the traffic flow related to the TWT LL SP (SCSID context is known).

Fig. 11a schematically illustrates a communication device 1100 (a non-AP MLD embedded with a plurality of non-AP stations 110 or an AP MLD embedded with a plurality of AP stations 100) configured to implement a radio network (network) of at least one embodiment of the present invention. The communication device 1100 may preferably be a device such as a microcomputer, a workstation, or a lightweight portable device. The communication device 1100 includes a communication bus 1113 that is preferably connected to:

a central processing unit 1101, such as a processor, labeled CPU;

a memory 1103 for storing executable code of a method or method steps according to an embodiment of the invention, and registers adapted to record variables and parameters needed to implement the methods; and

at least one communication interface 1102 that connects to a wireless communication network (e.g., a communication network according to one of the IEEE 802.11 family of standards) via a transmit and receive antenna 1104.

Preferably, the communication bus provides communication and interoperability between various elements included in the communication device 1100 or connected to the communication device 1100. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 1100, either directly or through other elements of the communication device 1100.

The executable code may be stored in a memory (which may be a read-only hard disk) or on a removable digital medium (e.g., a disk). According to an alternative variant, the executable code of the program may be received via the interface 1102 by means of the communication network to store the executable code in the memory of the communication device 1100 before execution.

In an embodiment, the apparatus is a programmable device that uses software to implement embodiments of the invention. Alternatively, however, embodiments of the invention may be implemented in whole or in part in hardware (e.g., in the form of an application specific integrated circuit or ASIC).

Fig. 11b is a block diagram schematically illustrating the architecture of a communication device 1100 adapted to at least partially perform the present invention. As shown, the apparatus 1100 includes a Physical (PHY) layer block 1123, a MAC layer block 1122, and an application layer block 1121.

PHY layer block 1123 (here, a plurality of 802.11 standardized PHY layer modules) has the task of formatting, modulating, or demodulating for any 20MHz channel or composite channel, to send or receive frames, such as 802.11 frames, over the radio network relative to the radio medium, e.g., medium access trigger frames for reserving transmission slots, 20 MHz-wide based MAC data and management frames (for interaction with legacy 802.11 stations), and OFDMA-type MAC data frames having a width less than the legacy 20MHz (typically 2 or 5 MHz).

The MAC layer block or controller 1122 preferably includes an MLE MAC802.11 layer 1124 implementing conventional 802.11MAC operations, as well as additional blocks 1125 for performing, at least in part, embodiments of the present invention. The MAC layer block 1222 may optionally be implemented in software that is loaded into RAM 1003 and executed by the CPU 1001. The MLE MAC802.11 layer 1124 may implement an upper MAC stack 230 as well as a series of lower MAC modules 220-x/z.

Preferably, an additional block 1125 called a multilink flow classification service management module for low latency services through multilink communication implements some embodiments of the present invention (from the station, non-AP MLD perspective or from the AP, AP MLD perspective). The block performs the operations of fig. 10 a/10 b or 10 c/10 d according to the role of the communication device 1100 (non-AP or AP MLD).

MAC802.11 layer 1124 and report management module 1125 interact to establish and accurately process communications between multiple non-AP MLD stations through an OFDMA RU according to an embodiment of the present invention.

In the upper part of fig. 11b, an application layer block 1121 runs an application that generates and receives data packets (such as data packets of a video stream or the like). The application layer block 1121 represents all stack layers above the MAC layer standardized according to ISO.

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

While reference has been made to the foregoing illustrative embodiments, many further modifications and variations will occur to those skilled in the art, these embodiments being given by way of example only and not being intended to limit the scope of the invention which is to be determined solely by the appended claims. In particular, different features from different embodiments may be interchanged where appropriate.

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

Claims (14)

1. A method of communication in a wireless network comprising a non-access point multi-link device, AP MLD, (11) associated with an access point multi-link device, AP MLD, (10):

identifying traffic flows with flow class service identifiers, SCSIDs; and

reporting one or more links to the AP MLD, wherein the identified traffic flow is expected to be transmitted on the one or more links.

2. The method of claim 1, wherein the one or more links are reported within respective one or more traffic specification elements, qoS characteristics, in a flow classification service descriptor (400, 500) associated with the traffic flow.

3. The method of claim 2, wherein the traffic specification element (525) includes an identifier of the link in a field (550) designed to indicate a traffic flow identifier.

4. The method of claim 1, wherein the one or more links are reported within the flow classification service descriptor comprising a mapping element (600), the mapping element (600) indicating a direction (601) of the traffic and one or more links (602) on which the traffic flow is expected to be transmitted.

5. The method of claim 4, wherein the flow classification service descriptor comprises:

a common traffic specification element (625) comprising parameters for defining a flow; and

one or more link-specific traffic specification elements (626) including link-specific parameters.

6. The method according to claim 1, wherein the method comprises:

a trigger frame is received from the AP MLD for allocating resources for transmission of one or more identified traffic flows.

7. The method of claim 6, wherein a target wake time, TWT, is allocated for transmission of the traffic stream.

8. The method of claim 6 or 7, wherein the trigger frame comprises:

An element (732) for indicating that the trigger frame includes a traffic flow identifier; and

an element (741, 743) for indicating the traffic flow identifier.

9. The method of claim 7, wherein the target wake time is described by an information element, TWT, IE (800) comprising a parameter information element (820), the parameter information element (820) comprising a single individual TWT parameter field comprising an identifier of the traffic flow.

10. The method of claim 7, wherein the target wake time is described by an information element, TWT, IE (800) comprising a parameter information element (820), the parameter information element (820) comprising one or more broadcast TWT parameter fields, each broadcast TWT parameter field comprising an identifier of the traffic flow.

11. The method of claim 1, wherein the traffic stream is transmitted using data units comprising sequential sequence numbers.

12. A computer program product for a programmable device, the computer program product comprising sequences of instructions for implementing the method of any one of claims 1 to 11 when loaded into and executed by the programmable device.

13. A computer readable storage medium storing instructions of a computer program for implementing the method according to any one of claims 1 to 11.

14. A communication device in a wireless network, the wireless network comprising a non-access point multi-link device, or non-AP MLD (11), associated with an access point multi-link device, or AP MLD (10), wherein the non-AP MLD comprises a processor configured to:

identifying traffic flows with flow class service identifiers, SCSIDs; and

reporting one or more links to the AP MLD, wherein the identified traffic flow is expected to be transmitted on the one or more links.