Lock-up mitigation in multi-link devices

Abstract

There is provided methods and devices arranged for the controlling media access in a wireless network. The wireless network may comprise a first device having a multi-link connection to a second device, the multi-link connection having a plurality of links. The method comprises transmitting by the first device to the second device, over the plurality of links, first messages, each first message (RTS) indicating a reservation of at least the respective link, for a transmission by the first device, the message containing an indication of a duration of said reservation, waiting for a first time period, by the first device, for a response message from the second device, on at least one of the plurality of links, after a second time period, transmitting, by the first device, at least one second message (NTS) over at least one link of the plurality of links, indicating a 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 in the first time period or upon a failure to receive the response message within the first time period.

Description

[0001] LOCK-UP MITIGATION IN MULTI-LINK DEVICES

[0002] FIELD

[0003] The present invention relates to wireless networks, in particular local networks such as those using the IEEE 802.11 standard.

[0004] BACKGROUND

[0005] Wireless networks are frequently very busy with many devices needing to transmit. The heavy occupation of the wireless medium can result in unacceptable delays or latency for some high importance transmissions. In certain networks like IEEE 802.11 (also known as ‘Wi-Fi’), device like Access Points (APs) may coordinate between themselves with the aim of improving usage of the medium. Also, many wireless networks overlap with and are subject to interference from other, similar and different, wireless networks.

[0006] The present application claims priority from US provisional applications 63 / 548408, 63 / 557641 and 63 / 626551, the entire disclosures of which are incorporated by reference.

[0007] SUMMARY

[0008] The inventors have realized that the problem is acute in networks using so-called multilink devices (MLDs, for short) because the level of complexity is greater - the need for coordination between devices is increased. In a situation where both AP and STA are MLDs, an interference, for example from another network (an OBSS in the case of 802.11) on one link can have an impact on the other link i.e. the throughput-loss problem is compounded.

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

[0010] The present invention discloses methods of ensuring the necessary link access for low latency PPDUs while ensuring that links are not blocked when not used.

[0011] In a basic embodiment, a special message is transmitted to release unused links reserved by a preceding RTS or CTS message. On reception of the message, nearby STAs may reset their NAVs and treat the link as available. Other embodiments disclose further improvements to system reliability.

[0012] In an aspect, there is provided a method of controlling media access in a wireless network, the wireless network comprising a first device having a multi-link connection to a second device, the multi -link connection having a plurality of links. The method comprises transmitting by the first device to the second device, over the plurality of links, first messages, each first message (RTS) indicating a reservation of at least the respective link, for a transmission by the first device, the message containing an indication of a duration of said reservation, waiting for a first time period, by the first device, for a response message (CTS) from the second device, on at least one of the plurality of links, after a second time period, transmitting, by the first device, at least one second message (NTS) over at least one link of the plurality of links, indicating a cancellation of the reservation for the at least one lin, wherein the second message (NTS) is sent in response to the response message sent by the second device in the first time period or upon a failure to receive the response message within the first time period.

[0013] In an aspect, the method of controlling media access in a wireless network, the wireless network comprises a first device having connection to a second device. The method comprises transmitting by the first device to the second device, at least one first message indicating a reservation for a transmission by the first device, the message containing an indication of a duration of said reservation, waiting for a first time period, by the first device, for a response message from the second device, on at least one of the plurality of links, after a second time period, transmitting, by the first device, at least one second message over at least one link of the plurality of links, the second message indicating a cancellation of the reservation for the at least one link, after a third time period, transmitting, by the second device, at least one third message (NTR), the second message indicating at least one of an acknowledgement of the second message and a cancellation of the reservation, wherein the second message is sent in response to the response message sent by the second device in the first time period or upon a failure to receive the response message within the first time period and the third message is sent in response to receiving the second message or the first message.

[0014] In an embodiment, the method comprises transmitting, on at least one of the plurality of links, by the second device to the first device, a response message comprising an acknowledgement of the first message. In an embodiment, the response message additionally provides an indication of a reservation of at least the respective link, for a transmission by the first device, the message containing an indication of a duration of said reservation.

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

[0016] In an embodiment, there is transmitting, on at least one of the plurality of links, by the second device to the first device, a third message indicating an acknowledgement of the second message.

[0017] In an embodiment, the third message further indicates a cancellation of a reservation made by a response message.

[0018] In an embodiment, the first, second and third messages contain a transaction identifier that is common across the plurality of links.

[0019] In an embodiment, reception by a third device of either of the second or third messages cause the device to consider the reservation cancelled if the third device had recorded the reservation and inhibited transmission from the third device.

[0020] In an aspect, there is provide a device, arranged for communication in a wireless network, wherein the device is arranged to communicate with a second device over a plurality of links, the device being arranged to transmit to the second device, over the plurality of links, first messages, each first message indicating a reservation of at least the respective link, for a transmission by the device, the message containing an indication of a duration of said reservation, wait for a first time period, for a response message from the second device, on at least one of the plurality of links, after a second time period, transmit at least one second message over at least one link of the plurality of links, indicating a 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 in the first time period or upon a failure to receive the response message within the first time period.

[0021] In an aspect, there is provided a device arranged for communication in a wireless network, the device being arranged to receive a first message from a first device, the message indicating a reservation for a transmission by the device, the message containing an indication of a duration of said reservation, wherein the device (STA2) is arranged to perform at least one of- transmitting a third message (NTR) in response to the first message (RTS) and receiving a second message (NTS) after an expiry of a wait time, the second message indicating a cancellation of the reservation.

[0022] In an aspect, there is provided a device arranged for communication in a wireless network 1, the device being arranged 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 a transmission, the message containing an indication of a duration, the timer being set based on the duration and having an effect of inhibiting transmission by the device (STA3) until expiration of the timer, reset a timer in response to receiving either a second message (NTS) or a third message (NTR) wherein the second message was sent by a first STA (STA1) to a second STA (STA2) and the third message was sent by the second STA (STA2) to the first STA (STA1).

[0023] In an aspect there is provided, a computer program product, storable on a computer- readable medium and arranged, when run a computer to execute the method disclosed herein.

[0024] BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Examples of several of the various embodiments of the present disclosure are described herein with reference to the drawings wherein:

[0026] Fig. 1 represents a wireless network;

[0027] Fig.2 represents a frame (i.e. message) exchange in the wireless network of Fig. 1;

[0028] Fig. 3 represents various problems that can occur with the frame exchange of Fig. 2;

[0029] Fig. 4 represents a frame exchange according to an embodiment;

[0030] Fig. 5 represents a frame exchange using multiple links and problems that can occur;

[0031] Fig. 6 represents a frame exchange according to an embodiment using multiple links;

[0032] Fig. 7 represents a frame exchange on multiple links in parallel;

[0033] Fig. 8 represents various events in frame exchanges on multiple links in parallel; Fig. 9a & b represent a frame exchange according to an embodiment on multiple links in parallel;

[0034] Fig. 10 represents a frame exchange according to an embodiment on multiple links in parallel

[0035] Fig. 11 represents frame structures according to an embodiment;

[0036] DETAILED DESCRIPTION

[0037] In the appended figures, same references designate same elements.

[0038] In the present disclosure, various embodiments are presented as examples of how the disclosed techniques may be implemented and / or how the disclosed techniques may be practiced in environments and scenarios. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the scope. After reading the description, it will be apparent to one skilled in the relevant art how to implement alternative embodiments. The present embodiments may not be limited by any of the described exemplary embodiments. The embodiments of the present disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create further embodiments within the scope of the disclosure. Any figures which highlight the functionality and advantages, are presented for example purposes only. The disclosed architecture is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown. For example, the actions listed in any flowchart may be reordered or only optionally used in some embodiments.

[0039] Embodiments may be configured to operate as needed. The disclosed mechanism may be performed when certain criteria are met, for example, in a station, an access point, a radio environment, a network, a combination of the above, and / or the like. Example criteria may be based, at least in part, on for example, wireless device or network node configurations, traffic load, initial system set up, packet sizes, traffic characteristics, a combination of the above, and / or the like. When the one or more criteria are met, various example embodiments may be applied. T Therefore, it may be possible to implement example embodiments that selectively implement disclosed protocols.

[0040] In this disclosure, “a” and “an” and similar phrases are to be interpreted as “at least one” and “one or more.” Similarly, any term that ends with the suffix “(s)” is to be interpreted as “at least one” and “one or more.” In this disclosure, the term “may” is to be interpreted as “may, for example.” In other words, the term “may” is indicative that the phrase following the term “may” is an example of one of a multitude of suitable possibilities that may, or may not, be employed by one or more of the various embodiments. The terms “comprises” and “consists of’, as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes” and does not exclude unenumerated components from being included in the element being described. By contrast, “consists of’ provides a complete enumeration of the one or more components of the element being described. The term “based on”, as used herein, may be interpreted as “based at least in part on” rather than, for example, “based solely on”. The term “and / or” as used herein represents any possible combination of enumerated elements. For example, “A, B, and / or C” may represent A; B; C; A and B; A and C; B and C; or

[0041] A, B, and C.

[0042] If A and B are sets and every element of A is an element of B, A is called a subset of

[0043] 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 equally “based at least on”) is indicative that the phrase following the term “based on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “in response to” (or equally “in response at least to”) is indicative that the phrase following the phrase “in response to” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “depending on” (or equally “depending at least to”) is indicative that the phrase following the phrase “depending on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “employing / using” (or equally “employing / using at least”) is indicative that the phrase following the phrase “employing / using” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments.

[0044] The term configured may relate to the capacity of a device whether the device is in an operational or non-operational state. Configured may refer to specific settings in a device that effect the operational characteristics of the device whether the device is in an operational or non- operational state. In other words, the hardware, software, firmware, registers, memory values, and / or the like may be “configured” within a device, whether the device is in an operational or nonoperational state, to provide the device with specific characteristics. Terms such as “a control message to cause in a device” may mean that a control message has parameters that may be used to configure specific characteristics or may be used to implement certain actions in the device, whether the device is in an operational or non-operational state. In this disclosure, parameters (or equally called, fields, or Information elements: IES) may comprise one or more information objects, and an information object may comprise one or more other objects. For example, if parameter (IE) N comprises parameter (IE) M, and parameter (IE) M comprises parameter (IE) K, and parameter (IE) K comprises parameter (information element) J. Then, for example, N comprises K, and N comprises J. In an example embodiment, when one or more messages / frames comprise a plurality of parameters, it implies that a parameter in the plurality of parameters is in at least one of the one or more messages / frames but does not have to be in each of the one or more messages / frames.

[0045] Many features presented are described as being optional through the use of “may” or the use of parentheses. For the sake of brevity and legibility, the present disclosure does not explicitly recite each and every permutation that may be obtained by choosing from the set of optional features. The present disclosure is to be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features may be embodied in seven ways, namely with just one of the three possible features, with any two of the three possible features or with three of the three possible features.

[0046] Many of the elements described in the disclosed embodiments may be implemented as modules. A module is defined here as an element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure may be implemented in hardware, software in combination with hardware, firmware, wetware (e.g., hardware with a biological element) or a combination thereof, which may be behavi orally equivalent. For example, modules may 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 or the like) or a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or Lab VIEWMathScript. It may be possible to implement modules using physical hardware that incorporates discrete or programmable analog, digital and / or quantum hardware. Examples of programmable hardware comprise 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, C++ or the like. FPGAs, ASICs and CPLDs are often programmed using hardware description languages (HDL) such as VHSIC hardware description language (VHDL) or Verilog that configure connections between internal hardware modules with lesser functionality on a programmable device. The mentioned technologies are often used in combination to achieve the result of a functional module. It is desirable for wireless networks to handle low latency traffic. IEEE 802.11bn, currently under development, has such a goal. Such traffic can be characterized by the presence of PPDUs that need to be delivered urgently within a short delay bound and which therefore may need to pre-empt or take priority over traffic with longer or no latency bounds. The present disclosure is described in the context, and uses terminology from, the IEEE 802.11 standard. Those skilled in the art will be able to apply the teaching to other types of wireless network.

[0047] In a conventional single-link arrangement in wireless networks, a first device, or STA, (STA1) might issue a Ready-To-Send (RTS) message to indicate to a second device (STA2) the availability and quantity of low latency data. On reception, STA2 responds with a Clear-To-Send (CTS) message indicating that it is ready to receive the low latency data and STA1 may then transmit the low latency PPDU in the agreed time frame.

[0048] If the RTS / CTS exchange fails, STA1 may, after determining that it has not received a CTS in an expected time frame, resend the RTS and hope for a better outcome.

[0049] To mitigate against RTS / CTS failure, a STA that hears an RTS for which it is not the intended recipient should refrain from transmission during the interval in which a CTS response is expected. STA1 should also ensure, via a listen-before-talk procedure, that the channel is clear before sending the initial RTS. However, it might not detect a transmission from a ‘hidden node’, for example, a STA in an adjacent network (a so-called ‘overlapping basic service set’ (OBSS)) that prevents STA2 from receiving the RTS.

[0050] The need to wait for a certain duration before resending RTS imposes a time penalty and raises the risk that the low latency data is delivered too late to be of use.

[0051] Networks may also use multi-link operation (MLO)- IEEE 802.1 Ibn also has as a goal the specification of this. This enables STA1 and STA2 to select from multiple links a link over which to exchange data. Multiple links might comprise multiple channels within a frequency band or across more than one frequency band, for example, or might comprise spatially-separated links if a STA has more than one physically-separated transceiver or antenna array. The multiple links can be used to mitigate against loss of RTS frame due to hidden node transmissions by allowed STA1 to send RTS messages substantially in parallel across the 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. STA1, receiving the CTS uses that link to send the low latency data PPDU. To further mitigate against failure to receive a CTS by STA1, STA2 returns a CTS on more than one link, perhaps on each link on which it receives an RTS. From the received CTS messages, STA1 selects one or more links on which to send the low latency PPDU. A problem can arise with the transmission of multiple parallel RTS messages. One of the contents of the RTS message is an indication of the expected location in time and duration of the PPDU transmission. Other STAs that receive the RTS message are expected to regard said time and duration as reserved and to set their Network Allocation Vectors (NAV) accordingly to prevent transmission during that interval. When RTS messages are sent on multiple links, a NAV is set for each link. If STA1 only uses one of the links to send the data, the other links are nevertheless blocked from being used for transmissions by other STAs. Further, if the RTS / CTS exchange fails, STA’s may have set their NAVs for all of the links concerned - such a STA might not be in a position to receive CTS so cannot assume that detecting RTS without the corresponding CTS means failure. Likewise, another third STA might only hear a CTS without the corresponding RTS.

[0052] In an embodiment, the STAs are arranged to maintain an NAV per link i.e. a NAV may be set / reset for one link separately from a NAV for another link. A similar problem exists for the case that STA2 responds with CTS on multiple links.

[0053] In IEEE 802.11, RTS (Ready To Send) ([1], 9.3.1.2) and CTS (Clear To Send) ([1], 9.3.1.3) frames may be exchanged by STAs as part of a virtual CS (Carrier Sense) mechanism. Each frame comprises a Duration field that indicates the period of time that the medium should be reserved for the transmission of the Data frame and the returning Ack frame. Each frame further comprises a Receiver Address (RA) field, being the MAC address of the intended destination STA and, in the case of the RTS but not the CTS, a Transmitter (i.e. sender) Address (TA) field, being the MAC address of the transmitting STA.

[0054] In basic operation, a first, transmitting, STA, STA1, wanting to send a data frame to a second, receiving, STA, STA2, issues an RTS frame, with the RA field set to the address of STA2, the TA field set to its own address and with the Duration field set to the number of microseconds required to receive a CTS frame in response, transmit the data frame and receive an ACK frame, plus a SIFS period before each frame.

[0055] On receiving an RTS frame with its own address in the Receiver Address field, STA2 responds after one SIFS period with a CTS frame addressed to STA1 with the Duration field set to the number of microseconds required to receive the data frame and transmit an ACK frame, plus a SIFS period before each frame.

[0056] Upon receiving the CTS response, STA1, after one SIFS period, transmits the data frame to STA2 and awaits an ACK frame in response. On successfully receiving the data frame, STA2 transmits an ACK frame to inform STA1 that the data frame was received successfully. In the figures, a labelled box with a solid line indicates a frame that was successfully sent by the source and received by the intended destination. A labelled box with a dashed line indicates a frame that was sent but not received. An unlabelled (empty) box with a dashed line indicates a point in the sequence wherein a frame would have been expected by the would-be destination but which was not sent by the source.

[0057] Fig. l represents a wireless network 1 where a first STA (STA1) is communicating with a second STA2 - represented by the solid line between them. One or more third STAs (STA3) are within reception range of messages from either or both of STA1 and STA2 - as represented by the dashed line between them and STA1 and / or STA2. Significantly, a given STA3 may only be able to detect messages from one but not the other of STA1 and STA2. In addition to the question of reception range, it should be noted that the ability of a given STA3 to detect messages passing between STA1 and STA2 may be affected by other factors such as interference from other networks.

[0058] Fig. 2, represents a message exchange between STA1 and STA2 and the behaviour of a STA3. In this example, the data frame is preceded by an announcement / request by STA1 and an acknowledgement / acceptance from STA2. This particular representation is based on figure 10.6 from [1] and shows an example of RTS / CTS operation - other wireless network types have similar protocols. In general, STA1 may choose whether or not to request an acknowledgement for transmitted data. When requested, STA2 sends an ACK frame on successful reception of a data frame. In the case that STA1 does not receive an ACK frame from STA2 when expected, it may choose to repeat the complete procedure or discard the data frame. For the embodiments described here, use of acknowledgement is assumed but it should be clear that the methods disclosed apply equally well when acknowledgements are not used.

[0059] Propagation and interference issues may mean that an RTS frame might not be received by STA2 owing to, for example, interference from another STA that is hidden from STA1. Alternatively, interference might cause STA1 to miss the CTS frame sent in response from STA2. In both cases, STA1, on not receiving a CTS response beginning within the SIFS period, should assume that the RTS transmission has failed and should not send the data frame. It may issue a new RTS frame as part of a new attempt to transmit the data frame or it may abandon transmission of the data frame altogether.

[0060] One or more third STAs (STA3) may be present and in range of STA1 and / or STA2, as exemplified in Fig. 3. STA3 may be understood to represent one or more STAs - where the singular is used herein for STA3, the plural may be understood. STA3 that receives the RTS frame sent by STA1 and / or the CTS frame sent by STA2 are expected to refrain from transmitting during the time reserved by the Duration field by updating a timer called their Network Allocation Vector (NAV). The NAV is first set by the receipt of the RTS (which may contain information relating to how long the NAV should be set for, such as the duration of the PHY data unit) and then adjusted to include any ACK frame that STA2 may be going to transmit. Until its NAV has expired, STA3 treats the medium as busy and does not try to transmit.

[0061] An issue is the expected behaviour of STA3 that received an RTS frame with a reservation but not the corresponding CTS frame confirming it. On the one hand, it could be that no CTS frame was sent; on the other hand, it could be that the CTS frame was sent but not received by the third STA. In the former case, the reservation made by the RTS frame is not valid and the reserved link resources could instead be used by other STAs. In the latter case, the reservation is valid and the reserved link resources should not be used by other STAs. Since STA3 is not in a position to determine why it did not receive a CTS frame, the safest course of action would be to assume that the reservation remains valid and avoid transmission on the reserved link resources.

[0062] A similar issue is the expected behaviour of a third STA that received a CTS frame confirming a reservation but not the corresponding preceding RTS. In this case, since the CTS frame confirms a reservation, the third STA can more readily assume that the reservation is valid.

[0063] In the case in which STA1 does not receive a CTS frame and chooses to abandon the attempt to send the data frame, STA3 that received the original RTS frame and / or the responding CTS frame that was sent by STA2 but not received by STA1 are potentially blocked from using link resources because its (their) NAV(s) are not updated to take into account the abandonment of the data transmission.

[0064] An objective of this invention is to provide means to minimize the blocking problem. It is a further objective of this invention to extend said means to enable full use to be made of the link diversity available in multilink operation (MLO) while minimising the cost to other STAs.

[0065] While the invention is described using the IEEE 802.11 protocol, it will be clear that the same principles may be applied to other systems, including but not limited to 802.15.4, 802.11, 3GPP 4G, 5G and, in general, systems that manage a shared resource in a distributed manner.

[0066] In an embodiment, a special message is transmitted to release unused links reserved by a preceding RTS or CTS message. On reception of the message, nearby STAs may reset their NAVs and treat the link as available. Other embodiments disclose further improvements to system reliability.

[0067] Fig. 3a shows the procedure illustrated in Fig.2 in a more compact format. STA1 sends an RTS frame to STA2, reserving a period of time, indicated in the Duration field, required to transmit a data frame and associated control frames. A STA3 that detects the RTS frame reserves the time by setting its NAV to the duration indicated. STA2 responds with a CTS frame confirming the reservation with the Duration field updated to reflect the passing of a SIFS interframe period and the duration of the CTS frame itself. STA3s that detect this frame and which did not detect the RTS frame reserve the time by setting their NAVs according to the duration expressed in the CTS frame. On receipt of the CTS frame, STA1 sends the Data frame free from interference by STA3. On successful receipt of the Data frame, STA2 issues an ACK frame confirming this to STA1. At this point, the data transmission procedure closes and the NAV fields of the nearby STA3s release the reservation.

[0068] In Fig. 3b, 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). Since, regardless, the reservations in the STA3 NAV fields have come to an end, STA1 cannot simply resend the Data frame but must begin the whole procedure again by issuing RTS to make another reservation, which will prevent STA3 from accessing the medium for even longer.

[0069] Fig. 3c illustrates an example of a problem caused by failure during the RTS-CTS exchange. STA2 responds to an RTS frame from STA1 but the CTS frame it sends is not received by STA1. Accordingly, STA1 does not send a Data frame. In some cases, STA1 may restart the procedure by resending RTS, as shown in Fig. 3d. In other cases, for example, after continued failure to receive a CTS frame, STA1 may choose to abandon the procedure. In this case, the NAVs of the STA3 continues to reserve time that is now not being used and is blocked from using the medium for its own transmissions.

[0070] Nothing to Send and Nothing to Receive frames

[0071] Figs. 4a to 4d, represent operation of embodiments where use is made of two new frames: a Nothing to Send (NTS) frame, comprising a Transmitter Address (TA), a Receiver Address (TA) and acting as an indication that the active reservation made by the previous RTS frame is released, and a Nothing to Receive (NTR) frame, comprising a Receiver Address (RA), and in a variant a Transmitter Address, and acting as an indication that the active reservation confirmed by the previous CTS frame is released. The phrases ‘releasing’ or ‘cancelling’ a reservation should be understood to include shortening or truncating the reservation, removing the need for other stations which were inhibiting their transmissions to remove that inhibition. In the case of IEEE 802.11, this may correspond to truncating or releasing a TXOP.

[0072] An NTS frame may be implemented as a purpose-defined frame or may be implemented by an existing frame type with a special value, for example, an RTS frame with the Duration field set to zero or another appropriate value (e.g., an interframe spacing) or, for example, a CF-End frame with the Duration field set to zero or an appropriate value. Similarly, an NTR frame may be implemented as a purpose-defined frame, a CTS frame with the Duration field set to zero and so on.

[0073] Fig. 4a, represents first embodiment, illustrated in STA1, on choosing to abandon transmission of a data frame, releases the reservation made by its previous RTS frame by transmitting a corresponding Nothing to Send (NTS) frame, comprising its address as TAs, the address of STA2 as RA, both as per the preceding RTS frame, and an indication that the active reservation corresponding to both those addresses is released which handles a case where STA3 has NAVs set by more than one STA. In an extension of the first embodiment, STA2, on receiving an RTS frame and responding with a CTS frame but receiving an NTS frame from STA1, releases the reservation made by its previous CTS frame by transmitting a corresponding Nothing to Receive (NTR) frame the address of STA1 as RA, in a variant comprising its own address as TA, and acting as an indication that the active reservation corresponding to both those addresses (e.g. the TXOP) is released. The NTR frame has a first purpose i.e. an acknowledgement of the NTS frame.

[0074] Fig. 4b shows an error condition in which the CTS frame from STA2 is not received by STA1, which duly sends a frame to cancel the reservation confirmed by the CTS frame - here represented by an NTS frame (though another frame having the effect of cancelling the reservation / TXOP could be envisaged. The inventor has realized that simply having STA1 send a frame (e.g. an NTS frame) to cancel leaves a problem in that this reservation cancelling frame (e.g. NTS) may not be received by STA2, which, therefore does not cancel the reservation made by its CTS frame. The same holds true where STA3 does not receive the reservation cancellation - it will not reset its NAV even though it could.

[0075] Fig. 4c shows a possible resolution of the error condition of Fig. 4b, in which STA2 sends an NTR frame upon not receiving any response to its CTS frame. The inventor has realized that there is a potential problem in that STA1 might have received the CTS frame and be transmitting the Data frame - it would be inappropriate for STA2 to release the reservation for other STAs because it is, in fact, still being used by STA1. To determine the actual situation, STA2 may perform an energy detection (ED) process to determine whether a transmission is in process or not; if not, it may then send an NTR message to release the reservation. The use of the NTR frame offers the advantage of cancelling the reservation for a STA3 that is able to detect frames from STA2 but not STA1 (such as represented in Fig. 4b). Thus the NTR frame has a second purpose in allowing STA2 to cancel the reservation when it detects that the medium is, in fact, not being used.

[0076] Fig. 4d shows an example in which the initial RTS frame was not seen by STA2. STA1, on detecting no CTS frame, issues NTS, which STA2 does receive. Despite not having sent a CTS frame, STA2 may nevertheless send an NTR frame to help any STA3s that heard the RTS frame but not the NTS frame comprising its address as TA, the address of STA1 as RA, where the address of STA1 is taken from the received NTS frame, and an indication that any active reservation corresponding to both those addresses is released. It is advantageous that STA3 should accept both NTS and NTR as releasing a reservation, regardless of whether it used RTS or CTS to establish the reservation. All STAs should handle an unexpected (i.e., not preceded by receipt of an earlier corresponding RTS or CTS frame) NTS or NTR frame gracefully - in other words, cancel reservations (e.g. reset their NAVs) corresponding to RTS and CTS frames sent by STA1 and STA2 or ignore when no such reservations are set

[0077] Multilink Operation (MLO)

[0078] Multi-link operation (MLO). offers a potential mitigation for transmission failure on one link by allowing STA1 and STA2 to operate over one or more second links. In general, if the quality of each link is independent of the others, then the probability that, at any one time, all links are suffering from interference is lower than the probability that any one link is suffering from interference. Thus, by exploiting this ‘link diversity’, STA1 and STA2 can potentially provide better service for low latency traffic.

[0079] In the following general description of a data transmission procedure using MLO, STA1 wants to send a data frame to STA2. RTS, CTS and ACK frames and the data frame are assumed to be sent using the RA and (for the frames that carry it) the TA fields discussed above. On any given link, STA3 can hear some or all of the exchange between STA1 and STA2 and must process frames to the extent that it can determine the duration of an intended data frame transmission and reserve the link by updating its Network Allocation Vectors (NAV) accordingly. The precise operation of a multi-link may depend on a number of factors, including the capabilities of STA1 and STA2, network policy, a policy in place at each of STA1 and STA2, or dynamic information including measurements of channel quality, the urgency and / or importance of the data being transferred, recent history regarding the success or otherwise of data transfers and so on. An exemplary sequence of steps is described below.

[0080] MLO sequential operation

[0081] Fig. 5 represents an example of MLO where, operating sequentially, STA1 may transmit an RTS frame on a first link and wait for a responding CTS frame. If no such frame is received in the expected time window, because of a transmission error or because no CTS frame was sent by STA2, STA1 may abandon the attempt to transmit data on the first link and attempt to transmit on a second link, sending a new RTS frame and awaiting a response. If still no response is received, STA1 may try on a third link and so on until it either receives a CTS frame in response and successfully sends the data frame or it abandons the attempt to send the data frame altogether.

[0082] STA1 attempts to transmit a data frame on Link 0 by sending an RTS frame to STA2. STA3 has detected the RTS and set its NAV for Link 0 accordingly. On Link ,STA3 has detected the RTS but not the CTS and sets its NAV 53 accordingly. Because STA2 does 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 adjusts its NAV. However, STA1 does not send the data frame 54 because it did not get the CTS yet a STA3 that did not receive the RTS but did receive the CTS has set its NAV and refrains from trying to use the medium. STA 1 then makes a last attempt on Link 5. STA2 has not received the expected data frame 54 on Link 2 but does finally receive an RTS frame on Link 5. It responds with a CTS frame, which is successfully received by STA1. STA1 then sends the data frame DATA and STA2 sends an acknowledgement ACK.

[0083] STA3 , detecting the RTS and CTS frames set its NAV to allow for the intended data frame transmission but, in links 0 and 2, these NAVs are not released when the transmissions are not made and the links are abandoned.

[0084] The ‘ghost’ RTS frames 51, 55 and STS frames52 indicate the timings had they been sent. As may be seen, STA1 has to wait until a time (indicated by the vertical line) after the CTS it failed to get on Link 2 in order to start on Link 5 with the RTS. Coincidentally this is the start of the time it would have sent data frame 54. It is clear that considerable time has been lost in achieving a transmission and STA3 has been prevented from accessing the medium during a period when it could have, since the attempts by STA1 had failed.

[0085] Fig. 6 shows an example of the operation of an embodiment with MLO. STA1 and STA2 respectively transmit NTS and NTR frames to release the reservation made by the preceding RTS and CTS frames on Links 0 and 2. On receiving these frames, STA3s can reset their NAVs accordingly on links 0 and 2. As can be seen by comparing with Fig. 5, the reservations are cancelled (or shortened) for these links STA3 (in the case of IEEE 802.11, STA3 resets its NAV), with the advantage that those links are freed for transmission resulting in lower latency in general and more efficient use of the medium.

[0086] MLO parallel operation

[0087] The time taken for each unsuccessful attempt can be significant for very low latency data. Advantageously, then, STA1 and STA2 may be capable of operating on multiple links simultaneously in order to take advantage of the redundancy inherent in parallel operation. In a second method, STA1 may send an RTS frame substantially simultaneously on more than one link, that it selects. STA2 may respond simultaneously on any of the links on which it received the RTS frame, selecting links according to, for example, a link quality assessment or the availability of the link for the duration necessary for transmission of the data frame and issues a CTS message on each selected link. STA1 may send the data frame simultaneously on any of the links on which it received the CTS frame, again selecting links according to, for example, a link quality assessment. Finally, if requested, STA2 may respond with an acknowledgement (ACK) frame simultaneously on any of the links on which it received the data frame, noting that it is sufficient for STA1 to receive a single ACK on any link.

[0088] Fig. 7 illustrates a possible arrangement in which a data frame is sent in parallel on all links. This is an extreme form of redundancy that may not always be efficient or necessary. Instead, the RTS / CTS dialogue can be used to negotiate a smaller number of links by allowing each side to determine the best quality link(s) according to some quality criteria.

[0089] In a first step, STA1 may determine a number of links to use from the full set of available links, forming a first subset comprising at least one, more than one or all links, selecting the best according to, for example, a figure of merit assigned to each. STA1 then sends to STA2 an RTS frame comprising a reservation duration to STA2 substantially simultaneously on all links of the first subset. In a second step, on receiving on a number of links an RTS frame with the same parameters, STA2 may determine the number of said links on which to transmit a CTS frame in reply, forming a second subset comprising at least one, more than one or all links, selecting the best according to certain criteria, for example, the received signal strength of the received RTS frame on each link and / or a predetermined figure of merit. STA2 then returns to STA1 a CTS frame comprising the same reservation duration (updated to remove a SIFS period and the time to transmit CTS) as confirmation substantially simultaneously on each link of the second subset.

[0090] In a third step, on receiving on a number of links, a CTS frame with the same parameters confirming the reservation made in the first step, STA1 may determine the number said of links on which to send the data frame, forming a third subset comprising at least one, more than one or all links, selecting the best according to, for example, the received signal strength of the received CTS frame on each link and / or the predetermined (but potentially updated) figure of merit. STA1 then sends a data frame comprising the payload data substantially simultaneously on each link of the third subset.

[0091] Finally, in a fourth step, if STA2 successfully receives the data frame on any link, it sends an ACK frame on at least one such link. To take advantage of the redundancy afforded by parallel links, it may send the ACK on all links on which it detected that the data frame was sent, even if the data frame was not successfully received on that link.

[0092] Selecting preferred links

[0093] Fig. 8 illustrate an example of steps of selecting a subset of preferred links (in this case, a single link) for data frame transmission for a set of eight links chosen by STA1. STA1 sends an RTS frame simultaneously on all links of the set. STA2 selects a subset (in this example, 0, 1, 2, 5 and 7) according to some quality criteria and returns a CTS frame on those links). On receiving the CTS frames, STA1 determines, according to some quality criteria, the best link to be Link 5 and sends the data frame on that link, receiving an ACK frame from STA2. In a variation, STA1 can select two or more links on which to send the data frame.

[0094] On each link, a STA3, receiving the RTS frame and / or the CTS frame, reads the duration field and reserves the link by updating its Network Allocation Vector (NAV) accordingly. The inventor has realized that careless use of multiple links may exacerbate the blocking problem discussed previously because, while a reservation might be made on several links, not all of said reservations will actually be used to transmit the data frame. In this example, seven out of eight frames are abandoned but the STA3 NAVs are not updated to reflect this. This means that those STA3s are prevented from using the abandoned links for their own communications. The inventor has realized that this selection procedure is as inefficient as the parallel procedure in which all available links are used to transmit a data frame.

[0095] Link subset selection with NTS / NTR

[0096] Figs. 9a and 9b show an exemplary operation according to embodiment in which the NTS and NTR frames described earlier are used to release the unused reservations on abandoned links. As before, STA1 sends an RTS frame simultaneously on all links of the set chosen by STA1. STA2 selects a subset (0, 1, 2, 4, 5 and 7) according to some quality criteria and returns a CTS frame on those links). On receiving the CTS frames, STA1 determines, according to some quality criteria, the best link to be Link 5 and sends the data frame on that link, receiving an ACK frame from STA2.

[0097] Transmission of the data frame on other links is inhibited by a variety of events, many of which can be mitigated by the NTS and NTR frames. In general, NTS may be used to release NAVs set by RTS on STA3 in range of STA1, while NTR may be used to release NAVs set by CTS on STA3 in range of STA2 but not STA1. Nevertheless, in a variant where both NTS and NTR carry both the transmitter and receiver addresses, either frame can be used by a STA3 to release the relevant NAV reservation. This is explicit in some examples and should be assumed to be implicit in others.

[0098] Link 0 illustrates the intended usage in which STA1 decides that it no longer wishes to use Link 0 and informs STA2 by sending an NTS frame. Receiving STA3s that also received the original RTS (and CTS) frame(s) can update their NAVs to release the reservation made by RTS. STA2 responds with an NTR that acknowledges STAl’s NTS frame and releases NAVs reserved by STA3s that missed the NTS message.

[0099] Link 1 shows a variation in which the CTS message from STA2 was not received by STA1. STA1 issues NTS in response to release the reservation and STA2 acknowledges with NTR.

[0100] Link 2 shows a further variant in which STA1 issues NTS to indicate that it no longer intends to use Link 2. STA2 does not receive this and, on performing an energy check and finding the link unoccupied (e.g., by the expected data transmission), may issue NTR to release any uncleared STA3 NAV reservations. This shows that NTR can be sent when NTS was expected but not received. Note that, as illustrated, some STA3s that set their NAV according to RTS might also not receive NTS if NTS is subject to a burst of noise, for example. In this case, NTR is also sufficient to release the NAV reservations of these STA3s.

[0101] On link 3, the RTS frame from STA1 was not received by STA2, which does not send a CTS in response. As with link 1, STA responds to the absence of an expected CTS message by issuing NTS, which is acknowledged by STA2 with an NTR frame. As illustrated by the dashed outline, no NAVs should have been set by CTS but NTR may still play a role in releasing NAVs set by RTS.

[0102] On link 4, STA2’s NTR frame is not received by STA1. STA1 may choose to reissue NTS in the hope of getting an NTR on a subsequent attempt. If STA3 also missed the first NTR, this provides an extra chance for them to release the reservation made by CTS - as shown by the dashed portion of the NAV (CTS). STA1 can, in principle, repeat this until NTR is received. In practice, there will be practical limits on how many times it is useful to do this.

[0103] Link 6 illustrates an instance where STA2 explicitly rejects STAl’s RTS overture by returning NTR in place of RTS. This is useful here when the reason for STA2’s rejection is preference of other link(s) but might also have a role to play if STA2 is currently unable to receive a data frame, perhaps owing to buffer constraints. To release STA3’s NAV(s) set by the RTS, STA1 sends NTS in response. In this example, the NTS / NTR exchange is reversed. Protocol purity could be maintained by requiring STA2 to respond, albeit unnecessarily for the present purpose, with a further NTR message, acknowledging the NTS and by considering the first NTR message as a ‘Not Ready to Receive’ (NRR) message or a simple ‘Reject’ (REJ) message. In a variant, the NRR / REJ message may have a different message type (as indicated in the Frame Control). If STA2 simply doesn't send CTS, STA1 doesn't know whether it failed to receive CTS or whether one wasn't sent. It could make another attempt on Link 6, which wasn't STA2's intention.

[0104] The advantage of an explicit rejection is that it avoids STA1 retrying on Link 6 and so reduces inefficiency i.e. STA3 will be able to use that link earlier.

[0105] In a variant, the NTR / REJ message may carry a suggested alternative link, using the Link Info field. In another variant, the Link Info field may be used to encode a suggested wait time, for example in multiples of lOOmS.

[0106] Finally, link 7 illustrates a case similar to link 2 in which STA2 apparently receives no response to a CTS frame. In this case, STA1 has started to send a data frame but STA2 has not received the header. On performing an energy check and finding the channel occupied, it assumes that a data frame is being sent and explicitly does not issue an NTR message. Because the data frame was not received, there is no ACK frame from STA2. The STA3 NAV reservation(s) remain in place until the time the ACK would have been completed. STA1 and STA2 fall back into standard data recovery procedures when STA1 fails to receive an ACK from STA2.

[0107] As may be seen, medium access time is gained by the use of the NTS / NTR frames in place of waiting for CTS responses and retrying, as described above.

[0108] Multiple data frames

[0109] When link capacity is an issue, STA1 may arrange to send different data frames on different links. In contrast to running this procedure in separate parallel instances, STA1 may select the best k links (or multiple k links) and send the next k data frames on a separate link (or multiple links).

[0110] Fig.10 shows an embodiment using this approach - omitting the STA3s for clarity. STA1 has four data frames, A, B, C and D, to send and issues RTS frames on eight links, said RTS frames optionally indicating that four frames are to be transmitted. STA2 responds by selecting six good links (0, 1, 2, 4, 5, and 7), returning a CTS frame on each and, optionally, an NTR frame on the rejected links (3 and 6). STA1 selects the best four links (0, 2, 5 and 7), optionally ranks them in descending order of quality (5, 2, 0 and 7) and sends data frames in the order most urgent or important to least. On the remaining links, it sends NTS to clear the NAVs on those frames. STA2 sends NTR on the links it previously sent CTS (1 and 4). All four data frames (DATA A,B,C and D) are acknowledged by an ACK frame. In a variant, each ACK frame may contain an acknowledgement for all transmitted frames in order to provide redundancy.

[0111] Fig. 11 represents various frame formats according to embodiments. Information may be included in the frames to assist STA1, STA2 and STA3 with their decisions. In a variant, this is information indicating the urgency of the data. In the case of IEEE 802.11, an extended RTS frame 1101 may contain a field a Priority / Link Info field in addition to the Frame Control, Durations, Receiver Address (RA), Transmitter Address (TA) and FCS fields. The Priority may be related to the Access Category of the data in the case of a QoS STA or another indication of the urgency of the data. The Link Info may be information relating to the links in an MLO situation - it might contain a target minimum number of links expected to be used by STA2. Alternatively or additionally, it might indicate which links it considers to be optimal by, example, a bit map, or by indicating with the RTS frame on each link a figure of merit of the link according to STAl’s assessment. Also, the Link Info may contain a transaction identifier allowing a STA hearing multiple extended RTS frames to determine whether they all relate to a same parallel transaction. The Priority / Link Info may be a variable length field - for example, the Link Info may be omitted for a non-MLO situation. To cater for this a bit of the field may be used as a flag or the receiving STA may base its parsing of the frame on prior knowledge of the presence or not of MLO. An advantage of using a dedicated MLO flag bit could be that a STA3 could detect that the STA1 - ST2 connection was a multi-link connection. An extended CTS frame 1102 contains a Link Info field which may be used to indicate which links of those that it considers optimal for data reception or indicate a figure of merit, based on, for example, a link assessment or it may contain a selection of a subset of the links indicated in the Link Info of the extended RTS frame 1101. In a first step, STA1 may communicate information about the urgency and / or importance of the data to be sent to assist STA2 decide how many links to use. Similarly, in a second step, STA2, in its CTS response, An extended RTS or CTS frame 1101, 1002 may also indicate on which links RTS and CTS frames have also been sent. NTS and NTR messages may also comprise information about reasons for rejection, which may help with rescheduling or buffer management, for example.

[0112] Variations on the steps are possible. For example exceptionally, in the second step, STA2 may not receive RTS frames on any link. Exceptionally, in step 3, STA1 will not receive CTS frames on any link, even if any were transmitted by STA2. In both cases, STA1 will time out and may choose to restart the transmission procedure using a different subset of links, hoping for more success.

[0113] In an example inspired by IEEE 802.11, an NTS frame 1104 may comprise RA, TA, BSSID (TA) fields and a Link Info field (Link Info), where the BSSID (TA) is the network identifier for the transmitter of the original reservation frame e.g. the RTS. The NTS frame 1104 contains a Link Info field which may be used to indicate which links are concerned by the transmission of the frame (where MLO is being used). Unlike a simpler reservation-cancelling frame like an IEEE 802.11 CF-End frame 1103, the NTS frame may contain a TA field as well as the Link Info field. In an example taken from IEEE 802.11, an NTR frame 1105 may comprise RA, BSSID (TA) fields and a Link Info field (Link Info). In a variant, the NTR frame may contain a TA field. The Frame Control field of the NTS and NTR frames may contain information to allow the receiver of the frame to distinguish between the NTS and NTR frames 1104, 1105 and between them and other types of frame. The initial RTS may have been a multi-user communication, such as an MU-RTS or basic trigger frame in the case of IEE 802.11. In IEEE 802.11, trigger frames carry resource unit (RU) allocation information for the STAs. Unlike some response frames (such a CTS), the TA allows the receiving STA to know which STA (of the multiple STA2s) has either responded to the NTS or rejected the RTS in a multi-user situation. It should be understood that different links may be separated in frequency e.g. using different channels and / or subcarriers. In a variant, an AP may be arranged to use the information concerning rejections or indications of nothing to send from the STAs on particular links to adjust the RU allocations where different STAs are using different links i.e. not all STAs are using all the links in question. For example, this could be achieved by sending, once it is clear to the AP which links will be used, a new trigger frame with updated RU allocations whenever the number or characteristics of the links that will be unused warrants a re-allocation.

[0114] Multi-AP and OBSS

[0115] Fig. 12 represents how a further possible advantage of the NTS / NTR frames may be obtained. In a multi-AP situation, of which an example is Coordinated TDMA (C-TDMA), an API (the sharing AP) allows an AP2 (the shared AP) to use part of a TXOP owned by API - as represented by the arrow TXOP. The sharing is setup by an MRTT frame 1202. API and AP2 and their associated STA 1 and STA2 may execute frame exchanges with frames 1203 - 1207. Frame 1205 is a sent by AP2 to cancel or truncate its part of the TXOP and return it to API, as shown by the shortening of STAl’s NAV 1208 (represented by the dotted line portion). Problems may arise when a STA3, not associated with either of the BSSS’s of API or AP2, is in range of the multi- AP group. It is desirable that this OBSS STA3 has set its basic (or inter-BSSS) NAV to protect the transmissions within the group - as shown by the shaded bar 1209. The effect of the use of a frame like a CF-End frame for frame 1205 would be to cause the OBSS STA3 to reset its basic NAV - as represented by the different hatching of the later part of bar 1209. This is undesirable because it removes the inter-BSS protection for the TXOP in question. Currently, only APs use the BSSSID (TA) field so this OBSS STA will not ignore the CF-End sent by APs in the multi-AP group to manage the TXOP they share. This problem may be avoided by using an NTS (or NTR) frame where the use of this NTS frame could be used as a flag to non-AP STAs that they should also use the BSSID (TA) field in the NTS / NTR frame, whereby STA3 could detect that frame 1205 concerns a BSSS other than its own and so not act upon it i.e. maintain its basic (i.e. inter-BSS) NAV as represented by the full length of bar 1209 with both types of hatching. This could be achieved by the fact that they are being used i.e. the Frame Control identification.

[0116] It should be noted that, while STA1 and STA2 are expected to understand NTS and NTR frames, legacy STA3s will simply ignore them and revert to legacy behaviour. Thus, the introduction of these frames would be compatible with legacy devices.

Claims

CLAIMS1. A method of controlling media access in a wireless network, the wireless network comprising a first device having a multi-link connection to a second device, the multi-link connection having a plurality of links, the method comprising: transmitting by the first device to the second device, over the plurality of links, first messages, each first message (RTS) indicating a reservation of at least the respective link, for a transmission by the first device, the message containing an indication of a duration of said reservation; waiting for a first time period, by the first device, for a response message (CTS) from the second device, on at least one of the plurality of links; after a second time period, transmitting, by the first device, at least one second message (NTS) over at least one link of the plurality of links, indicating a cancellation of the reservation for the at least one link; wherein the second message (NTS) is sent in response to the response message sent by the second device in the first time period or upon a failure to receive the response message within the first time period.

2. A method of controlling media access in a wireless network, the wireless network comprising a first device having connection to a second device, the method comprising: transmitting by the first device to the second device, at least one first message (RTS) indicating a reservation for a transmission by the first device, the message containing an indication of a duration of said reservation; waiting for a first time period, by the first device, for a response message (CTS) from the second device, on at least one of the plurality of links; after a second time period, transmitting, by the first device, at least one second message over at least one link of the plurality of links, the second message (NTS) indicating a cancellation of the reservation for the at least one link; after a third time period, transmitting, by the second device, at least one third message (NTR), the second message indicating at least one of an acknowledgement of the second message and a cancellation of the reservation;wherein the second message is sent in response to the response message sent by the second device in the first time period or upon a failure to receive the response message within the first time period and the third message is sent in response to receiving the second message or the first message.

3. The method of claim 1 comprising transmitting, by the second device a third message (NTR) after a third time period, at least one third message (NTR), the third message indicating at least one of an acknowledgement of the second message and a cancellation of the reservation wherein the third message is sent in response to receiving the second message or the first message.

4. The method of either of claims 1 or 2 comprising transmitting, on at least one of the plurality of links, by the second device to the first device, a response message (CTS) comprising an acknowledgement of the first message.

5. The method of claim 1 or any claim dependent thereon wherein the response message additionally provides an indication of a reservation of at least the respective link, for a transmission by the first device, the message containing an indication of a duration of said reservation.

6. The method of claim 2 or 3 wherein the response message (NTR) additionally provides an indication that the first device should not use the link for a transmission.

7. The method of claim 1 or any claim dependent thereon, comprising transmitting, on at least one of the plurality of links, by the second device to the first device, a third message indicating an acknowledgement of the second message.

8. The method of claim 5 wherein the third message further indicates a cancellation of a reservation made by a response message.

9. The method of any of the previous claims wherein the first, second and third messages (RTS, NTS, NTR) contain a transaction identifier that is common across the plurality of links.

10. The method of any previous claim wherein reception by a third device of either of the second or third messages cause the device to consider the reservation cancelled if the third device had recorded the reservation and inhibited transmission from the third device.

11. The method of any previous claim wherein, if the third device belongs to another BSS, the third device does not reset its basic NAV upon receipt of either the second or third messages.

12. A device (STA1), arranged for communication in a wireless network 1, wherein the device (STA1) is arranged to communicate with a second device (STA2) over a plurality of links, the device (STA1) being arranged to: transmit to the second device (STA2), over the plurality of links, first messages (RTS), each first message indicating a reservation of at least the respective link, for a transmission by the device, the message containing an indication of a duration of said reservation; wait for a first time period, for a response message from the second device (STA2), on at least one of the plurality of links; after a second time period, transmit at least one second message (NTS) over at least one link of the plurality of links, indicating a 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 in the first time period or upon a failure to receive the response message within the first time period.

13. A device (STA2) arranged for communication in a wireless network, the device (STA2) being arranged to receive a first message (RTS) from a first device (STA1), the message indicating a reservation for a transmission by the device, the message containing an indication of a duration of said reservation, wherein the device (STA2) is arranged to perform at least one of:- transmitting a third message (NTR) in response to the first message (RTS) and- receiving a second message (NTS) after an expiry of a wait time, the second message indicating a cancellation of the reservation.

14. A device arranged for communication in a wireless network 1, the device (STA3) being arranged 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 a transmission, the message containing an indication of a duration, the timer being set based on the duration and having an effect of inhibiting transmission by the device (STA3) until expiration of the timer;reset a timer in response to receiving either a second message (NTS) or a third message (NTR) wherein the second message was sent by a first STA (STA1) to a second STA (STA2) and the third message was sent by the second STA (STA2) to the first STA (STA1).

15. A computer program product, storable on a computer-readable medium and arranged, when run a computer to execute the method of any of claims 1 - 10.

Images