Preemption requests and permission

Abstract

Embodiments of this disclosure relate to preemption requests and permissions. In one embodiment, a first device receives a preemption request from a second device regarding the preemption of a transmit opportunity (TXOP) initiated by the first device. The first device determines whether to permit or deny the preemption of the TXOP. The first device performs an action to notify the second device whether the preemption of the TXOP is permitted or denied. By preempting a TXOP in a negotiation manner with the TXOP holder in this way, low-latency data frame transmission can be facilitated.

Description

Technical Field

[0001] Various exemplary embodiments relate to the field of communications, and more particularly, to devices, methods, apparatuses, and computer-readable media related to preemption requests and grants.

Background Art

[0002] Recently, the IEEE (Institute of Electrical and Electronic Engineers) 802.11 Working Group formed a new Study Group (SG) to define projects for new physical (PHY) and media access control (MAC) technologies in order to further increase the reliability and throughput of 802.11 wireless local area networks (WLANs). Latency improvement is one of the main requirements in the UHR group, as described in the approved motions and project approval requests (PARs) for the formation of the ultra-high reliability (UHR) SG.

[0003] Several new features have been developed to support low-latency data frame transmission. These features include multi-link operation (MLO), restricted target wake time (R-TWT), and an MLO stream classification service (MSCS)-based quality of service (QoS) signaling mechanism. Combining R-TWT with MSCS-based QoS signaling on 802.11be devices can achieve bounded latencies of less than 25 ms. However, this still does not meet the demands of industrial applications requiring latencies ranging from tens of milliseconds to less than a few milliseconds. Preemption solutions are being discussed to schedule low-latency data frame transmissions. [Overview of the project]

[0004] Generally speaking, exemplary embodiments of this disclosure provide solutions relating to preemption requests and authorizations.

[0005] In a first embodiment, a first device is provided, comprising at least one processor and at least one memory for storing instructions, the instruction, when executed by at least one processor, causes the first device to perform at least the steps of: receiving a preemption request from a second device regarding the preemption of a transmission opportunity (TXOP) initiated by the first device; determining whether to permit or deny the preemption of the TXOP; and performing an action to notify the second device that the preemption of the TXOP is permitted or denied.

[0006] In a second embodiment, a second device is provided, comprising at least one processor and at least one memory for storing instructions, the instruction, when executed by at least one processor, causes the second device to perform at least the steps of: determining to preempt a TXOP initiated by the first device; sending a preemption request relating to the preemption of the TXOP to the first device; and determining whether the preemption of the TXOP is permitted or denied by the first device in accordance with an operation performed by the first device.

[0007] A third embodiment provides a method, the method comprising: a first device receiving a preemption request from a second device relating to the preemption of a Transmit Opportunity (TXOP) initiated by the first device; determining whether to allow or deny the preemption of the TXOP; and performing an action to notify the second device that the preemption of the TXOP is allowed or denied.

[0008] A fourth aspect provides a method, the method comprising: determining in a second device to preempt a TXOP initiated by a first device; sending a preemption request to the first device regarding the preemption of the TXOP; and determining whether the first device is permitted or denied preemption of the TXOP depending on an action performed by the first device.

[0009] In a fifth aspect, an apparatus is provided. The apparatus includes, in a first device, means for receiving a preemption request from a second device relating to the preemption of a TXOP initiated by the first device; means for determining whether to permit or deny the preemption of the TXOP; and means for performing an action to notify the second device that the preemption of the TXOP is permitted or denied.

[0010] In a sixth aspect, an apparatus is provided, the apparatus including means for determining in a second device to preempt a Transmit Opportunity (TXOP) initiated by a first device; means for transmitting a preemption request relating to the preemption of the TXOP to the first device; and means for determining whether the first device is permitted or denied preemption of the TXOP in response to an operation performed by the first device.

[0011] In the seventh aspect, a non-temporary computer-readable medium is provided, comprising program instructions that cause the device to perform at least one of the methods according to the third to fourth aspects described above.

[0012] In the eighth aspect, a computer program product is provided that includes program instructions for performing at least one of the methods described in the third to fourth aspects above.

[0013] In the ninth aspect, a computer program comprising instructions is provided, and when the instructions are executed by a device, the device is caused to perform at least one of the methods according to the third to fourth aspects described above.

[0014] In a tenth embodiment, a first device is provided. The first device includes a receiving circuit configured to receive a preemption request from a second device relating to the preemption of a TXOP initiated by the first device; a determining circuit configured to determine whether to permit or deny the preemption of the TXOP; and an executing circuit configured to perform an operation to notify the second device whether the preemption of the TXOP is permitted or denied.

[0015] In an eleventh embodiment, a second device is provided. The second device includes a determination circuit configured to determine whether to preempt a TXOP initiated by the first device; a transmission circuit configured to send a preemption request relating to the preemption of the TXOP to the first device; and a determination circuit configured to determine whether the preemption of the TXOP is permitted or denied by the first device, depending on an operation performed by the first device.

[0016] It should be understood that the summary section of the invention is not intended to identify any major or essential features of the embodiments of this disclosure, nor is it intended to be used to limit the scope of this disclosure. Other features of this disclosure will be readily apparent from the following description.

[0017] Next, several exemplary embodiments will be described with reference to the attached drawings. [Brief explanation of the drawing]

[0018] [Figure 1A] This figure shows an exemplary communication system in which embodiments of the present disclosure may be implemented. [Figure 1B] This is a schematic diagram illustrating preemption cases for low-latency data frame transmission. [Figure 1C] This is a schematic diagram illustrating potential delay issues that can occur in preemption cases for low-latency data frame transmission. [Figure 2] This figure shows an exemplary signaling chart of an exemplary process according to some embodiments of the present disclosure. [Figure 3] This figure shows an exemplary signaling chart of an exemplary explicit preemption permission process according to some embodiments of the present disclosure. [Figure 4] This figure shows an exemplary signaling chart of an exemplary implicit preemption permission process according to some embodiments of the present disclosure. [Figure 5]A schematic diagram showing an explicit preemption permission procedure according to some embodiments of the present disclosure. [Figure 6] A schematic diagram showing an implicit preemption permission procedure according to some embodiments of the present disclosure. [Figure 7] A schematic diagram showing a method implemented in a first device according to some other embodiments of the present disclosure. [Figure 8] A schematic diagram showing a method implemented in a second device according to some other embodiments of the present disclosure. [Figure 9] A simplified block diagram of a device suitable for implementing embodiments of the present disclosure is shown. [Figure 10] A block diagram of an exemplary computer-readable medium according to some embodiments of the present disclosure is shown.

[0019] Throughout the drawings, the same or similar reference numerals represent the same or similar elements.

Best Mode for Carrying Out the Invention

[0020] Next, the principles of the present disclosure will be described with reference to some exemplary embodiments. These embodiments are described for illustrative purposes only and are intended to assist those skilled in the art in understanding and implementing the present disclosure, but it should be understood that they do not imply any limitation regarding the scope of the present disclosure. The disclosure described herein can be implemented in various ways other than those described below.

[0021] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0022] References in this disclosure such as “one embodiment,” “embodiment,” and “exemplary embodiment” indicate that the embodiments described may include certain features, structures, or characteristics, but not all embodiments are required to include such features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when certain features, structures, or characteristics are described in relation to one embodiment, it is understood that their influence on other embodiments, whether explicitly described or not, is within the knowledge of those skilled in the art.

[0023] The terms “first,” “second,” etc., may be used herein to describe various elements, but it should be understood that these elements should not be limited by these terms. These terms are used solely to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, the first element may be called the second element, and similarly, the second element may be called the first element. Where used herein, the term “and / or” includes any one or more of the enumerated terms and all combinations thereof.

[0024] The terms used herein are intended solely to describe specific embodiments and are not intended to limit the exemplary embodiments. Where used herein, the singular forms “a,” “an,” and “the” also include the plural form unless the context explicitly indicates otherwise. Furthermore, where used herein, the terms “comprises,” “comprising,” “has,” “having,” “includes,” and / or “including” specify the presence of the described features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. Where used herein, “at least one of the following <list of two or more elements>” and “at least one of the <list of two or more elements>” and similar phrases, where the lists of two or more elements are joined by “and” or “or,” mean at least one of the elements, or at least two or more of the elements, or at least all of the elements.

[0025] The term "circuit" as used in this application may refer to one, more, or all of the following: (a) Hardware-only circuit implementation (e.g., implementation using only analog and / or digital circuits), (b) A combination of hardware circuitry and software, for example (where applicable), (i) combinations of analog and / or digital hardware circuits and software / firmware, (ii) A part of a hardware processor in which software (including a digital signal processor), software, and one or more memories work together to enable a mobile phone or server or other device to perform various functions. (c) Hardware circuits and / or processors, such as microprocessors, that require software (e.g., firmware) for operation, but may not be present if the software is not required for operation.

[0026] This definition of circuit applies to all uses of the term in this application, including any claim. Further as an example, as used in this application, the term circuit also includes simply a hardware circuit or processor (or more processors), or a part of a hardware circuit or processor, and any implementation of its (or their) accompanying software and / or firmware. The term circuit also includes, for example, a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device, as applicable to an element of a particular claim.

[0027] As used herein, the term “communication network” refers to a network conforming to any appropriate communication standard, such as WLAN, Long-Term Evolution (LTE), LTE Advanced (LTE-A), Broadband Code Division Multiple Access (WCDMA®), High-Speed ​​Packet Access (HSPA), and Narrowband Internet of Things (NB-IoT). Furthermore, communication between terminal devices and network devices in a communication network may be performed in accordance with any appropriate generation communication protocol, including, but not limited to, first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, fifth-generation (5G), and future sixth-generation (6G) communication protocols, and / or any other protocols currently known or to be developed in the future, wireless local network communication protocols such as IEEE 802.11, and / or any other protocols currently known or to be developed in the future. Embodiments of this disclosure may be applied to a variety of communication systems. Given the rapid development of communications, there will naturally be future types of communication technologies and systems to which this disclosure may be realized. This should not be understood as limiting the scope of this disclosure to the aforementioned systems only.

[0028] As used herein, the term “network device” refers to a node in a communications network from which terminal devices access the network and receive services. Depending on the terminology and technology applied, a network device may refer to an access point (AP) or base station (BS), for example, a node B (NodeB or NB), an evolved node B (eNodeB or eNB), an NR NB (also called a gNB), a remote radio unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, and low-power nodes such as femto and pico. In the following description, the terms “network device,” “network (NW),” and “AP” may be used interchangeably.

[0029] The term "terminal device" refers to any end device that may be capable of wireless communication. Examples, though not limited to, terminal devices may also be called stations (STA), communication devices, user equipment (UE), subscriber stations (SS), portable subscriber stations, mobile stations (MS), or access terminals (AT). Terminal devices may include, but are not limited to, mobile phones, cellular phones, smartphones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices such as digital cameras, game terminal devices, music storage and playback devices, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop embedded devices (LMEs), USB dongles, smart devices, wireless customer premises equipment (CPEs), Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. In the following description, the terms “terminal device,” “communication device,” “terminal,” “user equipment,” “UE,” and “STA” may be used interchangeably.

[0030] As used herein, the term “AP device” may refer to any device for accessing a wired or wireless network. For example, a wired or wireless network may be a broadband network, the Internet, a local area network, a metropolitan area network, a mobile communications network, etc. For convenience, an AP device may also be referred to herein as an AP station or AP. An AP device may support, for example, the Wi-Fi protocol or any other known or future-developed similar protocol. For example, an AP device may be a wireless router, a terminal device with router functionality, a network device with router functionality, etc.

[0031] As used herein, the term “TXOP holder” may refer to a device that initiates a TXOP to communicate with other devices within that TXOP. For example, a device may sense a channel and acquire a TXOP in a listen-before-talk (LBT) procedure. A TXOP holder may also be called an initiating device. As used herein, the term “non-TXOP holder” may refer to a device that communicates with a TXOP holder or other devices within a TXOP initiated by a TXOP holder. A non-TXOP holder may also be called a responding device.

[0032] The functions described herein may, in various exemplary embodiments, be performed in fixed and / or wireless network nodes, but in other exemplary embodiments, the functions may be implemented in user equipment (such as a mobile phone or tablet computer or laptop computer or desktop computer or mobile IoT device or fixed IoT device). This user equipment may, for example, have corresponding capabilities as described in relation to fixed and / or wireless network nodes. The user equipment may be a control device, such as a chipset or processor, configured to control the user equipment when installed in the user equipment and / or within it. Examples of such functions include bootstrapping server functions and / or home subscriber servers, which may be implemented in the user equipment by providing the user equipment with software configured to cause the user equipment to perform these functions / nodes.

[0033] The principles and implementations of this disclosure will be described in detail below with reference to the drawings. Figure 1A shows an exemplary communication system 100 in which embodiments of this disclosure may be implemented. System 100 includes STA110 and AP120. System 100 may also include STA130. In some embodiments, STA110 may initiate TXOP to communicate with AP120. In this case, STA110 is a TXOP holder and AP120 is a non-TXOP holder. Alternatively, AP120 may be a TXOP holder and STA110 may be a non-TXOP holder.

[0034] The number of APs and STAs and their connections are for illustrative purposes only and should be understood as not to imply any limitation. System 100 may include any appropriate number of APs and STAs adapted to implement embodiments of the present disclosure.

[0035] Communication in communication system 100 may be implemented in accordance with any suitable communication protocol, including but not limited to, wireless local network communication protocols such as IEEE 802.11, cellular communication protocols, and / or any other protocols currently known or to be developed in the future. Furthermore, communication may utilize any suitable wireless communication technology, including but not limited to, code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), frequency division duplexing (FDD), time division duplexing (TDD), multiple input multiple output (MIMO), orthogonal frequency division multiple access (OFDM), discrete Fourier transform spread OFDM (DFT-s-OFDM), and / or any other technologies currently known or to be developed in the future.

[0036] Preemption solutions are being discussed to schedule low-latency data frame transmissions. One possible case is to preempt an ongoing transmission or TXOP by a non-TXOP holder, i.e., if a low-latency data frame is buffered by a non-TXOP holder, the low-latency data frame can be transmitted before the current TXOP finishes.

[0037] Figure 1B shows a schematic diagram illustrating a preemption case for low-latency data frame transmission. As shown in Figure 1B, a non-TXOP holder (i.e., AP) can transmit a low-latency data frame to another device (i.e., STA2) by preempting the current TXOP initiated by the TXOP holder (i.e., STA1).

[0038] For example, as shown in Figure 1B, STA1, as a TXOP holder, can send a Request to Send (RTS) frame 151 to AP, and AP may send a Permission to Send (CTS) frame 152 to STA1 in response. STA1 can then send a non-low latency data frame 153 to AP. Low latency data for STA2 may arrive at AP STA1 at time A while STA1 is sending the non-low latency data frame 153 to AP. To send the low latency data frame to STA2, AP may need to preempt the TXOP initiated by STA1. AP can terminate the transmission of the non-low latency data frame by sending a block acknowledgment (BA) frame 154 to STA1. AP can then send the low latency data frame 155 to STA2 within STA1's TXOP. Upon receiving the low latency data frame, STA2 may send a BA frame 156 to AP. STA1 may continue transmitting 157 non-low latency data frames to AP during the remaining time of STA1's TXOP.

[0039] In this case, the AP needs to schedule low-latency data frame transmissions by preempting ongoing transmissions or preempting TXOPs initiated by the STA. An unresolved issue regarding preemption behavior is that the STA may also buffer low-latency data frames for transmission within its TXOP, making the TXOP preemption proposal unfair and detrimental to the STA.

[0040] Figure 1C shows a schematic diagram illustrating the delay issues that can occur in the preemption case for low-latency data frame transmission. As shown in Figure 1C, when STA1 is sending a data frame to AP within its TXOP, the low-latency data frame is buffered at both AP and STA1. If AP interrupts an ongoing transmission from STA1 and uses STA1's TXOP to schedule a low-latency frame transmission 155 to STA2, and as a result STA1 is unable to send the low-latency data frame 158 to AP in time, a greater delay issue occurs in the low-latency data frame transmission to STA1.

[0041] Another unresolved issue is that an AP may not be permitted to preempt a TXOP initiated by another device for low-latency data frame transmission. For example, according to the European Telecommunications Standards Institute (ETSI) regulations concerning Responding Device Channel Access Mechanisms in the 5GHz unlicensed band, a responding device may transmit on the current operating channel for the remainder of the channel occupancy time (i.e., the TXOP) after receiving transmit permission from the relevant initiating device (i.e., the TXOP holder). This means that an AP must receive transmit permission from the STA for preemption in order to be able to schedule low-latency data frame transmission within a TXOP initiated by the STA. [Table 1]

[0042] In consideration of the above and other embodiments, some embodiments of the present disclosure provide a negotiation-based authorization solution for preemption operations within a TXOP. In this solution, a second device, acting as a non-TXOP holder, determines to preempt a TXOP initiated by a first device and sends a preemption request regarding the preemption of the TXOP to the first device. Upon receiving the preemption request, the first device, acting as a TXOP holder, determines whether to permit or deny the preemption of the TXOP and notifies the second device whether the preemption of the TXOP is permitted or denied. Depending on the actions performed by the first device, the second device determines whether the preemption of the TXOP is permitted or denied by the first device. By preempting a TXOP in a negotiation manner with the TXOP holder in this way, low-latency data frame transmission can be facilitated. Furthermore, this solution would be user-friendly for TXOP holders, as they can determine during the negotiation process whether preemption is permitted by considering certain conditions, such as their own data frame type / QoS.

[0043] Figure 2 shows an exemplary signaling chart illustrating an exemplary process 200 according to some embodiments of the present disclosure. Process 200 may include a first device 201 and a second device 202. The first device 201 may be a TXOP holder, for example, one of STA110 or AP120 as shown in Figure 1A. The second device 202 may be a non-TXOP holder, for example, the other of AP120 or STA110 as shown in Figure 1A.

[0044] Referring to Figure 2, a second device 202, which is a non-TXOP holder, may send instruction 211 to a first device 201, which is a TXOP holder (210). Instruction 211 may be used to configure the first device 201 to support negotiation regarding the preemption of a TXOP initiated by the first device 201. The first device 201 may receive instruction 211 (212).

[0045] As shown in Figure 2, the second device 202 determines to preempt the TXOP initiated by the first device 201 (213). The second device 202 then sends a preemption request 215 regarding the preemption of the TXOP to the first device 201 (214).

[0046] Upon receiving a preemption request 215 (216), the first device 201 determines whether to allow or deny the preemption of the TXOP (217), and then performs an action to notify the second device 202 whether the preemption of the TXOP is allowed or denied (218). Depending on the action performed by the first device 201, the second device 202 determines whether the preemption of the TXOP is allowed or denied by the first device 201 (219).

[0047] In some embodiments, the second device 202 may send a preemption request via an acknowledgment (ACK) frame (e.g., a BA frame) in response to a physical protocol data unit (PPDU) frame received from the first device 201 within TXOP. Alternatively, the second device 202 may also send a preemption request via a frame in a further link between the multilinks established between the first device 201 and the second device 202.

[0048] A preemption request may indicate at least one of the type information, priority information, or latency information of a data frame to be transmitted or received by the second device 202. The first device 201 may determine whether to allow or deny preemption of the TXOP depending on at least one of the type information, priority information, or latency information of the data frame indicated in the preemption request. Alternatively, the first device 201 may also determine whether to allow or deny preemption of the TXOP depending on at least one of the type information, priority information, or latency information of a data frame to be buffered in the first device 201.

[0049] In some embodiments, if low-latency data frames should be transmitted by the first device 201 within the TXOP, the first device 201 may determine to reject TXOP preemption. If there is no need for the first device 201 to transmit low-latency data frames within the TXOP, the first device 201 may determine to allow TXOP preemption.

[0050] To notify the second device 202 that TXOP preemption is permitted or denied, the first device 201 may send a preemption response to the preemption request to the second device.

[0051] If preemption is permitted, the first device 201 may terminate any ongoing transmissions within the TXOP. The second device 202 may perform data frame transmissions with the first device 201 or the third device within the TXOP. If preemption is denied, the first device 201 may continue any ongoing transmissions within the TXOP.

[0052] Instead of directly sending a preemption response, the first device 201 can implicitly notify the second device 202 that the TXOP preemption is permitted or denied. In this case, a time window may be established after the transmission of the preemption request. The time window may comprise at least one inter-frame space (IFS).

[0053] For example, if the first device 201 determines to allow preemption, it may terminate any ongoing transmissions within the TXOP without sending a preemption response to the second device and refrain from transmitting data during the time window. If the first device 201 determines to reject preemption, it may continue any ongoing transmissions after the time window.

[0054] On the second device side, the second device 202 may monitor data transmission from the first device 201 during the time window. If data transmission from the first device 201 is detected during the time window, the second device 202 determines that TXOP preemption has been denied. If no data transmission from the first device 201 is detected during the time window, the second device 202 determines that TXOP preemption has been permitted by the first device.

[0055] To monitor whether there is any data transmission from the first device 201 during a time window, the second device 202 may perform energy detection (ED) within the time window. For example, the second device 202 may detect energy within the time window and compare the detected energy to a threshold. If the detected energy level is lower than the ED threshold, the channel is considered idle and therefore permitted to transmit data to the second device 202. Alternatively, the second device 202 may perform signal detection within the time window. For example, the second device 202 may detect the preamble and / or MAC header to determine whether a data transmission is being performed by the first device 201.

[0056] If TXOP preemption is permitted, the second device 202 may perform data frame transmission with the first device 201 or the third device within the TXOP after the time window. Information regarding the time window may be predefined or preconfigured. Alternatively, the second device 202 may transmit information regarding the time window to the first device in the preemption request 215 or in instruction 211.

[0057] Using process 200, embodiments of the present disclosure provide a negotiation-based solution for preemption operations within a TXOP. The basic idea is that if a non-TXOP holder (e.g., a second device 202) needs to preempt the current TXOP for low-latency data frame transmission, it sends a preemption request to the TXOP holder (e.g., a first device 201). Upon receiving the preemption request, the TXOP holder can determine whether to allow the preemption operation based on several conditions, such as the data frame type and / or the QoS (e.g., priority, latency) of locally buffered data frames, and such conditions may be indicated in a preemption negotiation procedure.

[0058] If preemption is permitted, the TXOP holder, after receiving a preemption request from a non-TXOP holder, may respond with a preemption permission instruction and then implicitly or explicitly terminate any ongoing transmissions. Otherwise, the TXOP holder continues any ongoing transmissions with the remaining TXOPs.

[0059] If a non-TXOP holder implicitly or explicitly receives a preemption permission instruction, it can schedule low-latency data frame transmissions within the remaining TXOP. Otherwise, if the non-TXOP holder is a PPDU receiver, it will continue to receive transmissions from the TXOP holder.

[0060] In one embodiment, preemption request signaling may be delivered by a non-TXOP holder via a new field in a BA frame requested by the TXOP holder for the delivery of its aggregate MAC protocol data unit (a-MPDU), or via a frame (e.g., an action / control frame) in a further active link established between the non-TXOP holder and the TXOP holder for multi-link operation.

[0061] In another embodiment, the determination of preemption permission may be based at least on the fact that the TXOP holder does not intend to transmit low-latency data frames within the TXOP. Or, in addition, the determination of preemption permission may be based at least on the fact that preemption conditions set by a non-TXOP holder are met.

[0062] In further embodiments, a TXOP holder may implicitly or explicitly transmit a preemption grant instruction to a non-TXOP holder. For example, explicitly, a TXOP holder may transmit a preemption response carrying a preemption grant instruction via a frame (e.g., an action / control frame) in the current link or a further active link where the preemption request was received. Implicitly, it is assumed that a time window applies to the preemption grant operation. The time window may be configured after the transmission of the preemption request frame, and a non-TXOP holder may determine whether the TXOP holder grants the preemption operation based on the reception of data frame transmissions at least within the time window.

[0063] A time window may comprise at least one IFS. For example, in some embodiments, a time window may comprise two preemption-related inter-frame spaces (P-IFS), where the second P-IFS follows the first. A P-IFS can be any IFS defined in the 802.11 SPEC, such as Short Inter-frame Space (SIFS), Point Coordination Function (PIFS), Distributed Coordination Function (DIFS), Extended Inter-frame Space (EIFS), or any new IFS defined in future 802.11bn SPECs. A time window may be predefined, negotiated between TXOP and non-TXOP holders, or indicated via a preemption request or other signaling.

[0064] In this way, preempting the TXOP through a negotiation mechanism with the TXOP holder facilitates low-latency data frame transmission. Furthermore, this solution is TXOP holder-friendly, as the TXOP holder can determine whether preemption is permitted by considering several conditions. Note that the above process 200 is merely an example and may have additional or fewer operations. Note also that the operations of the above process 200 may be performed separately or in any appropriate combination.

[0065] Figure 3 shows an exemplary signaling chart of an exemplary explicit preemption authorization process 300 according to several embodiments of the present disclosure. Process 300 may be an example of process 200 shown in Figure 2. Process 300 may involve a first device 201 (i.e., a TXOP holder) and a second device 202 (i.e., a non-TXOP holder) as shown in Figure 2, and a third device 203. The third device 203 may be an STA that communicates with at least one of the first device 201 and the second device 202.

[0066] As shown in Figure 3, in 310, the TXOP holder may be set up or / configured by a non-TXOP holder to support preemption operations. In 311, the non-TXOP holder determines to send a preemption request to the TXOP holder if a low-latency data frame is being buffered in the non-TXOP holder. In one embodiment, the preemption request may further carry at least one of the buffered QoS data frame type information, priority information, and / or latency information.

[0067] In 312, the non-TXOP holder sends a preemption request to the TXOP holder via a new field in the ACK frame, such as a block ACK, a multi-traffic identifier (Multi-TID) block ACK, or a multi-STA block ACK frame, after the TXOP holder has sent the PPDU and requested an ACK frame from the non-TXOP holder. Alternatively, the non-TXOP holder may also send a preemption request to the TXOP holder via a frame in an additional active link set up between the non-TXOP holder and the TXOP holder for multilink operation (e.g., an action / control frame).

[0068] In 313, the TXOP holder determines whether to allow a preemption operation. The determination may be based on at least one of the type information, priority information, and / or latency information of the buffered QoS data frame at the non-TXOP holder as indicated in the preemption request. Alternatively, the determination may be based on at least one of the type information, priority information, and / or latency information of the buffered QoS data frame at the TXOP holder.

[0069] If the TXOP holder determines to allow the non-TXOP holder to preempt the current TXOP, the TXOP holder sends a preemption permission instruction to the non-TXOP holder via a frame (e.g., an action / control frame), as shown in 314. If the non-TXOP holder receives a preemption permission instruction from the TXOP holder, the non-TXOP holder sends a low-latency data frame within the remaining TXOP, as shown in 315. In one embodiment, the receiver of the low-latency data frame may be either the TXOP holder or a third device.

[0070] If the TXOP holder determines to allow the non-TXOP holder to preempt the current TXOP, it must terminate any ongoing transmissions, as shown in 316. If, in 317, the TXOP holder determines not to allow the non-TXOP holder to preempt the current TXOP (for example, to deny it), the TXOP holder continues any ongoing transmissions to the non-TXOP holder.

[0071] Using process 300, embodiments of the present disclosure provide negotiation-based explicit preemption permission. Low-latency data frame transmission can be facilitated by preempting the TXOP in a negotiation manner with the TXOP holder. Furthermore, this solution will be TXOP holder-friendly, as the TXOP holder can determine whether preemption operation is permitted by considering several conditions. Note that process 300 described above is merely an example and may have additional or fewer operations. Note also that the operations of process 300 described above may be performed separately or in any appropriate combination.

[0072] Figure 4 shows an exemplary signaling chart of an exemplary implicit preemption authorization process 400 according to several embodiments of the present disclosure. Process 400 may be an example of process 200 shown in Figure 2. Similar to Figure 3, process 400 may involve a first device 201 (i.e., a TXOP holder) and a second device 202 (i.e., a non-TXOP holder) as shown in Figure 2, and a third device 203. The third device 203 may be an STA that communicates with at least one of the first device 201 and the second device 202.

[0073] As shown in Figure 4, 410-413 are the same as 310-313 in Figure 3 and will not be repeated here. The difference is that a time window is applied to support implicit preemption permission, and information regarding the time window may be sent from a non-TXOP holder to a TXOP holder through configuration in 410 and / or a preemption request in 412. It should be understood that the time window may also be predefined or preconfigured, or configured by a device other than a non-TXOP holder.

[0074] Referring to Figure 4, if the TXOP holder determines to allow the non-TXOP holder to preempt the current TXOP, the TXOP holder terminates the ongoing transmission without sending a TXOP preemption response after receiving the TXOP preemption request, as shown in 414.

[0075] In 415, the non-TXOP holder monitors data transmissions from the TXOP holder during the time window. In one embodiment, the time window may comprise at least one IFS. For example, the time window may comprise two P-IFSs, the second P-IFS following the first P-IFS. In this scenario, the non-TXOP holder may monitor data transmissions from the TXOP holder during the second P-IFS.

[0076] In 416, if a non-TXOP holder does not detect a transmission from TXOP during a time window (e.g., between the second P-IFS), it immediately transmits a low-latency data frame within the remaining TXOP.

[0077] If the TXOP holder determines that it will not allow (for example, refuse) the non-TXOP holder to preempt the current TXOP, the TXOP holder will continue the transmission in progress from the first P-IFS onward, as shown in 417. At the same time, if the non-TXOP holder detects a transmission from the TXOP during the time window, and the non-TXOP is a PPDU receiver, it will continue to receive data transmissions from the TXOP holder.

[0078] Using process 400, embodiments of the present disclosure provide negotiation-based implicit preemption permission. Low-latency data frame transmission can be facilitated by preempting the TXOP in a negotiation manner with the TXOP holder. Furthermore, this solution will be TXOP holder-friendly, as the TXOP holder can determine whether preemption operation is permitted by considering several conditions. Note that process 400 described above is merely an example and may have additional or fewer operations. Note also that the operations of process 400 described above may be performed separately or in any appropriate combination.

[0079] An example of explicit preemption authorization is described in detail with reference to Figure 5. In the schematic diagram 500 shown in Figure 5, STA1 (e.g., the first device 201 shown in Figures 2-4) is a TXOP holder, and AP (e.g., the second device shown in Figures 2-4) and STA2 (e.g., the third device shown in Figures 3 and 4) are non-TXOP holders.

[0080] Referring to Figure 5, STA1 initiates a TXOP for communication with AP. STA1 sends an RTS frame 501 to AP, and AP may send a CTS frame 502 to STA1 in response. When the low-latency data frame arrives at AP at time A, AP sends a preemption request to the TXOP holder (STA1) via a new field in a BA frame 504, requested by a PPDU frame 503 sent from STA1.

[0081] Upon receiving a preemption request from the AP, STA1 determines to send a preemption response frame 505 to the AP carrying a preemption permission instruction, in which the AP is permitted to preempt the TXOP for low-latency traffic transmission. This determination may be made because STA1 does not have any low-latency data buffered. STA1 then terminates any ongoing non-low-latency data frame transmissions. The AP may then schedule a low-latency frame transmission 506 to STA2 with the remaining TXOP. After the low-latency frame transmission 506 is completed, STA2 may send a BA frame 507 to the AP.

[0082] Figure 6 shows a schematic diagram 600 illustrating an implicit preemption authorization procedure according to several embodiments of the present disclosure. In Figure 6, STA1 (e.g., the first device 201 shown in Figures 2-4) is a TXOP holder, and AP (e.g., the second device shown in Figures 2-4) and STA2 (e.g., the third device shown in Figures 3 and 4) are non-TXOP holders.

[0083] As shown in Figure 6, STA1 initiates a TXOP for communication with AP. STA1 sends an RTS frame 601 to AP, and AP can send a CTS frame 602 to STA1 in response. When the low-latency data frame arrives at time A in AP, AP finishes receiving the PPDU frame 603 from STA1 and then sends a preemption request to the TXOP holder (STA1) via a new field in a BA frame 604.

[0084] Figure 6(a) illustrates a scenario where a TXOP holder (STA1) does not allow a non-TXOP holder (AP) to preempt the current TXOP, and the TXOP holder may continue sending PPDU 605 after the time window. In this case, the time window is shown to include two IFSs, namely xIFS#1 and xIFS#2. It should be understood that the time window can include any appropriate number of IFSs or can be any appropriate duration to implicitly indicate whether to allow or deny preemption.

[0085] The AP monitors for data frame transmissions from STA1 during the time window. Since data frame transmissions from STA1 have already been detected during the second P-IFS, the AP assumes that STA1 has rejected the preemption request, and thereafter the AP continues to receive data frame transmissions from STA1.

[0086] Figure 6(b) shows that STA1 allows AP to preempt the current TXOP for a low-latency data frame transmission. In this case, STA1 terminates the ongoing transmission. Simultaneously, AP may not monitor data frame transmissions from STA1 during the time window. In this case, the time window is shown to include two IFSs, namely xIFS#1 and xIFS#2. Since no PPDU transmission from STA1 is detected in either xIFS#1 or xIFS#2, AP assumes that STA1 has permitted its preemption request, and then AP schedules a low-latency frame transmission 606 within the remaining TXOP after the time window. After the low-latency frame transmission 606 has finished, STA2 can send a BA frame 607 to AP.

[0087] Figure 7 shows a schematic diagram illustrating Method 700 as implemented in a first device according to some other embodiments of the present disclosure. For the purposes of discussion, Method 700 will be described in terms of a first device 201, for example, as shown in Figures 2-4. In some other embodiments, the first device 201 may also be STA1 in Figures 5-6.

[0088] As shown in Figure 7, in block 710, the first device 201 receives a preemption request from the second device 202 regarding the TXOP preemption initiated by the first device 201. In block 720, the first device 201 determines whether to allow or deny the TXOP preemption. In block 730, the first device 201 performs an action to notify the second device 202 whether the TXOP preemption is allowed or denied.

[0089] In some embodiments, before receiving a preemption request, the first device 201 may receive instructions to configure the first device 201 to support negotiation regarding TXOP preemption.

[0090] In some embodiments, the first device 201 may receive a preemption request via an ACK frame in response to a PPDU frame transmitted by the first device 201 within a TXOP. Alternatively, the first device 201 may also receive a preemption request via frames in further links between multiple links established between the first device 201 and the second device 202.

[0091] In some embodiments, the first device 201 may determine whether to allow or deny TXOP preemption based on at least one of the data frame type information, priority information, or latency information indicated in the preemption request. Alternatively, the first device 201 may also determine whether to allow or deny TXOP preemption based on at least one of the data frame type information, priority information, or latency information buffered in the first device 201.

[0092] In some embodiments, if low-latency data frames are to be transmitted by the first device 201 within the TXOP, the first device 201 may determine to reject preemption. Alternatively, if low-latency data frames are not to be transmitted by the first device 201 within the TXOP, the first device 201 may determine to allow preemption.

[0093] In some embodiments, the first device 201 may send a preemption response to the second device 202 to notify the second device 202 whether preemption of the TXOP is permitted or denied. If the first device 201 determines that preemption is permitted, it may terminate any ongoing transmissions within the TXOP. Alternatively, if the first device 201 determines that preemption is denied, it may continue any ongoing transmissions within the TXOP.

[0094] In some embodiments, the first device 201 may notify the second device 202 that TXOP preemption is permitted or denied by performing a transmission or refraining from transmitting data during a time window configured after the transmission of the preemption request. The time window may comprise at least one IFS.

[0095] In some embodiments, if the first device 201 determines to allow preemption, it may terminate the ongoing transmission within the TXOP without sending a preemption response to the second device 202, and refrain from transmitting data during the time window. If the first device 201 determines to reject preemption, it may continue the ongoing transmission after the time window.

[0096] In some embodiments, information regarding the time window may be predefined or preconfigured, or may be received from the second device 202 in a preemption request or instruction.

[0097] In some embodiments, the first device 201 is either an STA or an AP, and the second device 202 is the other of the STA or an AP.

[0098] Figure 8 shows a schematic diagram illustrating Method 800 as implemented in a second device according to some other embodiments of the present disclosure. For the purposes of discussion, Method 800 will be described in terms of a second device 202, for example, as shown in Figures 2-4. In some other embodiments, the second device 202 may also be the AP shown in Figures 5-6.

[0099] As shown in Figure 8, in block 810, the second device 202 determines to preempt the TXOP initiated by the first device 201. In block 820, the second device 202 sends a preemption request regarding the preemption of the TXOP to the first device 201. In block 830, depending on the action performed by the first device 201, the second device 202 determines whether the preemption of the TXOP is permitted or denied by the first device 201.

[0100] In some embodiments, before sending a preemption request, the second device 202 may send instructions to the first device 201 to configure the first device 201 to support negotiation regarding the preemption of the TXOP.

[0101] In some embodiments, the second device 202 may send a preemption request via an ACK frame in response to a PPDU frame received from the first device 201 within TXOP. Alternatively, the second device 202 may also send a preemption request via a frame on a further link between the multilinks established between the first device 201 and the second device 202.

[0102] In some embodiments, the preemption request may indicate at least one of the following: type information, priority information, or latency information for a data frame to be transmitted or received by the second device 202.

[0103] In some embodiments, the second device 202 may receive a preemption response to inform the second device 202 that TXOP preemption is permitted or denied. If TXOP preemption is permitted, the second device 202 may perform data frame transmission with the first device 201 or the third device within the TXOP.

[0104] In some embodiments, the second device 202 may be notified by an action performed by the first device 201 that TXOP preemption is permitted or denied. The action may include performing a transmission or refraining from transmitting data during a time window configured after the transmission of the preemption request. The time window may include at least one IFS.

[0105] In some embodiments, the second device 202 may monitor data transmissions from the first device during a time window. If data transmissions from the first device are detected during the time window, the second device 202 may determine that TXOP preemption has been denied. If no data transmissions from the first device are detected during the time window, the second device 202 may determine that TXOP preemption has been permitted.

[0106] In some embodiments, if TXOP preemption is permitted, the second device 202 may perform data frame transmission with the first device 201 or the third device within the TXOP after a time window.

[0107] In some embodiments, information regarding the time window may be predefined or preconfigured, or may be transmitted from the second device 202 to the first device 201 in a preemption request or instruction.

[0108] In some embodiments, the first device 201 is either an STA or an AP, and the second device is the other of the STA or AP.

[0109] In some embodiments, an apparatus capable of performing any of the methods 700 (e.g., the first device 201) may include means for performing each step of the method 700. The means can be implemented in any preferred form. For example, the means can be implemented in a circuit or a software module.

[0110] In some embodiments, the apparatus includes means for receiving a preemption request from a second device relating to the preemption of a transmission opportunity (TXOP) initiated by the first device; means for determining whether to permit or deny the preemption of the TXOP; and means for performing an action to notify the second device that the preemption of the TXOP is permitted or denied.

[0111] In some embodiments, the device further includes means for receiving instructions to configure the first device to support negotiation regarding the preemption of a TXOP before receiving a preemption request.

[0112] In some embodiments, means for receiving preemption requests include means for receiving preemption requests via acknowledgment (ACK) frames in response to physical protocol data unit (PPDU) frames transmitted by the first device within TXOP, or means for receiving preemption requests via frames in further links between a plurality of links established between the first device and the second device.

[0113] In some embodiments, means for determining whether to allow or deny TXOP preemption include means for determining whether to allow or deny TXOP preemption in accordance with at least one of the data frame type information, priority information, or latency information indicated in the preemption request, or at least one of the data frame type information, priority information, or latency information buffered in the first device.

[0114] In some embodiments, means for determining whether to allow or deny preemption of a TXOP includes means for determining whether to deny preemption in accordance with at least one of the following: determining that low-latency data frames are scheduled to be transmitted within the TXOP by a first device, or determining that preemption is permitted in accordance with determining that low-latency data frames are not scheduled to be transmitted within the TXOP by a first device.

[0115] In some embodiments, means for performing an action to notify a second device include means for sending a preemption response to the second device informing the second device that the preemption of the TXOP is permitted or denied.

[0116] In some embodiments, the device further includes means for terminating an ongoing transmission within the TXOP in response to determining that preemption is permitted, or means for continuing an ongoing transmission within the TXOP in response to determining that preemption is rejected.

[0117] In some embodiments, the operation includes performing a transmission or refraining from transmitting data during a time window configured after the transmission of a preemption request. In some embodiments, the time window includes at least one IFS.

[0118] In some embodiments, the means for performing an action to notify a second device includes, in response to determining that preemption is permitted, means for terminating an ongoing transmission within the TXOP without sending a preemption response to the second device, and means for refraining from transmitting data during a time window.

[0119] In some embodiments, the means for performing an action to notify a second device includes means for continuing an ongoing transmission after a time window, in response to determining that preemption is to be rejected.

[0120] In some embodiments, information regarding the time window is predefined or preconfigured, or received from a second device in a preemption request or instruction. In some embodiments, the first device is either an STA or an AP, and the second device is the other of the STA or AP.

[0121] In some embodiments, the apparatus further includes means for performing other steps in some embodiments of Method 700. In some embodiments, the means comprises at least one processor and at least one memory containing computer program code, the at least one memory and the computer program code being configured to cause the at least one processor to perform the operation of the apparatus.

[0122] In some embodiments, an apparatus capable of performing any of the methods 800 (e.g., a second device 202) may include means for performing each step of the method 800. The means can be implemented in any preferred form. For example, the means can be implemented in a circuit or a software module.

[0123] In some embodiments, the apparatus includes means for determining in a second device to preempt a transmission opportunity (TXOP) initiated by a first device; means for sending a preemption request relating to the preemption of the TXOP to the first device; and means for determining whether the first device is permitted or denied preemption of the TXOP depending on an operation performed by the first device.

[0124] In some embodiments, the apparatus further includes means for sending instructions to a first device to configure the first device to support negotiation regarding the preemption of a TXOP, before sending a preemption request.

[0125] In some embodiments, the means for transmitting a preemption request includes means for transmitting a preemption request via an ACK frame in response to a PPDU frame received from a first device within a TXOP, or means for transmitting a preemption request via a frame in a further link between a multilink established between the first device and the second device.

[0126] In some embodiments, the preemption request may indicate at least one of the following: type information, priority information, or latency information for a data frame to be transmitted or received by the second device.

[0127] In some embodiments, the device further includes means for receiving a preemption response that notifies a second device that preemption of the TXOP is permitted or denied.

[0128] In some embodiments, the device further includes means for performing data frame transmission with a first or third device within a TXOP, depending on whether it determines that preemption of the TXOP is permitted.

[0129] In some embodiments, the operation includes the first device performing a transmission or refraining from transmitting data during a time window configured after the transmission of a preemption request. In some embodiments, the time window includes at least one IFS.

[0130] In some embodiments, means for determining whether TXOP preemption is permitted or denied include means for determining that TXOP preemption is denied in response to detecting data transmission from a first device during a time window, or means for determining that TXOP preemption is permitted in response to not detecting data transmission from a first device during a time window.

[0131] In some embodiments, the device further includes means for performing data frame transmission with a first or third device within the TXOP after a time window, depending on the determination that preemption of the TXOP is permitted.

[0132] In some embodiments, information regarding the time window is predefined or preconfigured, or transmitted to the first device in a preemption request or instruction. In some embodiments, the first device is either an STA or an AP, and the second device is the other of the STA or AP.

[0133] In some embodiments, the apparatus further includes means for performing other steps in some embodiments of Method 800. In some embodiments, the means comprises at least one processor and at least one memory containing computer program code, wherein the at least one memory and the computer program code are configured to cause the at least one processor to perform the operation of the apparatus.

[0134] Figure 9 is a simplified block diagram of a device 900 suitable for carrying out embodiments of the present disclosure. The device 900 may be provided for implementing a communication device, for example, a first device 201 or a second device 202 as shown in Figures 2 to 4. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processors 910, and one or more communication modules 940 coupled to the processors 910.

[0135] The communication module 940 is for bidirectional communication. The communication module 940 has at least one antenna to facilitate communication. The communication interface may represent any interface necessary for communication with other network elements.

[0136] The processor 910 can be any type suitable for a local technology network and, in non-limiting examples, may include one or more of general-purpose computers, dedicated computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures. The device 900 may have multiple processors, such as application-specific integrated circuit chips that are temporally slaved to a clock that synchronizes the main processor.

[0137] Memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 924, electrically programmable read-only memory (EPROM), flash memory, hard disks, compact discs (CDs), digital video discs (DVDs), and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random-access memory (RAM) 922 and other volatile memories that do not persist during power-down periods.

[0138] The computer program 930 includes computer executable instructions that are executed by the associated processor 910. The program 930 may be stored in the ROM 920. The processor 910 can perform any appropriate actions and processes by loading the program 930 into the RAM 920.

[0139] Embodiments of the present disclosure may be implemented by program 930 such that device 900 can perform any process of the present disclosure, as discussed with reference to Figures 2 to 8. Embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0140] In some embodiments, the program 930 may be tangibly contained in a computer-readable medium which may be contained in device 900 (such as memory 920) or other storage devices accessible by device 900. Device 900 may load the program 930 from the computer-readable medium into RAM 922 for execution. The computer-readable medium may include any type of tangible non-volatile storage such as ROM, EPROM, flash memory, hard disk, CD, or DVD. Figure 10 shows an example of a computer-readable medium 1000 in the form of a CD or DVD. The computer-readable medium has the program 930 stored thereon.

[0141] In general, various embodiments of this disclosure may be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some embodiments may be implemented in hardware, while others may be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Various embodiments of this disclosure are illustrated and described using block diagrams, flowcharts, or some other pictorial representations, but it should be understood that any blocks, apparatus, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers, or other computing devices, or some combination thereof, as non-limiting examples.

[0142] This disclosure also provides at least one computer program product tangibly stored on a non-temporary computer-readable storage medium. The computer program product includes computer-executable instructions, such as those contained in a program module executed on a device on a target real or virtual processor to perform the methods 700 or 800 described above with reference to Figures 7 and 8. Generally, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform a particular task or implement a particular abstract data type. The functionality of the program modules may be combined or separated amongst the program modules, as desired in various embodiments. The machine-executable instructions for the program modules may be executed in local or distributed devices. In distributed devices, the program modules may reside on both local and remote storage media.

[0143] Program code for performing the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, a dedicated computer, or other programmable data processing device, so that when executed by the processor or controller, the program code implements the functions / operations specified in the flowcharts and / or block diagrams. The program code may run entirely on a machine, partially on a machine, as a standalone software package, partially on a machine, partially on a remote machine, or entirely on a remote machine or server.

[0144] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform various processes and operations as described above. Examples of carriers include signals, computer-readable media, and the like.

[0145] A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. More specific examples of computer-readable storage media include electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. As used herein, the term “non-temporary” refers to the medium itself (i.e., tangible rather than signal) and not to limitations on data storage persistence (e.g., RAM vs. ROM).

[0146] Furthermore, although the operations are presented in a specific order, this should not be understood as requiring that such operations be performed in a specific or sequential order, or that all presented operations be performed, in order to achieve a desired result. In some situations, multitasking and parallel processing may be advantageous. Similarly, while some specific implementation details are included in the above description, these should not be interpreted as limitations on the scope of this disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Some features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination.

[0147] While this disclosure is described in language specific to structural features and / or methodological actions, it should be understood that the disclosure as defined in the attached claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms of implementing the claims.

Claims

1. At least one processor, A first device comprising at least one memory for storing instructions, wherein when an instruction is executed by the at least one processor, the first device contains at least one memory for storing instructions. The steps include receiving a preemption request from a second device regarding the preemption of a transmission opportunity (TXOP) initiated by the first device, A step of determining whether to allow or deny the preemption of the TXOP, The first device is characterized by causing the first device to perform the step of performing an operation to notify the second device that the preemption of the TXOP is permitted or denied.

2. The first device further, The first device according to claim 1, characterized in that, before receiving the preemption request, it performs the step of receiving instructions to configure the first device to support negotiation regarding the preemption of the TXOP.

3. The first device is By receiving the preemption request via an acknowledgment (ACK) frame in response to a physical protocol data unit (PPDU) frame transmitted by the first device within the TXOP, or, By receiving the preemption request via a frame in a further link between a plurality of links established between the first device and the second device, The first device according to claim 1 or 2, characterized by performing the step of receiving the preemption request.

4. The first device is At least one of the data frame type information, priority information, or latency information indicated in the preemption request, At least one of the data frame type information, priority information, or latency information buffered in the first device, The first device according to claim 1 or 2, characterized in that it performs the step of determining whether to allow or deny the preemption of the TXOP depending on at least one of the following:

5. The first device is In determining that a low-latency data frame is scheduled to be transmitted by the first device within the TXOP, it is determined to reject the preemption, or In determining that low-latency data frames are not intended to be transmitted by the first device within the TXOP, it is determined to allow the preemption. The first device according to claim 1 or 2, characterized in that it performs the step of determining whether to allow or deny the preemption of the TXOP by at least one of the following:

6. The first device is By sending a preemption response to the second device and notifying the second device whether the preemption of the TXOP is permitted or denied, The first device according to claim 1 or 2, characterized by performing the step of performing an operation to notify the second device.

7. The first device further, In response to determining that the preemption is permitted, the steps include: terminating the transmission in progress within the TXOP, or The first device according to claim 6, characterized in that, in response to determining to reject the preemption, it performs the step of continuing the transmission in progress within the TXOP.

8. The first device according to claim 1 or 2, characterized in that the operation includes performing a transmission or refraining from transmitting data during a time window configured after the transmission of the preemption request.

9. The first device according to claim 8, characterized in that the time window includes at least one interframe space (IFS).

10. The first device is In response to determining that the preemption is permitted, the transmission in progress within the TXOP is terminated without sending a preemption response to the second device, and By refraining from transmitting data during the aforementioned time window, The first device according to claim 8, characterized in that it performs the step of performing the operation to notify the second device.

11. The first device is In response to determining that the aforementioned preemption is to be rejected, the transmission in progress after the aforementioned time window is continued. The first device according to claim 8, characterized in that it performs the step of performing the operation to notify the second device.

12. The first device according to claim 8, characterized in that the information regarding the time window is predefined or preconfigured, or received from the second device in the preemption request or instruction.

13. The first device according to claim 1 or 2, characterized in that the first device is either a station (STA) or an access point (AP), and the second device is either an STA or an AP.

14. At least one processor, A second device comprising at least one memory for storing instructions, wherein when an instruction is executed by the at least one processor, the second device contains at least one memory for storing instructions. A step of determining to preempt a transmission opportunity (TXOP) initiated by the first device, The steps include sending a preemption request regarding the preemption of the TXOP to the first device, A second device characterized by causing the first device to perform the step of determining whether the preemption of the TXOP is permitted or denied in response to an operation performed by the first device.

15. The first device receives a preemption request from a second device regarding the preemption of a transmission opportunity (TXOP) initiated by the first device. A step of determining whether to allow or deny the preemption of the TXOP, A method comprising the step of performing an action to notify the second device that the preemption of the TXOP is permitted or denied.

16. The second device determines to preempt the transmission opportunity (TXOP) initiated by the first device, The steps include sending a preemption request regarding the preemption of the TXOP to the first device, A method comprising the step of determining whether the preemption of the TXOP is permitted or denied by the first device in response to the operation performed by the first device.

Images