Contention in interframe period for TXOP pre-emption at mac level

The MAC-level TXOP preemption scheme in wireless networks allows stations to preempt ongoing TXOPs for their transmissions within an interframe period, addressing delayed traffic issues and improving network efficiency for low latency applications.

WO2026012830A1PCT designated stage Publication Date: 2026-01-15CANON KK +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
PCT/EP2025/068647
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-07-08
Filing Date
2025-07-01
Publication Date
2026-01-15

AI Technical Summary

Technical Problem

In wireless communication networks, particularly in WLANs based on IEEE 802.11 standards, some stations may not be granted opportunities to transmit during successive TXOPs, leading to delayed traffic transmissions, especially for low latency applications like high-definition video, advanced telemedicine, and augmented/virtual reality data, degrading network performance.

Method used

A MAC-level TXOP preemption scheme is introduced, allowing stations to contend for medium access within an interframe period during an ongoing TXOP, enabling them to preempt the TXOP for their own transmissions if successful, while maintaining compatibility with legacy systems and minimizing collision risks.

Benefits of technology

This scheme enhances network efficiency by providing additional transmission opportunities for high-priority traffic, reducing latency, and maintaining compatibility with legacy systems without increasing complexity.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure EP2025068647_15012026_PF_FP_ABST
    Figure EP2025068647_15012026_PF_FP_ABST
Patent Text Reader

Abstract

A STA willing to pre-empt senses a transmission end within an on-going TXOP and performs medium access contention through a backoff procedure during the SIFS period following the transmission end. The STA decrements a pre-emption backoff counter at each RIFS slot as long as the medium is idle, within a contention period that preferably ends at least one RIFS before the SIFS end. Upon successful contention – backoff counter reaching zero – the STA transmits a pre-emption request frame, starting before the end of the SIFS, which frame is acknowledged by the TXOP holder to confirm the TXOP pre- emption. The request frame signals the duration of the pre-empted period. The STA operates frame exchange sequences during the pre-empted period and gives the medium back to the TXOP holder at the end of the pre-empted period.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] CONTENTION IN INTERFRAME PERIOD FOR TXOP PRE-EMPTION AT MAC LEVEL

[0002] FIELD OF THE INVENTION

[0003] The present disclosure relates generally to wireless communication and more particularly to medium access.

[0004] BACKGROUND OF THE INVENTION

[0005] The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section.

[0006] Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks.

[0007] The WLAN (Wireless Local Area Network) technology based on the IEEE (Institute of Electrical and Electronics Engineers - RTM) 802.11 family standards provides a very simple distributed channel access mechanism. Distributed channel access means that a wireless device, in IEEE 802.11 terminology known as a station (STA), either access point (AP) or a non-access point (non-AP), tries to access an operating channel when it has data to send, usually using contention schemes on a so-called primary channel.

[0008] An operating channel of 40, 80, 160 or 320MHz bandwidth (as defined in the latest IEEE 802.11 be D6.0 standard, but may be wider in future amendments) is usually made of a primary channel and one or more secondary channels (each channel being 20MHz or a multiple thereof). The primary channel is used for signalling (including channel access procedure) and backwards compatibility while the secondary channels are only used when sending data at full speed.

[0009] The basic unit of allocation of the right to transmit onto the wireless medium is the transmission opportunity or “TXOP”, defined by a starting time and a defined maximum length.

[0010] The TXOP is often obtained by a STA winning an instance of contention. A contention function is in charge of driving the contention.

[0011] Known contention includes the Distributed coordination function (DCF). DCF relies on a carrier-sense multiple access with collision avoidance (CSMA / CA) with a binary exponential backoff algorithm. It uses a backoff counter which is initialized with a backoff value randomly drawn from respective contention parameters. The backoff counter is decremented during a contention period at each time slot the wireless medium is detected as idle. Conventionally, the contention period starts a DIFS (DCF InterFrame Space - equal to SIFS + 2 * SlotTime) after the medium is detected as being idle. The decrementing is stopped and deferred when the wireless medium becomes busy. On the other hand, when it reaches zero, the station gains access to the wireless medium, hence can transmit pending data.

[0012] Below, a “TXOP holder” or “TXOP owner” is understood as being a station (STA) that has either been granted a TXOP by the hybrid coordinator (HC) or successfully contended for a TXOP.

[0013] QoS (Quality of Service) is provided in 802.1 1 networks thanks to Enhanced Distributed Channel Access or "EDCA" which defines traffic categories and four corresponding access categories making it possible to handle differently high-priority traffic compared to low-priority traffic. Implementation of EDCA in the stations can be made using a plurality of traffic queues (known as "Access Categories (AC)") for serving data traffic at respective different priorities, each traffic queue being associated with a respective queue backoff counter.

[0014] EDCA enhances DCF. Conventionally, EDCA proposes four ACs, each one having its own queue backoff counter, the initializing backoff value of which being randomly drawn from respective queue contention parameters, known as EDCA parameters. The function performing the EDCA contention for one AC is also known as EDCA function or “EDCAF”. As the EDCA parameters are specific to each AC queue, packets from different ACs are transmitted according to different priorities mirroring the respective EDCA parameters.

[0015] Once the STA is granted a TXOP, the medium is reserved for that STA for the TXOP length, while the other STAs not involved in the TXOP cannot transmit. Indeed, during the TXOP, the granted STA organizes data transmissions, be them single-user transmissions, multi-user transmissions, uplink transmissions, downlink transmissions, peer-to-peer transmissions, and so on.

[0016] In a WLAN network in which multiple STAs are active, some STAs may not be granted opportunities to transmit during successive TXOPs, hence delaying their traffic transmissions. This obviously degrades network performance, in particular with respect to low latency traffic such as high-definition video, advanced telemedicine, ultra-low latency gaming, and ARA / R (augmented / virtual reality) data.

[0017] Accordingly, improvements in the field are desired.

[0018] SUMMARY OF THE INVENTION

[0019] Discussions have emerged in the 802.11 bn work group to enable pre-emption of the wireless medium while a TXOP is on-going. Pre-emption would allow the medium to be accessed by interrupting a rightful transmission sequence (TXOP) by a contention function (e.g. EDCAF) that did not obtain the TXOP. Physical layer (PHY)-based protocol data unit (PPDU)-level pre-emption has been considered. However, it requires substantive PHY modifications and dedicated solutions for both downlink and uplink PPDU pre-emption. Furthermore, while it may provide reduced overhead (e.g., increased efficiency), it is at the cost of very higher complexity.

[0020] That is why a pre-emption at MAC level is now considered. MAC-based TXOP-level preemption would advantageously have simpler implementation compared to PHY-based preemption with slightly higher overhead. However, no MAC-based pre-emption mechanism or scheme is currently proposed.

[0021] In this context, the present disclosure proposes a TXOP pre-emption scheme at MAC level involving contention in an interframe space, for ST As to have the opportunity to pre-empt all or part of the TXOP for their own transmissions.

[0022] A first aspect of the disclosure relates to a communication method in a wireless network, comprising, at a station (STA), be it an AP or a non-AP STA within a multi-link device (MLD) or not: sensing an end of frame transmission in a frame exchange sequence scheduled by a TXOP holder different from the STA within a transmission opportunity (TXOP) granted to the TXOP holder, and contending for medium access within an interframe period inside the TXOP and starting from the end of the frame transmission, to pre-empt medium access over the TXOP holder in the TXOP in case of contention success.

[0023] In case of successful contention, the STA takes precedence over the TXOP holder, i.e. replaces it (at least temporarily) for use of the wireless medium.

[0024] A contention immediately after a frame transmission made by another station and within the interframe period allows both (1) the proposed pre-emption scheme not to create collision with a conventional transmission (scheduled by the TXOP holder) starting after the interframe period, and (2) the proposed pre-emption scheme to be transparent to legacy stations.

[0025] Furthermore, the proposed scheme can keep the conventional contention / transmission sequence. Indeed, once the pre-emption is obtained through successful contention, the STA can use the wireless medium, hence transmit its own data.

[0026] In addition, the proposed scheme advantageously allows the wireless medium to be still kept by the TXOP owner if no pre-emption is granted, hence transmissions can continue in a legacy way.

[0027] From the TXOP holder, a communication method in a wireless network comprises, at a station (STA), be it an AP or a non-AP STA within a multi-link device (MLD) or not: obtaining a transmission opportunity (TXOP) on the wireless medium and scheduling a frame exchange sequence, sensing whether a pre-empting frame is transmitted by another STA during an interframe period inside the TXOP and starting from an end of a frame transmission in the frame exchange sequence, to the effect of pre-empting the TXOP, and using the TXOP in the continuity of the interframe period in case no pre-empting frame is sensed.

[0028] Using the frame transmission means organizing or authorizing, as TXOP holder, a frame transmission between two stations, involving itself or not. Here, the station manages its own TXOP until another station succeeds in pre-empting the TXOP.

[0029] Optional features are defined below with reference to methods, while they can be transposed into device features.

[0030] In some embodiments, the TXOP holder signals whether the TXOP is open to preemption (i.e., is available for pre-emption, meaning preemptable), e.g. in a management frame prior to the TXOP, in a frame reserving the TXOP or in a frame within the TXOP. A dynamic control of the TXOP pre-emption can then be organized. Of course, in variants, the type of TXOP than can be pre-empted may be predefined, e.g. at BSS level (hence advertised by the AP).

[0031] In embodiments, the TXOP holder or an access point signals which of the following stations are authorized to contend for pre-empting the TXOP: all non-AP stations associated with the TXOP holder acting as an access point (AP), or one or more stations specifically identified by the TXOP holder, or an access point (AP) with which the TXOP holder acting as a non-AP station is associated. Again, this allows a dynamic control of the pre-empting beneficiaries, e.g. to provide improved network efficiency.

[0032] In other embodiments, the TXOP holder signals which type or types (or classes) of preempting traffic are authorized for transmission in case of pre-emption of the TXOP. Pre-empting traffic means any type or class of data, including AC, SCS stream, and so on. The above provision allows some additional transmission opportunities to be offered to some data classes, hence improving network efficiency. Of course, the types may be predefined, e.g. at BSS level (hence advertised by the AP).

[0033] In some embodiments, the interframe period is a SIFS period. It means the contention takes place within a SIFS, for the TXOP holder to be able to detect any TXOP pre-emption before continuing using its TXOP. Alternatively, the interframe period may be a PIFS period following the end of frame transmission within the TXOP. Indeed, the PIFS period is also a safe period (usually for the AP as TXOP holder) during which other stations are not allowed to transmit.

[0034] In embodiments, the end of the frame transmission matches an end of an acknowledgement within the frame exchange sequence. This is to avoid perturbating the legacy 802.11 sequence for legacy STAs involved in the on-going TXOP. Of course, alternatively, the pre-empting contention may occur during the interframe period immediately following the end of a data frame, and not its acknowledgment.

[0035] In embodiments, contending for medium access includes performing a pre-emption backoff procedure within the interframe period, the pre-emption backoff procedure including a pre-emption backoff counter that is decremented over time. Using a backoff procedure advantageously mitigates the risks of collision between stations candidates to the TXOP preemption.

[0036] In particular embodiments, the decrementing (or counting down) of the pre-emption backoff counter is made on a Reduced Interframe Space (RIFS)-length time slot basis, e.g. RIFS = 2ps. An efficient backoff procedure with a substantial number of stations can therefore be conducted, even in quite short interframe periods.

[0037] In particular embodiments, the pre-emption backoff counter is reinitialized at each new TXOP to be pre-empted. The pre-emption need can thus be re-evaluated for each TXOP, depending on whether any transmission of the corresponding data was performed in the meantime since the last preemptable TXOP.

[0038] In other particular embodiments, the decrementing of the pre-emption backoff counter is suspended when contending a first time for medium access in the TXOP (for example because another STA gains pre-emption, or the interframe period ends) and is resumed when contending a second time for medium access in the same TXOP. This introduces fairness between the candidate STAs to TXOP pre-emption, within a given TXOP.

[0039] Alternatively, the backoff counter could be reinitialized to a new value at each new contention try, even within the same TXOP.

[0040] In particular embodiments, the method may comprise contending for medium access within multiple interframe periods in the same TXOP up to a predefined maximum number of contending tries. This aims to reduce the risks of collision in case of numerous candidate preempting stations, hence to provide better chance to perform transmission of pre-empting data.

[0041] In particular embodiments, the method may comprise obtaining a pre-emption contention window value from parameters transmitted by an access point, and drawing an initialization value for the pre-emption backoff counter based on the pre-emption contention window value. This allows the AP to dynamically regulate the TXOP pre-emptions by the STAs given e.g. evolving network conditions.

[0042] In particular embodiments, a pre-emption contention window value is defined per access category. In that case, multiple contentions (one per AC) may be conducted in parallel during the interframe period. This allows TXOP pre-emption to prioritize certain types of data, e.g. to facilitate low latency communications.

[0043] In embodiments, a pre-emption contention period for medium access within the interframe period is configured to end at least one decrementing time slot before the end of the interframe period. This is for the STA to start transmitting the next frame (e.g. a pre-emption request frame) still within the interframe period, hence for the other stations - in particular the TXOP holder and the other stations competing for the TXOP pre-emption - to detect such frame (and thus the pre-emption) before the end of the period.

[0044] In embodiments, contending for medium access includes: in case the STA is not an access point, deferring a decrementing of the pre-emption backoff counter by at least one decrementing time slot, and, in case the STA is an access point, immediately decrementing the pre-emption backoff counter initialized at 1 . This approach provides full pre-emption priority to the AP in case it needs medium access during a TXOP of one of its associated non-AP STA.

[0045] In embodiments, contending for medium access includes deferring a decrementing of the pre-emption backoff counter by an Arbitration Pre-emption Interframe Space that is function of an access category of pre-empting traffic the STA intends to transmit over the pre-empted medium. Again, this allows TXOP pre-emption to prioritize certain types of data, e.g. to facilitate low latency communications.

[0046] In embodiments, the method comprises, at the STA, evaluating time remaining in the TXOP with respect to an amount of data to be transmitted, and triggering the contention for medium access in case there is sufficient time. This is to avoid useless TXOP pre-emption.

[0047] In embodiments, the method comprises, at the STA, transmitting a pre-emption request frame over the medium upon successfully contending access to the medium within the interframe period. The transmission is advantageously started immediately after the contention (end of preemption backoff procedure), i.e., within the interframe period to ensure the STA has priority over any other station.

[0048] Of course, alternatively, a data frame may be transmitted directly over the pre-empted medium, rather than using the pre-emption request frame.

[0049] However, the pre-emption request frame advantageously reduces the impact of frame interference on network efficiency, because a request frame is likely to be substantially shorter than a data frame.

[0050] In embodiments, the pre-emption request frame is made of a legacy preamble made of a L-STF field, a L-LTF field and a L-SIG field, optionally supplemented by one or more preamble field from HT (802.11 n), VHT (802.11 ac), HE (802.11 ax) or EHT (802.11 be D6.0) standard and optionally supplemented by a length-varying part.

[0051] In embodiments, the method comprises receiving, from the TXOP holder, a pre-emption response frame acknowledging the pre-emption request frame. This contributes to frame collision detection, hence to network efficiency.

[0052] In embodiments, the pre-emption request frame includes a length-varying part, the length of which depends on a type of pre-empting traffic the STA intends to transmit overthe pre-empted medium. This configuration allows prioritization of some data classes over other, since longer request frame can be sensed by other stations as an indication that the sending station uses the medium.

[0053] In embodiments, the method comprises obtaining a length-varying part length (indirectly a pre-emption request frame length) from parameters transmitted by an access point, and designing the length-varying part of the pre-emption request frame to match the length-varying part length. For example, padding may be used to adjust the length of the pre-emption request frame.

[0054] In particular embodiments, the length-varying part length is defined per access category.

[0055] In that case, the length corresponding to the AC (or the higher priority AC) of the data intended to be transmitted over the pre-empted medium can be used to design the pre-emption request frame.

[0056] In embodiments, the method comprises determining whether the medium is busy during the interframe period after having transmitted the pre-emption request frame. This allows to determine whether the STA has won the pre-emption (medium idle) or not (medium busy by another STA transmitting its own - e.g. longer - pre-emption request frame).

[0057] In embodiments, the pre-emption request frame indicates a time length of the medium pre-emption within the TXOP. This eases the release of the medium to the TXOP holder after the pre-emption.

[0058] From TXOP holder perspective, it may be contemplated that the interframe period is a SIFS or PIFS period, and using the TXOP starts again a SIFS or PIFS after the end of the frame transmission in case no pre-empting frame is sensed during the SIFS or PIFS period. As mentioned above, if no TXOP pre-emption occurs, the TXOP holder can advantageously keep using its TXOP.

[0059] In embodiments, no pre-empting frame to the effect of pre-empting the TXOP is sensed when a frame collision is sensed during the interframe period. Detection of a collision means that the listening station is not able to decode the frames transmitted. With this configuration, no subsequent (long) data frame sent by pre-empting stations will collide, hence saving network efficiency.

[0060] In particular, using the TXOP may start again substantially a SIFS after an end of the sensed collided frames.

[0061] Also, at the station (TXOP holder): in case the station (TXOP holder) senses a preempting frame (i.e., for TXOP pre-emption) during the interframe period, it sends a pre-emption response frame in response to the sensed pre-empting frame to acknowledge TXOP pre-emption, while in case the station senses activity during the interframe period but no pre-empting frame (the station may be unable to decode frames due to frame collision), it does not send any acknowledgment frame.

[0062] Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out any method as described above.

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

[0064] At least parts of the methods according to the disclosure may be computer implemented. Accordingly, it 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, it may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the proposed mechanisms can be implemented in software, they can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include 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.

[0065] BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Some embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which:

[0067] Figure 1 illustrates a typical wireless communication system in which embodiments of the disclosure may be implemented;

[0068] Figure 2 illustrates 802.1 1 e mechanism for the backoff counter countdown in a conventional channel access scheme;

[0069] Figure 3 illustrates, using a flowchart, general steps of a communication method involving a TXOP pre-emption according to embodiments;

[0070] Figure 4 illustrates, using a timeline, an exemplary scenario of TXOP pre-emption according to embodiments;

[0071] Figure 4a illustrates, using a timeline, an exemplary scenario of TXOP pre-emption according to other embodiments;

[0072] Figure 5 illustrates, using a flowchart, steps of a communication method involving a TXOP pre-emption according to other embodiments;

[0073] Figure 6 illustrates exemplary formats of a PR frame according to embodiments;

[0074] Figure 7 illustrates, using a timeline, an exemplary scenario of TXOP pre-emption operations with frame collision, according to other embodiments;

[0075] Figure 8 illustrates, using a timeline, an exemplary scenario of TXOP pre-emption according to yet other embodiments;

[0076] Figure 9 illustrates, using a timeline, an exemplary scenario of TXOP pre-emption operations without successful pre-emption, according to other embodiments;

[0077] Figure 10 illustrates, using a flowchart, general steps for a STA to obtain the pre-emption contention parameters;

[0078] Figure 11 illustrates an exemplary format of a TXOP Pre-emption Parameter Set element according to embodiments;

[0079] Figure 12 illustrates an exemplary enhanced Stream Classification Service, SCS, Descriptor element format for requesting TXOP pre-emption authorization, according to embodiments;

[0080] Figure 13a shows a schematic representation of a communication device; and Figure 13b illustrates schematically the architecture of the communication device of Figure 13a.

[0081] DETAILED DESCRIPTION

[0082] The invention will now be described by means of specific non-limiting exemplary embodiments and by reference to the figures.

[0083] In the following description, the term legacy refers devices that may operate in accordance with one or more of IEEE 802.11 a / b / g / n / ac / ad / af / ah / aj / ay / ax / be, or another legacy wireless communication standard. The legacy devices may be STAs, IEEE STAs or Wireless- Fidelity (Wi-Fi) STAs.

[0084] An AP may communicate with legacy devices in accordance with legacy IEEE 802.11 communication techniques.

[0085] Figure 1 illustrates a communication system in which several communication devices or stations (or “nodes”) 101-107 exchange data frames over a radio transmission channel 100 of a wireless local area network (WLAN), under the management of a central station, or access point (AP) 1 10, also seen as a station of the network. The radio transmission channel 100 is defined by an operating frequency band constituted by a single channel or a plurality of channels (usually each of 20MHz width) forming a composite or operating channel. Below the “medium” or “wireless medium” is considered synonymous with the radio transmission or composite or operating channel.

[0086] In the following, the word “station” or “STA” refers to any kind of station. The wording “access point station”, or in short “access point” (AP), refers to the station playing the role of access point 110. The wording “non-access point station”, or in short “non-AP station” or “non-AP STA”, refers to the other stations 101 -107.

[0087] The STAs may be affiliated stations of multi-link devices as defined in the IEEE P802.11 be / 6.0 standard, and / or stations implementing multi-user transmission features as defined in the IEEE 802.11 ax standard, and / or stations implementing any previous version of the 802.11 standard.

[0088] Access to the shared radio medium to send data frames is primarily based on the CSMA / CA technique, for sensing the carrier and avoiding collision by separating concurrent transmissions in space and time.

[0089] Carrier sensing in CSMA / CA is performed by both physical and virtual mechanisms. Virtual carrier sensing is achieved by transmitting control frames to reserve the medium prior to transmission of data frames.

[0090] Next, a source or transmitting station, including the AP, first attempts through the physical mechanism, to sense a medium that has been idle for at least one interframe time period known as DIFS (standing for DCF InterFrame Spacing), before transmitting data frames.

[0091] However, if it is sensed that the shared radio medium is busy during the interframe period, the source station continues to wait until the radio medium becomes idle. The wireless communication system of Figure 1 comprises physical access point 110 configured to manage the WLAN BSS (Basic Service Set), i.e., a group of non-AP STAs which have previously registered to the AP. Such BSS managed by the AP is called an infrastructure BSS. In the following, the term BSS will be used as an equivalent of infrastructure BSS.

[0092] Once the BSS is established, the Access Point can bridge traffic inside the BSS or from other networks (e.g., wired networks) into the BSS (or vice and versa). Thus, the non-AP STAs of the BSS originally talked to the AP only, which is in charge of relaying data frames if the data frames are targeted to another non-AP STA of the BSS. Two directions of communication are therefore defined: “downlink” from the AP to the non-AP STAs and “uplink” from any non-AP STA to the AP.

[0093] In embodiments, the AP may consider setting up a pre-emption enabled BSSID of a multiple BSSID set, where the TXOP pre-emption scheme as proposed below can be effective. Preferably, this BSS is configured with long TXOP Limits. In theory, this would affect the medium access delay for legacy stations, in contrary to TXOP pre-emption enabled stations of the disclosure that can pre-empt those TXOPs.

[0094] Recent developments in the 802.1 1 family of standards have given the opportunity to the non-AP STAs to send data directly to another non-AP STA, referred to as peer-to-peer (P2P) or Direct Link communications.

[0095] The basic medium access to obtain a transmission opportunity or “TXOP” is the DCF channel access scheme that uses CSMA / CA and a random backoff count following a busy medium condition, i.e., an end of a previous frame transmission (by any STA).

[0096] The time interval between frames is called the interframe space (IFS). A STA determines that the medium is idle through the use of the CS (Channel Sensing) function for the interframe space specified. The interframe space corresponds from the end of the last symbol of the previous frame to the beginning of the first symbol of the preamble of the subsequent frame as sensed on the wireless medium.

[0097] Figure 2 illustrates some interframe spaces to provide priority levels for access to the wireless medium.

[0098] Not shown, the reduced interframe space or RIFS was originally used to reduce overhead and thereby increase network efficiency, in replacement of the SIFS to separate multiple transmissions from a single transmitter, when no SIFS-separated response transmission is expected. RIFS is the shortest IFS, e.g. 2 ps.

[0099] The short interframe space or SIFS is used prior to transmission of specific frames, such as Ack (acknowledgement) frames, listed in the standard IEEE Std 802.11 ™-2020, section 10.3.2.3.3. SIFS is for example 16 ps.

[0100] SIFS is used when STAs have seized the medium and need to keep it for the duration of a frame exchange sequence to be performed. Using the smallest gap (RIFS has become obsolete in the meantime) between transmissions within the frame exchange sequence prevents other ST As, which are required to wait for the medium to be idle for a longer gap, from attempting to use the medium, thus giving priority to completion of the frame exchange sequence in progress.

[0101] The priority interframe space or PIFS is used to gain priority access to the medium to transmit specific frames as listed in the standard IEEE Std 802.11 ™-2020, section 10.3.2.3.4. In particular, priority access is often offered to the AP and / or to a TXOP holder (a STA that is granted a TXOP). PIFS is for example 25 ps.

[0102] The DCF interframe space or DIFS is used by ST As operating under the DCF to transmit Data frames (MPDUs) and Management frames (MMPDUs). For example, a STA using may transmit if both after it has correctly received a frame, its Carrier Sensing (CS) mechanism determines that the medium still idle at the end of the DIFS period and the STA’s backoff counter BC has a value of zero. DIFS is for example 34 ps.

[0103] A STA invokes the backoff procedure to transmit a frame.

[0104] After the DIFS medium idle time, a contention period starts. The STA generates a random backoff count for an additional deferral time before transmitting, unless the backoff counter already contains a nonzero value. The initializing backoff count value is a pseudorandom integer drawn from a uniform distribution over the interval [0,CW], where CW (contention window) is an integerwithin the range [CWmin, CWmax], As a shortcut, [0,CW] is also referred to as “contention window”.

[0105] The backoff procedure uses the CS mechanism to determine whether there is activity on the medium during each backoff slot “aSlotTime” (9ps). If no medium activity is indicated for the duration of a particular backoff slot, then the backoff procedure decrements its backoff counter. If the medium is determined to be busy, the backoff counter is not decremented for that slot, and the backoff counter can be next decremented only during a next contention period, i.e., after the medium has been determined to be idle for the duration of a DIFS. Transmission commences when the backoff counter equals 0.

[0106] Management of quality of service (QoS) has been introduced at station level in the wireless networks, through well-known EDCA mechanism defined in the IEEE 802.1 1 e standard (Enhanced Distributed Channel Access). EDCA enhances or extends the functionality of the original DCF scheme.

[0107] EDCA adds four independent enhanced distributed channel access functions (EDCAFs) to provide differentiated priorities to transmitted traffic, through the use of four different access categories (ACs), each having its own transmit queue. The four ACs are the following in decreasing priority order: voice (or “AC_VO”), video (or “AC_VI”), best effort (or “AC_BE”) and background (or“AC_BK”). In embodiments, QoS may be extended to support a different - higher - number of access categories.

[0108] A mapping of UP (user priorities of MSDUs, incoming from an upper layer) to the transmit queue and the mapping to AC is well-known and not reproduced here for brevity.

[0109] A backoff procedure (as described above for the DCF scheme) can be invoked by each EDCAF (i.e., independently for each AC). With EDCA, the DIFS period is replaced at AC level by a so-called arbitration interframe space or AIFS. An AIFS is thus defined for each AC: AIFS[AC],

[0110] A STA using the EDCAF obtains a TXOP for an AC if the STA’s CS mechanism determines that the medium is idle during the AIFS[AC] period, after a correctly received frame, and the backoff counter for that AC, BC[AC], has a value of zero. The duration AIFS[AC] is a duration derived from value AIFSN[AC] (which is between 2 and 15): AIFS[AC] = AIFSN[AC] * aSlotTime + SIFS.

[0111] Each EDCAF[AC] maintains its backoff counter BC[AC], which has a value measured in backoff slots. After the AIFS[AC] period, the backoff counter is set to an integer value chosen randomly with a uniform distribution taking values in the range [0, CW[AC]], unless the backoff counter already contains a nonzero value. Contention window for the AC, CW[AC], is an integer within the range [CWmin[AC], CWmax[AC]]. As for DCF, if no medium activity is indicated for the duration of a particular backoff slot (aSlotTime), then EDCAF[AC] decrements its backoff counter BC[AC], If the medium is determined to be busy, the backoff counter is not decremented for that slot, and the backoff counter can be next decremented only during a next contention period, i.e., after the medium has been determined to be idle for the duration of an AIFS[AC], Transmission commences when the backoff counter equals 0.

[0112] In a BSS, the EDCA Parameters, such as CWmin[AC], CWmax[AC], AIFSN[AC] and TXOP_Limit[AC] (maximum length of a TXOP a STA may request), are advertised by the AP in a so-called EDCA Parameter Set element in Beacon and Probe Response frames transmitted by the AP. The EDCA Parameter Set element therefore provides the EDCA Parameters for all (four) ACs.

[0113] Due to different EDCA Parameters for different ACs, the deferring of the contention period for the ACs are different. For example, AC_VO has the highest priority and as such has the lowest AIFS. Although configurable, default values of the AIFS are the following ones:

[0114] AC_VO 1 SIFS + 2 * slot time (AIFSN[3] = 2)

[0115] AC_VI 1 SIFS + 2 * slot time (AIFSN[2] = 2)

[0116] AC_BE 1 SIFS + 3 * slot time (AIFSN[1] = 3)

[0117] AC_BG 1 SIFS + 7 * slot time (AIFSN[0] = 7)

[0118] For example, as shown in Figure 2, two AIFS corresponding to AC=i and AC=j are considered. Due to this prioritizing difference, AC ‘j’ starts decrementing its backoff value earlier than less-prioritized AC T.

[0119] Relative prioritization of the ACs (hence QoS) is therefore obtained, which can be tuned by adjusting the EDCA Parameters of the ACs.

[0120] The ACs within the same STA thus compete one with each other (using their EDCAF) to access the wireless medium and to obtain a TXOP.

[0121] Furthermore, the use of lower AIFSN values, additional to the use of an on-average lower CW for high priority ACs compared to low priority ACs makes that traffic of a high priority AC has a higher chance to be transmitted than traffic from a low priority AC: a STA having high priority AC traffic statistically waits less, on average, to be granted a TXOP and then send its packet than a STA having low priority AC traffic.

[0122] Recently-created IEEE 802.11 bn (the successor of IEEE 802.11 be) Task group works on ultra-reliable low-latency communication (URLLC) requirements, focusing on some aspects such as tail latency and jitter, and high priority access for latency-sensitive applications.

[0123] Applications with data having tight latency requirements include high-definition video, advanced telemedicine, ultra-low latency gaming, and AR / VR (augmented / virtual reality) data.

[0124] Time-Sensitive Networking (TSN) is another exemplary targeted extension of 802.11 / WiFi communications with deterministic elements and time-sensitive capabilities. TSN enables reliable and timely communication over networks by providing a suite of mechanisms and protocols that enable networked devices to exchange critical data with very low latency and high reliability.

[0125] TXOP Pre-emption is proposed to reach tight latency requirements. TXOP Pre-emption is a mechanism to access the medium by interrupting a rightful transmission sequence by an EDCAF that did not obtain an on-going TXOP.

[0126] TXOP Pre-emption should operate with any type of communication and devices, including either or both of single-user (SU) or multi-user (MU) communication frames, either or both of uplink (UL) or downlink (DL) communication frames, either or both of single-link or multi-link devices.

[0127] As many traffic flows from many STAs may be willing to pre-empt a current TXOP, the proposed TXOP pre-emption scheme is contention-based, in particular to reduce overhead for pre-emption schemes based on explicit query / response.

[0128] Figure 3 illustrates, using a flowchart, general steps of a communication method involving a TXOP pre-emption according to embodiments. The method may be implemented by any STA wishing to use the wireless medium currently reserved through an on-going TXOP. The STA may be a communication partner of the TXOP holder during the TXOP or be a STA not involved in the TXOP. More generally, the STA may be a non-AP STA willing to send uplink data to the AP, a non-AP STA willing to transmit peer-to-peer data to a peer non-AP STA partner, an AP willing to send downlink data to one or more non-AP STAs, or even a second AP willing to obtain the medium for its BSS in a context of multi-AP coordination.

[0129] At step 300, the STA senses an end of frame transmission in a frame exchange sequence scheduled by a TXOP holder different from the STA within an on-going transmission opportunity (TXOP) granted to the TXOP holder.

[0130] Next, at step 310, the STA starts and performs for medium access during the interframe space or period within the on-going TXOP, immediately following the end of the frame transmission. The interframe period to be considered is the conventional one before a STA (e.g. the TXOP holder) involved in the TXOP sends the next frame. Usually, it is a SIFS period. However, in embodiments, a PIFS period may be contemplated.

[0131] The contention may invoke a backoff procedure as described below. The success of the contention (test 320) determines whether the STA has indeed preempted medium access over the TXOP holder in the TXOP (330) or not.

[0132] Once the STA has pre-empted the medium - in replacement of the TXOP holder -, the STA may use the medium for its own transmissions as described below. The STA may initiate one or more frame exchange sequences. In particular, the STA starts sending a first frame immediately when gaining pre-empting access (e.g. backoff counter equals 0) to the medium.

[0133] Figure 4 illustrates, using a timeline, an exemplary contention mechanism for TXOP preemption according to the disclosure.

[0134] The Figure shows the behaviour of two non-AP STAs and one AP.

[0135] AP and STA1 are involved in an on-going TXOP 400 while STA2 is the station willing to pre-empt the TXOP over the TXOP holder (here the AP). Hence, STA2 implements the preemption mechanism of the present disclosure. This is only an example. For instance, STA1 could alternatively (or simultaneously) implement the pre-emption mechanism to have control over the TXOP, in replacement of AP. Any other combination is possible, whatever the TXOP holder is an AP or not.

[0136] For the sake of illustration, this timeline is illustrated for only one stream per STA, but of course several streams belonging to different priorities can coexist in a given STA. In that case, an optimization can be performed at the STA to arbitrate in between the streams and apply the TXOP pre-emption mechanism to the higher-priority stream.

[0137] The Figure illustrates an existing TXOP 400 in between AP and STA1 . TXOP 400 is defined as a preemptable TXOP, that is to say STAs may try to pre-empt it. AP and STA1 have a frame exchange sequence during which frame 401 is sent by AP to STA1 , in response to which STA1 sends an ACK frame 402 after a SIFS period.

[0138] Pre-empting STA2 senses the end of the ACK frame 402, ending the frame exchange sequence. It decides to start contending for pre-emption medium access by sensing the channel (or partial channel) during a pre-emption period 410 starting immediately afterthe end of the ACK frame 402 and lasting during the conventional interframe period. Hence, the pre-emption period 410 lasts at most the interframe period considered (a SIFS period in the present example).

[0139] As shown, a "pre-emption" backoff procedure is implemented to try to gain channel access. STA2, as pre-empting STA, only senses the channel condition during the pre-emption period 410. If the channel condition is idle for a pre-emption backoff slot time 411 , then the preemption backoff (PBO) counter is decremented by one. Otherwise, the PBO counter is not decremented, and the contention period 410 stops (another STA may have won the pre-emption contention) and the decrementing can be resumed for a next TXOP pre-emption operation within the same TXOP. STA2 wins the pre-emption and gains channel access when its PBO counter reaches zero with the channel still idle.

[0140] In embodiments, STA2 transmits a pre-emption request frame 403 (PR frame) over the medium upon successfully contending access to the medium within the interframe period. This request allows pre-empting STA2 to reserve a pre-empted period 420 within the on-going TXOP to perform its transmission. The pre-empted period 420 may end before the TXOP (as shown in the Figure) to give the medium back to the TXOP holder. In variants, STA2 may decide occupying the entire remaining time of the on-going TXOP.

[0141] Next, after the legal interframe space (SIFS period), STA2 can transmit another frame 404 (e.g. management frame, or data frame).

[0142] Optionally (as shown in dotted lines), the TXOP holder (here the AP) can acknowledge the pre-emption, so that STA2 waits for and receives, from the pre-empted TXOP holder, a preemption response frame 405 acknowledging the pre-emption request frame. This is to ensure the successful pre-emption. As shown, the ACK 405 is sent a SIFS after PR frame 403, and STA2 may start transmitting its data (frame 404) a SIFS after the ACK 405.

[0143] In other embodiments, STA2 transmits a data (or management) frame directly upon successfully contending access to the medium within the interframe period. In these embodiments, no PR frame 403 is sent.

[0144] In the example of the Figure, the pre-emption period 410 is started after the ACK 402 in order not to interrupt the transmission of an individual data frame 401 (which requires acknowledgment). In this example, an end of frame transmission (from which the contention starts) matches an end of an acknowledgement within a frame exchange sequence. However, in less strict implementations, the pre-emption period 410 may take place during the SIFS period immediately following data frame 401 .

[0145] Figure 5 illustrates, using a flowchart, steps of a communication method involving a TXOP pre-emption according to other embodiments. The method may be implemented by any STA wishing to use the wireless medium currently reserved through an on-going TXOP. The STA may be a communication partner of the TXOP holder during the TXOP or be a STA not involved in the TXOP. More generally, the STA may be a non-AP STA willing to send uplink data to the AP, a non-AP STA willing to transmit peer-to-peer data to a peer non-AP STA partner, or an AP willing to send downlink data to one or more non-AP STAs.

[0146] The method is presented for the transmission of a single data frame through pre-emption of an on-going TXOP. However, it is obvious that several frames pertaining to many classifications (ACs, SCSs as described below) may be considered when a TXOP pre-emption is gained.

[0147] The method starts at step 500 where the STA retrieves authorization information about which TXOP is open to pre-emption and / or which STA or STAs are allowed to pre-empt the ongoing TXOP.

[0148] In some embodiments, the pre-emption may be available for any TXOP and / or to the benefit of any STA, in which case step 500 can be omitted.

[0149] In other embodiments, limitations or restrictions on preemptable TXOP and pre-empting STA can be defined either statically (e.g. at the BSS level, the AP advertising its associated STAs using dedicated frames such as Beacon frames) or dynamically (e.g. by the TXOP holder itself).

[0150] Preferably, the TXOP holder signals whetherthe (on-going) TXOP is open to pre-emption (i.e., is available for pre-emption, meaning preemptable), e.g. in a management frame priorto the TXOP, in a frame reserving the TXOP or in a frame within the TXOP. For example, the AP, as TXOP holder, may allow an interruption of its ongoing (lower priority) DL data transmission (in the TXOP) by other STAs.

[0151] A management frame prior to the TXOP may include a TWT like frame announcing the pre-emption contention period 410, hence indicating to the beneficiary (i.e., candidate to preemption) STAs to wake up, to check they have a frame to emit by pre-emption and then to perform pre-emption.

[0152] A frame reserving the TXOP may include a Trigger frame or a RTS (or MU-RTS) frame.

[0153] A frame within the TXOP may include the first frame (MPDU) sent by the TXOP holder within the TXOP, regardless of the type of frame. Alternatively, it may be any frame of a frame exchange sequence after which the pre-emption is allowed.

[0154] A MAC signalling may be used, providing the pre-emption authorization or prohibition in one or more reserved bits of the MAC header, in a new A-Control field, or in one or more reserved bits of a MPDU delimiter. It is possible for the MAC signalling (indicating pre-emption authorization or prohibition) to be inserted by the PHY layer.

[0155] Similarly, the TXOP holder may signal which STAs are allowed to pre-empt its TXOP, in the same type of frames (prior to the TXOP, the frame reserving the TXOP or a frame within the TXOP). Or the AP may signal the authorized STAs for TXOP pre-emption for the entire BSS, which authorization may be provided for all types of TXOP or per TXOP type (e.g. depending on the type of frame reserving the TXOP).

[0156] A similar MAC signalling may be used.

[0157] As an example, the authorization for TXOP pre-emption may be given to: all non-AP STAs associated with the TXOP holder acting as AP, or one or more STAs specifically identified by the TXOP holder, or the AP with which the TXOP holder acting as a non-AP STA is associated.

[0158] The definition of the authorized pre-empting STAs may also be given through an indication of the traffic authorized in the pre-empted period 420. In other words, the TXOP holder (or alternatively the AP) may signal which type or types of pre-empting traffic are authorized for transmission in case of pre-emption of the TXOP. In that case, this is a duty of the candidate preempting STA to determine, based on the traffic they wish to transmit, whether they are authorised or not to perform the TXOP pre-emption.

[0159] In a scenario, the TXOP holder, upon gaining a new TXOP, limits the preemptable TXOP to certain priorities or data. Non-limitative exemplary pre-emption QoS rules, which can be used independently or in combination to indicate allowed pre-empting traffics, may include: one or more User Priorities (UP), one or more Traffic classifications (TOLAS). TOLAS element(s) can specify the IP classifier (in term of IP Addresses and Ports), and can be used together with a TOLAS Processing element, one or more transmission directions: uplink traffic, downlink traffic, peer-to-peer traffic, one or more Stream Classification Service (SCS) streams as defined in the IEEE 802.1 1- 2020 Standard and supplemented by the IEEE P802.11 be / 6.0 standard. A SCS enables a non-AP STA to manage AP treatment of uplink traffic data flows based on TIDs. The SCSID field indicates an index value, selected by the non-AP STA, that is a unique identifier of the SCS rule between the AP and the non-AP STA. one or more specific DSCP mapping policies. DSCP marking policies as part of network wide QoS management by the AP may be envisaged in order to manage the mapping between DSCP values and User Priorities on both APs and non-AP STAs to achieve differentiated QoS. The non-AP STA uses the DSCP-to-UP Mapping table to classify its incoming traffic. The DSCP Policy feature allows finer-grained QoS management for uplink IP flows. For example, it enables configuration of policies that cause IP flows that would otherwise be marked with the same DSCP value (e.g., Default Forwarding) to instead be marked with different DSCP values, and therefore be assigned to different User Priorities or queueing allowed to use TXOP pre-emption.

[0160] It may be noted that the authorization or prohibition of the TXOP pre-emption scheme for types of traffic may be set on demand, by the AP (being the TXOP holder or not) possibly upon request by the pre-empting STA. Any management frame may be used although the SCS Action frame sounds suitable for such signalling. As an example, the AP or the STA may transmit (to each other) a Stream Classification Service (SCS) Action frame including an SCS Descriptor element defining a class of data, the SCS Descriptor element having a field or bit set to a first value to enable the TXOP pre-emption scheme for the class of data or set to a second value to disable such TXOP pre-emption scheme for the class of data.

[0161] In embodiments, the use of the TXOP pre-emption scheme for an access class of data is allowed by the AP upon admitting traffic having such access class for a given STA in its BSS. This could result from a STA-initiated negotiation of uplink (or direct-link) QoS by the SCS mechanism, where the traffic characteristics (e.g. low latency characteristics) and TID / UP used by the STA to transmit the stream are specified. As an example, the SCS Request frame transmitted by the STA may contain a QoS Characteristics element within an SCS Descriptor element that requests use of the TXOP pre-emption scheme, while the SCS Response frame from the AP may contain an SCS Descriptor with a QoS Characteristics element indicating that the use of the TXOP pre-emption scheme is accepted for the specified traffic or class thereof. Figure 12 illustrates an exemplary signalling for such request and response.

[0162] The AP is therefore free to accept or not new data classes (e.g. new incoming SCS streams) in the TXOP pre-emption scheme, depending for example on the activity within its BSS. Similarly, it is also free to adjust the pre-emption contention parameters of the TXOP pre-emption scheme depending on the activity, for example according to the (evolving) number of SCSID indexes (per STA, as new SCS streams are accepted) and the (evolving) number of STAs and / or on the load and the collision rates. Still with reference to Figure 5, next step is step 510 where the STA determines that a MAC layer frame requires transmission, hence TXOP pre-emption should the medium not be available (TXOPs are on-going), for instance to meet latency requirements. This frame and any other data that can be transmitted are referred below as pre-empting data.

[0163] In one or more embodiments, time-sensitive (low latency) packets may be indicated by higher layers of the communication stack (e.g., based on user priority), and corresponding MSDU's may be identified to trigger the TXOP pre-emption scheme.

[0164] The STA may for example include a MSDU classification module configured to classify any MSDU received from higher levels of the communication stack as time-sensitive and thus placed it in a dedicated time-sensitive queue. It may be one of the four legacy EDCA queues or an additional one dedicated to pre-empting traffic which may share the EDCA parameters with one of the four EDCA queue. In the last case, only the additional time-sensitive queue is allowed to use the TXOP pre-emption scheme in case of emergency.

[0165] As mentioned above, some types of traffic data may be allowed for TXOP pre-emption and other types not allowed. The STA may have built, based on the information retrieved at step 500, a black list of ACs (or traffic types) forwhich TXOP pre-emption is not allowed and / or a white list of ACs for which TXOP pre-emption is authorized. For example, if the AC of pending data belongs to a predefined group of ACs, the TXOP pre-emption scheme may be disabled.

[0166] Similarly, the proposed TXOP pre-emption mechanism may be enabled / activated or disabled / deactivated on demand, by the AP possibly upon request of a non-AP STA. Any management frame may be used although the SCS Action frame sounds suitable for such signalling. As an example, the AP or the STA may transmit (to the other) a Stream Classification Service (SCS) Action frame including an SCS Descriptor element defining a class of data, the SCS Descriptor element having a field or bit set to a first value to enable the TXOP pre-emption backoff procedure for the class of data or set to a second value to disable such TXOP pre-emption for the class of data.

[0167] At step 520, the STA determines whether the TXOP pre-emption scheme must be triggered. This may consist in determining whether a transmission opportunity (TXOP) granted to a TXOP holder different from the STA is on-going (identified or sensed through the reception of a frame, such as an RTS-CTS exchange or a trigger frame, reserving the TXOP to the TXOP holder), then checking that the on-going TXOP is preemptable for the STA (authorized) and the pre-empting data to be transmitted (authorized), based on the information retrieved at step 500 and the data frame identified at step 510.

[0168] In some embodiments, additional conditions may be considered to trigger the TXOP preemption scheme for efficiency purposes.

[0169] For example, the STA may not systematically trigger the scheme but considers whether the remaining time in the on-going TXOP (thanks to the signalled duration of the TXOP) is reasonable or sufficient to transmit the pre-empting data (identified at step 510). To illustrate this, in case the authorization to pre-empt the TXOP is conveyed in a MPDU transmitted near the end of the TXOP, the pre-emption scheme may be triggered occur only if there is enough room (time) to transmit the pre-empting data (here an MPDU conveying the new MSDU data). This is to ensure that the pre-empting data can be transmitted within the duration of the current TXOP. As a result of test 520, the decision about triggering the TXOP pre-emption scheme may be based on a successful determination of whether the pre-empting data can be transmitted in priority during the TXOP.

[0170] Other additional criteria may be taken into account in combination or in variants, such as an occupancy threshold for the dedicated time-sensitive queue (or the like), a flow priority, and so on.

[0171] Another criterion relies on the number of TXOP pre-emption operations already performed in the considered on-going TXOP. In embodiments, it may be considered that the STA can contend for medium access multiple times (i.e., during multiple interframe periods) within the same TXOP up to a predefined maximum numberof contending tries. Afterthis maximum number of tries (named "PBO Retry Limit"), the STA is no longer authorized to perform TXOP pre-emption in this TXOP.

[0172] Yet another criterion relies on the existence of a previous successful TXOP pre-emption for the STA and / or for the type of pre-empting data, within the on-going TXOP. Indeed, in embodiments, a single successful pre-emption procedure may be allowed inside a TXOP per a given traffic flow and / or STA. This is because a pre-empting STA has still the opportunity to aggregate several MSDUs from different traffic flows inside the frame it will send when preempting the TXOP. This approach reduces the number of contentions and thus of possible collisions.

[0173] Next at step 530, the STA senses an end of frame transmission within the on-going TXOP. This may be done through Channel Sensing (CS) of the medium by the STA.

[0174] In particular, the STA may sense an end of an acknowledgement within a frame exchange sequence, as shown for example in Figure 4. This is to avoid perturbating the legacy 802.11 sequence for legacy STAs involved in the on-going TXOP that are not able to understand a disruption in their communication (e.g. STA1 expects to send a response 402 towards the AP after receiving data frame 401).

[0175] Upon detecting this end, the STA starts, at step 540, the TXOP pre-emption operation within the legacy interframe period that follows the previous frame, e.g. a SIFS period following ACK 402 in the scenario of Figure 4. This step represents the contention phase of the TXOP preemption scheme.

[0176] In embodiments illustrated below, contending for medium access includes performing a pre-emption backoff procedure within the interframe period, i.e., using a pre-emption backoff (PBO) counter that is decremented over time (pre-emption slot times).

[0177] In embodiments, the PBO backoff procedure is performed by the queue backoff engine associated with the AC corresponding to the pre-empting data to be transmitted (as identified at step 510). It means the EDCAF of the AC manages two backoff counters: the conventional EDCA BO counter and the PBO counter. It also means that, in case data of various ACs are to be transmitted (e.g., AC-VO and AC-VI), multiple PBO backoff procedures may run in parallel for these ACs, each having its own PBO counter.

[0178] In variants, a PBO function dedicated to TXOP pre-emption and distinct from the EDCA queue backoff engines can be used.

[0179] At step 542, the PBO counter is set for decrementing. The STA obtains an initializing PBO count or generates a random PBO count for initialization, unless the PBO counter already contains a nonzero value.

[0180] The initializing PBO count value may be predefined (e.g. by the AP and advertised by it) per STA or per AC (more generally per data class).

[0181] In variants, it is a pseudorandom integer drawn from a uniform distribution over the interval [0, PCW], where PCW is the contention window for TXOP pre-emption.

[0182] The PCW value may be a fixed value for all the ACs or per AC (or more generally per data class). In particular, the AP may obtain the PCW value from EDCA parameters transmitted by the AP, and then draw the initialization value for the PBO counter based on the obtained PCW. The PCW value may be transmitted by the AP as illustrated below with reference to Figure 11.

[0183] In variants, the PCW value (per AC or for all ACs) may be variable over time.

[0184] The PBO counter may be reinitialized at each new TXOP to be pre-empted. In particular, it may be computed prior to step 530 or 520 or even 510, for example when a new preemptable TXOP is detected.

[0185] The PBO counter may not be reinitialized at each new TXOP pre-emption operation within the same TXOP. That means the PBO counter already contains a nonzero value in case the STA did not gain TXOP pre-emption in a first TXOP pre-emption operation within the on-going TXOP. In that case, the decrementing of the PBO counter has been suspended when contending a first time for medium access in the on-going TXOP and can be resumed when contending a second time for medium access in the same TXOP.

[0186] However, in variants, the PBO counter may be reinitialized at each new TXOP preemption operation within the same TXOP.

[0187] Next to step 542, the STA starts decrementing the PBO counter each elementary time unit the communication channel is detected as idle (step 544). Usually the medium remains free, because the TXOP was granted to the TXOP holder. Only pre-empting STAs in the meaning of the present disclosure may make the medium busy due to the transmission of a PR frame 403 (when their PBO reaches 0).

[0188] The pre-emption backoff procedure uses the CS mechanism to determine whether there is activity on the medium during each pre-emption backoff slot 41 1 (Figure 4). If no medium activity is sensed for the duration of a particular pre-emption backoff slot, then the backoff procedure decrements the PBO counter. If the medium is determined to be busy (meaning a concurrent pre-empting STA has issued a medium access for pre-emption, as described at step 550), the PBO counter is not decremented for that slot, the PBO counter is suspended and the PBO counter can be next decremented only during a next pre-emption contention period 410, preferably in the same on-going TXOP. T ransmission commences when the PBO counter equals 0.

[0189] The pre-emption backoff procedure can use the Reduced Interframe Space (RIFS, equal to 2ps) duration as pre-emption backoff slot 411 , meaning that at most 8 pre-emption backoff slots can be counted down in a SIFS period, and 12 pre-emption backoff slots can be counted down in a PIFS period.

[0190] Therefore, PCW may be set (per AC or not) with a maximum value of 8 (or 12) given the maximum of 8 (or 12) slots per contention opportunity in case the pre-emption contention window is within a SIFS (or PIFS). However, in particular for cases where TXOP pre-emption operations can be repeated within the same TXOP, higher values may be considered for PCW.

[0191] The pre-emption contention period 410 may be defined to last one pre-emption backoff slot less than the legacy interframe period (e.g. SIFS) considered after the frame detected at step 530. In that case, the contention for medium access within the interframe period is configured to end at least one decrementing time slot before the end of the interframe period. This is for the STA to start transmitting the next frame (e.g. pre-emption request frame 403) still within the interframe (SIFS) period, hence for the other stations to detect such frame (and thus the preemption) before the end of the (SIFS) period.

[0192] Note that in the embodiments described above (as illustrated in Figure 4), no deferred mechanism is implemented to defer the beginning of the decrementing past the end of the previous frame (ACK 402).

[0193] In embodiments, a deferring mechanism similar to the AIFS mechanism may be implemented. Indeed, chipset implementations may need time (e.g. a first pre-emption time slot 411 of RIFS duration) prior to contending during period 41 Ox.

[0194] To that end, an Arbitration Pre-emption Interframe Space (APIFS) may be defined that indicates, per AC, the number of pre-emption backoff slots 411 the STA must wait before starting decrementing the corresponding PBO counter. In other words, contending for medium access includes deferring a decrementing of the pre-emption backoff counter by an Arbitration Preemption Interframe Space that is function of an access category of pre-empting traffic the STA intends to transmit over the pre-empted medium. The Pre-emption Interframe Space may be few pre-emption backoff slots: for example, 0 for AC_VO, 1 for AC_VI, 2 for AC_BE and 3 for AC_BK.

[0195] The deferring may apply to all STAs or to non-AP STAs only.

[0196] The deferring may also consider different numbers of pre-emption backoff slots for non- AP STAs compared to the AP, in particular shorter backoff slot numbers compared to non-AP STAs.

[0197] For example, the AP as a pre-emption STA may decrement its PBO counter without deferment to have more priority on the TXOP pre-emption, while the non-AP STAs (that may thus compete with the AP) implement a deferment of their PBO counter decrementing. The deferment may be conducted on a STA basis, or on an AC (or data class) basis. Pre-emption Interframe Space can be combined with those embodiments, for example, while the AP does not defer, the following Arbitration Pre-emption Interframe Spaces (APIFS) apply for non-AP STA: 1 for AC_VO, 2 for AC_VI, 3 for AC_BE and 4 for AC_BK.

[0198] Figure 4a illustrates, using timelines, embodiments providing relative priorities in between candidate pre-empting STAs when applying TXOP pre-emption operations.

[0199] This scenario illustrates an ongoing TXOP 400 gained by STA2 (TXOP holder) to exchange data with STA1 , and forwhich eitherthe AP and / or non-AP stations (as STA1 according to the figure) wish to pre-empt.

[0200] As illustrated by contention period 410a, the AP is provided a priority pre-emption consisting in a single pre-emption slot time countdown with no deferment. In contrast, the candidate pre-empting non-AP stations are provided a deferred pre-emption contention period 410b starting after 410a. That is to say the AP may pre-empt the TXOP access during the first pre-emption slot time following the end of previous transmission (e.g. ACK 402), whereas the other candidate pre-empting stations only starts their contention after this pre-emption slot time.

[0201] If the AP does not send PR frame 403 (that means it does not want to pre-empt), then STA1 may contend in 410b and send its PR frame 403’ in case its PBO counter reaches 0.

[0202] In summary, in the scenario of the Figure, the TXOP pre-emption by contention includes deferring (or delaying) a decrementing of the pre-emption backoff counter by at least one time slot in case the STA is not an access point or includes immediately decrementing the pre-emption backoff counter initialized at 1 in case the STA is an access point. This ensures the AP gains the pre-emption over non-AP STAs, while ensuring a non-AP STA may gain the pre-emption in case the AP does not compete with it. In a less strict approach, the AP may have a PBO counter initialized at a higher value than 1 in order to introduce real competition with the non-AP STAs.

[0203] The decrementing step 544 lasts as long as the interframe period 410 does not end and the medium remains idle and the PBO counter (or none if multiple PBO counters) does not reach zero. Pre-emption success is detected (test 546) when the PBO counter (or one if multiple PBO counters) reaches zero.

[0204] In case of successful TXOP pre-emption, the STA can access the medium and use it at step 550.

[0205] In embodiments as illustrated for example in Figure 4, the STA announces the TXOP pre-emption by sending (551) a pre-emption request frame, PR frame 403, as soon as the PBO counter reaches zero. As the TXOP pre-emption is contention-based, frame collision may occur (if several pre-empting STAs are using the same pre-emption slots). The PR frame, together with the ACK 405 below, allow PR frame collision to be detected at low cost compared to a long data frame.

[0206] An exemplary PR frame is shown in Figure 6 under reference 600. Frame 600 is PPDU made of legacy fields used for 802.11 frame detection, synchronization, carrying necessary information (e.g., MCSs and frame length), namely the following fields: the L-STF field, the L-LTF field and the L-SIG field. Using legacy fields ensures backward compatibility. Frame 600 is short (20ps) and easily detectable by 802.11 stations.

[0207] In enhanced embodiments, the above legacy fields may be supplemented (followed) by one or more of preambles (or part of) for HT (the 802.11 n standard), VHT (the 802.11 ac standard), HE (the 802.11 ax standard), EHT (the IEEE P802.11 be D6.0 standard) or UHR (the 802.11 bn standard under development) PHY versions.

[0208] For example, as shown in Figure 6 under reference 650, PR frame 650 includes in addition to the above legacy fields, a L-SIG preamble field repeated as RL-SIG (Repeated Non- HT SIGNAL field) and U-SIG preamble field. When an HE / EHT / UHR station recognizes the RL- SIG, it understands it is HE or upper frame format. Similarly, when an EHT / UHR station recognizes the U-SIG, it understands it is EHT or upper frame format. Those pre-EHT modulated fields, which include L-STF, L-LTF, L-SIG, RL-SIG, and U-SIG fields, are sent only on the 20 MHz channels where the STA’s EHT modulated fields are present.

[0209] In the U-SIG field, the version independent fields include the PHY version identifier (Bits B0-B2 of U-SIG-1 , e.g. value 0 is set for EHT, 1-7 are unused yet), UL / DL flag, BSS color, TXOP duration (Bits B13-B19 of U-SIG-1), and so on.

[0210] In embodiments, all or part of those fields may be reused forTXOP pre-emption purposes, in particular to signal TXOP pre-emption parameters, as follows: a new PHY version identifier for UHR, including the TXOP pre-emption mechanism (e.g. value 1 for bits B0-B2 of U-SIG-1 , first symbol of U-SIG), and / or

[0211] TXOP field (B13-B19 of U-SIG-1 , first symbol of U-SIG) is used to indicate (by the STA) the duration of the pre-empted period 420. It means that in some embodiments, the pre-emption request frame indicates a time length of the medium pre-emption within the TXOP. This is useful in particular when the pre-empting STA intends to use the medium for a long time (e.g. to transmit multiple data frames 404), and / or

[0212] PPDU Type is augmented by a new PR Preamble type (B0-B1 of U-SIG-2, second symbol of U-SIG, e.g. value 3), and / or one of bits B20-B24 of U-SIG-1 (first symbol of U-SIG) can be defined as a new field indicating the frame is a PR Frame.

[0213] PR frame formats 600 and 650 are short frame formats as mentioned above. In other embodiments, they can be followed by a MAC header, with a dedicated new type and thus including the MAC address of the pre-empting STA.

[0214] Once the PR frame 403 has been transmitted, the pre-empting STA can initiate (and perform) one or more frame exchange sequences 404 (using pending pre-empting data) with any other station. This is step 553. Note that in case the pre-empting STA is the AP, it may schedule MU transmission (uplink or downlink).

[0215] Optionally, the STA can wait (step 552) for a pre-emption response frame, ACK 405 in Figure 4, from the TXOP holder that validates the TXOP pre-emption. This is to reduce risks of collision during the data transmission 404. The pre-emption response frame may be a mere acknowledgment frame, i.e., Ack frame. In variant, the pre-emption response frame may be a copy of PR frame 403.

[0216] The STA may not receive the pre-emption response frame 405, in particular because the PR frame 403 collided with another PR frame sent by another candidate pre-empting STA. This is illustrated in Figure 7.

[0217] STA1 and STA2 count down their PBO, and reach zero at the same time, hence send their PR frame 403 and 403’ substantially at the same time. A frame collision therefore occurs. The TXOP holder detects the collision because the PR frames 403, 403’ may not be strictly aligned, and also because their content may not be the same (e.g. if the address of the STA is signalled).

[0218] Due to the lack of ACK 504, STA1 and STA2 know they are not allowed to pre-empt the TXOP. Hence, the AP owns back the wireless medium a SIFS after the PR frames, or preferably a little before the end of SIFS in order to block any transmission from STA1 or STA2.

[0219] In this scenario, the TXOP holder considers there is no pre-empting frame, hence no TXOP pre-emption, in case frame collision is sensed during the interframe period. Frame collision is detected e.g. when the TXOP holder is unable to decode a frame. Therefore, the TXOP holder can use the TXOP again substantially a SIFS after an end of the sensed collided frames.

[0220] Steps 551 to 553 are shown in detail (a) of Figure 5.

[0221] In other embodiments depicted in detail (b) of Figure 5, the pre-empting STA may directly perform data transmission 404 (step 553) upon having its PBO counter reaching 0.

[0222] In yet other embodiments depicted in detail (c) of Figure 5 and illustrated in Figure 8, the PR frame is of variable length, for example depending on the AC of the pre-empting data to be transmitted. To do so, the PR frame includes a length-varying part, the length of which depends on a type of pre-empting traffic the STA intends to transmit over the pre-empted medium. Adapting the duration of the PR frame makes possible to reduce the competing stations to a limited number of stations, that is profitable for contention (reduce risk of collision).

[0223] Figure 6 shows a padding portion 690 which may be added to PR frame format 600 or 650. The length of the padding portion is adjusted to the AC of the pre-empting data, to prioritize the ACs between them. The length may be defined as a number of symbols or pre-emption slots 411 , for example, 3 for AC_VO, 2 for AC_VI, 1 for AC_BE and 0 for AC_BK. More generally, the length may be incrementing by one slot / symbol up to the maximum number of considered queues (0 to 4 for AC queues, or 0 to 7 if UP is considered, and so on).

[0224] In that way, when two candidate pre-empting STAs have their PBO counter reaching 0 at the same pre-emption slot time 411 (see Figure 8), the one with the longest PR frame can win the TXOP pre-emption, in particular because the other STA can detect activity in the additional pre-emption slot time, hence infer collision and infer that its pre-emption attempt has failed.

[0225] To allow such detection, the contention for medium access within the interframe period is configured to end at least one decrementing (pre-emption) time slot 411 before the end of the interframe period. In other words, the pre-emption contention period 410 is shorter than the interframe period and ends before (at least one slot 411) the interframe period.

[0226] The length of the padding portion may be indicated per AC by the AP, as a number of symbols (4ps) to be added or as a number of pre-emption slots (2ps) to be added. The minimum value of the length is 0, meaning the shortest PR frame corresponds to the transmission of the preamble 600 or 650 alone. A PR Size subfield per AC may be used to signal the length of the padding portion, as illustrated in Figure 11.

[0227] When PR frames of variable length are used, the STA having its PBO counter reaching 0 sends the PR frame 403 with the appropriate length (based on the AC of the pending preempting data). This is step 551 .

[0228] Next, the STA senses (step 554) the medium during the next pre-emption slot time 411 (preferably during the rest of the interframe period) to determine (step 555) whether a more prioritized PR frame 403’ is transmitted by another candidate pre-empting STA. In other words, it determines whether the medium is busy during the interframe period after having transmitted the pre-emption request frame.

[0229] In the affirmative, the STA does not win the TXOP pre-emption at the end.

[0230] In the negative, the STA wins the TXOP pre-emption and can trigger one or more frame exchange sequences using e.g. its pending pre-empting data (step 553), optionally upon receiving (step 552) an acknowledgment from the TXOP holder.

[0231] Once the STA has performed the data exchange 553, it releases (step 560) the preempted TXOP, meaning the TXOP holder can take it back to use it. The release takes place at the end of the pre-empted period 420. If the length of the pre-empted period 420 is signalled in the PR frame 403, the TXOP holder only has to wait for the end of the pre-empted period 420. If it is not signalled, the TXOP holder may consider using a PIFS period after each transmission within the pre-empted period 420 (to try to take the TXOP back) whilst the pre-empting STA uses only SIFS periods as long as it wants to continue transmitting in the pre-empted period 420.

[0232] In case of unsuccessful TXOP pre-emption at step 546, the STA suspends the decrementing of its PBO counter or counters, which can be resumed for a next TXOP pre-emption operation within the same TXOP.

[0233] Figure 9 illustrates a scenario where no station gains TXOP pre-emption. STA1 and STA2 have counting down their PBO, but none reaches zero (PBO counter is greater than 8). Therefore, no pre-emption access is performed.

[0234] As a result, the AP will notice this absence of PR frame and continue its communication inside its TXOP by sending next frame(s) 905, which are legacy frames (not pre-emption frames).

[0235] The AP starts transmitting the next frame 905 in between a SIFS delay and PIFS delay (later case represented in the figure) after ACK frame 402 reception of prior data 401 . In practice, frame 905 is sent immediately after the TXOP holder (here AP) has detected no activity in the wireless medium, depending on its capability to sense and transmit back on the medium. “immediately after” means “in the continuity of’ without any other STA being able to access the medium using legacy channel access schemes. For example, the TXOP holder may start exactly at the SIFS delay if it had time to sense the medium (for PR frame detection) during the SIFS period, which is possible e.g. if the pre-emption contention period 410 ends before (at least one slot 41 1) the SIFS period. Otherwise, the TXOP holder starts one or more slot 41 1 after the end of the SIFS period, but before the end of the PIFS period.

[0236] In this scenario, the TXOP holder obtains a transmission opportunity (TXOP) on the wireless medium and scheduling one or more frame exchange sequences, senses whether a preempting frame is transmitted by another STA during an interframe period inside the TXOP and starting from an end of a frame transmission in the frame exchange sequence, to the effect of pre-empting the TXOP, and continues using the TXOP in the continuity of the interframe period in case no pre-empting frame is sensed.

[0237] The pre-emption contention parameters used by the STAs to conduct TXOP pre-emption operations include one or more of the initializing PBO count value (in case no random drawing of the initializing value is conducted), the pre-emption contention window PCW (per STA, or per AC orthe like), the length PR Size of the padding portion of the PR frame (hence defining the variable length of the PR frame), the deferment APIFS (per SA, or per AC orthe like) before decrementing the PBO counter. The pre-emption contention parameters may be predefined or defined at STA level.

[0238] As mentioned above, they are preferably advertised by the AP in a management frame, such as a Beacon, Probe Response or (Re)Association Response frame. Hence, they can be updated over time in new frames.

[0239] Figure 10 illustrates, using a flowchart, general steps for a STA to obtain the pre-emption contention parameters. This process preferably takes place before the one of Figure 3 or 5, after which the STA stores, in local memory, the obtained pre-emption contention parameters for use when operating the TXOP pre-emption.

[0240] At step 1000, the STA obtains a management frame from the AP, which management frame includes the pre-emption contention parameters. Next at step 1010, the STA obtains the pre-emption contention parameters from the management frame, for example by traversing corresponding fields.

[0241] Figure 11 illustrates an exemplary signalling of pre-emption contention parameters in a frame. The Figure illustrates a Parameter Set format that is based on the EDCA Parameter Set element format (depicted in Fig.9-293 of the IEEE Std 802.1 1-2020 standard). Although the proposed format is built on the known EDCA Parameter Set element format that advertises about fourACs (hence four profiles), a numberof parameter profiles different from the AC queue number can be provided. They could be applied per UP, per SCSID, or any identifier able to discriminate different types of data (more generally any data class or traffic class or access class). The enhanced Parameter Set format is named “TXOP Pre-emption Parameter Set element” (or TP Parameter Set element in case the TXOP pre-emption mechanism specifically targets LL traffic).

[0242] The TXOP Pre-emption Parameter Set element may be included in Beacon frames or Probe Response frames or (Re)Association Response frames or even in a Stream Classification Service, SCS, descriptor transmitted by the AP

[0243] The TXOP Pre-emption Parameter Set element 1100 includes QoS Info field 1120 and four AC Parameter Record fields 1130 corresponding to the four ACs and denoted “LL_AC_xx Parameter Record” fields where “xx” corresponds to the ACs.

[0244] QoS Info field 1120 contains (not shown) an EDCA Parameter Set Update Count subfield, which indicates when the parameters (including the new ones for pre-emption) have changed.

[0245] The formats of LL_AC_BE, LL_AC_BK, LL_AC_VI, and LL_AC_VO Parameter Record fields 1130 are identical. Of course, it is still possible to include more records according to the number of queues (for example, there could have eight records corresponding to the eight possible User priorities UPs).

[0246] As shown, the records are based on the ACI / AIFSN field format of Fig.9-296 of the IEEE Std 802.1 1-2020 standard, but augmented by one byte to include a first field 1134 and a second field 1135.

[0247] Subfields 1131 to 1133 are same as the legacy format: the AIFSN subfield 1131 indicates the number of slots after a SIFS a STA defers before either invoking a backoff or starting a transmission. The minimum value of the AIFSN subfield is 2. the ACM (admission control mandatory) subfield 1132 indicates that admission control is required for the AC. For example, such an admission control mandates the use of an SCS Request by the client STA. If the ACM subfield is equal to 0, then there is no admission control for the corresponding AC. If the ACM subfield is set to 1 , admission control has to be used prior to transmission using the pre-emption parameters specified for this AC. the value of the AC index (ACI, 1133) references the AC to which all parameters in this record correspond.

[0248] Additional first field 1134 from bit 7 to bit 10 may be used to convey the pre-emption contention window PCW for this AC, e.g. the maximum number of pre-emption time slots 411 corresponding to pre-emption period 410 (hence after a start of the contention period).

[0249] In one embodiment, the first field 1134 contains the PCW value per se, meaning maximum value of PCW is 16.

[0250] In another embodiment that allows higher values for the PCW, the first field 1134 may encode the PCW in an exponent form, meaning the field stored an EPCW value (standing for Exponent-form Pre-emption Contention Window) so that PCW = 2EPCW- 1 . Hence, the minimum encoded value of PCW is 0, while the maximum value is 32 767. In case no random drawing of the initializing PBO count value is made, the first field 1134 may directly store the initializing PBO count value

[0251] Additional first field 1135 from bit 11 to bit 15 may be used to convey the PR Size value for the AC considered. The PR Size field 1135 is specified as an unsigned integer, in units of given number of ps (e.g., 2ps as RIFS based) or number of symbols (4psec).

[0252] An additional field (not shown) may be provided in record 1 130 to indicate the APIFS value for the AC considered. As an example, this field may indicate the deferment as a number of pre-emption time slots 411 . A two-bit long field allows four possible deferment values (from 0 to 3). A three-bit long field allows eight possible deferment values (from 0 to 7).

[0253] In a variant, subfield 1 131 may be used to convey the APIFS value. In that case, TXOP Pre-emption Parameter Set element 1100 no longer convey conventional EDCA parameters.

[0254] By providing adaptive EPCW and PR Size in between AC queues, the mechanism provides a simple way to prioritize TXOP pre-emption access in between the AC for low-latency traffic. The PR frame aims at pre-empting medium access against pre-emption concurrent devices by varying the duration or pre-emption delays of the PR per queues.

[0255] Figure 12 illustrates an exemplary enhanced Stream Classification Service, SCS, Descriptor element format for requesting / allowing the TXOP pre-emption mechanism according to the disclosure.

[0256] SCS is a service that may be provided by an AP to its associated ST As that support SCS. In SCS, the AP classifies incoming individually addressed MSDUs based upon parameters provided by the non-AP STA, hence defining SCS flows or streams. The classification allows the UP, drop eligibility, and EDCA transmit queue to be selected for all MSDUs matching the classification.

[0257] A non-AP STA that supports SCS may request use of SCS by sending an SCS Request frame that includes an SCS Descriptor element with the Request Type field set to “Add” or “Change.” The SCS Descriptor List field in the SCS Descriptor element identifies how MSDUs are classified and the priority to assign to MSDUs that match this classification. Each SCS stream is identified by an SCSID. This SCSID is used by a non-AP STA to request creation, modification, or deletion of an SCS stream. The SCSID is used by an AP to identify an SCS stream in SCS responses.

[0258] In the D6.0 standard, SCS can be used to additionally specify QoS rules for certain SCS flows (e.g., assign flows to the desired Access Categories), and therefore allows traffic characteristics (e.g., traffic data rate and burst size) and QoS expectations or KPIs (e.g., latency bound) to be specified. An activation of SCS rules is always initiated by the non-AP STA (acting as client device) sending the SCS Request frame to the AP: the request from the non-AP STA explicitly provides the AP with classification parameters for each SCS flow (as example, UP can be used but also other elements included in various TCP / UDP / IP headers of the frames forming the flow). Because SCS streams are used to define separate streams with different QoS requirements (especially low-latency traffics), they may be privileged candidates for negotiating the activation of the TXOP pre-emption mechanism described above.

[0259] Following the format provided in the D6.0 Standard, the SCS Descriptor element 1200 includes: a SCSID field 1220 carrying an identifier for the traffic stream described / defined by element 1200. The ID is assigned by a STA requesting classification of the stream and is unique across the STA; a Request Type field 1221 takes a value to identify the type of SCS request: Add, Remove, or Change; an Optional Intra-Access Category Priority element 1222 provides information to the AP on the relative priorities of the SCS traffic streams within an AC. It corresponds to the optional introduction of two alternate queues proposed by the IEEE 802.11 aa standard, compared to the four primary queues of EDCA. Such a queue may be considered as storing queue for preempting data; a TCLAS Elements 1223 and a TCLAS Processing Element 1224, if present, describe criteria the STA requests for traffic classification, which criteria the AP has to apply to identify the data or MSDUs forming the corresponding SCS stream; and a QoS Characteristics Element 1225 providing a Traffic Specification. QoS Characteristics Element field 1225 contains zero or one QoS Characteristics element to describe the traffic characteristics and QoS expectations of traffic flows that belong to this SCS traffic stream.

[0260] The QoS Characteristics are considered by the AP to properly schedule the STA to transmit the local SCS stream. As an example, the AP may enable the transmission of frames from the STA with an interval that falls between the requested minimum and maximum service intervals and the AP may meet the minimum data rate requested if the Direction subfield of the QoS Characteristics element indicates uplink or direct-link.

[0261] As shown in the Figure, various fields are provided in QoS Characteristics element 1225 that define various QoS transmission parameters for the local SCS stream.

[0262] Control Info field 1240 within QoS Characteristics element 1225 is defined as follows: Direction subfield 1241 specifies the direction of data forming the stream: Uplink (field set to 0), Downlink (1) or Direct-link (2);

[0263] TID subfield 1242 contains the target TID value of the MSDUs belonging to the local SCS stream (i.e., as described by the SCS Descriptor 1200). In practice, this TID can then be used by the AP to schedule (e.g., polling Buffer status reports, allocating resources in emitted trigger frames) the SCS stream, rather than using the SCSID;

[0264] User Priority subfield 1243 contains the UP (value 0-7) of the data frames that are described by this element. When the TCLAS element 1224 is present in the SCS frame containing this element, the User Priority subfield 1243 is set to the user priority value specified in the TCLAS element; and LinkID subfield 1244 contains the link identifier of the link (in case of MLD) for which the P2P or direct link transmissions are going to occur (therefore only considered when Direction subfield 1241 specifies Direct-link).

[0265] Other subfields of QoS Characteristics element 1225 are of less importance for the present disclosure; they represent the set of parameters defining the characteristics and QoS expectations for the SCS stream (e.g., Minimum and Maximum Service Intervals, Minimum Data Rate, Delay Bound).

[0266] As mentioned above, the definition of the SCS stream may be used to request AP’s assistance to deliver uplink traffic, in particular through the proposed TXOP pre-emption scheme. It is thus envisaged that the non-AP STA indicates to the AP its wish to take benefit of the TXOP pre-emption mechanism.

[0267] To do so, a bit (or more generally a field) is provided in SCS Descriptor element 1200, preferably in one QoS Characteristics element 1225, more preferably in its Control Info field 1240, more preferably in one of reserved bits B29-B31 , such as bit B29, to signal a request for TXOP pre-emption authorization or not for the SCS stream concerned.

[0268] The request for TXOP pre-emption authorization may be in replacement to conventional EHT AP’s scheduling (i.e., trigger-based MU UL transmission), or in complement thereto.

[0269] Hence, in embodiments where it replaces EHT AP’s scheduling, the QoS Characteristics element 1225, in which the Direction subfield is equal to uplink or direct link and with ’TXOP Preemption Scheme” subfield 1250 (bit b29 of Control Info) is set to 1 , is no longer taken into account when the AP schedules RUs for the ST As using trigger frames (EHT AP’s scheduling).

[0270] In that case, a non-AP EHT STA may transmit an SCS Request frame with SCS Descriptor element(s) containing a QoS Characteristics element if the Request Type field 1221 in the frame is set to “Add” or “Change”. The QoS Characteristics element 1225, in which the Direction subfield 1241 is equal to uplink or direct link, describes the traffic characteristics of the requested SCS stream and requests (bit B29) the use of TXOP pre-emption mechanism for enhanced EDCA access.

[0271] The AP responds with an SCS Response frame.

[0272] In embodiments, an AP can directly send an unsolicited SCS Response to the non-AP STA to signal the STA is allowed to apply the TXOP pre-emption scheme. This allows the AP to install UL QoS mandating executing the pre-emption scheme of the disclosure, for business- critical flows on the STAs of its administrated BSS.

[0273] In an SCS Response frame with a Status field value set to REJECTED_WITH_SUGGESTED_CHANGES, an AP may include an SCS Descriptor element containing a QoS Characteristics element with bit B29 set to a different value than the QoS Characteristics element contained in the SCS Descriptor element of the corresponding SCS Request frame. For example, if the STA has requested the use of the TXOP pre-emption mechanism (B29 = 1 in the request), the AP can refuse it (B29 = 0 in the response). Similarly, if the STA has not requested the use of the TXOP pre-emption mechanism (B29 = 0 in the request), the AP can impose it (B29 = 1 in the response).

[0274] If an AP is not able to answer QoS expectations for the SCS stream proposed in the SCS Request frame requesting the use of the deferred mechanism (e.g., any of Minimum and Maximum Service Intervals, Minimum Data Rate, Delay Bound), it may send an SCS Response frame with a Status field value set to REJECTED_WITH_SUGGESTED_CHANGES, including an SCS Descriptor element containing a QoS Characteristics element with bit B29 set to 1 . Keeping bit B29 to 1 with a rejection response indicates the non-AP STA will not obtain triggered-based transmission opportunities from the AP as assistance to deliver the specified traffic, but the STA can use the TXOP pre-emption mechanism of the present disclosure.

[0275] In a variant, when bit B29 is set to 1 , the LinkID subfield (1244) contains a link bitmap to identify the link(s) for which the TXOP pre-emption mechanism is active. This applies for multilink devices.

[0276] By providing to the AP means to allow TXOP pre-emption operations to a STA, the AP may control the number of contending stations for TXOP pre-emption, hence reducing collisions for this scheme.

[0277] In some embodiments, the TXOP Pre-emption Parameter Set element 1 100 (Figure 11) may be included in the SCS Response frame from the AP to provide the pre-emption contention parameters to the STA. As an example, the TXOP Pre-emption Parameter Set element 1100 may be included in Optional Sub-elements subfield 1226 of the SCS Descriptor element 1200.

[0278] The description above proposes a contention-based TXOP pre-emption. Even if medium contention is a well-known technique, the proposed scheme through backoff procedure is original due to the execution of the contention within the on-going TXOP.

[0279] Compared to a legacy EDCA backoff procedure, the pre-emption backoff procedure is performed inside a TXOP, with shortest duration for backoff slots, in order that the maximum preemption contention period lasts an interframe delay (SIFS or PIFS). There is no need to wait for a deferring DIFS period before decrementing the pre-emption backoff counter because the contention is limited to small number of STAs (possibly under allowance by the AP via a QoS traffic management) and the medium was already granted to the TXOP holder which agrees to be pre-empted by those stations / flows.

[0280] One major advantage is that if no pre-emption is granted, the wireless medium is still kept by the TXOP owner and transmissions can continue in a legacy way.

[0281] Figure 13a schematically illustrates a communication device 1300, which may be any stations of radio network 100 of Figure 1 , configured to implement at least one embodiment of the present disclosure. The communication device 1300 may preferably be a device such as a micro-computer, a workstation or a light portable device.

[0282] It should also be appreciated that the communication device is configured to operate in different modes (TXOP holder, TXOP share participant, source, intermediate, destination, first AP, other AP, stations associated with the first AP, stations associated with another AP, coordinator, coordinate, AP in an OBSS, STA in an OBSS, and so forth), depending on what role it is performing in the current communication context.

[0283] The communication device 1300 comprises a communication bus 1313 to which there are preferably connected: a central processing unit 1301 , such as a processor, denoted CPU; a memory 1303 for storing an executable code of methods or steps of the methods according to embodiments of the disclosure as well as the registers adapted to record variables and parameters necessary for implementing the methods; and at least one communication interface 1302 connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards and / or Wireless-Fidelity (Wi-Fi) specifications, via transmitting and receiving antennas 1304.

[0284] Preferably the communication bus 1313 provides communication and interoperability between the various elements included in the communication device 1300 or connected to it. The representation of the bus is not limiting and in particular the central processing unit 1301 is operable to communicate instructions to any element of the communication device 1300 directly or by means of another element of the communication device 1300.

[0285] The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 1302, in order to be stored in the memory of the communication device 1300 before being executed.

[0286] In an embodiment, the device is a programmable apparatus which uses software to implement embodiments of the disclosure. However, alternatively, embodiments of the present disclosure may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

[0287] Figure 13b is a block diagram schematically illustrating the architecture of the communication device 1300, adapted to carry out, at least partially, some embodiments of the disclosure. As illustrated, device 1300 comprises a physical (PHY) layer block 1323, a MAC layer block 1322, and an application layer block 1321 .

[0288] The PHY layer block 1323, here a plurality of 802.11 standardized PHY layer modules in case the device is a MLD (however a single PHY layer module may be contemplated when the device is single link), has the task of formatting, modulating on or demodulating from any 20MHz channel or composite channel or resource unit. The PHY layer thus sends or receives frames over the radio medium NETW, such as 802.11 frames. These frames may include frames to reserve and obtain a TXOP, data frames, Ack frames, PR frames as those shown in Figure 6 (made of legacy preambles in some embodiments), and other conventional 802.11 frames.

[0289] The MAC layer block or controller 1322 preferably comprises a MAC 802.11 layer 1324 implementing conventional 802.11 MAC operations. It may comprise additional block 1325 for carrying out, at least partially, embodiments of the disclosure. MAC layer block 1322 may optionally be implemented in software, which software is loaded into RAM 1303 and executed by CPU 1301. MAC 802.11 layer 1324 may implement an Upper-MAC stack 1324a along with one or more Lower-MAC modules 1324b in case the device is a MLD. Of course, a single-link architecture is supported (whereas not illustrated here).

[0290] Preferably, additional block 1325, referred to as “TXOP Pre-emption access” module, implements, in collaboration with MAC 802.11 layer 1324, embodiments of the present disclosure to perform TXOP pre-emption operations to transmit, within an existing granted TXOP, pending data, such as data of latency sensitive traffic streams. As an example, block 1325 performs the operations of the methods illustrated in Figures 3 to 10.

[0291] On top of the Figure, application layer block 1321 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 1321 represents all the stack layers above MAC layer according to the ISO standardization.

[0292] Although the present disclosure has been described herein above with reference to specific embodiments, it is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present disclosure.

[0293] Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the disclosure, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

[0294] 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 different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

CLAIMS1. A communication method in a wireless network, comprising, at a station (STA): sensing an end of frame transmission in a frame exchange sequence scheduled by aTXOP holder different from the STA within a transmission opportunity (TXOP) granted to the TXOP holder, and contending for medium access within an interframe period inside the TXOP and starting from the end of the frame transmission, to pre-empt medium access over the TXOP holder in the TXOP in case of contention success.

2. The method of Claim 1 , wherein the TXOP holder signals whether the TXOP is open to pre-emption, for example in a management frame prior to the TXOP, in a frame reserving the TXOP or in a frame within the TXOP.

3. The method of Claim 1 , wherein the TXOP holder or an access point signals which of the following stations are authorized to contend for pre-empting the TXOP: all non-AP stations associated with the TXOP holder as an access point (AP), or one or more stations specifically identified by the TXOP holder, or an access point (AP) with which the TXOP holder acting as a non-AP station is associated.

4. The method of Claim 1 , wherein the TXOP holder signals which type or types of preempting traffic are authorized for transmission in case of pre-emption of the TXOP.

5. The method of Claim 1 , wherein the interframe period is a SIFS period.

6. The method of Claim 1 , wherein the end of the frame transmission matches an end of an acknowledgement within the frame exchange sequence.

7. The method of Claim 1 , wherein contending for medium access includes performing a pre-emption backoff procedure within the interframe period, the pre-emption backoff procedure including a pre-emption backoff counter that is decremented over time.

8. The method of Claim 7, wherein the decrementing of the pre-emption backoff counter is made on a Reduced Interframe Space (RIFS)-length time slot basis.

9. The method of Claim 7, wherein the pre-emption backoff counter is reinitialized at each new TXOP to be pre-empted.

10. The method of Claim 7, wherein the decrementing of the pre-emption backoff counter is suspended when contending a first time for medium access in the TXOP and is resumed when contending a second time for medium access in the same TXOP.

11. The method of Claim 7, comprising obtaining a pre-emption contention window value from parameters transmitted by an access point, and drawing an initialization value for the preemption backoff counter based on the pre-emption contention window value.

12. The method of Claim 11 , wherein a pre-emption contention window value is defined per access category.

13. The method of Claim 7, wherein a pre-emption contention period for medium access contention within the interframe period is configured to end at least one decrementing time slot before the end of the interframe period.

14. The method of Claim 7, wherein contending for medium access includes: in case the STA is not an access point, deferring a decrementing of the pre-emption backoff counter by at least one decrementing time slot, and in case the STA is an access point, immediately decrementing the pre-emption backoff counter initialized at 1 .

15. The method of Claim 7, wherein contending for medium access includes deferring a decrementing of the pre-emption backoff counter by an Arbitration Pre-emption Interframe Space that is function of an access category of pre-empting traffic the STA intends to transmit over the pre-empted medium.

16. The method of Claim 1 , comprising contending for medium access within multiple interframe periods in the same TXOP up to a predefined maximum number of contending tries.

17. The method of Claim 1 , comprising, at the STA, evaluating time remaining in the TXOP with respect to an amount of data to be transmitted, and triggering the contention for medium access in case there is sufficient time.

18. The method of Claim 1 , comprising, at the STA, transmitting a pre-emption request frame over the medium upon successfully contending access to the medium within the interframe period.

19. The method of Claim 18, wherein the pre-emption request frame is made of a legacy preamble made of a L-STF field, a L-LTF field and a L-SIG field, optionally supplemented by one or more preamble field from HT (802.11 n), VHT (802.11 ac), HE (802.11 ax) or EHT (802.11 be D6.0) standard and optionally supplemented by a length-varying part.

20. The method of Claim 18, comprising receiving, from the TXOP holder, a pre-emption response frame acknowledging the pre-emption request frame.

21. The method of Claim 18, wherein the pre-emption request frame includes a lengthvarying part, the length of which depends on a type of pre-empting traffic the STA intends to transmit over the pre-empted medium.

22. The method of Claim 21 , comprising obtaining a length-varying part length from parameters transmitted by an access point, and designing the length-varying part of the preemption request frame to match the length-varying part length.

23. The method of Claim 21 , wherein the length-varying part length is defined per access category.

24. The method of Claim 18, comprising determining whether the medium is busy during the interframe period after having transmitted the pre-emption request frame.

25. The method of Claim 18, wherein the pre-emption request frame indicates a time length of the medium pre-emption within the TXOP.

26. A communication method in a wireless network, comprising, at a station (STA):obtaining a transmission opportunity (TXOP) on the wireless medium and scheduling a frame exchange sequence, sensing whether a pre-empting frame is transmitted by another STA during an interframe period inside the TXOP and starting from an end of a frame transmission in the frame exchange sequence, to the effect of pre-empting the TXOP, and using the TXOP in the continuity of the interframe period in case no pre-empting frame is sensed.

27. The method of Claim 26, wherein the interframe period is a SIFS or PIFS period, and using the TXOP starts again a SIFS or PIFS after the end of the frame transmission in case no pre-empting frame is sensed during the SIFS or PIFS period.

28. The method of Claim 26, wherein no pre-empting frame to the effect of pre-empting the TXOP is sensed when a frame collision is sensed during the interframe period.

29. The method of Claim 28, wherein using the TXOP starts again substantially a SIFS after an end of the sensed collided frames.

30. The method of Claim 26, comprising, at the station: in case the station senses a pre-empting frame during the interframe period, sending a pre-emption response frame in response to the sensed pre-empting frame to acknowledge TXOP pre-emption, and in case the station senses activity during the interframe period but no pre-empting frame, not sending any acknowledgment frame.31 . A wireless communication device comprising at least one microprocessor configured for carrying out the method of Claim 1 or 26.

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