Lock mitigation in multi-link devices

Abstract

Methods and apparatuses are provided for controlling medium access in a wireless network. The wireless network can include a first device having a multi-link connection to a second device, the multi-link connection having a plurality of links. The method includes transmitting, by the first device, first messages to the second device on the plurality of links, each first message (RTS) indicating a reservation of at least a respective link for transmission by the first device, the message containing an indication of a duration of the reservation; waiting, by the first device, for a response message from the second device on at least one of the plurality of links for a first time period; after a second time period, transmitting, by the first device, at least one second message (NTS) on the at least one of the plurality of links, the at least one second message indicating a cancellation of the reservation for the at least one link, wherein the second message is transmitted in response to a response message sent by the second device in the first time period or in the event of a failure to receive a response message within the first time period.

Description

Technical Field

[0001] This invention relates to wireless networks, particularly local networks such as those using the IEEE 802.11 standard. Background Technology

[0002] Wireless networks are often extremely busy with numerous devices needing to transmit. This heavy occupancy of wireless media can lead to unacceptable delays or latency in some critical transmissions. In some networks, such as IEEE 802.11 (also known as 'Wi-Fi'), devices like access points (APs) can coordinate among themselves to improve media usage. Furthermore, many wireless networks overlap with and are subject to interference from other similar and different wireless networks.

[0003] This application claims priority to U.S. Provisional Applications US 63 / 548408, 63 / 557641 and 63 / 626551, the entire disclosure of which is incorporated herein by reference. Summary of the Invention

[0004] The inventors recognized that this problem is severe in networks using so-called multi-link devices (MLDs) due to the higher level of complexity—the increased need for coordination between devices. When both the AP and STA are MLDs, interference on one link, for example from another network (OBSS in the case of 802.11), can affect the other link, thus exacerbating the throughput loss problem.

[0005] Therefore, aspects, embodiments, and variations of the invention are defined in the appended claims.

[0006] This invention discloses a method for ensuring necessary link access for low-latency PPDUs while ensuring that the links are not blocked when not in use.

[0007] In the basic embodiment, a special message is transmitted to release unused links reserved by previous RTS or CTS messages. Upon receiving the message, nearby STAs can reset their NAV and treat the link as available. Other embodiments disclose further improvements to system reliability.

[0008] In one aspect, a method for controlling media access in a wireless network is provided, the wireless network including a first device having a multi-link connection to a second device, the multi-link connection having a plurality of links. The method includes: the first device transmitting first messages to the second device on the plurality of links, each first message (RTS) indicating a reservation for at least a corresponding link, the reservation being for a transmission performed by the first device, the message including an indication of the duration of the reservation; the first device waiting for a response message (CTS) from the second device on at least one of the plurality of links for a first time period; and after the second time period, the first device transmitting at least one second message (NTS) on at least one of the plurality of links, the at least one second message indicating cancellation of the reservation for the at least one link, wherein the second message (NTS) is sent in response to a response message sent by the second device during the first time period or in the event that a response message was not received during the first time period.

[0009] In one aspect, a method for controlling media access in a wireless network, the wireless network including a first device having a connection to a second device. The method includes: transmitting at least one first message from the first device to the second device, the at least one first message indicating a reservation for a transmission performed by the first device, the message including an indication of the duration of the reservation; waiting by the first device for a response message from the second device on at least one of a plurality of links for a first time period; after a second time period, transmitting at least one second message from the first device on at least one of the plurality of links, the second message indicating cancellation of the reservation for the at least one link; and after a third time period, transmitting at least one third message (NTR) from the second device, the second message indicating at least one of acknowledgment of the second message and cancellation of the reservation, wherein the second message is sent in response to a response message sent by the second device during the first time period or in the event that the response message was not received during the first time period, and the third message is sent in response to receiving either the second message or the first message.

[0010] In one embodiment, the method includes a second device transmitting a response message, including an acknowledgment of a first message, to a first device on at least one of a plurality of links.

[0011] In one embodiment, the response message also provides an indication of a reservation for at least a corresponding link for transmission by the first device, the message including an indication of the duration of the reservation.

[0012] In an embodiment, the response message additionally provides an indication that the first device should not use the link for transmission.

[0013] In one embodiment, the second device transmits a third message indicating confirmation of the second message to the first device on at least one of a plurality of links.

[0014] In an embodiment, the third message also indicates the cancellation of the reservation made by the response message.

[0015] In this embodiment, the first, second, and third messages contain a transaction identifier shared across multiple links.

[0016] In an embodiment, if the third device has recorded the reservation and blocked transmission from the third device, then the third device's receipt of either the second message or the third message causes the device to consider the reservation to be cancelled.

[0017] In one aspect, an apparatus is provided for communication in a wireless network, wherein the apparatus is arranged to communicate with a second device on a plurality of links, the apparatus being arranged to: transmit a first message to the second device on the plurality of links, each first message indicating a reservation for at least a corresponding link, the reservation being for transmission by the apparatus, the message including an indication of the duration of the reservation; wait for a response message from the second device on at least one of the plurality of links for a first time period; and after a second time period, transmit at least one second message on at least one of the plurality of links, the at least one second message indicating cancellation of the reservation for the at least one link, wherein the second message is sent in response to a response message sent by the second device during the first time period or in the event that the response message is not received during the first time period.

[0018] In one aspect, there is provided an apparatus arranged for communication in a wireless network, the apparatus being arranged to receive a first message from a first device, the message indicating a reservation for a transmission performed by the device, the message including an indication of the duration of the reservation, wherein the device (STA2) is arranged to perform at least one of the following: transmitting a third message (NTR) in response to the first message (RTS), and receiving a second message (NTS) after a waiting time has expired, the second message indicating cancellation of the reservation.

[0019] In one aspect, a device is provided for communication in a wireless network 1, the device being configured to: set a timer after receiving a first message (RTS), the first message being sent from a first STA (STA1) to a second STA (STA2), the first message (RTS) containing an indication of a reservation for transmission, the message containing an indication of a duration, the timer being set based on the duration, and having the effect of preventing transmission by the device (STA3) until the timer expires; and reset the timer in response to receiving a second message (NTS) or a third message (NTR), wherein the second message is sent from the first STA (STA1) to the second STA (STA2), and the third message is sent from the second STA (STA2) to the first STA (STA1).

[0020] In one aspect, a computer program product is provided that can be stored on a computer-readable medium and is configured to perform the methods disclosed herein when a computer is running. Attached Figure Description

[0021] This document describes examples of several embodiments of various embodiments of the present disclosure with reference to the accompanying drawings.

[0022] Figure 1 Indicates a wireless network;

[0023] Figure 2 express Figure 1 Frame (i.e., message) exchange in a wireless network;

[0024] Figure 3 shows the possible connections with Figure 2 Various problems that occur together with frame switching;

[0025] Figure 4 illustrates frame switching according to an embodiment;

[0026] Figure 5 This indicates frame switching using multiple links and potential problems;

[0027] Figure 6 This indicates frame switching based on an embodiment using multiple links;

[0028] Figure 7 This indicates frame switching on multiple links in parallel.

[0029] Figure 8 Represents various events in frame switching across multiple parallel links;

[0030] Figure 9a b represents frame switching on multiple links in parallel according to the embodiment;

[0031] Figure 10This indicates frame switching on multiple links in parallel according to an embodiment.

[0032] Figure 11 This indicates the frame structure according to the embodiment; Detailed Implementation

[0033] In the accompanying drawings, the same reference numerals designate the same elements.

[0034] In this disclosure, various embodiments are presented as examples of how the disclosed techniques and / or how the disclosed techniques can be practiced in environments and scenarios. It will be apparent to those skilled in the art that various changes in form and detail can be made without departing from the scope. After reading the specification, those skilled in the art will understand how to implement alternative embodiments. This embodiment is not limited to any of the described exemplary embodiments. Embodiments of this disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments can be combined to create further embodiments within the scope of this disclosure. Any drawings highlighting features and advantages are presented for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be used in ways other than those shown. For example, any actions listed in the flowcharts can be reordered or used only optionally in some embodiments.

[0035] The embodiments can be configured to operate as needed. The disclosed mechanisms can be executed when certain criteria are met, for example, in a station, access point, radio environment, network, or a combination thereof. Example criteria may be based at least in part on, for example, wireless device or network node configuration, traffic load, initial system settings, packet size, service characteristics, or a combination thereof. Various example embodiments can be applied when one or more criteria are met. Therefore, example embodiments that selectively implement the disclosed protocols can be implemented.

[0036] In this disclosure, “a” and “an” and similar phrases should be interpreted as “at least one” and “one or more”. Similarly, any term ending with the suffix “(s)” will be interpreted as “at least one” and “one or more”. In this disclosure, the term “may” should be interpreted as “may, for example,.” In other words, the term “may” indicates that the phrase following the term “may” is an example of one of a variety of suitable possibilities that may or may not be employed by one or more embodiments in various embodiments. As used herein, the terms “comprising” and “consisting of” enumerate one or more components of the described element. The term “comprising” is interchangeable with “including” and does not exclude the inclusion of unlisted components in the described element. In contrast, “consisting of” provides a complete enumeration of one or more components of the described element. As used herein, the term “based on” can be interpreted as “at least partially based on” rather than, for example, “based on only.” The term “and / or” as used herein refers to any possible combination of the enumerated elements. For example, “A, B and / or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C.

[0037] If A and B are sets and every element of A is an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1, STA2} are: {STA1}, {STA2}, and {STA1, STA2}. The phrase “based on” (or likewise “at least based on”) indicates that the phrase following the term “based on” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments. The phrase “in response to” (or likewise “at least in response to”) indicates that the phrase following the phrase “in response to” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments. The phrase “depends on” (or likewise “at least depends on”) indicates that the phrase following the phrase “depends on” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments. The phrase “adopts / uses” (or likewise “adopts / uses at least”) indicates that the phrase following the phrase “adopts / uses” is an example of one of a variety of suitable possibilities that may or may not be used in one or more embodiments in various embodiments.

[0038] The term "configured" can refer to the capacity of a device, regardless of whether the device is in an operational or non-operational state. "Configured" can also refer to specific settings within a device that affect its operational characteristics, regardless of whether the device is in an operational or non-operational state. In other words, hardware, software, firmware, registers, memory values, etc., can be "configured" within a device, regardless of whether the device is in an operational or non-operational state, to provide specific characteristics to the device. Terms such as "control messages generated in the device" can mean that control messages have parameters that can be used to configure specific characteristics or to perform certain actions within the device, regardless of whether the device is in an operational or non-operational state.

[0039] In this disclosure, a parameter (or equivalently referred to as a field or information element: IE) may include one or more information objects, and an information object may include one or more other objects. For example, if parameter (IE)N includes parameter (IE)M, and parameter (IE)M includes parameter (IE)K, and parameter (IE)K includes parameter (information element)J, then, for example, N includes K, and N includes J. In the example embodiments, when one or more messages / frames include multiple parameters, this means that a parameter among the multiple parameters is present in at least one of the one or more messages / frames, but not necessarily in every one of the one or more messages / frames.

[0040] Many of the features presented are described as optional using the word "may" or parentheses. For the sake of brevity and readability, this disclosure does not explicitly describe every permutation that can be obtained by selecting from the set of optional features. This disclosure will be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features can be embodied in seven ways: having only one of the three possible features, having any two of the three possible features, or having three of the three possible features.

[0041] Many of the elements described in the disclosed embodiments can be implemented as modules. A module is defined herein as an element that performs a defined function and has a defined interface to other elements. Modules described in this disclosure can be implemented in hardware, software combined with hardware, firmware, wet hardware (e.g., hardware with biological elements), or combinations thereof, and may be behaviorally equivalent. For example, a module can be implemented as a software routine written in a computer language configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program (such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript). Modules can be implemented using physical hardware that combines discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field-programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, and C++. FPGAs, ASICs, and CPLDs are typically programmed using a hardware description language (HDL) (e.g., VHSIC Hardware Description Language (VHDL) or Verilog), which configures the connections between internal hardware modules with a limited set of functions on the programmable device. The techniques mentioned are often used in combination to implement the result of functional modules.

[0042] Wireless networks are expected to handle low-latency services. The currently developing IEEE 802.11bn standard has this objective. Such services may be characterized by the presence of PPDUs that need to be delivered urgently within short latency limits, which may therefore need to preempt or take precedence over services with longer latency limits or no latency limits. This disclosure is described in context and uses terminology from the IEEE 802.11 standard. Those skilled in the art will be able to apply the teachings to other types of wireless networks.

[0043] In a typical single-link setup in a wireless network, the first device or STA (STA1) can send a Ready to Transmit (RTS) message to indicate the availability and quantity of low-latency data to the second device (STA2). Upon reception, STA2 responds with a Clear to Transmit (CTS) message indicating that it is ready to receive low-latency data, and STA1 can then transmit a low-latency PPDU in an agreed-upon time frame.

[0044] If the RTS / CTS exchange fails, STA1 can retransmit the RTS after determining that it did not receive the CTS in the expected time frame, hoping to get a better result.

[0045] To mitigate RTS / CTS failures, a STA that hears an RTS that is not the intended recipient should avoid transmitting during the interval of the expected CTS response. STA1 should also ensure the channel is idle before sending the initial RTS via a listen-before-speak procedure. However, it may fail to detect transmissions from “hidden nodes,” such as STAs in neighboring networks (so-called “overlapping basic service sets” (OBSS)) that are preventing STA2 from receiving RTSs.

[0046] The requirement to wait a certain amount of time before resending the RTS imposes a time penalty and risks that low-latency data may be delivered too late to be usable.

[0047] The network can also utilize multi-link operation, and (MLO)-IEEE 802.11bn also has specifications for this as a target. This allows STA1 and STA2 to select from multiple links to exchange data. Multiple links may include, for example, multiple channels within a frequency band or across more than one frequency band, or spatially separated links if the STA has more than one physically separate transceiver or antenna array. Multiple links can be used to mitigate the loss of RTS frames due to hidden node transmissions by allowing STA1 to transmit RTS messages substantially in parallel across multiple links. In one embodiment, STA2, receiving an RTS message on one or more links, selects a single such link on which to return a CTS. In STA1, the link used to receive the CTS is used to transmit low-latency data PPDUs. To further mitigate the failure of STA1 to receive a CTS, STA2 returns a CTS on more than one link (possibly on each link on which it receives an RTS). From the received CTS message, STA1 selects one or more links on which to transmit low-latency PPDUs.

[0048] The transmission of multiple parallel RTS messages can encounter problems. One aspect of an RTS message is an indication of the expected location of a PPDU transmission in terms of time and duration. Other STAs receiving the RTS message expect to treat this time and duration as reserved and accordingly set their Network Allocation Vector (NAV) to prevent transmission during that interval. When an RTS message is sent on multiple links, an NAV is set for each link. If STA1 uses only one link to send data, the other links are still blocked from transmission for other STAs. Furthermore, if the RTS / CTS exchange fails, the STA may have already set its NAV for all relevant links—such an STA may not be in a position to receive a CTS, so it cannot be assumed that detecting an RTS without a corresponding CTS means failure. Similarly, a third STA may only hear a CTS without a corresponding RTS.

[0049] In this embodiment, the STA is configured to maintain the NAV for each link, meaning that the NAV of a link can be set / reset separately from the NAV of another link. A similar issue exists when STA2 responds in CTS mode on multiple links.

[0050] In IEEE 802.11, RTS (Ready to Send) ([1], 9.3.1.2) and CTS (Clear to Send) ([1], 9.3.1.3) frames can be exchanged by STAs as part of a virtual CS (Carrier Sense) mechanism. Each frame includes a duration field that indicates the time period for which medium should be reserved for the transmission of data frames and the return Ack frame. Each frame also includes a receiver address (RA) field, which is the MAC address of the intended destination STA, and in the case of RTS instead of CTS, a transmitter (i.e., sender) address (TA) field, which is the MAC address of the transmitting STA.

[0051] In basic operation, the first transmitting STA STA1, which wants to send a data frame to the second receiving STA STA STA2, sends an RTS frame, in which the RA field is set to the address of STA2, the TA field is set to its own address, and the duration field is set to the following number of microseconds: in response to receiving a CTS frame, transmitting a data frame and receiving an ACK frame plus the SIFS period before each frame.

[0052] When receiving an RTS frame that has its own address in the receiver address field, STA2 responds with a CTS frame addressed to STA1 after a SIFS period, wherein the duration field is set to the required number of microseconds: the number of microseconds between receiving the data frame and transmitting the ACK frame plus the SIFS period preceding each frame.

[0053] After receiving the CTS response, STA1 transmits the data frame to STA2 after one SIFS period and waits for an ACK frame in response. Upon successful reception of the data frame, STA2 transmits an ACK frame to notify STA1 that the data frame has been successfully received.

[0054] In the accompanying figures, solid-lined bounding boxes indicate frames successfully transmitted by the source and received by the intended destination. Dashed-lined bounding boxes indicate frames that were transmitted but not received. Unmarked (empty) boxes with dashed lines indicate points in a sequence where a frame was expected by the intended destination but was not transmitted by the source.

[0055] Figure 1This represents wireless network 1, where a first STA (STA1) communicates with a second STA2 – indicated by the solid line between them. One or more third STAs (STA3) are within range of receiving messages from either or both of STA1 and STA2 – indicated by the dashed lines between them and STA1 and / or STA2. Importantly, a given STA3 may only be able to detect messages from one of STA1 and STA2, but not the other. Besides the issue of reception range, it should be noted that the ability of a given STA3 to detect messages relayed between STA1 and STA2 can be affected by other factors, such as interference from other networks.

[0056] Figure 2 This indicates the message exchange between STA1 and STA2, and the behavior of STA3. In this example, the data frame is preceded by an announcement / request from STA1 and an acknowledgment / acceptance from STA2. This specific representation is based on [1]. Figure 10 Section 6 illustrates an example of RTS / CTS operation—other wireless network types have similar protocols. Typically, STA1 can choose whether to request acknowledgment for the transmitted data. When requested, STA2 sends an ACK frame upon successful reception of the data frame. If STA1 does not receive an ACK frame from STA2 as expected, it can choose to repeat the entire process or discard the data frame. For the embodiments described herein, acknowledgment is assumed to be used; however, it should be understood that the disclosed method is equally applicable when acknowledgment is not used.

[0057] Propagation and interference issues may mean that STA2 may not receive RTS frames due to interference, for example, from another STA hidden from STA1. Alternatively, interference may cause STA1 to miss a CTS frame sent from STA2 in response. In both cases, if STA1 does not receive a CTS response that begins within the SIFS period, it should assume that the RTS transmission has failed and should not send a data frame. It may send a new RTS frame as part of a new attempt to transmit a data frame, or it may abandon the transmission of a data frame altogether.

[0058] One or more third STAs (STA3) may exist and be within the scope of STA1 and / or STA2, as illustrated in Figure 3. STA3 can be understood as representing one or more STAs - where the singular is used in this document for STA3, and the plural can be understood.

[0059] STA3, receiving an RTS frame from STA1 and / or a CTS frame from STA2, intends to avoid transmission for a period reserved by the duration field by updating a timer called its Network Allocation Vector (NAV). The NAV is first set by receiving an RTS (which may contain information about how long the NAV should be set, such as the duration of the PHY data unit), and then adjusted to include any ACK frames that STA2 might transmit. Until its NAV expires, STA3 considers the medium busy and does not attempt to transmit.

[0060] The problem is the expected behavior of STA3 upon receiving a reserved RTS frame instead of its corresponding CTS frame. On the one hand, no CTS frame might be sent; on the other hand, the CTS frame might be sent but not received by the third STA. In the former case, the reservation made by the RTS frame is invalid, and the reserved link resources can be used by other STAs instead. In the latter case, the reservation is valid, and the reserved link resources should not be used by other STAs. Since STA3 cannot determine why it did not receive the CTS frame, the safest course of action would be to assume the reservation remains valid and avoid transmitting on the reserved link resources.

[0061] A similar issue arises from the expected behavior of a third STA that receives a CTS frame confirming the reservation instead of the corresponding previous RTS. In this case, since the CTS frame confirms the reservation, the third STA can more easily assume that the reservation is valid.

[0062] If STA1 does not receive a CTS frame and chooses to abandon its attempt to send a data frame, STA3 that receives the original RTS frame and / or response CTS frame sent by STA2 but not received by STA1 may be blocked from using link resources because its NAV has not been updated to account for the abandonment of data transmission.

[0063] The object of this invention is to provide a means to minimize blocking problems. Another object of this invention is to extend the means to make full use of the link diversity available in multi-link operation (MLO) while minimizing the cost of other STAs.

[0064] Although the present invention has been described using the IEEE 802.11 protocol, it will be clear that the same principles can be applied to other systems, including but not limited to 802.15.4, 802.11, 3GPP 4G, 5G, and systems that typically manage shared resources in a distributed manner.

[0065] In one embodiment, a special message is transmitted to release unused links reserved by a previous RTS or CTS message. Upon receiving the message, nearby STAs can reset their NAV and treat the link as available. Other embodiments disclose further improvements to system reliability.

[0066] Figure 3a It is shown in a more compact format. Figure 2 The process is illustrated below. STA1 sends an RTS frame to STA2, with its Reserved Duration field indicating the time period required for transmitting data frames and associated control frames. STA3, which detects the RTS frame, reserves time by setting its NAV to the indicated duration. STA2 responds with a CTS frame acknowledging the reservation, where the Duration field is updated to reflect the passage of the SIFS inter-frame period and the duration of the CTS frame itself. STA3, which detects this frame but not the RTS frame, reserves time by setting its NAV according to the duration expressed in the CTS frame. Upon receiving the CTS frame, STA1 transmits a data frame without interference from STA3. Upon successfully receiving the data frame, STA2 sends an ACK frame to STA1 acknowledging this. At this point, the data transmission process is closed, and the NAV field of the nearby STA3 is released from reservation.

[0067] exist Figure 3b In this scenario, the ACK frame sent by STA2 is not received by STA1 (equivalently, STA2 fails to receive the data frame correctly and does not send an ACK frame). However, since the reservation in STA3's NAV field has reached its end, STA1 cannot simply retransmit the data frame; instead, it must restart the entire process by issuing an RTS to make another reservation, which will prevent STA3 from accessing the medium for an extended period.

[0068] Figure 3c The illustration shows an example of a problem caused by a failure during RTS-CTS exchange. STA2 responds to an RTS frame from STA1, but its transmitted CTS frame is not received by STA1. Therefore, STA1 does not transmit a data frame. In some cases, STA1 can restart the process by retransmitting the RTS, such as... Figure 3d As shown. In other cases, such as after a continued failure to receive CTS frames, STA1 may choose to abandon the process. In this case, STA3's NAV continues to reserve time that is not currently being used and is prevented from using the medium for its own transmission.

[0069] Do not send any thing frames and do not receive any thing frames.

[0070] Figures 4a to 4dThis describes the operation of an embodiment utilizing two new frames: a No-Send (NTS) frame, which includes the transmitter address (TA), receiver address (TA), and serves as an indication that an active reservation confirmed by a previous RTS frame has been released; and a No-Receive (NTR) frame, which includes the receiver address (RA) and, in variations, the transmitter address, and serves as an indication that an active reservation confirmed by a previous CTS frame has been released. The phrase "release" or "cancel" reservation should be understood to include shortening or truncating the reservation, thereby eliminating the need for other stations that are suppressing its transmission to remove that suppression. In the case of IEEE 802.11, this could correspond to truncating or releasing a TXOP.

[0071] NTS frames can be implemented as purpose-defined frames, or they can be implemented by existing frame types with special values, such as RTS frames with the duration field set to zero or another appropriate value (e.g., inter-frame interval), or CF-End frames with the duration field set to zero or an appropriate value. Similarly, NTR frames can be implemented as purpose-defined frames, CTS frames with the duration field set to zero, etc.

[0072] Figure 4a The first embodiment illustrated in STA1, when choosing to abandon the transmission of a data frame, releases the reservation made by its previous RTS frame by transmitting a corresponding No Send Anything (NTS) frame. This NTS frame includes its address as TA, and STA2's address as RA, both based on the previous RTS frame, along with an indication that the active reservation corresponding to these two addresses has been released. STA3 handles cases where NAVs are set by more than one STA. In an extension of the first embodiment, upon receiving an RTS frame and responding with a CTS frame but receiving an NTS frame from STA1, STA2 releases the reservation made by its previous CTS frame by transmitting a corresponding No Receive Anything (NTR) frame, with STA1's address as RA, and in variations including its own address as TA, and serving as an indication that the active reservation corresponding to these two addresses (e.g., TXOP) has been released. The NTR frame has a primary purpose: acknowledgment of the NTS frame.

[0073] Figure 4bAn error condition is illustrated where a CTS frame from STA2 is not received by STA1, and STA1 appropriately sends a frame to cancel the reservation acknowledged by the CTS frame—represented here by an NTS frame (although another frame with the effect of canceling the reservation / TXOP can be envisioned). The inventors have recognized that simply having STA1 send a frame (e.g., an NTS frame) to cancel leaves a problem where the reservation cancellation frame (e.g., the NTS) might not be received by STA2, and therefore it will not cancel the reservation made by its CTS frame. The same applies in the case where STA3 does not receive the reservation cancellation—even if it could, it would not reset its NAV.

[0074] Figure 4c It shows Figure 4b A possible solution to the error condition is that STA2 sends an NTR frame when it does not receive any response to its CTS frame. The inventors have recognized a potential problem where STA1 may have already received the CTS frame and is transmitting a data frame—it would be inappropriate for STA2 to release a reservation for another STA, as it would still be in use by STA1. To determine the actual situation, STA2 can perform an Energy Detection (ED) procedure to determine if a transmission is in progress; if not, it can send an NTR message to release the reservation. The use of NTR frames provides the advantage of cancelling reservations for STA3, which is capable of detecting frames from STA2 rather than STA1 (such as in...). Figure 4b (as indicated in the text). Therefore, the NTR frame has the secondary purpose of allowing STA2 to cancel the reservation when it detects that the medium is not actually being used.

[0075] Figure 4d This illustrates an example where STA2 does not see the initial RTS frame. STA1, without detecting a CTS frame, sends an NTS that STA2 did receive. Although no CTS frame was sent, STA2 can still send an NTR frame instead of an NTS frame to help any STA3 that heard the RTS frame. This NTR frame includes its address as TA, STA1's address as RA, where STA1's address is taken from the received NTS frame, and an indication that any active reservations corresponding to these two addresses are released. Advantageously, STA3 should accept both NTS and NTR frames when releasing a reservation, regardless of whether it used RTS or CTS to establish the reservation. All STAs should gracefully handle unexpected (i.e., no earlier corresponding RTS or CTS frame received) NTS or NTR frames—in other words, cancel the reservation corresponding to the RTS and CTS frames sent by STA1 and STA2 (e.g., reset its NAV), or ignore it if no such reservation was set.

[0076] Multi-link operation (MLO)

[0077] Multilink diversity (MLO) provides potential mitigation for transmission failures on a single link by allowing STA1 and STA2 to operate on one or more secondary links. Generally, if the quality of each link is independent of the others, the probability of all links being interfered with at any given time is lower than the probability of any single link being interfered with. Therefore, by utilizing this link diversity, STA1 and STA2 can potentially provide better service for low-latency traffic.

[0078] In the following general description of the data transmission procedure using MLO, STA1 wants to send a data frame to STA2. RTS, CTS, and ACK frames, as well as data frames, are assumed to be sent using the RA and (for frames carrying them) TA fields described above. On any given link, STA3 can hear some or all of the exchanges between STA1 and STA2 and must process the frames to the extent that it can determine the expected duration of the data frame transmission and reserve the link by updating its Network Allocation Vector (NAV) accordingly.

[0079] The precise operation of multiple links can depend on several factors, including the capabilities of STA1 and STA2, network policies, appropriate strategies at each point in STA1 and STA2, or dynamic information including channel quality measurements, the urgency and / or importance of the data being transmitted, recent history of successful data transmission, or other aspects. An exemplary sequence of steps is described below.

[0080] MLO sequential operations

[0081] Figure 5 An example of MLO (Multiple-Transmission Optimization) is shown where STA1, operating sequentially, can transmit an RTS (Redirecting Time Frame) on the first link and wait for a CTS (Content Response Frame) in response. If no such frame is received within the expected time window, STA1 can abandon the attempt to transmit data on the first link due to a transmission error or because STA2 did not send a CTS frame, and attempt to transmit on the second link, sending a new RTS frame and waiting for a response. If no response is still received, STA1 can try the third link, and so on, until it receives a CTS frame in response and successfully transmits a data frame, or it completely abandons the attempt to transmit a data frame.

[0082] STA1 attempts to transmit a data frame on link 0 by sending an RTS frame to STA2. STA3 has detected the RTS and sets its NAV for link 0 accordingly. On link 2, STA3 has detected the RTS instead of the CTS and sets its NAV to 53 accordingly. Because STA2 did not respond with a CTS frame 50 in the expected time frame, STA1 makes a second attempt on link 2, where STA2 does respond with a CTS frame, but this is not received by STA1. STA3 has detected the RTS and adjusted its NAV. However, STA1 does not send a data frame 54 because it did not receive the CTS, but STA3, having received the CTS but not the RTS, has set its NAV and avoids attempting to use the medium. STA1 then makes a final attempt on link 5. STA2 has not yet received the expected data frame 54 on link 2, but eventually receives the RTS frame on link 5. It responds with a CTS frame successfully received by STA1. STA1 then sends a data frame DATA, and STA2 sends an acknowledgment ACK.

[0083] In STA3, the detection RTS and CTS frames set their NAVs to allow the expected data frame transmission, but in links 0 and 2, these NAVs are not released when no transmission is taking place and the link is abandoned.

[0084] The “ghosting” RTS frames 51, 55, and STS frame 52 indicate the timing at which they have been transmitted. As can be seen, STA1, having failed to arrive on link 2, must wait until some time after CTS (indicated by the vertical line) in order to begin using RTS on link 5. Meanwhile, this is the start of the timer, and it has already transmitted data frame 54.

[0085] It is clear that since STA1’s attempt has failed, a considerable amount of time has been lost in the process of achieving transmission, and STA3 has been prevented from accessing the medium during its possible time period.

[0086] Figure 6 An example of operation with an embodiment having MLO is shown. STA1 and STA2 transmit NTS and NTR frames respectively to release reservations made by previous RTS and CTS frames on links 0 and 2. Upon receiving these frames, STA3 can reset its NAV accordingly on links 0 and 2. (As shown by...) Figure 5 As can be seen from the comparison, canceling (or shortening) the reservations of these links for STA3 (in the case of IEEE 802.11, STA3 resets its NAV) has the advantage that these links are freed up for transmission, resulting in generally lower latency and more efficient use of media.

[0087] MLO parallel operation

[0088] The time spent on each unsuccessful attempt can be significant for very low latency data. Advantageously, STA1 and STA2 can then operate simultaneously on multiple links to take advantage of the redundancy inherent in parallel operation. In the second approach, STA1 can transmit RTS frames substantially simultaneously on more than one link of its selection. STA2 can respond simultaneously on any link in which it receives RTS frames, selecting links based on, for example, link quality assessment or the availability of the links for the duration required to transmit the data frames, and issuing a CTS message on each selected link. STA1 can simultaneously transmit data frames on any link in which it receives CTS frames, again selecting links based on, for example, link quality assessment. Finally, if requested, STA2 can respond simultaneously with an acknowledgment (ACK) frame on any link in which it receives data frames, noting that it is sufficient for STA1 to receive a single ACK on any link.

[0089] Figure 7 The diagram illustrates a possible arrangement for sending data frames in parallel across all links. This is an extreme form of redundancy that may not always be efficient or necessary. Instead, RTS / CTS dialogue can be used to negotiate a smaller number of links by allowing each side to determine the optimal quality link based on some quality criteria.

[0090] In the first step, STA1 can determine the number of links to use from the complete set of available links, thus forming a first subset that includes at least one, more than one, or all links, and select the best link based on, for example, a quality factor assigned to each link. Then, STA1 sends RTS frames, including reserved durations for STA2, to STA2 substantially simultaneously on all links in the first subset.

[0091] In the second step, when RTS frames with identical parameters are received on multiple links, STA2 can determine the number of links on which to transmit CTS frames as an acknowledgment, thus forming a second subset comprising at least one, more than one, or all links, selected optimally based on certain criteria (e.g., the received signal strength and / or predetermined quality factor of the RTS frames received on each link). STA2 then returns a CTS frame as an acknowledgment to STA1 substantially simultaneously on each link in the second subset, the CTS frame including the same reserved duration (updated to remove the SIFS period and the time for transmitting the CTS).

[0092] In the third step, upon receiving CTS frames with the same parameters reserved in the first step on multiple links, STA1 can determine the number of links on which to transmit data frames, thus forming a third subset comprising at least one, more than one, or all links, selected optimally based on, for example, the received signal strength of the CTS frames received on each link and / or a predetermined (but potentially updated) quality factor. STA1 then transmits data frames, including payload data, substantially simultaneously on each link of the third subset. Finally, in the fourth step, if STA2 successfully receives a data frame on any link, it transmits an ACK frame on at least one such link. To utilize the redundancy provided by the parallel links, it can transmit ACKs on all links on which it detects data frame transmission, even if a data frame was not successfully received on that link.

[0093] Select the preferred link

[0094] Figure 8 The illustration shows an example of the steps involved in selecting a subset (in this case, a single link) of preferred links for data frame transmission from a set of eight links chosen by STA1. STA1 simultaneously transmits RTS frames on all links in the set. STA2 selects a subset (0, 1, 2, 5, and 7 in this example) based on some quality criteria and returns CTS frames on these links. Upon receiving a CTS frame, STA1 determines link 5 as the optimal link based on some quality criteria and transmits a data frame on that link, receiving an ACK frame from STA2. In a variant, STA1 can select two or more links on which to transmit data frames.

[0095] On each link, the STA3 receiving RTS and / or CTS frames reads the duration field and reserves the link by updating its Network Allocation Vector (NAV) accordingly. The inventors have recognized that careless use of multiple links can exacerbate the blocking problem discussed earlier, because while reservations may be made on several links, not all of these reservations will actually be used to transmit data frames.

[0096] In this example, seven out of eight frames are discarded, but the STA3 NAV is not updated to reflect this. This means that those STA3s are prevented from using the discarded links for their own communication. The inventors have recognized that this selection process is as inefficient as a parallel process that uses all available links to transmit data frames.

[0097] Link subset selection using NTS / NTR

[0098] Figure 9a and 9bAn exemplary operation according to an embodiment is illustrated, wherein the previously described NTS and NTR frames are used to release unused reservations on abandoned links. As previously stated, STA1 simultaneously transmits RTS frames on all links in a set selected by STA1. STA2 selects a subset (0, 1, 2, 4, 5, and 7) based on some quality criteria and returns CTS frames on these links. Upon receiving a CTS frame, STA1 determines link 5 as the optimal link based on some quality criteria and transmits a data frame on that link, receiving an ACK frame from STA2.

[0099] Transmission of data frames on other links is hampered by various events, many of which can be mitigated by NTS and NTR frames. Typically, an NTS can be used to release a NAV set by an RTS on STA3 within the range of STA1, while an NTR can be used to release a NAV set by a CTS on STA3 within the range of STA2 (but not STA1). However, in variations where both the NTS and NTR carry transmitter and receiver addresses, STA3 can use either frame to release the associated NAV reservation. This is explicit in some examples and should be assumed to be implicit in others.

[0100] Link 0 is illustrated in the diagram, where STA1 decides it no longer wishes to use Link 0 and notifies STA2 by sending an NTS frame. The receiving STA3, which also receives the original RTS (and CTS) frames, can update its NAV to release the reservation made by the RTS. STA2 responds with an NTR that acknowledges STA1's NTS frame and releases the NAV reserved by STA3 that missed the NTS message.

[0101] Link 1 illustrates a variation where STA1 does not receive a CTS message from STA2. STA1 issues an NTS in response to release the reservation, and STA2 acknowledges it using an NTR.

[0102] Link 2 illustrates another variation where STA1 issues an NTS to indicate it no longer intends to use Link 2. STA2 does not receive this and, while performing an energy check and finding an unoccupied link (e.g., via the expected data transmission), can issue an NTR to release any unclaimed NAV reservations of STA3. This demonstrates that an NTR can be sent when an NTS is expected but not received. Note that, as shown, for example, some STA3s that set their NAV according to the RTS may also not receive the NTS if, for example, the NTS is subjected to a noise burst. In this case, an NTR would also be sufficient to release the NAV reservations of these STA3s.

[0103] On link 3, an RTS frame from STA1 is not received by STA2, and STA2 does not send a CTS in response. Similar to link 1, the STA responds to the absence of the expected CTS message by sending an NTS, which is acknowledged by STA2 with an NTR frame. As shown by the dashed outline, CTS should not set a NAV, but NTR can still play a role in releasing a NAV set by RTS.

[0104] On link 4, STA1 did not receive the NTR frame from STA2. STA1 can choose to retransmit the NTS in the hope of receiving the NTR in a subsequent attempt. If STA3 also misses the first NTR, this gives them an additional opportunity to release the reservation made by the CTS, as shown by the dashed portion of the NAV(CTS). In principle, STA1 can repeat this operation until it receives the NTR. In practice, there will be a practical limit to the number of times this will be useful.

[0105] Link 6 illustrates an instance where STA2 explicitly rejects STA1's RTS overflow by returning an NTR instead of an RTS. This is useful here when STA2's rejection is due to a preference for other links, but it can also come into play if STA2 is currently unable to receive data frames (possibly due to buffer constraints). To release the NAV set by RTS for STA3, STA1 sends an NTS in response. In this example, the NTS / NTR exchange is reversed. Protocol purity can be maintained by requesting STA2 to respond with an additional NTR message (though unnecessary for the current purpose), by acknowledging the NTS, and by treating the first NTR message as a "Not Ready to Receive" (NRR) message or a simple "Reject" (REJ) message. In variations, NRR / REJ messages can have different message types (as indicated in frame control). If STA2 simply does not send a CTS, STA1 does not know whether it failed to receive a CTS or did not send one. It can make another attempt on Link 6, which is not STA2's intention.

[0106] The advantage of explicit rejection is that it avoids STA1 retrying on link 6, and thus reduces inefficiency, meaning STA3 will be able to use the link earlier.

[0107] In one variant, the NTR / REJ message can use a link information field to carry suggested alternative links. In another variant, the link information field can be used to encode the suggested wait time, for example, in multiples of 100ms.

[0108] Finally, Link 7 illustrates a situation similar to Link 2, where STA2 has clearly not received a response to the CTS frame. In this case, STA1 has started transmitting data frames, but STA2 has not yet received the header. During the energy check and channel occupancy detection, it assumes data frames are being transmitted and explicitly does not issue an NTR message. Because no data frames are received, there is no ACK frame from STA2. The STA3 NAV reservation remains in place until the ACK has been completed. When STA1 fails to receive an ACK from STA2, STA1 and STA2 fall back to the standard data recovery procedure.

[0109] As can be seen from the above, media access time is obtained by using NTS / NTR frames instead of waiting for CTS response and retrying.

[0110] Multiple data frames

[0111] When link capacity is an issue, STA1 can be configured to send different data frames on different links. Compared to running the process in a separate parallel instance, STA1 can select the optimal k links (or multiple k links) and send the next k data frames on separate links (or multiple links).

[0112] Figure 10 An embodiment using this method is shown – STA3 is omitted for clarity. STA1 has four data frames A, B, C, and D to send and transmit RTS frames on eight links, the RTS frames optionally indicating four frames to be transmitted. STA2 responds by selecting six good links (0, 1, 2, 4, 5, and 7), returning a CTS frame on each link, and optionally returning an NTR frame (3 and 6) on the rejected links. STA1 selects the four best links (0, 2, 5, and 7), optionally sorting them in descending order of quality (5, 2, 0, and 7), and transmits data frames in the order of most urgent or most important to least important. On the remaining links, it transmits an NTS to clear NAVs on these frames. STA2 transmits an NTR on the links where it previously transmitted CTS (1 and 4). All four data frames (DATA A, B, C, and D) are acknowledged by ACK frames. In a variant, each ACK frame may contain an acknowledgment for all transmitted frames to provide redundancy.

[0113] Figure 11This represents various frame formats according to embodiments. Information can be included in the frame to assist STA1, STA2, and STA3 in making their decisions. In variations, this is information indicating the urgency of the data. In the case of IEEE 802.11, in addition to the frame control, duration, receiver address (RA), transmitter address (TA), and FCS fields, the extended RTS frame 1101 may also include a priority / link information field. Priority can be related to the access class of the data or another indication of the data urgency in the case of a QoS STA. Link information can be information related to links in the case of MLO—it may contain the target minimum number of links expected to be used by STA2. Alternatively or additionally, it can indicate which links it considers optimal by, for example, a bitmap or by indicating the link quality factor of the RTS frame on each link according to STA1's evaluation. Furthermore, the link information can include a transaction identifier that allows the STA to hear multiple extended RTS frames to determine whether they are all related to the same concurrent transaction. Priority / link information can be a variable-length field—for example, the link information can be omitted in the case of non-MLO. To achieve this, the bits in this field can be used as flags, or the receiving STA can base its frame parsing on prior knowledge of the presence of an MLO. An advantage of using a dedicated MLO flag is that STA3 can detect that the STA1-ST2 connection is a multi-link connection. Extended CTS frame 1102 contains a link information field, which can be used to indicate, for example, which links it considers optimal for data reception based on link evaluation, or to indicate a quality factor, or it can contain a selection of a subset of the links indicated in the link information of extended RTS frame 1101. In the first step, STA1 can transmit information about the urgency and / or importance of the data to be transmitted to help STA2 decide how many links to use. Similarly, in the second step, in STA2's CTS response, extended RTS or CTS frames 1101 / 1002 can also indicate on which links RTS and CTS frames have also been transmitted. NTS and NTR messages can also include information about the reasons for rejection, which can be helpful, for example, for rescheduling or buffer management.

[0114] Variations in the steps are possible. For example, in step two, STA2 may not receive RTS frames on any link. Conversely, in step 3, STA1 will not receive CTS frames on any link, even if STA2 transmits any CTS frames. In both cases, STA1 will time out and may choose to restart the transmission process using a different subset of links, hoping for greater success.

[0115] In an example inspired by IEEE 802.11, NTS frame 1104 may include RA, TA, BSSID (TA) fields, and a link information field (link information), where BSSID (TA) is the network identifier of the transmitter of the original reservation frame (e.g., RTS). NTS frame 1104 includes a link information field, which can be used to indicate which links the frame's transmission involves (where MLO is being used). Unlike simpler reservation cancellation frames like IEEE 802.11 CF-End frame 1103, NTS frames may include both a TA field and a link information field. In an example derived from IEEE 802.11, NTR frame 1105 may include RA, BSSID (TA) fields, and a link information field (link information). In a variant, NTR frames may include a TA field. The frame control fields of NTS and NTR frames may contain information that allows the frame receiver to distinguish between NTS frame 1104 and NTR frame 1105, as well as to distinguish them from other types of frames. In the case of IEEE 802.11, the initial RTS can already be a multi-user communication, such as a MU-RTS or a basic trigger frame. In IEEE 802.11, the trigger frame carries resource element (RU) allocation information for the STA. Unlike some response frames (such as CTS), the TA allows the receiving STA to know (among multiple STAs) which STA has responded to the NTS or, in a multi-user case, rejected the RTS. It should be understood that different links can be separated in frequency, for example, using different channels and / or subcarriers. In a variant, the AP can be arranged to regulate RU allocation using information about rejections or indications that no data is being sent from the STA on a particular link, where different STAs are using different links, i.e., not all STAs are using all the links in question. For example, this can be achieved by sending a new trigger frame with updated RU allocations whenever the number or characteristics of unused links are guaranteed to be reallocated, once the AP understands which links will be used.

[0116] Multiple APs and OBSS

[0117] Figure 12This illustrates how additional potential advantages of NTS / NTR frames can be obtained. In a multi-AP scenario (an example of which is Coordinated TDMA (C-TDMA)), AP1 (the sharing AP) allows AP2 (the shared AP) to use a portion of the TXOP owned by AP1, as indicated by the arrow TXOP. Sharing is established by MRTT frame 1202. AP1 and AP2, along with their associated STA1 and STA2, can perform frame exchanges with frames 1203-1207. Frame 1205 is sent by AP2 to cancel or truncate a portion of the TXOP and return it to AP1, as shown by the shortening of STA1's NAV 1208 (indicated by the dashed portion). Problems may arise when STA3, not associated with either AP1 or AP2's BSSS, is within the scope of a multi-AP group. It is expected that the OBSS STA3 has its basic (or BSSS-internal) NAV set to protect transmissions within the group—as shown by the shaded bar 1209. The effect of using a frame like a CF-End frame for frame 1205 would be to cause the OBSS STA3 to reset its basic NAV—as indicated by the different shaded lines of the latter part of bar 1209. This is undesirable because it eliminates inter-BSS protection for the TXOP in question. Currently, only APs use the BSSSID(TA) field, so the OBSS STA will not ignore CF-End frames sent by APs in a multi-AP group to manage their shared TXOPs. This problem can be avoided by using NTS (or NTR) frames, where the use of NTS frames can be used as a sign that non-AP STAs should also use the BSSID(TA) field in NTS / NTR frames. Thus, the STA3 can detect that frame 1205 involves a BSSS other than its own and therefore take no action against it, i.e., maintain its basic (i.e., intra-BSS) NAV, as indicated by the full length of bar 1209 with both types of shaded lines. This is achieved through the fact that they are used, i.e., frame control identification.

[0118] It should be noted that while STA1 and STA2 are expected to understand NTS and NTR frames, legacy STA3 will simply ignore them and revert to legacy behavior. Therefore, the introduction of these frames will ensure compatibility with legacy devices.

Claims

1. A method for controlling media access in a wireless network, the wireless network including a first device having a multi-link connection to a second device, the multi-link connection having multiple links, the method comprising: The first device transmits a first message to the second device on the plurality of links, each first message (RTS) indicating a reservation for at least the corresponding link, the reservation being used for transmission by the first device, the message containing an indication of the duration of the reservation; The first device waits for a response message (CTS) from the second device on at least one of the plurality of links for a first time period; After the second time period, the first device transmits at least one second message (NTS) on at least one of the plurality of links, the at least one second message indicating the cancellation of the reservation for the at least one link; The second message (NTS) is sent in response to a response message sent by the second device during the first time period, or if the response message is not received during the first time period.

2. A method for controlling media access in a wireless network, the wireless network including a first device having a connection to a second device, the method comprising: The first device transmits at least one first message (RTS) to the second device, the at least one first message indicating a reservation for a transmission performed by the first device, the message including an indication of the duration of the reservation; The first device waits for a response message (CTS) from the second device on at least one of the plurality of links for a first time period; After the second time period, the first device transmits at least one second message (NTS) on at least one of the plurality of links, the second message indicating cancellation of the reservation for the at least one link; After the third time period, the second device transmits at least one third message (NTR), the second message indicating at least one of the following: acknowledgment of the second message and cancellation of the reservation; The second message is sent in response to a response message sent by the second device during the first time period or in the event that the response message is not received during the first time period, and the third message is sent in response to receiving the second message or the first message.

3. The method according to claim 1, comprising: The second device transmits a third message (NTR) after a third time period, i.e., at least one third message (NTR), the third message indicating at least one of the following: acknowledgment of the second message and cancellation of the reservation, wherein the third message is sent in response to receiving the second message or the first message.

4. The method according to claim 1 or 2, comprising: The second device transmits a response message (CTS) acknowledging the first message to the first device on at least one of the plurality of links.

5. The method according to claim 1 or any dependent claim thereof, wherein, The response message also provides an indication of a reservation for at least the corresponding link, the reservation being used for transmissions performed by the first device, and the message includes an indication of the duration of the reservation.

6. The method according to claim 2 or 3, wherein, The response message (NTR) also provides an indication that the first device should not use the link for transmission.

7. The method according to claim 1 or any dependent claim thereof, comprising: The second device transmits a third message indicating confirmation of the second message to the first device on at least one of the plurality of links.

8. The method according to claim 5, wherein, The third message also indicates the cancellation of the reservation made by the response message.

9. The method according to any one of the preceding claims, wherein, The first message (RTS), the second message (NTS), and the third message (NTR) contain a transaction identifier common to the multiple links.

10. The method according to any of the preceding claims, wherein, If the third device has recorded the reservation and blocked transmission from the third device, then the third device's receipt of either the second message or the third message causes the device to consider the reservation to be cancelled.

11. The method according to any of the preceding claims, wherein, If the third device belongs to another BSS, the third device does not reset its basic NAV upon receiving the second message or the third message.

12. A device (STA1) arranged for communication in a wireless network 1, wherein, The device (STA1) is configured to communicate with the second device (STA2) on multiple links, and the device (STA1) is configured as follows: A first message (RTS) is transmitted to the second device (STA2) on the plurality of links, each first message indicating a reservation for at least the corresponding link for transmission by the device, the message containing an indication of the duration of the reservation; Waiting for a response message from the second device (STA2) on at least one of the plurality of links during a first time period; After the second time period, at least one second message (NTS) is transmitted on at least one of the plurality of links, the at least one second message indicating the cancellation of the reservation for the at least one link; The second message is sent in response to a response message sent by the second device during the first time period, or if the response message is not received during the first time period.

13. A device (STA2) arranged for communication in a wireless network, the device (STA2) being configured to receive a first message (RTS) from a first device (STA1), the message indicating a reservation for a transmission to be performed by the device, the message including an indication of the duration of the reservation, wherein, The device (STA2) is configured to perform at least one of the following operations: In response to the first message (RTS), a third message (NTR) is transmitted, and After the waiting time expires, a second message (NTS) is received, indicating the cancellation of the reservation.

14. A device arranged for communication in a wireless network 1, wherein the device (STA3) is arranged as follows: After receiving a first message (RTS), a timer is set. The first message is sent from a first STA (STA1) to a second STA (STA2). The first message (RTS) contains an indication of a reservation for transmission and an indication of a duration. The timer is set based on the duration and has the effect of preventing transmission by the device (STA3) until the timer expires. The timer is reset in response to receiving a second message (NTS) or a third message (NTR), wherein, The second message is sent from the first STA (STA1) to the second STA (STA2), and the third message is sent from the second STA (STA2) to the first STA (STA1).

15. A computer program product that can be stored on a computer-readable medium and is configured to perform the method according to any one of claims 1-10 when a computer is running.

Images