CN116783976A - Channel access on non-simultaneous transmit/receive links - Google Patents

Abstract

A wireless communication protocol in which multilink operation particularly provides enhanced efficiency for non-simultaneous transmit receive (NSTR) communications between Stations (STAs) of a multilink device (MLD). When MLD1 is the TXOP holder of Link1 and a channel is accessed by MLD2 on Link2 to transmit to MLD 1; if MLD1 is receiving on Link1, MLD2 immediately sends to MLD1 on Link 2. If MLD1 is transmitting on Link1, MLD2 transmits a frame on Link2 to occupy the channel, and then MLD2 transmits another frame to MLD1 when MLD1 is receiving on Link 1.

Description

Channel access on non-simultaneous transmit/receive links

Cross Reference to Related Applications

The present application claims priority and benefit from U.S. patent application Ser. No. 17/847,342 filed on 6/23 at 2022, the entire contents of which are incorporated herein by reference. The present application also claims priority and benefit from U.S. provisional patent application serial No. 63/223,634 filed on 7/20 at 2021, the entire contents of which are incorporated herein by reference.

Statement regarding federally sponsored research or development

Is not suitable for

Notification of copyrighted material

A portion of the material in this patent document may be subject to copyright protection in accordance with the united states and other national copyright laws. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the united states patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner has therefore not relinquished any rights to the patent document, including without limitation its rights in accordance with 37 c.f.r. ≡1.14.

Background

1. Technical field

The technology of the present disclosure relates generally to Wireless LANs (WLANs) using carrier sense multiple access/collision avoidance (CSMA/CA) for channel access, and more particularly, to obtaining channel access for stations of non-simultaneous transmission/reception (NSTR) multi-link devices (MLDs).

2. Background discussion

Current wireless technologies using CSMA/CA focus on high throughput performance of the network but lack sufficient low latency capability. Thus, there is a technical gap because an increased number of applications, including real-time applications (RTAs), require low latency communication capabilities.

RTA requires low latency communication and uses best effort communication. The data generated from RTA is called RTA traffic and is packetized into RTA packets at the sender STA. Conversely, data generated from non-time sensitive applications is referred to as non-RTA traffic and is packetized into non-RTA packets at the sender STA.

RTA packets require low latency due to the high timeliness requirements of the RTA packet for packet delivery. It is noted that the RTA packet is valid only when it is transmitted within a certain period of time.

These problems become more complex because some station STAs can perform Simultaneous Transmission and Reception (STR) as STR STAs, while other STAs cannot transmit and receive simultaneously and are referred to as non-STR STAs.

Thus, there is a need for a WLAN CSMA/CA protocol capable of supporting RTA communication for both STR and non-STR STAs. The present disclosure overcomes these problems while providing additional benefits.

Disclosure of Invention

Wireless Local Area Networks (WLANs) operate under IEEE 802.11 protocols, such as 802.11be, using carrier sense multiple access/collision avoidance (CSMA/CA), which allows non-simultaneous transmit/receive (NSTR) Stations (STAs) to occupy channels even if they cannot transmit immediately after obtaining channel access. In this protocol, although the transmission opportunity (TXOP) holders on two links come from different multi-link devices (MLDs), the associated MLDs schedule transmissions on the links at the same time.

Additional aspects of the technology described herein will be set forth in the section below in the description wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon.

Drawings

The techniques described herein will be more fully understood by reference to the following drawings, which are for illustrative purposes only:

fig. 1 is a flowchart of CSMA/CA channel access processing in an IEEE 802.11 wireless LAN.

Fig. 2 is a data field diagram describing a data frame format in a conventional WLAN system.

Fig. 3 is a data field diagram describing an ACK frame format in a conventional WLAN system.

Fig. 4 is a data field diagram describing a High Efficiency (HE) Single User (SU) physical layer protocol data unit (PPDU) format for transmission in IEEE 802.11 ax.

Fig. 5 is a communication diagram of retransmission under CSMA/CA, in which a back-off time increases due to retransmission.

Fig. 6 is a communication diagram of an example in which packets are discarded after the number of retransmissions exceeds a retry limit.

Fig. 7 is a communication diagram of a reference model of an Enhanced DCF Channel Access (EDCA) queue in IEEE 802.11.

Fig. 8 is a communication diagram of a channel access procedure of EDCA in IEEE 802.1D.

Fig. 9 is a data field diagram describing the HT control field format of the a-control subfield variant as defined in IEEE 802.11 ax.

Fig. 10 is a data field diagram of a control information subfield format in the case where the control ID field in fig. 9 indicates that control information is used for BSR.

Fig. 11 is a data field diagram of a control information subfield format in the case where the control ID field in fig. 9 indicates that control information is used for CAS.

Fig. 12 is a communication diagram of a problem that can occur with communications over an NSTR link pair.

Fig. 13 is a hardware block diagram of wireless Station (STA) hardware in accordance with at least one embodiment of the present disclosure.

Fig. 14 is a hardware block diagram of a station structure such as that contained in multi-link device (MLD) hardware in accordance with at least one embodiment of the present disclosure.

Fig. 15 is a network topology of a generic multi-link connection in accordance with at least one embodiment of the present disclosure.

Fig. 16 is a flow diagram of channel access performed by STA4 on Link2 when STA1 is transmitting on Link1 in accordance with at least one embodiment of the present disclosure.

Fig. 17 is a communication diagram of STA4 using dummy frames on Link2 to reserve a TXOP in accordance with at least one embodiment of the present disclosure.

Fig. 18 is a communication diagram of STA4 using a dummy frame on Link2 to reserve a TXOP but lacking an opportunity to transmit to STA2 during the reserved TXOP in accordance with at least one embodiment of the present disclosure.

Fig. 19 is a communication diagram of STA4 using dummy frames on Link2 to occupy a channel in accordance with at least one embodiment of the present disclosure.

Fig. 20 is a communication diagram of STA4 transmitting a PPDU to STA2 on Link2 immediately after STA4 accesses a channel in accordance with at least one embodiment of the present disclosure.

Fig. 21 is a communication diagram of STA4 using a shared frame on Link2 to reserve a TXOP in accordance with at least one embodiment of the present disclosure.

Fig. 22 is a communication diagram of STA4 waiting to communicate with an intended receiver on Link2 with its backoff being zero in accordance with at least one embodiment of the present disclosure.

Fig. 23 is a data field diagram describing a shared frame in accordance with at least one embodiment of the present disclosure.

Fig. 24 is a flow chart of STA4 requesting NSTR coordination such that MLD1 or MLD2 will schedule transmissions on both Link1 and Link2 simultaneously in accordance with at least one embodiment of the present disclosure.

Fig. 25 is a flow chart of STA2 or MLD1 responding to an NSTR coordination request in accordance with at least one embodiment of the present disclosure.

Fig. 26 is a communication diagram of STA4 requesting NSTR coordination to allow MLD1 to schedule transmissions on an NSTR link in accordance with at least one embodiment of the present disclosure.

Fig. 27 is a communication diagram of STA4 requesting NSTR coordination to allow MLD2 to schedule transmissions on an NSTR link in accordance with at least one embodiment of the present disclosure.

Fig. 28 is a communication diagram in which MLD1 denies the NSTR coordination request.

Fig. 29 is a communication diagram of STA4 indicating (requesting) that MLD1 schedule transmission on an NSTR link in accordance with at least one embodiment of the present disclosure.

Fig. 30 and 31 are communication diagrams of re-use of Reverse Direction Grant (RDG) for NSTR coordination in accordance with at least one embodiment of the present disclosure.

Fig. 32 is a data field diagram describing an NSTR reconcile request, response, and indication frame in accordance with at least one embodiment of the present disclosure.

Fig. 33 is a data field diagram describing a ready-to-forward (RTF) frame in accordance with at least one embodiment of the present disclosure.

Fig. 34 is a data field diagram depicting an extended CAS control subfield variant of an a-control subfield in accordance with at least one embodiment of the present disclosure.

Fig. 35 is a network topology of an MLD connection as discussed in this section in accordance with at least one embodiment of the present disclosure.

Fig. 36 is a communication diagram of STA4 using a dummy frame on Link2 to reserve a TXOP while STA1 is transmitting to STA5 in accordance with at least one embodiment of the present disclosure.

Fig. 37 is a communication diagram of an MLD1 accepting an NSTR coordination request and scheduling transmissions for different MLDs on an NSTR link in accordance with at least one embodiment of the present disclosure.

Detailed Description

Introduction to WLAN

CSMA/CA WLAN system

In WLAN systems, IEEE 802.11 uses carrier sense multiple access/collision avoidance (CSMA/CA) to allow STAs to access channels for packet transmission and retransmission.

Fig. 1 depicts a CSMA/CA channel access process. In the CSMA/CA system, the STA needs to sense a channel and set a backoff time to contend for channel access before each transmission and retransmission. The backoff time is determined by a uniform random variable between zero and the size of the contention window. During contention, the STA senses that the channel is idle and reduces its backoff. When the backoff reaches zero, the STA has acquired a channel to transmit the packet. Retransmission may be required if the STA does not receive an Acknowledgement (ACK) before the timeout interval expires. Otherwise, the transmission is successful.

When retransmission is required, the STA checks the number of retransmissions of the packet. If the number of retransmissions exceeds the retry limit, the packet is discarded and no retransmissions are scheduled. Otherwise, retransmission is scheduled.

Another backoff time is required to contend for channel access before retransmission is performed. If the size of the Contention Window (CW) does not reach the upper limit of the CW size, the STA increases the CW size. The STA sets another backoff time according to the new size of the contention window. The STA waits for a backoff time for retransmission and this continues until successful transmission or retransmission is achieved.

Fig. 2 shows a data frame format in a conventional WLAN system. The frame control field indicates the type of frame. The duration field contains NAV information for CSMA/CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA transmitting the frame. The sequence control field contains the fragment number and sequence number of the packet.

Fig. 3 shows an ACK frame format in a conventional WLAN system. The frame control field indicates the type of frame. The duration field contains NAV information for CSMA/CA channel access. The RA field contains the address of the recipient of the frame.

Fig. 4 shows a High Efficiency (HE) Single User (SU) physical layer protocol data unit (PPDU) format for transmission in IEEE 802.11 ax. It should be noted that the PPDU contains at least a preamble field and a data field and has the following fields in at least one embodiment.

The L-STF field is a non-high throughput (non-HT) short training field. The L-LTF field is a non-HT long training field. The L-SIG field is a non-HT signal field. The RL-SIG field is a repeated non-HT signal field. Ext> theext> HEext> -ext> SIGext> -ext> Aext> fieldext> isext> anext> HEext> signalext> Aext> fieldext>.ext> The HE-STF field is an HE short training field. The HE-LTF field is an HE long training field. The data field carries data of a Physical Layer Convergence Procedure (PLCP) protocol data unit, referred to as a (PSDU). The PE field is a packet extension field.

Fig. 5 shows an example of retransmission under CSMA/CA, in which a back-off time increases due to retransmission. The data frame and the ACK frame use the formats as shown in fig. 2 and 3, respectively. Using the packet format as shown in fig. 4, the frames are packed. After the initial transmission of the transmitter transmission packet, it does not receive an ACK before a timeout. Then, it sets another backoff time, whereby the size of the contention window is "n" slots. After waiting for the backoff time, the transmitter STA retransmits the packet for the first time. However, in the example, the retransmission also fails. In order for the transmitter STA to retransmit the packet, it again sets a backoff time to contend for channel access. However, this time, since it is a retransmission, the size of the contention window is doubled, i.e. 2*n slots. The expected backoff time is also doubled by the contention window size. The second retransmission is successful because it receives an ACK before the timeout.

Fig. 6 shows an example in which packets are discarded after the number of retransmissions exceeds the retry limit. In this example, the retry limit is represented by "R". The data frame and the ACK frame use the formats as shown in fig. 2 and 3, respectively. Using the packet format as shown in fig. 4, the frames are packed. As shown in fig. 6, after the initial transmission failure of the packet, the transmitter STA retransmits the packet a plurality of times. However, the retransmission was unsuccessful. After retransmitting R times, the number of retransmissions exceeds the retry limit, whereby the transmitter STA stops retransmitting the packet and the packet is discarded.

EDCA system

Fig. 7 shows a reference model of EDCA queues (enhanced DCF channel access) in IEEE 802.11. The system contains six transmit queues and four Access Categories (ACs). Each AC uses an EDCA function (EDCAF) to contend for channel access so that packets in its corresponding transmit queue can be transmitted.

The six transmit queues are speech (VO), alternative speech (a VO), alternative video (a VI), video (VI), best Effort (BE) and Background (BK). Each transmit queue determines the order in which packets in the queue are transmitted.

The four ACs are Voice (VO), video (VI), best Effort (BE), and Background (BK). Each AC has an EDCA function (EDCAF) to provide a function of channel contention. When multiple EDCAFs attempt to access channels simultaneously, an internal collision avoidance mechanism is used. When an internal collision occurs, the EDCAF with higher priority gains channel access.

Table 1 lists the UP-to-AC mapping used in the EDCA queue of IEEE 802.11. The second and third columns represent user priorities of the services and their corresponding designations in IEEE 802.1D. In each row, traffic will be queued in the corresponding transmit queue and access class according to user priority. The priority increases from top row to bottom row. Traffic with higher priority has a higher probability of being sent earlier.

Fig. 8 shows the channel access procedure of EDCA. As shown in the figure, it also compares EDCA channel access when only a Distributed Coordination Function (DCF) is used.

When only DCF is used, the STA can immediately access the channel and the medium is idle beyond DCF inter space (DIFS) time; otherwise, it uses CSMA/CA to contend for the channel. After sensing the channel idle DIFS time, the STA starts counting down its backoff as soon as the medium is idle. The number of backoff slots is randomly selected between zero and its contention window. When CCA is busy (or medium busy) occurs, for example when the STA senses that the channel is busy, the STA pauses counting back down the backoff. When the backoff count reaches zero, the STA starts transmitting packets.

In EDCA, each EDCAF as shown in fig. 7 is able to access a channel immediately if the medium is idle for more than DIFS time or more than an arbitration inter-frame space (AIFS) time of the AC required to obtain channel access. It should be noted that AIFS [ i ] as shown in the figure represents the AIFS time of AC i. Otherwise, each EDCAF uses CSMA/CA to contend for the channel for each AC for which channel access is to be obtained. After sensing the channel idle AIFS time, it starts counting down its backoff when the medium is idle. The number of backoff slots to be counted down is randomly selected between zero and its contention window size. When CCA is busy (or medium busy) occurs, i.e., when the STA senses that the channel is busy, the STA pauses counting back down the backoff. When the backoff countdown reaches zero, the STA starts transmitting packets of the AC.

It should be noted that multiple EDCAFs may compete for channels in parallel. For example, EDCAF for AC i and AC j can contend for the channel simultaneously, as shown in FIG. 8. When an internal collision occurs, the EDCAF with higher priority gains channel access, and the EDCAF with lower priority will double its contention window. When the ACs are VO or VI, they can reserve a contention free time (such as TXOP) for transmitting packets. The maximum duration of a TXOP is denoted as the TXOP limit.

Table 2 lists default parameter settings for EDCA channel access. Each AC has its own minimum contention window and maximum contention window. The AIFSN represents the AIFS duration in terms of the number of backoff slots. The TXOP limit represents the maximum duration of the TXOP that each AC can reserve at a time.

Control subfield variants of A-Control subfields

Fig. 9 shows the HT control field format of the a-control subfield variant as defined in IEEE 802.11 ax. The format indication field is used to indicate the format of the HT control field. When bits B0 and B1 are set to 1, it indicates that the HT control field uses HE/EHT format. There is an a-control field followed by this field. The a-control field carries different types of buffer status reports. The control ID field indicates the type of control information subfield. For example, when this bit is set to a value of "3", the control information field carries BSR information. The control information field carries control information indicated in the control ID field.

Fig. 10 shows a control information subfield format in the case where the control ID field in fig. 9 indicates that control information is used for BSR.

Fig. 11 shows a control information subfield format in the case where the control ID field in fig. 9 indicates that control information is used for CAS.

2. Statement of problem

MLDs may provide the capability of Simultaneous Transmission and Reception (STR), and these MLDs can transmit on one link while receiving on any other link due to their low in-device coexistence interference. However, the non-STR (NSTR) MLD cannot securely perform these simultaneous transmission and reception. Although STAs in either STR-MLD or non-STR MLD can transmit or receive simultaneously.

The present disclosure contemplates channel contention performed by a multi-link device (MLD) over an NSTR link pair using CSMA/CA. For MLD, in-device coexistence interference is high between the links of its NSTR link pair, e.g., interference due to signaling performed by an STA of the MLD on one link of the NSTR link pair can interfere with or block signal reception performed by another STA of the same MLD on the other link of the NSTR link pair. Thus, when an MLD receives on one of its NSTR link pairs, it should not transmit on the other of its same NSTR link pairs.

Fig. 12 shows a problem that can occur when STR MLD communicates with NSTR MLD via the NSTR link pair of NSTR MLD. Examples of this scenario are discussed in later sections, where MLD1 is the NSTR MLD and Link1 and Link2 are one NSTR Link pair of MLD 1.

Referring to fig. 12, a problem can occur when STA1 affiliated to MLD1 is a TXOP holder on Link1 and STA4 affiliated to MLD2 obtains channel access on Link2 to transmit to STA 2. STA3 can determine that STA1 is the TXOP holder on Link1 and monitor the status of STA1, for example, to determine whether STA1 is transmitting or receiving. If STA1 transmits and STA4 immediately accesses the channel and transmits to STA2, a transmission collision can occur due to in-device coexistence interference between NSTR links. If STA4 does not immediately access the channel, it may no longer access the channel after STA1 finishes transmitting on Link 1. The simplest solution is to prohibit STA4 from accessing the channel on Link 2. However, this conventional technique reduces the efficiency of transmission. Thus, the teachings of the present disclosure allow STAs (e.g., STA 4) that are not STR MLDs to access the channel and communicate with STA2, which results in wider bandwidth, higher throughput, and lower latency. This process can also create problems, despite its simple implementation.

In particular, the problem arises in the way STA4 informs STA2 or MLD1 that it is the TXOP holder on Link 2. STA4 must occupy the channel immediately after it accesses the channel. However, when STA4 accesses the channel, the following is possible: STA1 may be transmitting on Link 1. Then, the MLD1 (i.e., STA2 affiliated to the MLD 1) cannot receive the communication from the STA 4.

Since TXOP holders on Link1 and Link2 are different, in-device coexistence Interference (IDC) can often occur when the transmission directions of the two links are different. Accordingly, this disclosure describes a process for scheduling transmissions on Link1 and Link 2.

3. Contribution of the present disclosure

The present disclosure teaches a protocol (apparatus/method) to allow STAs other than STR MLD to occupy a channel even when the STAs (e.g., STA 4) are not allowed to transmit immediately (e.g., to STA 2) after gaining channel access (e.g., on Link 2).

Although the TXOP holders on the two links are from different MLDs, the disclosed CSMA/CA WLAN protocol allows either MLD (e.g., MLD1 or MLD 2) to schedule transmissions on the two links at the same time.

4. Hardware embodiment

STA and MLD hardware architecture

Fig. 13 shows an exemplary embodiment 10 of STA hardware configured to perform the protocols of the present disclosure. The external I/O connection 14 is preferably coupled to an internal bus 16 of the circuit 12, the internal bus 16 having a CPU 18 and a memory (e.g., RAM) 20 connected thereto for executing programs implementing a communication protocol. The host houses at least one modem 22 to support communications, the modem 22 being coupled to at least one RF module 24, 28, each RF module being connected to one or more antennas 29, 26a, 26b, 26c to 26n. An RF module having multiple antennas (e.g., an antenna array) allows beamforming to be performed during transmission and reception. In this way, STAs can transmit signals using multiple sets of beam patterns.

Bus 14 allows various devices to be connected to the CPU, such as to sensors, actuators, etc. The instructions from the memory 20 are executed on the processor 18 to execute programs implementing communication protocols that are executed to allow the STA to perform the functions of an Access Point (AP) station or a regular station (non-AP STA). It should also be appreciated that programming is configured to operate in different modes (TXOP holder, TXOP sharing participant, source, intermediate component, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinated, AP in OBSS, STA in OBSS, etc.) depending on what role it performs in the current communication context.

Thus, STA HW is shown configured with at least one modem and associated RF circuitry for providing communication over at least one frequency band. The present disclosure relates generally to the sub-6 GHz band.

It should be understood that the present disclosure can be configured with a plurality of modems 22, each coupled to any number of RF circuits. In general, the use of a larger number of RF circuits will result in a larger coverage area for the antenna beam direction. It should be appreciated that the number of RF circuits and the number of antennas used is determined by the hardware constraints of the particular device. When the STA determines that it is not necessary to communicate with a nearby STA, the RF circuitry and a portion of the antenna may be disabled. In at least one embodiment, the RF circuitry includes a frequency converter, an array antenna controller, and the like, and is connected to multiple antennas that are controlled to perform beamforming for transmission and reception. In this way, STAs can transmit signals using multiple sets of beam patterns, each beam pattern direction being considered an antenna sector.

In addition, it should be noted that multiple instances of station hardware as shown in the figures can be combined into a multi-link device (MLD) that would typically have a processor and memory for coordinating the station's activities.

Fig. 14 shows an exemplary embodiment 40 of a multi-link device (MLD) hardware architecture. There are two types of links for MLD, called primary and conditional links. A conditional link is a link that forms a non-simultaneous transmit and receive (NSTR) link pair with some basic links.

Multiple STAs are affiliated with the MLD, each STA operating on a different frequency link. The MLD has external I/O access to the application, which is connected to an MLD management entity 48 having a CPU 62 and a memory (e.g. RAM) 64 to allow execution of programs implementing communication protocols at the MLD level. The MLD is able to assign a task to each affiliated station to which it is connected and collect information from each affiliated station, which is exemplified herein as STA 142, STA 2 through STA N46, and share information among affiliated STAs.

In at least one embodiment, each STA of the MLD has its own CPU 50 and memory (RAM) 52, the CPU 50 and memory (RAM) 52 being coupled to at least one modem 54 by a bus 58, the modem 54 being connected to at least one RF circuit 56 having one or more antennas. In this example, the RF circuit has a plurality of antennas 60a, 60b, 60c to 60n, such as in an antenna array. The modem, in conjunction with RF circuitry and associated antenna, transmits/receives data frames for the neighboring STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with its antenna.

It should be appreciated that each STA of an MLD does not necessarily need its own processor and memory, as STAs may share resources with each other and/or with an MLD management entity depending on the particular MLD implementation. It should be understood that the above MLD diagrams are given by way of example and not limitation, and that the present disclosure is capable of operating with a wide range of MLD implementations.

4.2. STA topology for exemplary use

Fig. 15 shows an embodiment 70 of an exemplary network topology for explaining the objects of the present disclosure. It should be understood that such a topology (and all topologies illustrated herein) is described by way of example and not by way of limitation, as the apparatus and methods of the disclosure are not limited to any particular topology. In addition, specific MLD, STA, and link references are provided throughout this disclosure only to simplify understanding of operation. Note that Link1 and Link2 are one NSTR Link pair of MLD 1.

A multi-link device (MLD) is a device that: the apparatus has a plurality of affiliated STAs (typically two) and has one MAC Service Access Point (SAP) to Logical Link Control (LLC) including one MAC data service. If the STA of the MLD is an AP STA, the MLD is regarded as an AP MLD; otherwise, if the non-AP STA is affiliated with the MLD, the MLD is a non-AP MLD.

As shown in the exemplary figures, it is assumed that these STAs on the two MLDs 74, 76 are located within the structure 72 (such as a conference room). STA1 78 and STA2 80 are affiliated with MLD1, while STA382 and STA4 84 are affiliated with MLD2.STA1 and STA2 are associated with STA3 and STA4 via Link1 86 and Link288, respectively.

It will be appreciated that Link1 and Link2 will be, in some instances, an NSTR Link pair such as MLD1, as illustrated in the operational presentation of the present disclosure in this NSTR case. It should be noted that all STAs use CSMA/CA for random channel access on all links. In this particular exemplary topology, MLD1 is considered as NSTR MLD, while MLD2 is considered as STR MLD. Link1 and Link2 are one NSTR Link pair of MLD 1. STA1 communicates with STA3 via Link1 and STA2 communicates with STA4 via Link 2. The network topology as shown in the figure can represent the following two scenarios: (a) MLD2 is STR AP MLD and MLD1 is NSTR non-AP MLD, or (b) MLD1 is soft AP and MLD2 is STR non-AP MLD.

It should be noted that the term "softap" is an abbreviated term for "software enabled access point" or "NSTR mobile AP MLD"; wherein the software enables the STA to become an AP; as the station hardware may be the same as a conventional (non-AP) STA.

In the network topology shown in the drawings, it is assumed that MLD2 can determine the transmission and reception conditions of STA1 on Link1 because STA3 affiliated to MLD2 transmits or receives with STA1 on Link 1. Then, MLD2 can share status information of STA1 on Link1 with its affiliated STA4 on Link 2.

Channel access over NSTR link

This section explains: when STA1 is the TXOP holder on Link1, STA4 accesses the channel on Link 2. For simplicity of explanation, the network topology shown in fig. 15 is used in the flowchart and communication examples.

4.3.1. Channel access handling

Fig. 16 shows an exemplary embodiment 90 of channel access performed by STA4 on Link2 when STA1 transmits on Link 1.

When STA1 affiliated to MLD1 transmits 92 on Link1, STA4 affiliated to MLD2 accesses the channel on Link2 and communicates with STA2 affiliated to MLD 1.

In the case where Link1 and Link2 are the NSTR Link pair of MLD1, STA2 may not be able to receive from STA4 on Link2 (overhear STA 4) when STA1 transmits on Link 1. Thus, in block 94, STA4 transmits a dummy frame (such as a short frame without a packet) to STA2 to reserve a TXOP on Link 2. It should be noted that STA4 is able to broadcast dummy frames. The dummy frame may be created in many forms, such as a Ready To Send (RTS), a multi-user RTS (MU-RTS), a MU-RTS TXOP sharing (TXS) frame, a Clear To Send (CTS), a CTS-to-Self frame, or other shared frames, for example, as shown in fig. 23. The reserved TXOP time requested by the dummy frame occupies the channel until STA2 can receive from STA4 on Link2, after which STA4 can immediately transmit the frame to STA2.

A check 96 is made to determine if STA4 has an opportunity (occasion) to transmit to STA2 (e.g., STA2 to receive) before the TXOP reserved by the dummy frame ends. If the condition is met, STA4 sends 98 a packet to STA 2.

Otherwise, STA4 does not send packet 100 to STA 2. As a result, STA4 may immediately start a new backoff, or in some cases will not start a new backoff until the TXOP of STA1 ends, or it may start a new backoff when it has a packet to send to other STAs, or keep the backoff count at zero.

4.3.2. Link access examples

This section provides several examples to demonstrate that STA4 accesses a channel on Link2 when STA1 is the TXOP holder on Link 1. This facilitates a wider channel communication bandwidth between MLDs (i.e., MLD1 and MLD 2), which results in higher throughput and lower latency. It should be noted that as shown in the example in this section, the PPDUs (STA 4 to STA 2) may include an NSTRCrd request/indication frame (e.g., as seen in fig. 32 to 34) or a PPDU with rdg=1 and the NSTR coordination indication set to a first state (e.g., "1"), as shown in section 4.4, the NSTR coordination indication set to the first state initiates NSTR coordination.

In the example shown in this section, it is assumed that MLD2 can determine the transmission and reception conditions of STA1 on Link1, because STA3 affiliated to MLD2 transmits or receives with STA1 on Link 1. Then, MLD2 shares status information of STA1 on Link1 with its subordinate STA4 on Link 2.

Fig. 17 shows an exemplary embodiment 110 of STA4 using dummy frames on Link2 to reserve TXOPs. The figure depicts MLD2 76 with its associated STA3 82 and STA4 84, MLD2 76 communicating with MLD1 74 with associated STA1 78 and STA2 80.

The TXOP 112 is obtained by STA1 on Link1 and STA1 begins transmitting 114 to STA3 on Link 1. Then, while STA1 transmits on Link1, STA4 obtains channel access to transmit to STA 2. STA4 transmits a dummy frame 116 to reserve the TXOP for a short period of time. Before the end of the reserved TXOP for a short period of time, STA1 completes its transmission and begins to receive 118 from STA3 via Link 1. When STA1 receives, STA4 can send PPDU 120 to STA2, ensuring that STA2 reception will not be impeded by in-device coexistence interference.

It should be noted that although the direction of PPDU transmission on the two links should be aligned, PPDU alignment between the two links may not be necessary. In other words, the direction of PPDU transmission on both links should be UL or DL at the same time). The following is possible: when STA1 receives, the transmission information (preamble and MAC header of PPDU) on Link1 can help STA4 transmit PPDU (STA 4 to STA 2).

During the time between the dummy frame on Link2 and the PPDU from STA4 to STA2, STA4 may need to perform Carrier Sense (CS) 119 to sense channel conditions. If the channel becomes busy during this time, STA4 may not be able to transmit a PPDU from STA4 to STA2 and begin a new channel contention.

It should be noted that MLD2 is STR MLD. STA4 is thus able to start and end PPDU transmissions (e.g., may include multiple PPDUs) for STA2 within the time that STA4 receives on Link 1.

Fig. 18 shows an exemplary embodiment 130 in which STA4 uses a dummy frame to reserve a TXOP on Link2, but lacks the opportunity to transmit to STA2 during the reserved TXOP. In this case, when STA1 transmits on Link1, it sequentially transmits a plurality of PPDUs. The MLD, STA, and link are the same as those seen in fig. 17.

Again, STA1 is seen to acquire 112TXOP and begins transmitting 114 to STA 3. Then, while STA1 transmits on Link1, STA4 gains channel access to Link2 to transmit to STA2 and transmits 116 a dummy frame to reserve the TXOP for a short period of time. STA1 is still transmitting on Link1 during the reserved TXOP of short period 132; whereby STA4 cannot transmit to STA2 a PPDU that can be heard by STA 2. Therefore, the STA4 does not transmit any PPDU to the STA2 during the TXOP of a short period of time, and cannot access the channel.

After a short period of TXOP, STA4 may re-contend for the channel. In this case, in at least one embodiment/mode/case, STA4 continues channel access without increasing the Contention Window (CW) of the channel.

Fig. 19 shows an exemplary embodiment 150 in which STA4 uses dummy frames on Link2 to occupy the channel. The MLD, STA, and link are the same as those seen in fig. 18.

Again, STA1 is seen to acquire 112TXOP and begins transmitting 114 to STA 3. Then, while STA1 transmits on Link1, STA4 gains channel access to Link2 to transmit to STA2 and transmits 152 a dummy frame to occupy the channel for transmission to STA 2.

In this example, STA4 aligns the end time of the dummy frame 152 with the end time of STA1 transmission. This can be achieved because STA4 can determine the time at which STA1 ends transmitting, such as based on PPDU length information from STA 3. The dummy frames may include padding in the frames to achieve alignment.

After STA1 ends the transmission and begins receiving 154 on Link1, STA4 can transmit PPDU(s) 156 to STA2 and ensure that there is no in-device coexistence interference to prevent it from being heard by STA 2. It should be noted that, for example, if the direction of PPDU transmission on two links is properly aligned, then PPDU alignment between the two links may not be necessary when STA4 transmits a PPDU to STA 2.

During the time between the dummy frame on Link2 and the PPDU from STA4 to STA2, STA4 may need to perform Carrier Sensing (CS) to determine channel conditions. If the channel becomes busy during this time, STA4 may not be able to transmit a PPDU from STA4 to STA2 and begin a new channel contention.

Fig. 20 shows an exemplary embodiment 170 in which STA4 transmits a PPDU to STA2 on Link2 immediately after STA4 accesses the channel. The MLD, STA, and link are the same as those seen in fig. 19.

STA1 is seen to acquire 112TXOP and begins to receive 172 transmissions from STA 3. Then, when STA1 receives on Link1, STA4 gains channel access to Link2 to transmit to STA2 and transmits PPDU 174 to STA2 without any delay required to prevent interference, and thus, STA4 PPDU is immediately received by STA 2.

Fig. 21 shows an exemplary embodiment 190 of STA4 using a shared frame on Link2 to reserve a TXOP. The MLD, STA, and link are the same as those seen in fig. 17.

Again, STA1 is seen to acquire 112TXOP and begins transmitting 114 to STA 3. Then, while STA1 transmits on Link1, STA4 gains channel access to Link2 to transmit to STA2 and transmits a sharing frame 192, as shown in fig. 23, to allow other STAs to share the TXOP. Then, while STA1 is still transmitting 114 to STA3, STA4 shares 194 a TXOP with other STAs.

STA4 shares a TXOP with other STAs before it can transmit PPDUs (i.e., PPDUs STA4 through STA2 in the drawing) to STA 2. That is, other STAs can transmit during the shared TXOP time (i.e., the time between the shared frame and PPDU STA4 through STA 2). For example, the shared TXOP time can be obtained from a TXOP shared time field in the shared frame. Other STAs are not allowed to transmit beyond the TXOP sharing time. Then, STA4 stops TXOP sharing and transmits a packet 156 to STA 2.

It should be noted that, for example, in the case where the directions of PPDU transmission on two links are aligned, when STA4 transmits a PPDU to STA2, PPDU alignment between the two links may not be necessary.

In at least one embodiment/mode/scenario, the shared frame is replaced with a multi-user (MU) RTS TXOP shared (TXS) frame. STA4 is also allowed to transmit trigger frames instead of shared frames to trigger some transmissions before it begins transmissions with STA 2. Allowing STA4 to exchange frames with other STAs before it begins transmitting to STA 2.

Fig. 22 shows an exemplary embodiment 210 of STA4 waiting for a backoff to communicate with an intended receiver on Link 2. The MLD, STA, and link are the same as those seen in fig. 17.

Again, STA1 is seen to acquire 112TXOP and begins transmitting 114 to STA 3. Then, STA4 counts down its Backoff (BO) to zero for Link2 when STA1 transmits on Link1, and keeps the BO count at zero when STA1 transmits on Link2, as described with respect to fig. 23.

When STA4 is able to transmit a PPDU to STA2 (i.e., PPDU STA4 through STA2 in the drawing), it accesses channel 214 and transmits PPDU 156 to STA 2.

It should be noted that PPDU alignment between two links may not be necessary, such as when the direction of PPDU transmission on the two links is aligned, when STA4 transmits a PPDU to STA 2.

3.3.3. Frame format

Fig. 23 shows an exemplary embodiment 230 of a shared frame with the following fields.

The frame control field indicates the type of frame. The duration field contains NAV information for CSMA/CA channel access. The RA field contains the address of the recipient of the frame. This RA field can also be broadcast. The TA field contains the address of the STA transmitting the frame.

The TXOP shares an information field. Other STAs may contend for the channel to obtain the TXOP, however, they need to end their TXOP (without exceeding the transmission of the TXOP) before the end of the TXOP sharing. The TXOP sharing indication field indicates whether TXOP sharing is allowed. This field may include a one-bit indication (flag); for example, if the field is set to a first state (e.g., "1"), TXOP sharing is allowed. When this field is set to a second state (e.g., "0"), TXOP sharing is not allowed. When the receiver STA receives this field, if the field is set to the TXOP shared state, it recognizes that it can be transmitted during the TXOP shared time. The TXOP shared time field indicates the time that the receiver STA may use to transmit after receiving this frame. The receiver STA should not transmit more than the TXOP sharing time. If the RA is broadcast, the receiver STAs contend for the channel before transmitting.

Including an access category field. The AC constraint field indicates whether only the AC specified in the ACI field can be transmitted during the TXOP sharing time. This field may include a one-bit indication; for example, when set to a first state (e.g., "1"), the receiver STA can only transmit traffic of the AC specified in the ACI field. Otherwise, the STA can transmit traffic from all ACs. The ACI field indicates the AC whose traffic can be sent during the TXOP sharing time. The format of this field can be the same as the ACI bitmap field or ACI high field shown in fig. 10.

Coordination over links of NSTR link pairs

To simplify the discussion of the examples, the network topology shown in fig. 15 is used in the flow diagrams and examples.

This section explains the manner in which STA4 requests coordination of transmissions on both Link1 and Link2 (denoted NSTR coordination) when STA1 and STA4 are TXOP holders on Link1 and Link2, respectively. When NSTR coordination of transmission occurs, MLD1 or MLD2 schedules transmission on both links simultaneously (i.e., serves as the TXOP holder). The MLD scheduled for transmission can then transmit or receive on both links simultaneously to avoid in-device coexistence (IDC) interference between the two links.

NSTR request processing

Fig. 24 shows an exemplary embodiment 250 in which STA4 requests NSTR coordination so that MLD1 or MLD2 schedules transmissions on both Link1 and Link 2. It should be understood that the MLD and STA numbers are used only to distinguish between MLDs and STAs, and the flow chart is not limited to any particular numbered MLD or STA.

When STA1 affiliated to MLD1 is TXOP holder 252 on Link1, STA4 affiliated to MLD2 performs channel access on Link2 and is to communicate with STA2 affiliated to MLD 1.

Then, in block 254, STA4 requests STA2 or MLD1 to have MLD1 (or MLD 2) schedule transmission on both Link1 and Link 2. It should be noted that when STA4 accesses the channel on Link2, if STA1 transmits on Link1, STA4 may not be able to transmit to STA2 on Link 2. By way of example and not limitation, STA4 can use the method described in section 4.3 to occupy the channel and transmit packets to STA2 at the appropriate time.

A check 256 is made to determine whether the MLD (MLD 1) has accepted the request. If the condition is met, MLD1 (or MLD2, respectively) simultaneously arranges 258 transmissions on both Link1 and Link2 on both links to eliminate the chance of in-device coexistence (IDC) interference occurring. It should be noted that in some cases, MLD1 (or MLD2, respectively) can stop scheduling transmissions when one of the TXOPs on both links ends.

Otherwise, if check 256 is not satisfied because the request is not accepted, at block 260, sta4 stops the current TXOP.

Fig. 25 shows an exemplary embodiment 270 of STA2 or MLD1 responding to an NSTR coordination request. When STA1 is the TXOP holder on Link1, STA2 receives 272 an NSTR coordination request from STA4 on Link2 to allow MLD1 (or MLD 2) to schedule transmissions on both links simultaneously.

A check 272 is made to determine if the request is accepted. If the request is accepted, at block 276, MLD1 responds to MLD 2: it accepts the request. Then, MLD1 (or MLD2, respectively) starts transmitting on both links simultaneously with arrangement 278.

Otherwise, if it is determined at block 274 that the request is denied by STA2 or MLD1, at block 280, an option is determined. If option 1 is selected 282, STA2 or MLD1 responds to MLD 2: it denies the request. Alternatively, if option 2 is selected, STA2 or MLD1 can reject request 284 without sending a response.

Examples of NSTR request operations

This section details several examples of STA4 requesting NSTR coordination from MLD1 after it has accessed the channel as described in section 4.3.

Fig. 26 shows an exemplary embodiment 310 in which STA4 requests NSTR coordination to allow MLD1 to schedule transmissions on the NSTR link. The figure depicts MLD 276 with its associated STA3 82 and STA4 84, MLD 276 communicating with MLD1 74 with associated STA1 78 and STA2 80.

STA1 obtains TXOP 112 on Link1 and begins to receive 312 from STA3 on Link 1. STA4 first transmits an NSTR coordination request frame (NSTRCrd Req, as shown in the figure) 314 to STA2 on Link2 to request MLD1 to schedule transmissions on both Link1 and Link 2. In the NSTR coordination request frame, STA4 is also able to indicate the NSTR coordination time that MLD1 will schedule transmission on both links. The buffer status of STA4 or MLD2 can also be carried by the NSTR coordination request frame. As shown in the drawing, although STA1 is a TXOP holder on Link1, STA2 can simultaneously receive an NSTR coordination request frame when STA1 receives.

The MLD1 then accepts the NSTR coordination request 315 and sends an NSTR coordination response frame (NSTRCrd Res, as shown in the figure) 316, 318 back to the MLD2 and associated STA3 and STA4 to accept the sharing request. It should be noted that the transmission of the NSTR coordination response frame on Link1 may not be necessary and that this frame can be replaced by any other PPDU transmitted by STA 1. Meanwhile, MLD1 schedules transmission on both links at the same time. For example, MLD1 can control simultaneous transmission on both links, or simultaneous reception on both links.

It should be noted that the format of the NSTR coordination request frame and the NSTR coordination response frame can be similar to the format of the frame in fig. 32. In at least one embodiment/mode/case, the NSTR coordination request frame may include a Ready To Forward (RTF) frame as shown in fig. 33 or a BSR frame as defined in IEEE 802.11ax, and the NSTR coordination response frame is a trigger frame as defined in IEEE 802.11 ax.

When MLD1 takes over the TXOPs on both links, PPDUs on both links should be sent in the same direction since both links belong to the same NSTR link pair. The figure describes PPDU transmissions 320 and 322 performed in a TXOP.

It should be noted that as the NSTRCrd Res (STA 2 to STA 4) on Link2 can provide the result of the NSTR coordination request, the NSTRCrd Res (STA 1 to STA 3) on Link1 shown in the figure can be replaced by any other PPDU. That is, it is not necessary to transmit NSTRCrd Res (STA 1 to STA 3) on Link 1.

Fig. 27 shows an exemplary embodiment 330 in which STA4 requests NSTR coordination to allow MLD2 to schedule transmissions on the NSTR link. The MLD, STA, and link are the same as those seen in fig. 26.

STA1 obtains TXOP 112 on Link1 and begins to receive 312 from STA3 on Link 1. STA4 sends an NSTR coordination request frame (NSTRCrd Req, as shown in the figure) 314 to request that transmissions be scheduled on both Link1 and Link 2. In the NSTR coordination request frame, STA4 is also able to indicate the period in which MLD1 should schedule transmission on both links. The buffer status of STA4 or MLD2 can also be carried by the NSTR coordination request frame. As shown in the drawing, although STA1 is a TXOP holder on Link1, STA2 can receive a sharing request frame when STA1 receives.

MLD1 then accepts 315 the NSTR coordination request and sends back to MLD2 NSTR coordination response frames (NSTRCrd Res, as shown in the figure) 316 and 318 to accept the NSTR coordination request. It should be noted that the transmission of the NSTR coordination response frame on Link1 may not be necessary and that this frame can be replaced by any other PPDU transmitted by STA 1. Then, MLD2 starts transmitting on both links with an arrangement 319. When MLD2 takes over the TXOPs on both links, PPDUs on both links should be sent in the same direction since both links belong to the same NSTR link pair. The figure shows PPDU transmission 332 from STA3 to STA1 and simultaneous PPDU transmission 334 from STA4 to STA 2.

It should be noted that the format of the NSTR coordination request frame and the NSTR coordination response frame can be similar to the format of the frame shown in fig. 32. In at least one embodiment/mode/scenario, the NSTR coordination request frame includes a Ready To Forward (RTF) frame as shown in fig. 33 or a BSR frame as defined in IEEE 802.11ax, and/or the NSTR coordination response frame is a MU-RTS TXS trigger frame as defined in IEEE 802.11 be.

Fig. 28 shows an exemplary embodiment 350 of MLD1 rejecting the NSTR coordination request. The MLD, STA, and link are the same as those seen in fig. 27.

STA1 obtains TXOP 112 on Link1 and begins to receive 352 from STA3 on Link 1. STA4 on Link2 sends an NSTR coordination request frame (NSTRCrd Req, as shown in the figure) 354 at this time to request MLD1 or MLD2 to schedule transmission on both Link1 and Link 2. In the NSTR coordination request frame, STA4 is also able to indicate when the MLD should schedule transmission on both links. The buffer status of STA4 or MLD2 can also be carried by the NSTR coordination request frame. As shown in the drawing, although STA1 is a TXOP holder on Link1, STA2 can receive a sharing request frame when STA1 receives.

MLD1 rejects 355 the NSTR coordination request and STA2 sends an NSTR coordination response frame (NSTRCrd Res, as shown in the figure) 358 back to STA4 to reject the NSTR coordination request. At the same time, STA1 can continue its transmission 356 on Link 1. MLD2 may then end the TXOP on Link2 and re-contend for the channel.

It should be noted that the format of the NSTR coordination request frame can be similar to the format of the frame shown in fig. 32.

Fig. 29 shows an exemplary embodiment 370 in which STA4 indicates (requests) that MLD1 is allowed to schedule transmissions on the NSTR link. The MLD, STA, and link are the same as those seen in fig. 28.

STA1 obtains TXOP 112 on Link1 and begins to receive 312 from STA3 on Link 1. STA4 on Link2 sends an NSTR coordination indication frame (NSTR crd Ind, as shown in the figure) 314 to STA2 at this time and indicates (requests) that MLD1 should schedule transmission on both Link1 and Link 2. In the NSTR coordination indication frame, STA4 is also able to choose to indicate when MLD1 should schedule transmission on both links. The buffer status of STA4 or MLD2 can also be carried by the NSTR coordination indication frame. As shown in the drawing, although STA1 is a TXOP holder on Link1, STA2 can simultaneously receive an NSTR coordination indication frame when STA1 receives.

Then, MLD1 accepts the request and starts to arrange PPDU transmission on both links. As shown in the figure, STA1 can start transmitting PPDUs 372 and 376 to STA3 on Link1 and STA2 can start transmitting PPDUs 374 and 378 to STA4 on Link 2. When MLD1 schedules transmission on both links, it should arrange it so that the transmission directions on both links are the same. During transmission on each link, the PPDUs may be aligned or misaligned.

It should be noted that the format of the NSTR indication frame can be similar to the format of the frame shown in fig. 32 or the MU-RTS TXS trigger frame as defined in IEEE 802.11 be.

It should also be noted that the first PPDU on Link2 (STA 2 through STA 4) can carry an acknowledgement frame to indicate that the NSTRCrd Ind frame has been successfully received.

Fig. 30 and 31 illustrate an exemplary embodiment 390 that re-uses Reverse Direction Grant (RDG) for NSTR coordination. The PPDU in the figure can carry the extended CAS control subfield as shown in fig. 34 in its HT control field.

The MLD, STA, and link are the same as those seen in fig. 29. STA1 obtains TXOP 112 on Link1 and begins receiving 392 from STA3 on Link 1.

STA4 transmits a PPDU 394 on Link2 (with RDG set to active (e.g., "1") and the NSTR coordination indication set to active (e.g., "1")) to indicate that MLD1 is able to schedule transmissions on both Link1 and Link 2.

MLD1 then schedules transmissions on both Link1 and Link2 using PPDUs 398, 400, 402, 404, 406, 408, 410, and 412. The RDG/more PPDU field in the PPDU transmitted by MLD1 is set to active (e.g., "1") to indicate ongoing NSTR coordination. The NSTR coordination period 396 is shown as delimiting PPDU transmissions.

The RDG/more PPDU field in the PPDU is set to ensure that the direction of PPDU transmission on both links is the same. For example, when RDG is inactive (e.g., "0") on Link1 and more PPDUs are active (e.g., "1") on Link2 at the same time, the next PPDUs on Link1 and Link2 will be sent by MLD 1. When RDG is set to active on Link1 and more PPDUs are inactive on Link2 at the same time, the next PPDUs on Link1 and Link2 will be sent by MLD 2. When more PPDUs are active on Link1 (e.g., "1") and simultaneously RDG is inactive on Link2 (e.g., "0"), the next PPDUs on Link1 and Link2 will be transmitted by MLD 2. When more PPDUs are inactive (e.g., "0") on Link1 and simultaneously RDG is active (e.g., "1") on Link2, the next PPDUs on Link1 and Link2 will be transmitted by MLD 1.

It should be noted that the RDG and more PPDU subfields share the same bits in the PPDU. When the STA is the TXOP holder, it transmits the RDG field in the PPDU. When the STA is a TXOP responder, it transmits the More data field in the PPDU. When the NSTR coordination indication is invalid in the PPDU, the NSTR coordination ends.

NSTR coordination format

Fig. 32 shows an exemplary embodiment 430 of an NSTR reconcile request, response and indication frame with the following fields. Thus, it should be appreciated that this frame is used in at least one embodiment for the NSTR coordination request, NSTR coordination response, and NSTR coordination indication.

The frame control field indicates the type of frame. This can indicate whether this frame is an NSTR coordination request frame or an NSTR coordination response frame or an NSTR coordination indication frame. In at least one embodiment/mode/case, this field only indicates that the frame carries NSTR coordination information, and it does not indicate whether it is an NSTR coordination request, response or indicates a frame. The duration field contains NAV information for CSMA/CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA transmitting the frame.

The NSTRCrd frame type field is set to indicate the type of NSTR coordination frame. When this field is set to "request", the frame is an NSTR coordination request frame. In response to such a request, the receiver decides whether it accepts the request based on the NSTR coordination information as indicated in the frame. The receiver of this frame may also respond with an NSTR coordination response frame to indicate its decision. When this field is set to "response", the frame is an NSTR coordination response frame. Upon receipt of this frame, the result (decision) regarding its NSTR coordination request is determined. If the request is accepted, both the sender and receiver of this frame will follow the NSTR coordination information as indicated in the frame. If the request is denied, the receiver of this frame may end the current TXOP and re-contend for the channel. When this field is set to "indicate", this frame is an NSTR coordination indication frame. The receiver of this frame thus determines that it can take over the TXOP resources as indicated in the NSTR coordination indication frame and act as the TXOP holder.

The NSTRCrd information field is set to indicate NSTR coordination information. When the STA or MLD receives such information, it can use the information in this field to perform NSTR coordination. The NSTRCrd indication field is an NSTR coordination indication set to indicate an NSTR coordination condition. This field can be implemented as a one-bit indication.

When this field is set to active (e.g., "1") in the NSTR coordination request frame, it indicates that the transmitter requests NSTR coordination. Otherwise, it is set to inactive (e.g., "0"). When the receiver receives this field in the NSTR coordination request frame, it can recognize that the transmitter is requesting NSTR coordination and decide to accept or reject the request and indicate its decision in the NSTR coordination response frame.

When this NSTR coordination field is set to active (e.g., "1") in the NSTR coordination response frame, it indicates that the transmitter of the NSTR coordination response frame accepts the NSTR coordination request from the receiver of the NSTR coordination response frame. Otherwise, it is set to inactive (e.g., "0") and instructs the transmitter to reject the NSTR coordination request. If this field is set to valid (e.g., "1"), the transmitter and receiver of this frame will begin NSTR coordination. Otherwise, the receiver is aware that the NSTR coordination request has been denied and it may end the current TXOP and re-contend for the channel.

When this NSTR coordination field is set to active (e.g., "1") in the NSTR coordination indication frame, it instructs the transmitter of the NSTR coordination indication frame to allow the receiver of the NSTR coordination indication frame to schedule transmission during the NSTR coordination time. The receiver can then take over the TXOP and act as the TXOP holder during the NSTR coordination time. Otherwise, this field is set to invalid (e.g., "0").

The NSTR coordinator field is set to indicate which MLD should schedule transmission or act as a TXOP holder during the NSTR coordination period on the link.

When this field is set to the transmitter MLD of the NSTR coordination request frame, it represents that the transmitter MLD should act as a TXOP holder on both links of the NSTR link pair during the NSTR coordination time.

When this field is set to the receiver MLD of the NSTR coordination request frame or NSTR coordination indication frame, this indicates that the receiver MLD should act as a TXOP holder and schedule transmission during the NSTR coordination time on both links of the NSTR link pair.

The NSTRCrd time field is set to indicate the NSTR coordination time on the link. This field indicates: the NSTR coordinator can schedule transmissions or act as a TXOP holder during the following NSTR coordination time.

The AC constraint field is set to indicate the AC that can send its traffic during the NSTR coordination time. It should be noted that this field may only be valid on the link that sent this field. If this field is valid on both links, then the transmissions on both links should follow the AC constraints indicated in this field.

This AC constraint field can be set to a single AC. Then, in at least one embodiment/mode/scenario, only traffic from the AC can be sent during the NSTR coordination time. In some instances, this field can represent the master AC during the NSTR coordination time. The transmitter and receiver of this field should follow a transmission rule (such as the TXOP sharing rule in IEEE 802.11 ax) to transmit during the NSTR coordination time. In at least one embodiment/mode/case, traffic from an AC having a priority higher than or equal to the AC indicated in this field can be sent during the NSTR coordination time.

This AC constraint field can also include an AC bitmap, whereby each bit represents an AC. When a bit in this field is set to be active (e.g., "1"), traffic from the AC corresponding to the bit is sent during the NSTR coordination time. Otherwise, this bit is set to inactive (e.g., "0") so that traffic from the AC corresponding to the bit will not be sent during the NSTR coordination time.

This AC constraint field can also include a one-bit indication. When this bit is set to active (e.g., "1"), only traffic from the primary AC can be sent during the NSTR coordination time. Otherwise, if this bit is set to inactive (e.g., "0"), traffic from any AC can be sent during the NSTR coordination time. TXOP sharing as defined in IEEE 802.11ax may be allowed.

The NSTR link ID field is set to indicate to the other link of the NSTR link pair: the NSTR coordinator will schedule transmissions during the NSTR coordination and act as a TXOP holder.

The minimum MPDU size field is set in the NSTR coordination request or indication frame to indicate that the STA setting this field requests the minimum MPDU size transmitted during the NSTR coordination time. When the NSTR coordination process begins, any MDPU transmitted by the STA that sets this field should be greater than the minimum MPDU size. This field can be set in a number of ways, by way of example and not limitation, the following. This field can be set in the NSTR coordination response frame by copying the value from the corresponding NSTR coordination request frame if the NSTR coordination request is accepted. This field can also be set in the NSTR coordination response frame to indicate a minimum size of MPDUs that the STA setting this field will transmit during the NSTR coordination time. It should be noted that this field can also contain a minimum MSDU size to indicate the minimum MSDU or a-MSDU size that the STA setting this field will send during the NSTR coordination time.

The transmit time field is set in an NSTR coordination request or indication frame to indicate a minimum period of time during which an STA setting this field has requested to transmit a PPDU to a receiver of this field. When NSTR coordination begins, the STA that sets this field should be allocated at least this amount of time for its transmission. This field can be set in a number of ways, by way of example and not limitation, the following. This field can be set in the NSTR coordination response frame by copying the value from the corresponding NSTR coordination request frame if the NSTR coordination request is accepted. This field can also be set in the NSTR coordination response frame to indicate the minimum time required for the STA that sets this field to perform its transmission during the NSTR coordination time.

The buffer status report field is set by the transmitter STA to indicate its buffer status. When the NSTR coordinator receives this field, it should schedule transmission during the NSTR coordination time based on the buffer status of the receiving transmitter. In at least one embodiment, this field can be formatted as defined in IEEE 802.11 ax.

Fig. 33 shows an exemplary embodiment 450 of an RTF frame. The frame control field indicates the type of frame. The duration field contains NAV information for CSMA/CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA transmitting the frame. The BSR control field is set by the transmitter to indicate its buffer status. When the STA receives this field, it can schedule transmission based on the buffer status of the receiving transmitter. The format of this field can be implemented as the same as defined in IEEE 802.11 ax. The trigger type field is set to indicate the trigger type that the transmitter requests the receiver to transmit after receiving this frame. The common information (Info) field is the same as the common information field of the trigger frame as indicated in the trigger type. The receiver should replicate the common information in the requested trigger frame it sends. The user information (Info) field is the same as the user information field of the trigger frame as indicated in the trigger type. The receiver should replicate the common information in the requested trigger frame it sends.

Fig. 34 illustrates an exemplary embodiment 470 of an extended CAS control subfield variant of the a-control subfield.

The AC constraint field can be represented in different ways, including using a one-bit indication. By way of example and not limitation, the unit indicator (flag) is implemented as follows. When this bit is set to a first state (e.g., "1"), only traffic from the primary AC can be sent during the NSTR coordination time. Otherwise, if this bit is set to a second state (e.g., "0"), traffic from any AC can be sent during the NSTR coordination time. TXOP sharing as defined in IEEE 802.11ax may be allowed.

The RDG/more PPDU field is a multi-purpose field. When the sender of this field is the TXOP holder, this field is the Reverse Direction Grant (RDG) field. If this bit is set to be valid (e.g., "1"), the next PPDU should be transmitted by the receiver. If this bit is set to invalid (e.g., "0"), the next PPDU is still transmitted by the transmitter.

When the transmitter of this field is a TXOP responder, this field is a more PPDU field. If this bit is set to be valid (e.g., "1"), the next PPDU should be transmitted by the transmitter. If this bit is set to invalid (e.g., "0"), the next PPDU should be transmitted by the receiver.

The PSRT PPDU subfield can be identical to the PSRT PPDU subfield as defined in IEEE 802.11 ax.

The NSTRCrd indication field is an NSTR coordination indication set to indicate an NSTR coordination condition. This field can be implemented in many ways, including using a one-bit indication (flag). Setting this field to a first state (e.g., "1") in the NSTR coordination indication frame indicates: NSTR coordination is ongoing. The MLD transmitting the following PPDUs should ensure that the direction of the PPDUs on the link is the same. Otherwise, this field is set to a second state (e.g., "0").

The NSTRCrd time field is set to indicate the NSTR coordination time on the link. This field indicates: the NSTR coordinator is allowed to schedule transmissions or act as a TXOP holder during the following NSTR coordination time.

The field ACI, scale factor, and queue size are fields representing the buffer status of the sender. The receiver can use this information for scheduling transmissions. The ACI field indicates the access category of the buffer reported by the transmitter. The scale factor field indicates a unit of queue size. The encoding of this field can be the same as in IEEE 802.11 ax. The queue size field indicates the amount of buffered traffic of the sender in units of scale factors.

4.5. Another example of a network topology

The previous example in section 4.4.2 shows NSTR coordination between MLD1 and MLD2 when STA1 affiliated with MLD1 is the TXOP holder on Link1 and communicates with STA3 affiliated with MLD 2. However, there may be cases where: when STA4 gains channel access on Link1 to initiate NSTR coordination, STA1 is the TXOP holder but does not communicate with STA 3. In this section, such a scenario is discussed.

Fig. 35 shows an exemplary embodiment 490 of a network topology as discussed in this section. In comparison with fig. 15, the network topology shown in fig. 35 adds another station STA5, STA5 being able to communicate with STA1 on Link 1. STA5 can be an STA that is affiliated to an MLD (e.g., MLD 3) or an STA that is not affiliated to an MLD as shown in the drawing.

It should be understood that embodiment 490 is an exemplary network topology for explaining the operations in this section. It should be understood that such a topology is described by way of example and not by way of limitation, as fig. 15, as the apparatus and methods of the present disclosure are not limited to any particular topology. In addition, specific MLD, STA and link references are provided throughout this disclosure only to simplify understanding of the operations in question.

As shown in the exemplary figures, it is assumed that STAs are located on three MLDs 494, 496 and 498 found within a structure 492, such as a conference room. STA1 500 and STA2 502 are affiliated with MLD1 494, STA3 504 and STA4 506 are affiliated with MLD2 496, and STA5508 and STA6 510 are affiliated with MLD3 498.STA1 and STA2 associate (communicate) with STA3 and STA4 via Link1 512 and Link2 514, respectively. Note that Link1 and Link2 are one NSTR Link pair of MLD 1. STA1 and STA5 communicate via Link1 516, link1 516 being peer-to-peer (P2P) communication.

In the figures, this is considered to be possible: MLD2 is STR AP, while MLD1 and MLD3 are non-AP MLDs associated with MLD 2. It should be noted that the association between MLD2 and MLD3 is not shown in the drawing, but the association between MLD2 and MLD3 can be achieved by the AP STA affiliated to MLD2 being associated with the non-AP STA affiliated to MLD3 via Link1 or Link2 or any other Link.

All STAs use CSMA/CA for random channel access on all links. Also assume in the network topology of fig. 35 that: since STA3 affiliated to MLD2 monitors transmissions between STA1 and STA5 on Link1, such as in response to checking the TA, RA fields of the TDLS frame, MLD2 is able to determine the transmission and reception conditions of STA1 on Link 1. Then, MLD2 can share status information of STA1 on Link1 with its affiliated STA4 on Link 2.

The example shown in section 4.3 illustrates channel access by STA4 when STA1 is communicating with STA 3. However, it is also possible that: when STA4 accesses the channel, STA1 is communicating with other STAs not affiliated to the same MLD as STA 4. This section shows: the same channel access method shown in section 4.3 also operates in this scenario.

Fig. 36 shows an exemplary embodiment 530 of STA4 using dummy frames on Link2 to reserve a TXOP similar to fig. 17, except that STA1 is transmitting to STA 5. The network topology for this example is shown in fig. 35.

The TXOP is obtained 532 by STA1, after which it begins to transmit 534 to STA 5. STA1 is transmitting on Link1 when STA4 gains channel access to transmit to STA 2. Thus, STA4 transmits a dummy frame 536 to reserve the TXOP for a short period of time. Before the end of the reserved TXOP for a short period of time, STA1 ends the transmission and begins receiving 540 from STA5 on Link 1. When STA1 begins to receive, STA4 is able to transmit PPDU 542 received by STA2 to STA2 without any possibility of in-device coexistence interference. It should be noted that PPDU alignment between two links may not be necessary. However, the direction of PPDU transmission on both links should be aligned. It should also be noted that the transmission information (preamble and MAC header of PPDU) on Link1 may help STA4 transmit PPDUs (STA 4 to STA 2) when STA1 receives.

During the time between the dummy frame on Link2 and the PPDU from STA4 to STA2, STA4 may need to perform carrier sensing (538 CS) to sense channel conditions. If the channel becomes busy during this time, STA4 may not be able to transmit a PPDU from STA4 to STA2 and begin a new channel contention process.

It should be noted that MLD2 is STR MLD. STA4 can start and end PPDU transmissions (which can be more than one PPDU) for STA2 within the time that STA4 receives on Link 1.

The example shown in section 4.4 represents NSTR coordination initiated by STA4 when STA1 is communicating with STA 3. However, in some examples, STA1 may be communicating with other STAs not affiliated to the same MLD as STA4 when STA4 accesses the channel. This section shows: the NSTR coordination mechanism also operates in this scenario.

Fig. 37 illustrates an exemplary embodiment 570 of MLD1 accepting an NSTR coordination request and scheduling transmissions for different MLDs on an NSTR link. The network topology in this example is shown in fig. 35.

The TXOP is obtained 532 by STA1, after which it begins to receive 572 from STA 5. STA4 first transmits an NSTR coordination request frame (NSTRCrd Req, as shown in the figure) 574 to STA2 to request that MLD1 schedule transmissions on both Link1 and Link 2. In the NSTR coordination request frame, STA4 is also able to indicate the period in which MLD1 should schedule transmission on both links. The buffer status of STA4 or MLD2 can also be carried by the NSTR coordination request frame. As shown in the drawing, although STA1 is a TXOP holder on Link1 in communication with STA5, STA2 can simultaneously receive an NSTR coordination request frame when STA1 receives.

Then, MLD1 accepts the NSTR coordination 575 and, when STA1 of MLD1 is transmitting PPDU 576 to STA5, STA2 transmits an NSTR coordination response frame (NSTRCrd Res, as shown in the drawing) 578 back to STA4 to accept the NSTR coordination request. MLD1 schedules transmissions on both links simultaneously. It should be noted that the TXOP responders on Link1 are STAs 5 that are not affiliated with MLD 2. In this case, when MLD1 starts to schedule transmission on both links, it continues its transmission with STA5 (shown as PPDUs 576 and 578) on Link1 and also starts transmission with STA4 (shown as PPDUs 582) on Link 2. It should be noted that when MLD1 schedules transmissions on two links, it should have the transmission directions on both links the same. During transmission on each link, the PPDUs may be aligned or misaligned.

It should be noted that the format of the NSTR coordination request frame and the NSTR coordination response frame can be similar to the format of the frame shown in fig. 32. In at least one embodiment/mode/case, the NSTR coordination request frame is an RTF frame as shown in fig. 33 or a BSR frame as defined in IEEE 802.11ax, and the NSTR coordination response frame is a trigger frame as defined in IEEE 802.11 ax.

5. General scope of the examples

Embodiments of the present technology may be described herein with reference to flowchart illustrations and/or procedures, algorithms, steps, operations, formulas, or other computational descriptions of methods and systems according to embodiments of the technology, which may also be implemented as computer program products. In this regard, each block or step of the flowcharts, and combinations of blocks (and/or steps) in the flowcharts, and any process, algorithm, step, operation, formula, or computational description can be implemented by various means, such as hardware, firmware, and/or software, including one or more computer program instructions embodied in computer readable program code. It will be appreciated that any such computer program instructions may be executed by one or more computer processors (including, without limitation, general purpose computers or special purpose computers or other programmable processing devices) to produce a machine, such that the computer program instructions which execute on the computer processor or other programmable processing devices create means for implementing the functions specified.

Accordingly, blocks and processes of the flowcharts, algorithms, steps, operations, formulas, or computational descriptions herein support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and computer program instructions for performing the specified functions such as those embodied in computer readable program code logic means. It will also be understood that each block of the flowchart illustrations, and any process, algorithm, step, operation, formula, or computational description, and combinations thereof, described herein can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer readable program code.

Additionally, such computer program instructions, such as embodied in computer-readable program code, may also be stored in one or more computer-readable memories or storage devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memories or storage devices produce an article of manufacture including instruction means which implement the functions specified in the flowchart block(s). The computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the flowchart block(s), process, algorithm, step(s), operation(s), formula(s), or computational description.

It will also be appreciated that, as used herein, the term "program" or "program executable" refers to one or more instructions capable of being executed by one or more computer processors to perform one or more functions as described herein. The instructions can be embodied in software, in firmware, or in a combination of software and firmware. The instructions can be stored locally with respect to the device in a non-transitory medium, or can be stored remotely such as on a server, or all or a portion of the instructions can be stored locally as well as remotely. The remotely stored instructions can be downloaded (pushed) to the device by user initiation, or automatically based on one or more factors.

It will also be understood that, as used herein, the terms processor, hardware processor, computer processor, central Processing Unit (CPU), and computer are synonymously used to denote a device capable of executing instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to include single or multiple devices, single and multi-core devices, and variations thereof.

From the description herein, it will be appreciated that the present disclosure includes a variety of implementations of the technology, including but not limited to the following implementations:

an apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit as a Station (STA) for performing a multi-link operation on a plurality of links of a channel and accessing the channel using carrier sense multiple access/collision avoidance (CSMA/CA) to communicate with other wireless Stations (STAs) of the network; (b) A processor coupled to the wireless communication circuit to execute a communication protocol; (c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs on the network; and (d) wherein the instructions, when executed by the processor, perform one or more steps comprising: (d) (i) wherein the first multi-Link device (MLD 1) is configured to perform non-simultaneous transmit receive (NSTR) communications and is a transmit opportunity (TXOP) holder of the first Link (Link 1); (d) (ii) wherein the STA operates in a second multi-Link device (MLD 2) and accesses a channel on a second Link (Link 2) to transmit to MLD 1; (d) (iii) wherein if MLD1 is receiving on Link1, then MLD2 immediately transmits to MLD1 on Link 2; and (d) (iv) wherein if MLD1 is transmitting on Link1, MLD2 transmits a frame on Link2 to occupy the channel, and then when MLD1 is receiving on Link1, MLD2 performs transmission of another frame to MLD 1.

An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit as a Station (STA) for performing a multi-link operation on a plurality of links of a channel and accessing the channel using carrier sense multiple access/collision avoidance (CSMA/CA) to communicate with other wireless Stations (STAs) of the network; (b) A processor coupled to the wireless communication circuit to execute a communication protocol; (c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs on the network; and (d) wherein the instructions, when executed by the processor, perform one or more steps comprising: (d) (i) wherein the STA is associated with a second multi-link device (MLD 2) and the other STA is associated with a first multi-link device (MLD 1) for performing non-simultaneous transmit receive (NSTR) communications; (d) (ii) wherein MLD1 is a transmission opportunity (TXOP) holder of the first Link (Link 1); (d) (iii) wherein the second MLD (MLD 2) is the TXOP holder of the second Link (Link 2) and is intended to transmit to MLD1 on Link 2; (d) (iv) transmitting, by MLD2, a non-simultaneous transmission reception (NSTR) coordination request to MLD1 on Link 2; (d) (v) wherein if MLD2 requests a response frame from MLD1, it receives a response frame from MLD1, the response frame indicating whether MLD1 has accepted or rejected the NSTR coordination request; and (d) (vi) wherein if the NSTR coordination request is accepted, transmission is scheduled by MLD1 or MLD2 on both Link1 and Link2, after which transmission is performed.

A method of performing wireless communication in a network, comprising: (a) Performing, by a wireless communication circuit as a Station (STA), a multi-link operation on a plurality of links of a channel, accessing the channel using carrier sense multiple access/collision avoidance (CSMA/CA) to communicate with other wireless Stations (STAs) of the network; (b) Performing non-simultaneous transmit receive (NSTR) communication by a first multi-Link device (MLD 1), the first multi-Link device (MLD 1) having become a transmit opportunity (TXOP) holder of a first Link (Link 1); (c) Accessing, by the STA associated with a second multi-Link device (MLD 2), a channel on a second Link (Link 2) for transmission to MLD 1; (d) If MLD1 is receiving on Link1, then it is immediately sent by MLD2 to MLD1 on Link 2; and (e) if MLD1 is transmitting on Link1, transmitting a frame by MLD2 on Link2 to occupy the channel, and then when MLD1 is receiving on Link1, MLD2 transmits another frame to MLD 1.

A wireless communication system/device performs transmission of packets, wherein CSMA/CA and multi-Link operation are applied, link1 and Link2 are the NSTR Link pair of MLD1, and MLD1 is the TXOP holder on Link1, comprising: (a) MLD2 accesses the channel on Link2 and will send to MLD 1; (b) If MLD1 is receiving on Link1, MLD2 immediately sends to MLD1 on Link 2; and (c) if MLD1 is transmitting on Link1, MLD2 transmits a frame to occupy the channel, and when MLD1 is receiving on Link1, MLD2 transmits another frame to MLD 1.

A wireless communication system/device performs transmission of packets, wherein CSMA/CA and multi-Link operation are applied, link1 and Link2 are NSTR Link pairs for MLD1, MLD1 is a TXOP holder on Link1, MLD2 is a TXOP holder on Link2 and is to be transmitted to MLD1, comprising: (a) MLD2 transmits an NSTR coordination request to MLD1 on Link 2; (b) the MLD1 then transmits a response frame to accept or reject the request; (c) Wherein if the request is accepted, MLD1 or MLD2 schedules transmission on both Link1 and Link 2.

An apparatus, system, or method as in any of the previous implementations, where MLD2 transmits a dummy frame that does not contain a data packet to reserve a portion of the TXOP and occupy a channel; then, when MLD1 starts to receive on Link1 before TXOP ends, MLD2 transmits a frame with a data packet to MLD1 on Link 2.

An apparatus, system, or method as in any of the previous implementations, where if MLD2 has determined not to wait for the time that MLD1 is receiving on Link1, then MLD2 re-contends for the channel without increasing its Contention Window (CW).

An apparatus, system, or method as in any preceding implementation, where MLD2 sends a Ready To Send (RTS) or a multi-user RTS (MU-RTS), the RTS or MU-RTS comprising padding to occupy channels on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 sends a clear-to-send (CTS) or CTS-to-self to MLD1 to occupy a channel on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 transmits a transmit opportunity (TXOP) shared frame to occupy a channel on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 transmits a transmit opportunity (TXOP) share frame to share TXOPs with other STAs on Link2 until MLD1 receives on Link 1.

The apparatus, system, or method of any of the preceding implementations, wherein the MLD2 transmits an NSTR coordination indication frame to begin NSTR coordination without requesting a response frame from the MLD 1.

A device, system, or method as in any previous implementation, where in response to receiving a frame from MLD1 indicating that it has denied the NSTR coordination request, MLD2 performs stopping its current TXOP.

The apparatus, system, or method of any of the foregoing implementations, wherein MLD2 need not receive a rejection of the NSTR coordination request, as MLD1 may not send anything back that instructs it to reject the NSTR coordination request.

An apparatus, system, or method as in any of the previous implementations, where MLD2 transmits a dummy frame that does not contain a data packet to reserve a portion of the TXOP and occupy a channel; then, when MLD1 starts to receive on Link1 before TXOP ends, MLD2 transmits a frame with a data packet to MLD1 on Link 2.

An apparatus, system, or method as in any of the previous implementations, where if MLD2 has determined not to wait for the time that MLD1 is receiving on Link1, then MLD2 re-contends for the channel without increasing its Contention Window (CW).

An apparatus, system, or method as in any preceding implementation, where MLD2 sends a Ready To Send (RTS) or a multi-user RTS (MU-RTS), the RTS or MU-RTS comprising padding to occupy channels on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 sends a clear-to-send (CTS) or CTS-to-self to MLD1 to occupy a channel on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 transmits a transmit opportunity (TXOP) shared frame to occupy a channel on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 transmits a transmit opportunity (TXOP) share frame to share TXOPs with other STAs on Link2 until MLD1 receives on Link 1.

An apparatus, system, or method as in any of the previous implementations, where MLD2 is capable of transmitting frames to reserve a short TXOP to occupy a channel, and if there is an opportunity before the TXOP ends, transmitting frames to MLD 1.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 is able to decide not to transmit to MLD1 on Link 2.

An apparatus, system, or method as in any of the previous implementations, where if MLD2 cannot wait for the time that MLD1 receives on Link1, then MLD2 can re-contend for the channel without increasing CW.

An apparatus, system, or method as in any of the previous implementations, where MLD2 is capable of sending RTS or MU-RTS with padding to occupy channels on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 is capable of sending CTS or CTS-to-self to MLD1 to occupy a channel on Link 2.

An apparatus, system, or method as in any of the preceding implementations, where MLD2 is capable of transmitting a TXOP sharing frame to occupy a channel on Link 2.

A device, system, or method as in any previous implementation, where MLD2 is able to send a TXOP sharing frame to share TXOPs with other STAs on Link2 until it gets an opportunity to send to MLD 1.

A device, system, or method as in any of the previous implementations, where MLD2 is capable of sending an NSTR coordination indication frame to begin NSTR coordination without requesting a response frame from MLD 1.

A device, system, or method as in any of the preceding implementations, where MLD1 is capable of sending a frame to reject the NSTR coordination request.

A device, system, or method as in any of the previous implementations, where MLD1 cannot send anything back to reject the NSTR coordination request.

As used herein, the term "implementation" is intended to include, without limitation, embodiments, examples, or other forms of implementing the techniques described herein.

As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Unless explicitly so stated, reference to the singular is not intended to mean "unique" but rather "one or more".

Phrase constructs (such as, "A, B and/or C") within the present disclosure describe the case where A, B or C can exist or any combination of items A, B and C. A phrase construct indicating, for example, "at least one of". And listing a set of elements thereafter indicates that at least one of the set of elements is present, including any possible combination of listed elements as desired.

References in the present disclosure to "an embodiment," "at least one embodiment," or similar embodiment words indicate that: the particular features, structures, or characteristics described in connection with the described embodiments are included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases are not necessarily all referring to the same embodiment or to a particular embodiment different from all other embodiments being described. The embodiment phrase should be construed as meaning: the particular features, structures, or characteristics of the given embodiments may be combined in any suitable manner in one or more embodiments of the disclosed devices, systems, or methods.

As used herein, the term "collection" refers to a collection of one or more objects. Thus, for example, a collection of objects can include a single object or multiple objects.

Relational terms such as "first" and "second," "top" and "bottom," and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

The terms "comprises," "comprising," "has," "having," "includes," "including," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, having an element "comprising," "having," "one," "containing," "one," or the like in the foregoing does not exclude the presence of other elements of the same process, method, article, or apparatus that comprises, has, contains, or consists of the element.

As used herein, the terms "approximately," "substantially," "essentially," and "about" or any other version thereof are used to describe and illustrate minor variations. When used in connection with an event or environment, the term can refer to instances where the event or environment occurs precisely, as well as instances where the event or environment occurs approximately. When used in connection with a numerical value, the term can represent a range of variation of less than or equal to ±10% of the numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, "substantial" alignment can represent a range of angular variation of less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

Additionally, amounts, ratios, and other numerical values may sometimes be provided herein in a range format. It is to be understood that such range format is used for convenience and brevity and should be interpreted flexibly to include the numerical values explicitly recited as the limits of the range, but also to include all the individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly recited. For example, ratios in the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also include individual ratios (such as about 2, about 3, and about 4) and subranges (such as about 10 to about 50, about 20 to about 100, etc.).

The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure that is "configured" in some way is configured in at least that way, but may also be configured in ways that are not listed.

The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of the techniques described herein or any or all the claims.

In addition, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting such intent: the claimed embodiments require more features than are expressly recited in each claim. Inventive subject matter may lie in less than all features of a single disclosed embodiment.

The abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. The technical disclosure is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

It will be appreciated that practice in some jurisdictions may require that one or more portions of the present disclosure be deleted after the application is filed. Accordingly, the reader should review the filed application to obtain the original disclosure. Any deletion of the present disclosure should not be construed as a disclaimer, loss of, or dedication of any subject matter of the initially filed application to the public.

The following claims are hereby included in the disclosure, with each claim standing on its own as a separately claimed subject matter.

While the description herein contains many specifics, these should not be construed as limiting the scope of the present disclosure, but merely as providing illustrations of some of the presently preferred embodiments. Accordingly, it will be understood that the scope of the present disclosure fully encompasses other embodiments that may become obvious to those skilled in the art.

All structural and functional equivalents to the elements of the disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. The claim elements herein should not be construed as "means plus function" elements unless the use of the phrase "means for. The claim elements herein should not be construed as "step plus function" elements unless the use of the phrase "step for..th.) explicitly recites an element.

Table 1UP to AC mapping

TABLE 2

Default parameter set

AC	CWmin	CWmax	AIFSN	TXOP limit
					BK	15	1023	7	0
BE	15	1023	3	0
					VI	7	15	2	3ms
VO	3	7	2	1.5ms

Claims (18)

1. An apparatus for wireless communication in a network, the apparatus comprising:

(a) A wireless communication circuit as a Station (STA) for performing a multi-link operation on a plurality of links of a channel and accessing the channel using carrier sense multiple access/collision avoidance (CSMA/CA) to communicate with other wireless Stations (STAs) of the network;

(b) A processor coupled to the wireless communication circuit to execute a communication protocol;

(c) A non-transitory memory storing instructions executable by the processor to communicate with other STAs on the network; and

(d) Wherein the instructions, when executed by the processor, perform one or more steps comprising:

(i) Wherein the first multi-Link device (MLD 1) is configured to perform non-simultaneous transmit receive (NSTR) communication and is a transmit opportunity (TXOP) holder of the first Link (Link 1);

(ii) Wherein the STA operates in a second multi-Link device (MLD 2) and accesses a channel on a second Link (Link 2) to transmit to MLD 1;

(iii) Wherein if MLD1 is receiving on Link1, MLD2 immediately transmits to MLD1 on Link 2; and is also provided with

(iv) Wherein if MLD1 is transmitting on Link1, MLD2 transmits a frame on Link2 to occupy the channel, and then when MLD1 is receiving on Link1, MLD2 performs transmitting another frame to MLD 1.

2. The apparatus of claim 1, wherein the MLD2 transmits a dummy frame that does not contain a data packet to reserve a portion of the TXOP and occupy a channel; then when MLD1 starts to receive on Link1 before TXOP ends, MLD2 sends a frame with data packets to MLD1 on Link 2.

3. The apparatus of claim 1, wherein if MLD2 has determined not to wait for a time for MLD1 to receive on Link1, then MLD2 re-contends for the channel without increasing a Contention Window (CW) of MLD 2.

4. The apparatus of claim 1, wherein MLD2 sends a Ready To Send (RTS) or a multi-user RTS (MU-RTS), the RTS or MU-RTS comprising padding to occupy channels on Link 2.

5. The apparatus of claim 1, wherein MLD2 sends a clear-to-send (CTS) or CTS-to-self to MLD1 to occupy a channel on Link 2.

6. The apparatus of claim 1, wherein MLD2 transmits a transmit opportunity (TXOP) shared frame to occupy a channel on Link 2.

7. The apparatus of claim 1, wherein MLD2 transmits a transmit opportunity (TXOP) share frame to share TXOPs with other STAs on Link2 until MLD1 receives on Link 1.

8. An apparatus for wireless communication in a network, the apparatus comprising:

(a) A wireless communication circuit as a Station (STA) for performing a multi-link operation on a plurality of links of a channel and accessing the channel using carrier sense multiple access/collision avoidance (CSMA/CA) to communicate with other wireless Stations (STAs) of the network;

(b) A processor coupled to the wireless communication circuit to execute a communication protocol;

(c) A non-transitory memory storing instructions executable by the processor to communicate with other STAs on the network; and

(d) Wherein the instructions, when executed by the processor, perform one or more steps comprising:

(i) Wherein the STA is associated with a second multi-link device (MLD 2) and the other STA is associated with a first multi-link device (MLD 1) for performing non-simultaneous transmission and reception (NSTR) communication;

(ii) Wherein MLD1 is a transmission opportunity (TXOP) holder of the first Link (Link 1);

(iii) Wherein the second MLD (MLD 2) is the TXOP holder of the second Link (Link 2) and is intended to transmit to MLD1 on Link 2;

(iv) Transmitting, by MLD2, a non-simultaneous transmission reception (NSTR) coordination request to MLD1 on Link 2;

(v) Wherein if MLD2 requests a response frame from MLD1, then MLD2 receives a response frame from MLD1, the response frame indicating whether MLD1 has accepted the NSTR coordination request or has rejected the NSTR coordination request; and is also provided with

(vi) Wherein if the NSTR coordination request is accepted, transmission is scheduled by MLD1 or MLD2 on both Link1 and Link2, after which transmission is performed.

9. The apparatus of claim 8, wherein the MLD2 transmits an NSTR coordination indication frame to start NSTR coordination without requesting a response frame from the MLD 1.

10. The apparatus of claim 8 wherein in response to receiving a frame from MLD1 indicating that MLD1 has denied the NSTR coordination request, MLD2 performs stopping the current TXOP of MLD 2.

11. The apparatus of claim 8, wherein MLD2 need not receive a rejection of the NSTR coordination request because MLD1 may not send anything back that instructs MLD1 to reject the NSTR coordination request.

12. A method of performing wireless communication in a network, comprising:

(a) Performing, by a wireless communication circuit as a Station (STA), a multi-link operation on a plurality of links of a channel, accessing the channel using carrier sense multiple access/collision avoidance (CSMA/CA) to communicate with other wireless Stations (STAs) of the network;

(b) Performing non-simultaneous transmit receive (NSTR) communication by a first multi-Link device (MLD 1), the first multi-Link device (MLD 1) having become a transmit opportunity (TXOP) holder of a first Link (Link 1);

(c) Accessing, by the STA associated with a second multi-Link device (MLD 2), a channel on a second Link (Link 2) for transmission to MLD 1;

(d) If MLD1 is receiving on Link1, then it is immediately sent by MLD2 to MLD1 on Link 2; and is also provided with

(e) If MLD1 is transmitting on Link1, then a frame is transmitted by MLD2 on Link2 to occupy the channel, and then MLD2 transmits another frame to MLD1 when MLD1 is receiving on Link 1.

13. The method of claim 12, wherein the MLD2 transmits a dummy frame that does not contain a data packet to reserve a portion of the TXOP and occupy a channel; then, when MLD1 starts to receive on Link1 before TXOP ends, MLD2 transmits a frame with a data packet to MLD1 on Link 2.

14. The method of claim 12, wherein if MLD2 has determined not to wait for a time for MLD1 to receive on Link1, then MLD2 re-contends for the channel without increasing a Contention Window (CW) of MLD 2.

15. The method of claim 12, wherein MLD2 sends a Ready To Send (RTS) or a multi-user RTS (MU-RTS), the RTS or MU-RTS comprising padding to occupy channels on Link 2.

16. The method of claim 12, wherein MLD2 sends a clear-to-send (CTS) or CTS-to-self to MLD1 to occupy a channel on Link 2.

17. The method of claim 12, wherein MLD2 transmits a transmit opportunity (TXOP) shared frame to occupy a channel on Link 2.

18. The method of claim 12 wherein MLD2 transmits a transmit opportunity (TXOP) share frame to share TXOPs with other STAs on Link2 until MLD1 receives on Link 1.