CN114424671A

CN114424671A - Method and apparatus for aggregating multiple wireless communication channels to achieve flexible full duplex communication

Info

Publication number: CN114424671A
Application number: CN201980100573.2A
Authority: CN
Inventors: 杨云松
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-09-26
Filing date: 2019-09-26
Publication date: 2022-04-29
Also published as: WO2020101807A3; WO2020101807A2

Abstract

A method, comprising: obtaining a first transmission opportunity (TXOP) on a first shared channel by winning a first channel contention of the first shared channel; transmitting a first transmission according to the first TXOP, the first transmission being part of a sequence of transmissions; receiving the first transmission response, the response being received over a second shared channel, the first shared channel and the second shared channel operating on different radio frequency carriers; obtaining a second TXOP by winning a second channel contention; transmitting a second transmission according to the second TXOP, the second transmission being part of the sequence of transmissions.

Description

Method and apparatus for aggregating multiple wireless communication channels to achieve flexible full duplex communication

Technical Field

The present invention relates generally to systems and methods for digital communications, and in particular embodiments to methods and apparatus for aggregating multiple wireless communication channels to enable flexible full duplex communications.

Background

A duplex communication system is a point-to-point system consisting of two or more devices that are able to communicate with each other in two directions. Duplex communication systems are of two types: full duplex and half duplex. In a full duplex system, two devices can communicate with each other simultaneously. In a half-duplex system, two devices are able to communicate with each other, but not simultaneously, i.e. the communication is one direction at a time.

Time-division duplexing (TDD) simulates full-duplex communication over a half-duplex channel by separating the outgoing and return signals in the time domain. TDD enables flexible and adaptive utilization of wired or wireless communication media when uplink and downlink traffic are asymmetric. TDD, on the other hand, tends to waste bandwidth when switching between transmission and reception, and has a greater inherent delay. Examples of TDD-based wireless communication technologies include UTRA-TDD, LTE-TDD, bluetooth, and IEEE 802.11; wherein, UTRA-TDD is a TDD derivative System of the third generation (3G) Universal Mobile Telecommunications System (UMTS); LTE-TDD is a fourth generation (4G) Long-Term Evolution (LTE) TDD-derived system. In UTRA-TDD and LTE-TDD, the timeslot patterns allocated for downlink and uplink traffic are pre-configured and indicated to User Equipment (UE) by infrastructure equipment (e.g., Node B or enhanced Node B). In bluetooth and IEEE802.11, transmitters must contend for the right to transmit over a shared Wireless Medium (WM) or channel, whether infrastructure devices or not.

Frequency-division duplexing (FDD) means that the transmitter and receiver operate at different carrier frequencies so that the sending of outgoing signals and the receiving of return signals can occur simultaneously. Examples of wireless communication systems based on FDD include UTRA-FDD, which is an FDD-derived system for 3G UMTS, and LTE-FDD, which is an FDD-derived system for 4G LTE.

Disclosure of Invention

According to a first aspect, a method implemented by a first device in a contention-based communication system is provided. The method comprises the following steps: the first device obtains a first transmission opportunity (TXOP) on a first shared channel by winning a first channel contention of the first shared channel; the first device sends a first transmission to a second device according to the first TXOP, the first transmission being part of a transmission sequence; the first device receiving the first transmission response from the second device, the response received over a second shared channel, the first shared channel and the second shared channel operating on different radio frequency carriers; the first device obtains a second TXOP by winning a second channel contention; the first device sends a second transmission to the second device according to the second TXOP, the second transmission being part of the sequence of transmissions.

In a first implementation form of the method according to the first aspect, the second TXOP is located on the second shared channel and the second channel contention is won on the second shared channel.

In a second implementation form of the method according to the first aspect as such or any of the preceding implementation forms of the first aspect, the first transmission response indicates a reception failure of a third transmission occurring before the first transmission, and the second transmission is a retransmission of the third transmission.

In a third implementation form of the method according to the first aspect as such or any of the preceding implementation forms of the first aspect, the first transmitted response is received before the first device sends the request for the first response.

In a fourth implementation form of the method according to the first aspect as such or any of the preceding implementation forms of the first aspect, the first transmission is a Transmission Control Protocol (TCP) segment, the first transmission response is a TCP acknowledgement indicating that the first transmission was successfully received, and the second transmission is sent after the first transmission.

In a fifth implementation form of the method according to the first aspect as such or any of the preceding implementation forms of the first aspect, the method further comprises: the first device receives the second transmission response from the second device, the second transmission response being received over the first shared channel.

In a sixth implementation form of the method according to the first aspect as such or any of the preceding implementation forms of the first aspect, the first device and the second device are stations operating in a peer-to-peer communication mode.

In a seventh implementation form of the method according to the first aspect as such or any of the preceding implementation forms of the first aspect, the first device is an Access Point (AP), and the second device is a non-AP station.

In an eighth implementation form of the method according to the first aspect as such or any of the preceding implementation forms of the first aspect, the first device is a non-AP station and the second device is an AP.

According to a second aspect, a method for communicating between a first device and a second device is provided. The first device and the second device operate in a contention-based communication system, and the method is implemented by the second device. The method comprises the following steps: the second device receiving a first transmission from the first device over a first shared channel, the first transmission being part of a sequence of transmissions; the second device obtains a first TXOP on a second shared channel by winning a first channel contention on the second shared channel, wherein the first shared channel and the second shared channel operate on different radio frequency carriers; the second device sends the first transmission response to the first device according to the first TXOP; the second device receives a second transmission from the first device according to whether the shared channel is available, the second transmission being part of the sequence of transmissions.

In a first implementation form of the method according to the second aspect, the second transmission is received over the second shared channel.

In a second implementation form of the method according to the second aspect as such or any of the preceding implementation forms of the second aspect, the response indicates that a third transmission was received in failure, the third transmission occurs before the first transmission, and the second transmission is a retransmission of the third transmission.

In a third implementation form of the method according to the second aspect as such or any of the preceding implementation forms of the second aspect, the first transmission response is sent before the second device receives the request for the first transmission response.

In a fourth implementation form of the method according to the second aspect as such or any of the preceding implementation forms of the second aspect, the first transmission is a TCP segment, the first transmission response is a TCP acknowledgement indicating that the first transmission was received successfully, and the second transmission is sent after the first transmission.

In a fifth implementation form of the method according to the second aspect as such or any of the preceding implementation forms of the second aspect, the method further comprises: the second device obtains a second TXOP on the first shared channel by winning a second channel contention on the first shared channel; and the second equipment sends the second transmission response to the first equipment according to the second TXOP.

In a sixth implementation form of the method according to the second aspect as such or any of the preceding implementation forms of the second aspect, the first device and the second device are stations operating in a peer-to-peer communication mode.

In a seventh implementation form of the method according to the second aspect as such or any of the preceding implementation forms of the second aspect, the first device is an Access Point (AP), and the second device is a non-AP station.

In an eighth implementation form of the method according to the second aspect as such or any of the preceding implementation forms of the second aspect, the first device is a non-AP station and the second device is an AP.

According to a third aspect, a multi-link (ML) communication device is provided. The ML communication device includes: a first Radio Frequency (RF) chain for transmitting and receiving data through a first shared channel; a second RF chain for transmitting and receiving data through a second shared channel; a demultiplexer/multiplexer unit operably coupled to the first and second RF chains, the demultiplexer/multiplexer unit to selectively route the data between the first and second RF chains and a Media Access Control (MAC) layer entity of the ML communication device according to a criterion of selecting a channel from the first and second shared channels when transmitting the data and according to an address associated with the data when receiving the data; an interface unit operably coupled to the MAC layer entity and a higher layer entity of the ML communication device, the interface unit to receive data from the higher layer entity for transmission over the selected channel and to transmit data received from the first shared channel and the second shared channel to the higher layer entity.

According to the third aspect, in a first implementation manner of the ML communication device, the ML communication device further includes: a first Physical (PHY) layer entity operably coupled to the first RF chain and the demultiplexer/multiplexer unit, the first PHY layer entity to prepare data for transmission over the first RF chain and process data received over the first RF chain; a second PHY layer entity operably coupled to the second RF chain and the demultiplexer/multiplexer unit, the second PHY layer entity to prepare data for transmission over the second RF chain and to process data received over the second RF chain.

In a second implementation form of the ML communication device according to the third aspect as such or any of the preceding implementation forms of the third aspect, the higher-layer entity is co-located with the ML communication device.

In a third implementation form of the ML communication device according to the third aspect as such or any of the preceding implementation forms of the third aspect, the address comprises a MAC address or parts of a MAC address.

In a fourth implementation form of the ML communication device according to the third aspect as such or any of the preceding implementation forms of the third aspect, the first shared channel is a master channel and the second shared channel is a slave channel.

According to a fourth aspect, a first ML communication device is provided. The first ML communication device includes: one or more processors; a non-transitory memory comprising instructions that, when executed by the one or more processors, cause the first ML communication device to: obtaining a first TXOP on a first shared channel by winning a first channel contention on the first shared channel; transmitting a first transmission to a second ML communication device in accordance with the first TXOP, the first transmission being part of a sequence of transmissions; receiving the first transmission response from the second ML communication device, the response received over a second shared channel, the first and second shared channels operating on different radio frequency carriers; obtaining a second TXOP by winning a second channel contention; transmitting a second transmission to the second ML communication device in accordance with the second TXOP, the second transmission being part of the sequence of transmissions.

In a first implementation form of the first ML communication device according to the fourth aspect, the second TXOP is located on the second shared channel and the second channel contention is won on the second shared channel.

In a second implementation form of the first ML communication device according to the fourth aspect as such or any of the preceding implementation forms of the fourth aspect, the first transmission response indicates a third transmission reception failure occurring before the first transmission, and the second transmission is a retransmission of the third transmission.

In a third implementation form of the first ML communication device according to the fourth aspect as such or any of the preceding implementation forms of the fourth aspect, the first transmission is a TCP segment, the first transmission response is a TCP acknowledgement indicating that the first transmission was received successfully, and the second transmission is sent after the first transmission.

In a fourth implementation form of the first ML communication device according to the fourth aspect as such or any of the preceding implementation forms of the fourth aspect, the instructions further cause the first ML communication device to receive the second transmission response from the second ML communication device, the second transmission response being received over the first shared channel.

In a fifth implementation form of the first ML communication device according to the fourth aspect as such or any of the preceding implementation forms of the fourth aspect, the first ML communication device and the second ML communication device are stations operating in a peer-to-peer communication mode.

In a sixth implementation form of the first ML communication device according to the fourth aspect as such or any of the preceding implementation forms of the fourth aspect, the first device is an AP and the second device is a non-AP station.

In a seventh implementation form of the first ML communication device according to the fourth aspect as such or any of the preceding implementation forms of the fourth aspect, the first ML communication device is a non-AP station and the second device is an AP.

According to a fifth aspect, a first ML communication device is provided. The first ML communication device includes: one or more processors; a non-transitory memory comprising instructions that, when executed by the one or more processors, cause the first ML communication device to: receiving a first transmission from a second ML communication device over a first shared channel, the first transmission being part of a sequence of transmissions; obtaining a first TXOP on a second shared channel by winning a first channel contention on the second shared channel, the first shared channel and the second shared channel operating on different radio frequency carriers; transmitting the first transmission response to the second ML communication device according to the first TXOP; receiving a second transmission from the second ML communication device in accordance with whether the shared channel is available, the second transmission being part of the sequence of transmissions.

In a first implementation form of the first ML communication device according to the fifth aspect, the first response indicates a failure to receive a third transmission, the third transmission occurs before the first transmission, and the second transmission is a retransmission of the third transmission.

In a second implementation form of the first ML communication device according to the fifth aspect as such or any of the preceding implementation forms of the fifth aspect, the first transmission is a TCP segment, the first transmission response is a TCP acknowledgement indicating that the first transmission was received successfully, and the second transmission is sent after the first transmission.

In a third implementation form of the first ML communication device according to the fifth aspect or any of the preceding implementation forms of the fourth aspect, the instructions further cause the first ML communication device to: obtaining a second TXOP on the first shared channel by winning a second channel contention on the first shared channel; and sending the second transmission response to the second ML communication device according to the second TXOP.

An advantage of the preferred embodiments is that there is no restriction on the direction of communication (i.e., downlink or uplink) of any shared channel. Any available shared channel may be dynamically used (e.g., on a first come first served basis) to transmit data or responses to data in the downlink or uplink direction. Thus, a response to received data may be sent back without interrupting or delaying the reception of subsequent data in the opposite direction. By reducing the queuing delay for transmitting upper layer protocol responses (e.g., TCP ACKs), a transmitting device can not only move its transmission window forward (which is used for congestion control purposes) to more quickly release subsequent data for transmission, but can also increase the size of the transmission window (until a limit is reached) so that more data can be transmitted while the corresponding upper layer acknowledgement is pending. Thus, the upper layer throughput is more quickly brought up to the highest throughput that can potentially be supported by the end-to-end path.

Drawings

For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

fig. 1A illustrates an exemplary communication system consisting of an infrastructure BSS;

fig. 1B illustrates an exemplary 802.11 network with stations communicating over an aggregated shared channel;

FIG. 2 illustrates an exemplary data transmission sequence between legacy devices that conform to 802.11;

FIG. 3 illustrates another exemplary data transmission sequence between 802.11 compliant legacy devices utilizing burst transmission;

fig. 4 illustrates yet another exemplary data transmission sequence between 802.11-compliant legacy devices involved in sending Transmission Control Protocol (TCP) data;

fig. 5 illustrates an exemplary block diagram of two devices communicating with each other using two contention-based TDD channels for flexible full duplex communication provided by exemplary embodiments described herein;

FIG. 6 illustrates a block diagram of a DEMUX/MUX unit provided by exemplary embodiments described herein;

FIG. 7 illustrates a detailed exemplary high level entity provided by the exemplary embodiments described herein;

FIG. 8A illustrates the format of an 802.11 data signal carrying higher layer data or higher layer responses provided by the exemplary embodiments described herein;

fig. 8B illustrates a frame format of an 802.11 Medium Access Control (MAC) layer control frame carrying an Acknowledgement (ACK) provided by the exemplary embodiments described herein;

fig. 8C illustrates a frame format of an 802.11MAC layer control frame carrying a Block ACK Request (BAR), Block ACK (BA), or Negative ACK (NACK) provided by the exemplary embodiments described herein;

fig. 9 is a diagram illustrating a first exemplary embodiment of flexible full duplex communication implemented using multiple contention-based TDD channels provided by exemplary embodiments described herein;

fig. 10 is a diagram illustrating a second exemplary embodiment of flexible full duplex communication implemented using multiple contention-based TDD channels provided by exemplary embodiments described herein;

fig. 11 is a diagram illustrating a third exemplary embodiment of flexible full duplex communication implemented using multiple contention-based TDD channels provided by exemplary embodiments described herein;

FIG. 12 illustrates a flowchart of exemplary operations occurring in a transmitter provided by exemplary embodiments described herein;

FIG. 13 illustrates a flowchart of exemplary operations that may occur in a receiver provided by exemplary embodiments described herein;

FIG. 14 illustrates an exemplary communication system provided by the exemplary embodiments described herein;

FIGS. 15A and 15B illustrate exemplary devices that may implement methods and teachings consistent with the present invention;

FIG. 16 illustrates a block diagram of a computing system that may be used to implement the apparatus and methods disclosed herein.

Detailed Description

The structure and use of the disclosed embodiments are discussed in detail below. It should be appreciated, however, that the present invention provides many applicable concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific structures and uses of the embodiments and do not limit the scope of the invention.

IEEE standard 802.11-2016 is a set of Medium Access Control (MAC) and Physical (PHY) layer specifications for implementing wireless Local Area Network (LAN) or wireless fidelity (Wi-Fi) communications in the 2.4GHz, 5GHz, 6GHz, and 60GHz frequency bands. A Basic Service Set (BSS) provides the basic building blocks of an 802.11 wireless LAN. In the infrastructure mode of 802.11, a single Access Point (AP) forms a BSS with all Associated Stations (STAs). The AP acts as a master to control the STAs within the BSS. A Station (STA) may also be referred to as a device, user equipment, terminal, node, etc. An AP may also be referred to as a network controller, a base station, a wireless router (which provides network connectivity since one router is co-located with the AP), etc. The simplest infrastructure BSS consists of one AP and one STA.

Fig. 1A illustrates an exemplary communication system 100 comprised of an infrastructure BSS. Communication system 100 includes an Access Point (AP) 105, access point 105 serving a plurality of stations, such as

STAs

110, 112, 114, 116, and 118. Access point 105 controls certain aspects of communication with or between its associated stations (e.g., radio frequency channels, transmission power limits, authentication, security, etc.). Generally, in the communication system 100, wireless resources for uplink (site-to-access point) and downlink (access point-to-site) transmissions are accessed by transmitters based on a distributed contention mechanism, commonly referred to as carrier sense multiple access with collision avoidance (CSMA/CA). However, the access point 105 may still affect access to the shared channel by assigning different access priorities to different STAs or different types of traffic flows.

An exemplary distributed channel contention procedure includes a transmitter detecting that a shared channel is in an idle state for a pre-specified time period called a distributed inter-frame space (DIFS), and then setting a backoff timer to a random value as a result of detecting that the shared channel is in an idle state for the DIFS. The transmitter decrements the back-off timer to zero at a uniform rate as long as the shared channel remains idle. When the shared channel becomes busy, e.g., when another device wins the channel contention and starts transmitting, the transmitter will pause the countdown, and after the shared channel again becomes idle within the DIFS, the transmitter will restart the countdown of its backoff timer. When the backoff timer reaches zero (or some other specified value), the transmitter determines that it has won channel contention and begins transmitting over the shared channel.

Legacy STAs compliant with 802.11 use Time Division Duplexing (TDD) to implement full duplex communication with each other, in which STAs transmit or receive over the same half-duplex shared channel using different time periods. In general, a channel may also be referred to as a link. Fig. 1B illustrates an exemplary 802.11 network 150 with devices communicating over an aggregated shared channel. Network 150 includes devices that communicate over an aggregated shared channel 160, including device 151 and device 152. The device may be an AP, a STA, or a combination of an AP and a STA. Aggregated shared channel 160 comprises a plurality of shared channels (e.g., 802.11 shared channels), including shared

channels

161, 162, and 163. As mentioned herein, a shared channel is different from another shared channel when the channels are established on different radio frequencies. In one embodiment, transmissions are sent over different shared channels without duplicating each other. In an embodiment, the transmissions are sent over different shared channels, wherein at least some of the transmissions are duplicated and sent over a plurality of different shared channels. For example, sending duplicate transmissions over multiple different shared channels helps to improve the reliability of the redundant transmissions.

Fig. 2 illustrates an exemplary data transmission sequence 200 between legacy devices that conform to 802.11. As shown in fig. 2, the transmitter 210, which is an STA having a data sequence (frame or transmission) to be transmitted, operates in a transmission mode to transmit first data (frame or transmission) 230 of the data sequence after winning channel contention, and then switches to a reception mode to receive a first Acknowledgement (ACK) frame 232 from the receiver 220, which is an intended receiving STA of the data sequence, the first ACK frame 232 confirming that the receiver 220 correctly receives the first data 230. When the transmitter 210 transmits the first data 230, the receiver 220 operates in a reception mode; when the transmitter 210 receives the first ACK frame 232, the receiver 220 operates in a transmit mode. Therefore, both the transmitter 210 and the receiver 220 are STAs capable of transmitting and receiving. The terms "transmitter" and "receiver" are used to emphasize the logical roles these STAs respectively play in transmitting or receiving particular data. A STA may be both a transmitter of one data and a receiver of another data.

A short inter-frame space (SIFS), such as SIFS 240, is the time gap between the first data 230 and the first ACK frame 232 to provide the transmitter 210 and receiver 220 with sufficient time to switch between transmit and receive modes. After receiving the first ACK frame 232, the transmitter 210 initiates another channel contention procedure and, after winning the channel contention, switches to a transmit mode to transmit the second data 245 in the data sequence, then switches to a receive mode to receive a second ACK frame 247, and so on. The DIFS plus random back-off (BO) period 250 is the time gap between the first ACK frame 232 and the second data 245, including the time when the transmitter 210 detects that the channel is in an idle state within the DIFS in order to initiate a random back-off and perform a back-off to win channel contention, and the time when the transmitter 210 and receiver 220 switch between transmit and receive modes. Random backoff involves setting the backoff timer to a random value and then counting down the backoff timer to zero at a uniform rate, as described above.

As shown in fig. 2, the transmitter 210 cannot transmit the subsequent data before receiving the ACK for the current data, and thus may delay transmission of the subsequent data. To address this problem, 802.11 supports a burst transmission mode in which a transmitter transmits a burst of data with an ACK frame uninterrupted therebetween, and at the end of the burst, transmits a Block ACK Request (BAR) frame to request a Block ACK (BA) frame from a receiver, the BA frame including a bitmap indicating whether each data in the burst has been correctly received by the receiver.

Fig. 3 illustrates an exemplary data transmission sequence 300 between 802.11 compliant legacy devices utilizing burst transmission. As shown in fig. 3, the transmitter 310 transmits a burst consisting of three data (e.g.,

data

325, 327, and 329) and BAR frames 335 (with SIFS in between). In response to BAR frame 335, receiver 320 sends BA frame 340, BA frame 340 indicating whether each of the three data in the burst has been correctly received. However, if the receiver 320 loses data early in the burst, the transmitter 310 is unaware of this situation before receiving the BA frame 340, which not only delays retransmission of the lost data, but can also lead to out-of-order transmission or head-end (HOL) blocking. HOL blocking refers to a condition where subsequently received data is blocked from being sent to a destination or higher layer entity due to the loss of data sent earlier in the sequence, such that the lost data is recovered before all data is sent in sequence. HOL blocking can severely impact the throughput of the Transmission Control Protocol (TCP).

Fig. 4 illustrates an exemplary data transfer sequence 400 between 802.11 compliant legacy devices involved in sending TCP data. As shown in fig. 4, a sender 410 has data sent to a receiver 420 in the form of TCP segments, and both the sender 410 and the receiver 420 include an 802.11 module and a TCP entity above the 802.11 module. Between the 802.11 module and the TCP entity, there is an IP entity that handles the processing of the IP layer. Detailed processing performed by the IP entity is intentionally omitted herein for the sake of simplicity. First, the 802.11 module of sender 410 sends a data frame 425 encapsulating a first TCP segment (e.g., TCP segment 1 in FIG. 4) to receiver 420. In response to receiving the data frame 425, the 802.11 module of the receiver 420 sends an ACK frame 427 to the sender 410 acknowledging receipt of the data frame 425. Further, at the TCP layer, in response to receiving the first TCP segment, the TCP entity of the receiver 420 generates a first TCP ACK (e.g., TCP ACK 1 in fig. 4) for the 802.11 module of the receiver 420 to send back to the sender 410. The 802.11 module of receiver 420 then sends a data frame 429 that encapsulates the first TCP ACK to sender 410. In response to receiving the data frame 429, the 802.11 module of the transmitter 410 sends an ACK frame 431 to the receiver 420 acknowledging receipt of the data frame 429. Further, at the TCP layer, in response to receiving the first TCP ACK, the TCP entity of sender 410 increases the size of its congestion window by 1 segment based on a congestion control algorithm (e.g., TCP Reno), which limits the maximum number of unacknowledged TCP segments that may be in end-to-end transmission, and as a result of increasing its congestion window, releases the next two TCP segments, e.g., TCP segment 2 and TCP segment 3, for sending by the 802.11 module of sender 410 to receiver 420.

The 802.11 module of the sender 410 then sends a first burst consisting of data frame 433 encapsulating TCP segment 2, data frame 435 encapsulating TCP segment 3, and BAR frame 437 (with SIFS in between) to the receiver 420. In response to receiving the BAR frame 437, the 802.11 module of the receiver 420 sends a BA frame 439 to the sender 410, the BA frame 439 indicating whether each of the data frame 433 and the data frame 435 has been correctly received. Receiver 420 also transmits to transmitter 410a second burst consisting of data frame 441 encapsulating TCP ACK2, data frame 443 encapsulating TCP ACK 3, and BAR frame 445, and in response receives BA frame 447 from transmitter 410, BA frame 447 indicating whether each of data frames 441 and 443 has been correctly received. At the TCP layer, receiving

TCP ACKs

2 and 3 causes the TCP entity of sender 410 to further increase its congestion window size by 2 segments and, if there are four or more TCP segments to be transmitted, release the next four TCP segments for transmission, and so on.

As shown in fig. 4, TCP ACK2 (to be encapsulated in data frame 441) may have arrived at the 802.11 module of receiver 420 for transmission immediately after encapsulating data frame 433 of TCP segment 2, but data frame 441 cannot be sent before transmitter 410 completes transmission of the first burst. As the size of the TCP congestion window of sender 410 increases, each subsequent burst transmission of sender 410 may involve more and more TCP segments. Thus, TCP ACKs later generated by the receiver 420 may experience more and more queuing delay before actually being transmitted because the shared channel utilized in TDD has not been cleared from previous transmissions (e.g., long burst transmissions from the transmitter 410). The delay incurred in sending these TCP ACKs will inhibit the rate of increase of the size of the TCP congestion window of sender 410, thus limiting the achievable TCP throughput of sender 410. In summary, TDD and long burst transmissions used by conventional 802.111 systems may limit the rate of increase of TCP throughput.

In accordance with an example embodiment, to address issues related to data sequence transmission, an apparatus and method for aggregating multiple contention-based TDD channels to enable flexible full duplex communication between devices is provided herein. Multiple contention-based TDD channels operate on different Radio Frequency (RF) carriers, which may be within the same frequency band or from different frequency bands, e.g., 2.4GHz, 5GHz, 60GHz, etc. The different radio frequency carriers of different shared channels are sufficiently separated, whether or not within the same frequency band, so that devices capable of such multilink operation can simultaneously transmit in one shared channel and receive in another shared channel without causing interference with each other.

The apparatus and method allow a data transmission device (i.e., sender) to receive a response, such as a response of a MAC layer (e.g., ACK or BA frame) or a higher layer (e.g., TCP ACK), to currently transmitted data without interrupting a subsequent data transmission or transmission of a subsequent data transmission delay response. The apparatus and methods also allow a data receiving device (i.e., receiver) to send a response to currently received data, such as a response by the MAC layer (e.g., ACK or BA frame) or higher layers (e.g., TCP ACK), without interrupting the reception of subsequent data or the transmission of such reception-delayed responses. The apparatus and method further enable the frequency and time resources of any of a plurality of channels between a data transmitting device and a data receiving device to be dynamically used to transmit data or responses to data in any direction, thereby minimizing not only the transmission duration of the data or responses, but also the transmission queuing delay of the responses.

For example, a first device (transmitter) may transmit at least some data in a traffic stream to a second device (receiver) over a first contention-based TDD channel (first shared channel) and at least some other data in the same traffic stream to the second device over a second contention-based TDD channel (second shared channel) based on first-come-first-serve or the like. Further, the second device may transmit at least some responses generated at the MAC layer (e.g., ACK or BA frames) or higher layers (e.g., TCP ACKs) in response to the data received from the first device over the first shared channel and at least some other responses generated at the MAC layer or higher layers in response to the data received from the first device over the second shared channel based on first come first serve, etc. For another example, the first device may send a data burst of a traffic stream to the second device over the first shared channel while receiving a response from the second device over the second shared channel, the receiving the response without interrupting transmission of the data burst over the first shared channel or requiring that the response be delayed until after transmission of the data burst over the first shared channel.

Fig. 5 illustrates a communication system 500, the communication system 500 highlighting an exemplary block diagram of two devices communicating with each other using multiple contention-based TDD channels to enable flexible full duplex communication. As shown in fig. 5, a multi-channel or multi-link (ML) device 1505 includes an STA 1506 and an STA2507, wherein the STA 1506 and the STA2507 operate on a channel 1508 and a channel 2509, respectively. Shown in fig. 5 are ML device 1505 and ML device 2510 in communication over channel 1508 and channel 2509. However, the acronym ML is used herein to denote multilink, since link and channel are synonyms, ML also denotes multichannel. However, the exemplary embodiments may operate in the case where the ML device communicates over more than two channels.

STA 1506 and STA2507 may be implemented as two separate wireless communication modules (RCMs) and identified by MAC addresses MAC _ Address1 and MAC _ Address2, respectively, where MAC _ Address1 and MAC _ Address2 may be the same or different. The ML device 2510 includes a STA3511 and a STA 4512, wherein the STA3511 and the STA 4512 operate on a channel 1508 and a channel 2509, respectively. STA3511 and STA 4512 may be implemented as two independent RCMs and are identified by MAC addresses MAC _ Address3 and MAC _ Address4, respectively, where MAC _ Address3 and MAC _ Address4 may be the same or different. The ML device 1505 and the ML device 2510 may be an Access Point (AP) device and a non-AP STA device (e.g., a client device), respectively, where the AP device is an infrastructure device that provides network access to the non-AP STA device. Similarly, the ML device 1505 and the ML device 2510 may be a non-AP STA device and an AP device, respectively. Alternatively, the ML device 1505 and the ML device 2510 may be two peer devices operating in a peer-to-peer (P2P) or ad hoc communication mode.

As shown in fig. 5, the ML device 1505 and the ML device 2510 may initially perform association and authentication procedures with each other and establish a shared key by exchanging management messages over a first channel (e.g., channel 1508) using the STA 1506 and the STA3511, respectively. In this case, the channel 1508 operates as the primary channel. STA 1506 and STA3511 operate as primary RCMs. The ML device 1505 and the ML device 2510 may then configure their respective STAs 2507 and 4512 to add a channel 2509 for exchanging data of a traffic stream, referred to as an ML traffic stream, using channel aggregation. In this case, the channel 2509 operates as a slave channel, and the STA2507 and the STA 4512 operate as a slave RCM.

Adding slave channels to enable channel aggregation may be configured on a per traffic flow basis or on a per device basis. Upon receiving a wireless signal carrying a PHY Protocol Data Unit (PPDU), a PHY entity (e.g., PHY entity 522 or PHY entity 532) of the slave RCM may optionally perform PPDU filtering based on whether a partial identifier in a PHY header of the received PPDU matches one of the at least one or more pre-configured partial identifiers. When configuring a slave channel (e.g., channel 2509), the PHY entity of the slave RCM may be configured to accept a received PPDU having a PHY header that contains a partial identifier assigned to the respective master RCM (e.g., STA 1506 and STA 3511).

For example, the PHY entity 522 of STA2507 may be configured to accept a received PPDU having a PHY header that includes a partial identifier assigned to STA 1506, and the PHY entity 532 of STA 4512 may be configured to accept a received PPDU having a PHY header that includes a partial identifier assigned to STA 3511. Further, if the STA2507 and the STA 4512 are also configured to exchange data of concurrent non-ML traffic streams between the ML device 1505 and the ML device 2510, the PHY entity 522 of the STA2507 may be configured to accept a received PPDU having a PHY header that includes a partial identifier assigned to the STA2507, and the PHY entity 532 of the STA 4512 may be configured to accept a received PPDU having a PHY header that includes a partial identifier assigned to the STA 4512. Channel 1508 and channel 2509 refer to shared Wireless Media (WM) operating on different radio frequencies. The master and slave channels are also referred to as channels, but emphasize the logical role of the channels in link aggregation operation. The discussion also proposes channel 1508 as the master channel and channel 2509 as the slave channel. However, the exemplary embodiments described herein may operate in the case where any one of the two channels is a master channel and the remaining one is a slave channel.

The differences between the master and slave channels (and between the master and slave RCMs) include: there is only one master channel (and thus one master RCM on both sides of the ML) while there may be one or more slave channels (and thus one or more slave RCMs on both sides).

According to an exemplary embodiment, 802.11 data frames carrying (higher layer) data of the ML traffic flow, management frames (e.g., 802.11 action frames) carrying management messages associated with channel aggregation used on the ML traffic flow, and control frames (e.g., ACK, BAR, and BA frames) are processed by the MAC entities of the master RCM at both ends of the ML for transmission and reception purposes, respectively. This is independent of which channel (i.e., the master or slave channel) is actually used in transmitting and receiving each of these frames. Thus, all data, management or control frames carry a MAC header that includes the MAC Address of the master RCM in the Receiver Address (RA) and Transmitter Address (TA) fields, e.g., MAC _ Address1 and MAC _ Address3, or vice versa, depending on the manner in which the frame is sent. The RA field is also referred to as an address1 (or a1) field, and the TA field is also referred to as an address2 (or a2) field. When data confidentiality or integrity protection is required, only the security keys shared between the master RCMs (e.g., STA 1506 and STA 3511) are used to protect the frames.

Another difference between the master and slave channels (and between the master and slave RCMs) is that the master RCM provides an interface with higher layers (i.e., data anchor points) for all data of the ML traffic stream. As shown in fig. 5, the ML device 1505 is connected with its higher layers via a MAC service access point (M-SAP) 516 of the STA 1506 to obtain higher layer data (e.g., IP packets encapsulating TCP segments) of the ML traffic stream to the ML device 2510 and to send higher layer responses (e.g., IP packets encapsulating TCP ACKs) received from the ML device 2510. Meanwhile, the ML device 2510 connects with its higher layers via the M-SAP 521 of the STA3511 to obtain a higher layer response to the ML device 1505 and transmit higher layer data of the ML traffic stream received from the ML device 1505. The MAC entities and M-SAPs of STA2507 and STA 4512 (shown as the shaded area in fig. 5) cannot be used to process data, nor can they be used as data anchors for the ML traffic flow. However, in other exemplary embodiments, the MAC entities and M-SAPs of the STA2507 and the STA 4512 may be utilized, for example, when the STA2507 and the STA 4512 are used to exchange data of concurrent non-ML traffic streams between the ML device 1505 and the ML device 2510.

As shown in fig. 5, in the ML device 1505 and the ML device 2510, a Demultiplexer (DEMUX) and a Multiplexer (MUX) unit (e.g., DEMUX/MUX units 530 and 535) are added between the MAC and PHY layers of the cross-channel 1508 and the channel 2509, respectively. In the transmit direction, for each frame generated by the MAC entity of the main RCM associated with the ML traffic stream, the DEMUX/MUX unit selects a channel among the multiple channels (e.g., channel 1508 and channel 2509) for transmission and forwards the frame to the PHY entity associated with the selected channel to perform the transmission. In the receive direction, the DEMUX/MUX unit aggregates frames associated with the ML traffic received over channel 1508 and channel 2509 and sends the frames to the MAC entity of the host RCM for processing as if the frames were all received over the host channel (e.g., channel 1).

Fig. 5 illustrates a case where two devices communicate with each other using a plurality of contention-based TDD channels. However, the exemplary embodiments described herein may operate where one device communicates with two or more other devices at the same time. In this case, the ML device 1505 may communicate with the ML device 2510, with channel 1505 being the master channel, channel 2509 being the slave channel; and the ML device 1505 may communicate with the ML device 3 with channel 2509 as the master channel and channel 1505 as the slave channel. In this case, the DEMUX/MUX unit 530 selects a channel for a frame addressed to the ML device 2510 or the ML device 3, or selects a channel for a frame from the ML device 2510 or the ML device 3. In this case, the DEMUX/MUX unit 530 can select a channel to support communication with two or more devices.

Fig. 6 shows a block diagram of DEMUX/MUX unit 600. DEMUX/MUX unit 600 may be an exemplary embodiment of DEMUX/

MUX units

530 and 535 shown in fig. 5. The DEMUX/MUX unit 600 includes interfaces for a master channel 605 and one or more slave channels 607. As shown in fig. 6, the DEMUX/MUX unit 600 includes an interface 610, an interface 612,

interfaces

620 and 626,

interfaces

622 and 624, an ML monitoring and selecting unit 630, a frame distributing unit 632, a-MPDU de-aggregation, MAC header and

CRC validation units

634 and 636, and address filtering

units

638 and 640; wherein the interface 610 connects with a MAC entity of the primary RCM (e.g., a MAC header and CRC creation and a-MPDU aggregation unit of the MAC entity of the primary RCM) to obtain a frame generated by the MAC entity of the primary RCM; the interface 612 is connected with a MAC entity of the master RCM (e.g., a block Ack register count unit of the MAC entity of the master RCM) to transmit frames received by the PHY entity of the master RCM and the slave RCM;

interfaces

620 and 626 are connected with Transmit (TX) paths of PHY entities of the master and slave RCMs, respectively, to transmit frames to a selected PHY entity for transmission;

interfaces

622 and 624 connect with the Receive (RX) paths of the PHY entities of the master and slave RCMs, respectively, to obtain frames received by these PHY entities. The DEMUX/MUX unit 600 may also include an interface 614 and an interface 616 connected to receive and transmit paths, respectively, from MAC entities of the RCM.

Interface 614 and interface 616 are not used for data of the ML traffic stream. However, if another concurrent traffic flow of the ML device configured through channel 2 (slave channel) does not use channel aggregation (i.e., a non-ML traffic flow), then the transmit data of the non-ML traffic flow may transparently pass through DEMUX/MUX unit 600 via interfaces 616 and 626 (shown in fig. 6 as downward dotted arrows), and the receive data of the non-ML traffic flow may transparently pass through DEMUX/MUX unit 600 via interfaces 624 and 614 (shown in fig. 6 as upward dotted arrows). Although only two channels (denoted as a master channel and a slave channel) are shown in fig. 6, DEMUX/MUX unit 600 may provide distribution and aggregation functionality for more than two channels.

In the transmission direction of the ML traffic stream (shown as a downward solid arrow), a sequence of frames generated by the MAC entity of the main RCM enters the DEMUX/MUX unit 600 via the interface 610. The ML monitoring and selecting unit 630 selects one channel (or more than one channel for redundancy purposes) among a plurality of channels to transmit the next frame through the channel. The selection of the channel (or channels) may be based on whether a channel is available. In the case where more than one channel is available, the ML monitoring and selecting unit 630 may select a channel from more than one channel according to the performance history of the channel, the error rate of the channel, the utilization of the channel, and the like. The ML monitoring and selection unit 630 may prioritize a frame as the next frame to be sent in the queue. For example, the frame to be retransmitted may have a higher priority, prioritized as the next frame. As another example, frames that encapsulate higher layer responses (e.g., TCP ACKs) may have a higher priority, prioritized as the next frame. For example, the frame encapsulating the TCP ACK may be identified according to the well-known fixed size of the TCP ACK. The MPDU distribution unit 632 forwards the next frame to the PHY entity of the RCM on the selected channel.

In the receiving direction of the ML traffic stream (shown as an upward solid arrow), if received through the main channel 605, frames received through a plurality of channels enter the DEMUX/MUX unit 600 via the interface 622; alternatively, if received through the slave channel 607, frames received through a plurality of channels enter the DEMUX/MUX unit 600 via the interface 624. Then, the a-MPDU de-aggregation, MAC header and

CRC validation units

634 and 636 perform a-MPDU de-aggregation, MAC header and CRC validation on frames received through their respective channels to ensure that the received frames are valid frames. The

address filtering units

638 and 640 may then perform frame filtering based on the MAC address in the MAC header of the corresponding received frame. For example, frame filtering may be based on a value in the RA field in the MAC header that matches the MAC address of the receiving primary RCM. Alternatively, frame filtering may be based on a value in the TA field in the MAC frame header that matches the MAC address of the sending primary RCM, which the receiving primary RCM uses to configure channel aggregation for the ML traffic flow. Still alternatively, frame filtering may be based on both matching RA and TA values. The

address filter units

638 and 640 pass the (matched) frames through the interface 612 to the MAC entity of the primary RCM for conventional MAC processing as if all of the frames were received over the primary channel 605.

Fig. 7 shows a detailed exemplary high level entity 700. The higher layer entity 700 may be an embodiment of the higher layer entity shown in figure 5. As shown in fig. 7, the higher layer entity 700 may include: a Logical Link Control (LLC) sublayer entity 705, which together with the MAC sublayer corresponds to the data link layer (also referred to as layer 2) in the Open Systems Interconnection (OSI) model; a network layer (also referred to as layer 3) entity 710; a transport layer (also referred to as layer 4) entity 715; application layer (also referred to as layer 7) entity 715. For example, a protocol commonly used in the network layer is the Internet Protocol (IP). For example, a protocol commonly used in the transport layer is a Transmission Control Protocol (TCP).

If the ML device (e.g., ML device 1505 or ML device 2510) is a client device (e.g., a mobile phone or UE), higher layer entities above the ML device are typically co-located with the ML device. On the other hand, if the ML device is an infrastructure device connected to the network, such as an AP device, the higher-level entities above the infrastructure ML device may not all be co-located with the infrastructure ML device. For example, as shown in fig. 7, application layer entity 720 and transport layer entity 715 above the infrastructure ML device may be implemented at a network server remote from the local area network where the infrastructure ML device and client ML device are located. Further, network layer entity 710 may be implemented at gateways co-located with the infrastructure ML devices and the web servers hosting the applications, respectively, and at a plurality of routers disposed along data transmission paths between the gateways.

Fig. 8A shows the format of an 802.11 data signal 800 that transmits higher layer data or higher layer responses. For example, a TCP segment (higher layer data) or a TCP ACK (higher layer response) is encapsulated in an IP packet as its payload, and the IP packet is encapsulated in an 802.11 data frame (also referred to as a MAC protocol data unit or MPDU) as the payload of a data frame, which is encapsulated in an 802.11PPDU as the payload of a PPDU. The data signal 800 includes a PHY header 805, a MAC header 807, an IP header 809, an IP payload 811, and a Cyclic Redundancy Check (CRC) field 813. The PHY header 805, the MAC header 807 and the IP header 809 contain control information for the various protocol entities processing the data signal 800. The IP payload 811 includes information such as the TCP segment and the TCP ACK. The CRC field 813 includes CRC information for checking the integrity of the data signal 800.

Fig. 8B shows the frame format of an 802.11MAC layer control frame 825 carrying an ACK frame. The control frame 825 includes a PHY header 830, a MAC frame header 832, and a CRC field 834. Information required for acknowledging the received data frame (e.g., the MAC address of the data transmitter, i.e., the intended receiver of the ACK) and Sequence Number (SN) and Fragment Number (FN) in the received data frame are included in the MAC frame header 832. The PHY header 830 may include a partial identifier of the intended receiver to facilitate PPDU filtering, which may optionally be performed by the receiver.

Fig. 8C shows the frame format of an 802.11MAC layer control frame 850 carrying BAR, BA, or Negative ACK (NACK) indications. The control frame 850 includes a PHY header 855, a MAC frame header 857, a payload field 859, and a CRC field 861. The payload field 859 includes BAR, BA, or NACK information. BAR, BA, and NACK frames share a similar frame format, but the details in the payload field 859 (i.e., BAR, BA, or NACK information) are different. The type subfield in the payload field 859 indicates which variant (i.e., BAR, BA, or NACK) is carried in the control frame 850.

Fig. 9 shows a diagram 900 of a first exemplary embodiment of flexible full duplex communication implemented using multiple contention-based TDD channels, in which a data receiving device (i.e., receiver 907) sends an unsolicited NACK to a data transmitting device (i.e., transmitter 905) indicating lost data without interrupting ongoing data reception to enable early retransmission of the lost data. For example, as shown in fig. 9, the transmitter 905 is an AP device consisting of AP1 and AP2 operating over channel 1910 and channel 2912, respectively, while the receiver 907 is a non-AP STA device consisting of STA1 and STA2 operating over channel 1910 and channel 2912, respectively. Herein, the AP device is referred to as an ML-AP device (transmitter 905) and the non-AP STA device is referred to as an ML-STA device (receiver 907) to avoid confusion with various components therein.

The ML-AP device (transmitter 905) first transmits a data burst to the ML-STA device (receiver 907) through the channel 1910 as a primary channel using the AP 1. The ML-STA device (receiver 907) receives the data burst over the channel 1910 using the STA 1. After receiving the data 1920 and the data 3924 instead of the data 2922, the ML-STA device (receiver 907) determines that the data 2922 is lost because the data is always transmitted in order. Without interrupting ongoing reception of a burst of data over the channel 1910, and without waiting for the burst to complete or waiting for an explicit request (e.g., BAR 926 in fig. 9) from the ML-AP device (transmitter 905), the ML-STA device (receiver 907) uses the MAC entity of the STA1 to generate an unsolicited NACK frame 928, the NACK frame 928 including an indication that the data 2922 was lost. Then, the ML-STA device (receiver 907) selects the channel 2912 for transmitting the NACK frame 928 using its DEMUX/MUX unit, and based on this, performs transmission of the NACK frame 928 to the AP2 through the channel 2912 using the PHY entity of the STA 2.

For example, NACK frame 928 may be a new control frame, an unsolicited BA frame, a new variant of a BA frame, or a Null Data Packet (NDP) frame with a new high-throughput (HT) control variant. The NACK frame 928 includes information identifying the missing data, e.g., the SN of the missing data frame or a bitmap whose bits correspond to the missing data is a value that indicates a negative acknowledgement is sent, so that strict timing between the NACK frame 928 and the missing data frame is not required. Upon determining missing data, a NACK frame 928 is prepared by the MAC entity of STA1, which is the primary RCM of the ML-STA device (receiver 907), as if the NACK frame 928 were to be sent over channel 1910, where the MAC header of the NACK frame 928 includes the MAC address of AP1 in the RA field and the MAC address of STA1 in the TA field, etc.

When the NACK frame 928 arrives at the DEMUX/MUX unit of the ML-STA device (receiver 907) for transmission, the ML-AP device (transmitter 905) is still transmitting data bursts using channel 1910, so channel 1910 is not effectively selected for the ML monitoring and selection unit within the DEMUX/MUX unit. This makes channel 2912 the only choice in this particular example. Thus, once the ML monitoring and selection unit within the DEMUX/MUX unit determines that channel 2912 is in an idle state, the frame distribution unit within the DEMUX/MUX unit routes NACK frames 928 to the PHY entities of STAs 2 for transmission. The PHY entity of STA2 adds a PHY header to NACK frame 928 to form a PPDU for transmission over channel 2912. At the same time, the ML-STA device (receiver 907) sends data 1920 via the M-SAP of STA1 to higher layers above the ML-STA device (receiver 907) while maintaining data 3924, resulting in HOL blocking (but less severe than if the ML-STA device did not send NACKs, then data 3-6 must be maintained). The added PHY header may also contain a partial identifier of the AP 1.

When AP1 transmits data 4930 over channel 1910, the PHY entity of AP2 receives the PPDU carrying NACK frame 928 over channel 2912. The PHY entity of AP2 has been used to accept the partial identifier of AP1 and thus pass the PHY payload (NACK frame 928) to the DEMUX/MUX unit of the ML-AP device (transmitter 905) which forwards the NACK frame 928 to the MAC entity of AP1 because the RA field in the MAC frame header carries the MAC address of AP 1. Thus, the MAC entity of the AP1 receives the NACK frame 928 as if the NACK frame 928 was received over channel 1. As a result, the MAC entity of AP1 is informed that data 2922 is lost and data 2 (shown as data 2Re-Tx 932 or data 2Re-Tx 936) is scheduled as the next retransmission in the queue. The ML-AP device (transmitter 905) can preferentially retransmit data 2 over channel 1910 by delaying data 5934 (where the retransmission of data 2 is shown as data 2Re-Tx 932), or retransmit data 2 over channel 2912 using AP2 without delaying data 5934 (where the retransmission of data 2 is shown as data 2Re-Tx 936, outlined by a dashed line). Then, the ML-STA device (receiver 907) receives the retransmitted data 2 (frame 932 or frame 936), and sequentially transmits the data 2-4 to a higher layer above the ML-STA device (receiver 907), earlier than the case where the ML-STA device (receiver 907) does not transmit the NACK frame 928, as shown in fig. 9. If no NACK frame 928 is sent, then the severity of HOL blocking will be higher, e.g., after the ML-AP device (transmitter 905) receives the BA frame 938, data 3-6 will be maintained until the ML-STA device (receiver 907) receives a retransmission of the data 2922.

Fig. 10 shows a diagram 1000 of a second exemplary embodiment of flexible full duplex communication implemented using multiple contention-based TDD channels, where any of the multiple channels can be used to send/receive data or response (at the MAC layer or TCP layer) data in any direction, as long as channels and frames for that direction are available. In this exemplary embodiment, the ML-AP device (transmitter 1005) includes an AP1 and an AP2 operating over a channel 11010 and a channel 21012, respectively, and the ML-STA device (receiver 1007) includes a STA1 and a STA2 operating over a channel 11010 and a channel 21012, respectively. As shown in fig. 10, the ML-AP device (transmitter 1005) first transmits a data frame 1020 encapsulating TCP segment 1 to the ML-STA device (receiver 1007) through a channel 11010 using an AP 1. The ML-STA device (receiver 1007) receives the data frame over channel 11010 using STA1 and sends back an ACK frame 1022. After the ML-STA device (receiver 1007) transmits the received TCP segment 1 to the TCP entity above the ML-STA device (receiver 1007), the TCP entity generates a TCP ACK 1 for the ML-STA device to send back to the ML-AP device (transmitter 1005). When data frame 1024, which is generated and encapsulates TCP ACK 1 by the MAC entity of STA1, arrives at the DEMUX/MUX unit of the ML-STA device (receiver 1007), channel 11010 is being used by AP1 to send ACK frame 1022 to STA1 acknowledging receipt of data frame 1020, while channel 21012 is in an idle state. This makes channel 21012 the first available choice for transmitting data frame 1024 encapsulating TCP ACK 1. Thus, the ML monitoring and selection unit of the DEMUX/MUX unit of the ML-STA (receiver 1007) selects channel 21012 and, based on this, the frame distribution unit forwards the data frame 1024 encapsulating TCP ACK 1 to the PHY entity of STA2 for transmission. Further, in response to the transmission, the PHY entity of STA2 receives ACK frame 1026 from AP2 without interrupting or waiting for the completion of the ongoing transmission over channel 11010.

As described above, TCP ACK 1 is obtained from the higher layer entity by M-SAP of STA 1. The data frame 1024 encapsulating TCP ACK 1 is generated by the MAC entity of STA1 as it would be sent over channel 11010, regardless of which channel data frame 1024 encapsulating TCP ACK 1 is actually sent. Thus, the MAC header of the data frame 1024 contains the MAC address of the AP1 in the RA field and the MAC address of the STA1 in the TA field. Furthermore, since the PHY entity of AP2 has been used to accept PPDUs having a PHY header that contains a partial identifier of AP1, the PHY entity of AP2 passes the PHY payload (i.e., data frame 1024) to the DEMUX/MUX unit of the ML-AP device (transmitter 1005) which further forwards the data frame 1024 to the MAC entity of AP1 for further processing. Then, the MAC entity of the AP1 transmits the IP packet encapsulating the TCP ACK 1 to a higher layer entity above the ML-AP device (transmitter 1005) via the M-SAP of the AP 1.

The reception of TCP ACK 1 by the TCP entity above the ML-AP device (transmitter 1005) causes the TCP entity to increase the size of its transmission window (for congestion control) by 1 segment and, based on this, send the other two TCP segments to the ML-AP device (transmitter 1005) for transmission to the ML-STA device (receiver 1007). For example, TCP segment 2 and TCP segment 3 arrive at the ML-AP device (sender 1005). As shown in fig. 10, since a channel 11010 is available, the ML-AP device (transmitter 1005) transmits a first burst consisting of a data frame 1028 and a data frame 1030 encapsulating TCP segment 2 and TCP segment 3, respectively, and a BAR frame 1032 to an STA1 through the channel 11010 using an AP1, and thus receives a BA frame 1040. When STA1 receives these TCP segments and passes them to the TCP entity above the ML-STA device (receiver 1007), the TCP entity generates TCP ACK2 and TCP ACK 3 for the ML-STA device (receiver 1007), respectively, to send back to the ML-AP device (transmitter 1005).

When the IP packet encapsulating TCP ACK2 arrives at the ML-STA device (receiver 1007) for transmission, channel 11010 is being used to transmit data frame 1030 encapsulating TCP segment 3 while channel 21012 is in an idle state. Thus, the ML-STA device (receiver 1007) uses the PHY entity of STA2 to send a data frame 1034 to AP2 (which generates and encapsulates TCP ACK2 using the MAC entity of STA 1) and in response receives ACK frame 1038 from AP2, both of which are sent over channel 21012 without interrupting or waiting for completion of an ongoing transmission over channel 11010.

When the IP packet encapsulating TCP ACK 3 arrives at the ML-STA device (receiver 1007) for transmission, channel 11010 is being used to send BA frame 1040 within the first burst, while channel 21012 becomes idle once transmission of ACK frame 1038 (data frame 1034 encapsulating TCP ACK 2) is complete. Thus, channel 21012 is the first available option for transmitting IP packets encapsulating TCP ACK 3, and based on this, the ML-STA device (receiver 1007) transmits a data frame 1036 (which was generated using the MAC entity of STA1 and encapsulates TCP ACK 3) to AP2 using the PHY entity of STA2, and in response receives ACK frame 1042 from AP2, both of which are transmitted over channel 21012, without interrupting ongoing transmission over channel 11010 or waiting for ongoing transmission to complete.

Receipt of TCP ACK2 and TCP ACK 3 by a TCP entity above the ML-AP device (transmitter 1005) may cause the TCP entity to further increase the size of its transmission window by 2 segments and, based thereon, send more than four TCP segments to the ML-AP device (transmitter 1005) for transmission, e.g., TCP segment 4 and TCP segment 5 arrive at the ML-AP device (transmitter 1005) in response to TCP ACK2 and TCP segment 6 and TCP segment 7 arrive at the ML-AP device in response to TCP ACK 3.

When the IP packets encapsulating TCP segment 4 and TCP segment 5 arrive at the ML-AP device (transmitter 1005), channel 21012 is being used to transmit an ACK frame 1042 of data frame 1036 (which encapsulates TCP ACK 3), while channel 11010 becomes idle once the transmission of BA frame 1040 in the first burst is complete. Thus, channel 11010 is the first available choice for transmitting IP packets encapsulating TCP segment 4 and TCP segment 5, and based on this, the ML-AP device uses AP1 to transmit a second burst consisting of data frame 1044 and data frame 1046 encapsulating TCP segment 4 and TCP segment 5, respectively, and BAR frame 1048 to STA1, and in response receives BA frame 1056 from STA1, all frames being transmitted over channel 11010.

When the IP packets encapsulating TCP segment 6 and TCP segment 7 arrive at the ML-AP device (transmitter 1005), channel 11010 is being used to transmit a second burst, while channel 21012 becomes idle once the transmission of ACK frame 1042 of data frame 1036 (which encapsulates TCP ACK 3) is complete. Thus, channel 21012 is the first available option for transmitting IP packets encapsulating TCP segment 6 and TCP segment 7, and based on this, the ML-AP device (transmitter 1005) transmits a third burst (generated using the MAC entity of AP1 and consisting of

data frames

1050 and 1052 encapsulating TCP segment 6 and TCP segment 7 and BAR frames 1054) to STA2 using the PHY entity of AP2, and in response receives BA frames 1058 from STA2, all transmitted over channel 21012.

When STA1 transmits IP packets encapsulating TCP segment 4 and TCP segment 5 to higher layer entities through its M-SAP, the TCP entities above the ML-STA device (receiver 1007) generate TCP ACK4 and TCP ACK 5, respectively, to return to the ML-AP device (receiver 1007). When TCP ACK4 arrives at the ML-STA device (receiver 1007) for transmission, both channels are in a busy state. Finally, after the transmission of the second burst is completed, the channel 11010 first becomes available. Thus, the ML-STA device (receiver 1007) transmits a data frame 1060 encapsulating TCP ACK4 to the AP1 using STA1 and in response receives an ACK frame 1064 from the AP1, both of which are transmitted over the channel 11010. When TCP ACK 5 arrives at the ML-STA device (receiver 1007) for transmission, both channels are busy. Finally, after the transmission of the third burst is completed, channel 21012 first becomes available. Thus, the ML-STA device (receiver 1007) transmits a data frame 1062 (which generates and encapsulates TCP ACK 5 using the MAC entity of STA 1) to AP2 using the PHY entity of STA2 and receives an ACK frame from AP2 in response, both of which are transmitted over channel 2. Due to the lack of space, the ACK frame for TCP ACK 5 is omitted in fig. 10.

As shown in fig. 10, a flexible full-duplex scheme allows for the transmission of data (e.g., TCP segments) in one direction and corresponding feedback (those at higher layers, such as both MAC layers and the transport layer) in the opposite direction at any of a plurality of channels on a first come first served basis, thereby reducing transmission queuing delay. Reducing the transmission queuing delay helps the TCP entity to increase its transmission window size faster than in the case shown in fig. 4 and as a result allows the TCP throughput to increase more quickly, since the size of the TCP transmission window as a congestion control mechanism limits the maximum number of unacknowledged TCP segments that can be in end-to-end transmission.

Fig. 11 shows a diagram 1100 of a third exemplary embodiment of flexible full duplex communication implemented using multiple contention-based TDD channels. The third exemplary embodiment is similar to the second embodiment shown in fig. 10, but there is a difference. As shown in fig. 10, the ML-AP device (transmitter 1005) transmits data frame 1044 and data frame 1046 (encapsulating TCP segment 4 and TCP segment 5, respectively) and BAR frame 1148, all transmitted over channel 11010. However, in fig. 11, before the ML-AP device (transmitter 1105) starts actually transmitting a data frame 1146 (encapsulating TCP segment 5) or a scheduled BAR frame 1148 over the channel 11110, since TCP ACK 3 is sent to a TCP entity above the ML-AP device (transmitter 1105), TCP segment 6 and TCP segment 7 also arrive at the ML-AP device (transmitter 1105) for transmission. Based on this, the ML-AP device (transmitter 1105) extends the originally intended second burst by adding data frame 1150 and data frame 1152 (encapsulating TCP segment 6 and TCP segment 7, respectively) after data frame 1146 (encapsulating TCP segment 5) and before BAR frame 1148. Meanwhile, channel 21112 becomes available after transmission of ACK frame 1156 (encapsulating TCP ACK 3) for data frame 1154. Thus, after distributing data frame 1146 (encapsulating TCP segment 5) to channel 11110, the DEMUX/MUX unit of the ML-AP device (transmitter 1105) distributes data frame 1150 (encapsulating TCP segment 6) to channel 21112, then distributes data frame 1152 (encapsulating TCP segment 7) to channel 11110, and then distributes BAR frame 1148 to channel 21112 for transmission, all based on a first come first serve policy. The BAR frame 1148 (in the second burst) is an acknowledgement request to data frame 1144 and 1152 (encapsulating TCP segments 4-7, respectively). In response, a BA frame 1158 is received over channel 21112 indicating whether each of the data frames 1144 and 1152 (encapsulating TCP segments 4-7, respectively) was correctly received by the ML-STA device (receiver 1107).

Before the ML-STA device (receiver 1107) sends a BA frame 1158, IP packets encapsulating TCP ACK4 ~ 7 arrive at the ML-STA device (receiver 1107). The ML-STA device (receiver 1107) may form its own third burst for transmission using the MAC entity of STA1 (its master RCM), which consists of data frames (

frames

1160, 1162, 1164, and 1166) and BAR frame 1168 encapsulating TCP ACKs 4-7, respectively. The DEMUX/MUX unit of the ML-STA device (receiver 1107) distributes data frame 1160 (encapsulating TCP ACK 4) to a first available channel, e.g., channel 11110, then distributes data frame 1162 (encapsulating TCP ACK 5) to a first available channel, e.g., channel 21112, then distributes data frame 1164 (encapsulating TCP ACK 6) to a first available channel, e.g., channel 11110, then distributes data frame 1166 (encapsulating TCP ACK 7) to a first available channel, e.g., channel 21112, and then distributes BAR frame 1168 to a first available channel, e.g., channel 11110, for transmission, all based on a first come first serve policy. BAR frame 1168 (in the third burst) is an acknowledgement request for data frames 1160-1166 (encapsulating TCP ACKs 4-7, respectively). In response, BA frame 1170 is received over channel 11110, indicating whether each of the data frames 1160 & 1166 (encapsulating TCP ACKs 4-7, respectively) was correctly received by the ML-AP device (transmitter 1105). In an alternative embodiment (not shown in fig. 11), the ML-STA device (receiver 1107) may aggregate TCP ACKs 4-7 into one MPDU by using aggregated MAC service data units (a-MSDUs), send the MPDU over channel 11110 and receive the ACK frame. In yet another alternative embodiment (also not shown in fig. 11), the ML-STA device (receiver 1107) may aggregate TCP ACKs 4-7 into one aggregate MPDU (a-MPDU), send the a-MPDU and BAR frames over channel 11110, and receive BA frames.

Fig. 12 shows a flow diagram of exemplary operations 1200 that occur in a transmitter. The operations 1200 may indicate operations that occur in a transmitter when the transmitter communicates using the flexible full duplex communication provided by the example embodiments described herein.

The operation 1200 begins with the transmitter obtaining a first transmission opportunity (TXOP) on the shared channel (block 1205). As described above, obtaining the TXOP involves the transmitter determining which of a plurality of shared channels are available and selecting a shared channel from the available shared channels. For example, the transmitter may determine whether the shared channel is available by: first, Clear Channel Assessment (CCA) is performed on the shared channel to determine that the shared channel is already in an idle state within the DIFS, then a backoff timer having a random value is set, then the backoff timer is decremented to zero at a uniform rate as long as the shared channel remains in the idle state, the countdown is suspended when the shared channel becomes a busy state, and the countdown is restarted when the shared channel again becomes an idle state within the DIFS, and it is determined that the shared channel may be used for transmission when the backoff timer reaches zero. In the case where no shared channels are available, the transmitter may wait until one or more shared channels become available. Alternatively, the transmitter may delay the transmission of the first transmission and retry at a later time.

If only one shared channel is available, the transmitter selects the only available shared channel. In case there are multiple available shared channels, the transmitter may apply a selection rule to select the shared channel. The transmitter may apply one or more selection rules to select the shared channel. Examples of selection rules include, but are not limited to: traffic on a shared channel; the type of shared channel (e.g., primary channel or secondary channel); a priority of the shared channel; performance guarantees (e.g., Quality of Service (QoS) guarantees) for the shared channel; the error rate of the shared channel; the output rate of the shared channel; a transmission failure rate of the shared channel; historical performance information of the shared channel; bandwidth of shared channels, etc. In addition, the transmitter may select the shared channel using its own shared channel selection information. As an example, the transmitter may select a shared channel on which to successfully transmit in the past. As another example, the transmitter may avoid a shared channel on which the past failed to transmit. In addition, the communication devices may share their shared channel selection information to assist their neighbors in selecting a shared channel.

The transmitter transmits a first transmission according to the first TXOP (block 1207). The first transmission may be a transmission of a sequence of transmissions. In other words, the first transmission is part of a transmission burst. In block 1205, a first transmission is sent on the shared channel selected by the transmitter.

The transmitter receives the first response (block 1209). The first response may be received on a shared channel available at the time the receiver transmits the first response. In other words, the first response is received on a shared channel selected based on whether the shared channel is available.

The transmitter obtains the second TXOP (block 1211). The second TXOP is obtained based on whether the shared channel is available, in a manner similar to the sender obtaining the description of the first TXOP. The transmitter transmits a second transmission according to the second TXOP (block 1213). The second transmission may be a transmission of a sequence of transmissions. In other words, the second transmission is part of a transmission burst. In block 1211, a second transmission is sent on the shared channel selected by the transmitter.

Fig. 13 shows a flow diagram of exemplary operations 1300 that occur in a receiver. The operations 1300 may indicate operations that occur in a receiver when the receiver communicates using the agile full duplex communication provided by the example embodiments described herein.

The operation 1300 begins with the receiver receiving a first transmission (block 1305). The first transmission may be received on a shared channel available at the time the transmitter transmits the first transmission. In other words, the first transmission is received on a shared channel selected based on whether the shared channel is available.

The receiver obtains the first TXOP (block 1307). As described above, obtaining a TXOP involves the receiver determining which shared channels of the multiple shared channels are available (i.e., performing a CCA on the shared channel to determine that the shared channel is already in an idle state within a DIFS, then setting a backoff timer with a random value, then counting down the backoff timer to zero at a uniform rate as long as the shared channel remains in an idle state, pausing the counting down when the shared channel becomes a busy state, and restarting the counting down when the shared channel again becomes an idle state within a DIFS, and determining that the shared channel may be used for transmission when the backoff timer reaches zero), and selecting a shared channel from the shared channels that are ready for transmission. In the case where no shared channels are available, the receiver may wait until one or more shared channels become available. Alternatively, the receiver may delay the transmission of the first transmission and retry at a later time.

If only one shared channel is available, the receiver selects the only available shared channel. In case there are multiple available shared channels, the transmitter may apply a selection rule to select the shared channel. The receiver may apply one or more selection rules to select the shared channel. Examples of selection rules are described above.

The receiver transmits a first response according to the first TXOP (block 1309). For example, the first response may be an acknowledgement of receipt of the first transmission. For example, the first response may be an acknowledgement that the transmission was received before the first transmission was received. The first response may be a response of the MAC layer (e.g., ACK or BA frame) or a higher layer (e.g., TCP ACK). In block 1307, a first response is sent on the shared channel selected by the receiver.

The receiver receives a second transmission (block 1311). The second transmission may be received on a shared channel available to the transmitter when transmitting the second transmission. In other words, the second transmission is received on a shared channel selected based on whether the shared channel is available.

Although the discussion described herein focuses on examples using IEEE802.11 radio access technologies, the embodiment techniques described herein may also be applied to other radio access technologies that utilize a wake-up radio or a preconfigured duty cycle as a means to reduce power consumption of wireless communication modules, examples of which include: bluetooth, Bluetooth Low Energy (BLE), IEEE 802.15.4/ZigBee, 3GPP Long Term Evolution (LTE), LTE-Unlicensed (LTE-U), Licensed Assisted Access (LAA), MuLTEFire, 5G New Radio (NR), and the like.

Fig. 14 illustrates an exemplary communication system 1400. In general, the system 1400 enables multiple wireless or wired users to send and receive data and other content. System 1400 can implement one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA).

In this example, communication system 1400 includes Electronic Devices (EDs) 1410 a-1410 c, Radio Access Networks (RANs) 1420 a-1420 b, a core network 1430, a Public Switched Telephone Network (PSTN) 1440, the internet 1450, and other networks 1460. Stations and stations supporting WUR are examples of EDs, and Wireless Local Area Networks (WLANs) are examples of RANs. Although fig. 14 shows a certain number of these components or elements, any number of these components or elements may be included in the system 1400.

The electronic devices 1410 a-1410 c are configured to operate or communicate in the system 1400. For example, the electronic devices 1410 a-1410 c are configured to transmit or receive over a wireless or wired communication channel. Each of the electronic devices 1410 a-1410 c represents any suitable end-user device, and may include the following (or may be referred to as): user Equipment (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, Personal Digital Assistant (PDA), smartphone, laptop, computer, touchpad, wireless sensor, or consumer electronics.

Here RANs 1420a and 1420b include base stations 1470a and 1470b, respectively. An AP is an example of a base station. Each of the base stations 1470a and 1470b is used to wirelessly connect with one or more of the electronic devices 1410 a-1410 c to enable access to a core network 1430, a PSTN 1440, the internet 1450, or other networks 1460. For example, the base stations 1470a-1470b may include (or be) one or more of a number of well-known devices, such as a Base Transceiver Station (BTS), a Node-b (NodeB), an evolved NodeB (eNodeB), a home eNodeB, a site controller, an AP, or a wireless router. The electronic devices 1410 a-1410 c are operable to connect and communicate with the internet 1450 and may access a core network 1430, the PSTN 1440, or other networks 1460.

In the embodiment illustrated in fig. 14, base station 1470a forms a portion of RAN 1420a, and RAN 1420a may include other base stations, elements, or devices. Further, base station 1470b forms a portion of RAN 1420b, and RAN 1420b may include other base stations, elements, or devices. Each base station 1470a and 1470b is configured to transmit or receive wireless signals within a particular geographic area (sometimes referred to as a "cell"). In some embodiments, multiple-input multiple-output (MIMO) technology may be employed, with multiple transceivers per cell.

Base stations 1470a-1470b may communicate with one or more of EDs 1410 a-1410 c over one or more air interfaces 1490 using a wireless communication channel. The air interface 1490 may use any suitable radio access technology.

It is contemplated that system 1400 may employ multi-channel access functionality, including schemes described above. In particular embodiments, the base station and the ED implement LTE, LTE-A or LTE-B. Of course, other multiple access schemes and wireless protocols may be used.

The RANs 1420a and 1420b communicate with a core network 1430 to provide voice, data, applications, voice over IP (VoIP) or other services to the electronic devices 1410 a-1410 c. It will be appreciated that RANs 1420a and 1420b, or core network 1430, may communicate directly or indirectly with one or more other RANs (not shown). The core network 1430 may also serve as a gateway access for other networks, such as the PSTN 1440, the internet 1450, and other networks 1460. Additionally, some or all of the electronic devices 1410 a-1410 c may be capable of communicating with different wireless networks over different wireless links using different wireless technologies or protocols. The ED may communicate with a service provider or switch (not shown) and the internet 1450 over wired communication channels, rather than (or in addition to) wireless communication.

Fig. 14 shows an example of a communication system, and various changes may be made to fig. 14. For example, communication system 1400 may include any number of electronic devices, base stations, networks, or other components in any suitable configuration.

FIGS. 15A and 15B illustrate exemplary devices that may implement the various methods and teachings provided by the present invention. In particular, fig. 15A illustrates an exemplary electronic device 1510 and fig. 15B illustrates an exemplary base station 1570. These components may be used in system 1400 or any other suitable system.

As shown in fig. 15A, an electronic device 1510 includes at least one processing unit 1500. The processing unit 1500 implements various processing operations of the electronic device 1510. For example, the processing unit 1500 may perform signal coding, data processing, power control, input/output processing, or any other function that enables the electronic device 1510 to operate in the system 1400. The processing unit 1500 also supports the methods and teachings described in detail above. Each processing unit 1500 includes any suitable processing or computing device for performing one or more operations. Each processing unit 1500 may include a microprocessor, microcontroller, digital signal processor, field programmable gate array, application specific integrated circuit, or the like.

The electronic device 1510 also includes at least one transceiver 1502. The transceiver 1502 is used to modulate data or other content for transmission over at least one antenna or Network Interface Controller (NIC) 1504. The transceiver 1502 is also configured to demodulate data or other content received by the at least one antenna 1504. One of the transceivers 1502 is configured to operate as a LP-WUR receiver (i.e., it is configured to receive a wake-up packet addressed to the ED 1510 and to wake-up the other of the transceivers 1502 upon receiving the wake-up packet). Each transceiver 1502 includes any suitable structure for generating signals for wireless or wired transmission, or for processing signals received wirelessly or wired. Each antenna 1504 includes any suitable structure for transmitting or receiving wireless or wired signals. One or more transceivers 1502 may be used for the electronic device 1510, and one or more antennas 1504 may be used for the electronic device 1510. Although shown as a single functional unit, the transceiver 1502 may also be implemented using at least one transceiver and at least one separate receiver that can be powered on or off, respectively, to facilitate energy conservation in accordance with the various embodiments described herein. Although shown as a single functional unit, processing unit 1500 may also be implemented using at least one processing unit associated with the at least one transceiver and at least one separate processing unit associated with the at least one separate receiver, wherein the at least one processing unit and the at least one separate processing unit are capable of being powered on and off, respectively, to facilitate power savings in accordance with various embodiments described herein.

The ED 1510 also includes one or more input/output devices 1506 or interfaces (e.g., a wired interface to the internet 1450). The input/output devices 1506 facilitate interaction with users or other devices in the network (network communications). Each input/output device 1506 includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

Further, electronic device 1510 includes at least one memory 1508. Memory 1508 stores instructions and data used, generated, or collected by electronic device 1510. For example, memory 1508 may store software or firmware instructions that are executed by one or more processing units 1500, as well as data for reducing or eliminating interference in incoming signals. Each memory 1508 includes any suitable volatile or non-volatile storage or storage and retrieval device or devices. Any suitable type of memory may be used, for example, Random Access Memory (RAM), Read Only Memory (ROM), hard disk, optical disk, Subscriber Identity Module (SIM) card, memory stick, Secure Digital (SD) memory card. Although shown as a single functional unit, memory 1508 can also be implemented using at least one memory associated with the at least one transceiver and at least one separate memory associated with the at least one separate receiver, wherein the at least one memory and the at least one separate memory can be powered on and off, respectively, to facilitate energy conservation in accordance with the various embodiments described herein.

As shown in fig. 15B, the base station 1570 includes at least one processing unit 1550, at least one transceiver 1552 (including the functionality of a transmitter and receiver), one or more antennas 1556, at least one memory 1558, and one or more input/output devices or interfaces 1566. A scheduler, as understood by those skilled in the art, is coupled to processing unit 1550. The scheduler may be included within base station 1570 or operate independently of base station 1570. Processing unit 1550 performs various processing operations for base station 1570 such as signal coding, data processing, power control, input/output processing, or any other functions. The processing unit 1550 may also support the methods and teachings detailed above. Each processing unit 1550 includes any suitable processing or computing device for performing one or more operations. Each processing unit 1550 may include a microprocessor, microcontroller, digital signal processor, field programmable gate array, or application specific integrated circuit, etc.

Each transceiver 1552 includes any suitable structure for generating signals for wireless or wired transmission to one or more electronic or other devices. Each transceiver 1552 also includes any suitable structure for processing signals received wirelessly or by wire from one or more electronic or other devices. Although the transmitter and receiver are shown combined as transceiver 1552, they may be separate components. Each antenna 1556 includes any suitable structure for transmitting or receiving wireless or wired signals. Although a common antenna 1556 is shown here as coupled to the transceiver 1552, one or more antennas 1556 can be coupled to one or more transceivers 1552 to support the coupling of separate antennas 1556 to transmitters and receivers (when the transmitters and receivers are separate components). Each memory 1558 includes any suitable one or more volatile or non-volatile storage and retrieval devices. Each input/output device 1566 facilitates interaction (network communication) with users or other devices in the network. Each input/output device 1566 includes any suitable structure for providing information to or receiving information from a user, including network interface communications.

Fig. 16 is a block diagram of a computing system 1600 that may be used to implement the apparatus and methods disclosed herein. For example, a computing system may be any entity of a UE, AN Access Network (AN), Mobility Management (MM), Session Management (SM), User Plane Gateway (UPGW), or Access Stratum (AS). A particular device may use all of the components shown or only a subset of the components, and the degree of integration between devices may vary. Further, a device may include multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. Computing system 1600 includes a processing unit 1602. The processing unit includes a Central Processing Unit (CPU) 1614, memory 1608, and may also include a mass storage device 1604 connected to bus 1620, a video adapter 1610, and an I/O interface 1612.

The bus 1620 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus. The CPU 1614 may include any type of electronic data processor. Memory 1608 may include any type of non-transitory system memory, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In one embodiment, memory 1608 may include ROM for use in startup and DRAM for storing programs and data for use in executing programs.

The mass storage 1604 may comprise any type of non-transitory storage device for storing data, programs, and other information and making the data, programs, and other information accessible via the bus 1620. The mass storage 1604 may include one or more of a solid state disk, a hard disk drive, a magnetic disk drive, or an optical disk drive, among others.

The video adapter 1610 and the I/O interface 1612 provide interfaces to couple external input and output devices to the processing unit 1602. As shown, examples of input and output devices include a display 1618 coupled to the video adapter 1610, and a mouse, keyboard, or printer 1616 coupled to the I/O interface 1612. Other devices may be coupled to the processing unit 1602, and more or fewer interface cards may be used. A serial interface, such as a Universal Serial Bus (USB) (not shown), may be used to interface to external devices.

Processing unit 1602 also includes one or more network interfaces 1606, and network interfaces 1606 may include wired channels such as ethernet cables, or wireless channels to access nodes or different networks. Network interface 1606 enables processing unit 1602 to communicate with remote units over a network. For example, network interface 1606 may provide wireless communication via one or more transmitter/transmit antennas and one or more receiver/receive antennas. In one embodiment, the processing unit 1602 is coupled to a local area network 1622 or a wide area network for data processing and communication with remote devices, such as other processing units, the Internet, or remote storage facilities.

It should be understood that one or more steps of the embodiment methods provided herein may be performed by corresponding units or modules. For example, the signal may be transmitted by a transmitting unit or a transmitting module. The signal may be received by a receiving unit or a receiving module. The signals may be processed by a processing unit or processing module. Other steps may be performed by a power control unit or module or a wake-up unit or module. The respective units or modules may be hardware, software or a combination thereof. For example, one or more of the units or modules may be an integrated circuit, such as a Field Programmable Gate Array (FPGA) or an application-specific integrated circuit (ASIC).

Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the scope of the disclosure as defined by the appended claims.

Claims

1. A method implemented by a first device in a contention-based communication system, the method comprising:

the first device obtains a first transmission opportunity (TXOP) on a first shared channel by winning a first channel contention of the first shared channel;

the first device sends a first transmission to a second device according to the first TXOP, the first transmission being part of a transmission sequence;

the first device receiving the first transmission response from the second device, the response received over a second shared channel, the first shared channel and the second shared channel operating on different radio frequency carriers;

the first device obtains a second TXOP by winning a second channel contention;

the first device sends a second transmission to the second device according to the second TXOP, the second transmission being part of the sequence of transmissions.

2. The method of claim 1, wherein the second TXOP is located on the second shared channel and the second channel contention is won on the second shared channel.

3. The method of any of claims 1-2, wherein the first transmission response indicates a failure to receive a third transmission that occurred prior to the first transmission, and wherein the second transmission is a retransmission of the third transmission.

4. The method of claim 3, wherein the first transmitted response is received before the first device sends the request for the first response.

5. The method of any of claims 1-2, wherein the first transmission is a Transmission Control Protocol (TCP) segment, wherein the first transmission response is a TCP acknowledgement indicating that the first transmission was received successfully, and wherein the second transmission is sent after the first transmission.

6. The method according to any one of claims 1-5, further comprising: the first device receives the second transmission response from the second device, the second transmission response being received over the first shared channel.

7. The method of any of claims 1-6, wherein the first device and the second device are stations operating in a peer-to-peer communication mode.

8. The method of any of claims 1-6, wherein the first device is an Access Point (AP) and the second device is a non-AP station.

9. The method of any of claims 1-6, wherein the first device is a non-AP station and the second device is an AP.

10. A method for communicating between a first device and a second device, wherein the first device and the second device operate in a contention-based communication system, the method being implemented by the second device, the method comprising:

the second device receiving a first transmission from the first device over a first shared channel, the first transmission being part of a sequence of transmissions;

the second device obtains a first transmission opportunity (TXOP) on a second shared channel by winning a first channel contention on the second shared channel, wherein the first shared channel and the second shared channel operate on different radio frequency carriers;

the second device sends the first transmission response to the first device according to the first TXOP;

the second device receives a second transmission from the first device according to whether the shared channel is available, the second transmission being part of the sequence of transmissions.

11. The method of claim 10, wherein the second transmission is received over the second shared channel.

12. The method of any of claims 10-11, wherein the response indicates a failure to receive a third transmission, wherein the third transmission occurs before the first transmission, and wherein the second transmission is a retransmission of the third transmission.

13. The method of claim 12, wherein the first transmission response is sent before the second device receives the request for the first transmission response.

14. The method of any of claims 10-11, wherein the first transmission is a Transmission Control Protocol (TCP) segment, wherein the first transmission response is a TCP acknowledgement indicating that the first transmission was received successfully, and wherein the second transmission is sent after the first transmission.

15. The method according to any one of claims 10-13, further comprising: the second device obtains a second TXOP on the first shared channel by winning a second channel contention on the first shared channel; and the second equipment sends the second transmission response to the first equipment according to the second TXOP.

16. The method of any of claims 10-15, wherein the first device and the second device are stations operating in a peer-to-peer communication mode.

17. The method of any of claims 10-15, wherein the first device is an Access Point (AP) and the second device is a non-AP station.

18. The method of any of claims 10-15, wherein the first device is a non-AP station and the second device is an AP.

19. A multi-link (ML) communication device, comprising:

a first Radio Frequency (RF) chain for transmitting and receiving data through a first shared channel;

a second RF chain for transmitting and receiving data through a second shared channel;

a demultiplexer/multiplexer unit operably coupled to the first and second RF chains, the demultiplexer/multiplexer unit to selectively route the data between the first and second RF chains and a Media Access Control (MAC) layer entity of the ML communication device according to a criterion of selecting a channel from the first and second shared channels when transmitting the data and according to an address associated with the data when receiving the data;

an interface unit operably coupled to the MAC layer entity and a higher layer entity of the ML communication device, the interface unit to receive data from the higher layer entity for transmission over the selected channel and to transmit data received from the first shared channel and the second shared channel to the higher layer entity.

20. The ML communication device according to claim 19, further comprising:

a first Physical (PHY) layer entity operably coupled to the first RF chain and the demultiplexer/multiplexer unit, the first PHY layer entity to prepare data for transmission over the first RF chain and process data received over the first RF chain;

a second PHY layer entity operably coupled to the second RF chain and the demultiplexer/multiplexer unit, the second PHY layer entity to prepare data for transmission over the second RF chain and to process data received over the second RF chain.

21. The ML communication device according to any one of claims 19-20, wherein the higher layer entity is co-located with the ML communication device.

22. The ML communication device according to any one of claims 19-21, wherein the address comprises a MAC address or portions of a MAC address.

23. The ML communication device according to any one of claims 19-22, wherein the first shared channel is a master channel and the second shared channel is a slave channel.

24. A first multi-link (ML) communication device, comprising:

one or more processors;

a non-transitory memory comprising instructions that, when executed by the one or more processors, cause the first ML communication device to:

obtaining a first transmission opportunity (TXOP) on a first shared channel by winning a first channel contention on the first shared channel;

transmitting a first transmission to a second ML communication device in accordance with the first TXOP, the first transmission being part of a sequence of transmissions;

receiving the first transmission response from the second ML communication device, the response received over a second shared channel, the first and second shared channels operating on different radio frequency carriers;

obtaining a second TXOP by winning a second channel contention;

transmitting a second transmission to the second ML communication device in accordance with the second TXOP, the second transmission being part of the sequence of transmissions.

25. The first ML communications device of claim 24, wherein the second TXOP is located on the second shared channel and the second channel contention is won on the second shared channel.

26. The first ML communication device according to any one of claims 24-25, wherein the first transmission response indicates a failure to receive a third transmission that occurred prior to the first transmission, and wherein the second transmission is a retransmission of the third transmission.

27. The first ML communication device according to any one of claims 24-25, wherein the first transmission is a Transmission Control Protocol (TCP) segment, the first transmission response is a TCP acknowledgement indicating that the first transmission was successfully received, and the second transmission is sent after the first transmission.

28. The first ML communication device of any one of claims 24-27, wherein the instructions further cause the first ML communication device to receive the second transmission response from the second ML communication device, the second transmission response being received over the first shared channel.

29. The first ML communication device of any one of claims 24-28, wherein the first ML communication device and the second ML communication device are stations operating in a peer-to-peer communication mode.

30. A first ML communication device as claimed in any one of claims 24-28, wherein the first device is an Access Point (AP) and the second device is a non-AP station.

31. A first ML communication device as claimed in any one of claims 24-28, wherein the first ML communication device is a non-AP station and the second device is an AP.

32. A first multi-link (ML) communication device, comprising:

one or more processors;

receiving a first transmission from a second ML communication device over a first shared channel, the first transmission being part of a sequence of transmissions;

obtaining a first transmission opportunity (TXOP) on a second shared channel by winning a first channel contention on the second shared channel, the first shared channel and the second shared channel operating on different radio frequency carriers;

transmitting the first transmission response to the second ML communication device according to the first TXOP;

receiving a second transmission from the second ML communication device in accordance with whether the shared channel is available, the second transmission being part of the sequence of transmissions.

33. The first ML communication device of claim 32, wherein the first response indicates a failure to receive a third transmission, wherein the third transmission occurs before the first transmission, and wherein the second transmission is a retransmission of the third transmission.

34. The first ML communication device according to any one of claims 32-33, wherein the first transmission is a Transmission Control Protocol (TCP) segment, wherein the first transmission response is a TCP acknowledgement indicating that the first transmission was successfully received, and wherein the second transmission is sent after the first transmission.

35. The first ML communication device of any one of claims 32-33, wherein the instructions further cause the first ML communication device to: obtaining a second TXOP on the first shared channel by winning a second channel contention on the first shared channel; and sending the second transmission response to the second ML communication device according to the second TXOP.