WO2020101807A2

WO2020101807A2 - Methods and apparatus aggregating multiple wireless communications channels for flexible full-duplex communications

Info

Publication number: WO2020101807A2
Application number: PCT/US2019/053202
Authority: WO
Inventors: Yunsong Yang
Original assignee: Futurewei Technologies, Inc.
Priority date: 2019-09-26
Filing date: 2019-09-26
Publication date: 2020-05-22
Also published as: WO2020101807A3; CN114424671A

Abstract

A method includes obtaining a first transmission opportunity (TXOP) on a first shared channel by winning a first channel contention for the first shared channel, transmitting a first transmission in accordance with the first TXOP, the first transmission being part of a sequence of transmissions, receiving a response to the first transmission, 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, and transmitting a second transmission in accordance with the second TXOP, the second transmission being part of the sequence of transmissions.

Description

METHODS AND APPARATUS AGGREGATING MULTIPLE WIRELESS COMMUNICATIONS CHANNELS FOR FLEXIBLE FULL-DUPLEX

COMMUNICATIONS

TECHNICAL FIELD

The present disclosure relates generally to a system and method for digital communications, and, in particular embodiments, to methods and apparatus for aggregating multiple wireless communications channels for flexible full-duplex communications.

BACKGROUND

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

Time-division duplexing (TDD) emulates full-duplex communications over a half-duplex channel by separating outward and return signals in the time domain. TDD can be flexible and adaptive in the utilization of the communications medium, wired or wireless, when the uplink and downlink traffic are asymmetric. On the other hand, TDD tends to waste bandwidth during the switch-over between transmitting and receiving, and has greater inherent latency. Examples of TDD based wireless communications technologies include UTRA-TDD, which is the TDD flavor of the third generation (3G) Universal Mobile Telecommunications System (UMTS), LTE- TDD, which is the TDD flavor of the fourth generation (4G) Long-Term Evolution (LTE), Bluetooth, and IEEE 802.11. In UTRA-TDD and LTE-TDD, the pattern of time slots allocated for downlink and uplink traffic is pre-configured by an infrastructure equipment (e.g., Node B or enhanced Node B) and indicated to user equipment (UEs). In Bluetooth and IEEE 802.11, a transmitter, whether an infrastructure equipment or not, must contend for the right to transmit over a shared wireless medium (WM) or channel.

Frequency-division duplexing (FDD) means that the transmitter and receiver operate at different carrier frequencies so that transmitting outward signals and receiving return signals can occur simultaneously. FDD can be efficient when the uplink and downlink traffics, e.g., voice or voice over IP (VoIP), are symmetric. Examples of FDD based wireless communications systems include UTRA-FDD, which is the FDD flavor of the 3G UMTS, and LTE-FDD, which is the FDD flavor of the 4G LTE.

SUMMARY

According to a first aspect, a method implemented by a first device in a contention based communications system is provided. The method includes obtaining, by the first device, a first transmission opportunity (TXOP) on a first shared channel by winning a first channel contention for the first shared channel, transmitting, by the first device, to a second device, a first transmission in accordance with the first TXOP, the first transmission being part of a sequence of transmissions, receiving, by the first device, from the second device, a response to the first transmission, 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, by the first device, a second TXOP by winning a second channel contention; and transmitting, by the first device, to the second device, a second transmission in accordance with 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 as such, the second TXOP being on the second shared channel and the second channel contention being won on the second shared channel.

In a second implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the response to the first transmission indicating a failure in a reception of a third transmission occurring prior to the first

transmission, the second transmission being a retransmission of the third transmission.

In a third implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the response to the first transmission being received prior to a request for the first response is transmitted by the first device. In a fourth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the first transmission being a transmission control protocol (TCP) segment, the response to the first transmission being a TCP

acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission. In a fifth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, further comprising receiving, by the first device, from the second device, a response to the second transmission, the response to the second transmission being received over the first shared channel. In a sixth implementation form of the method according to the first aspect as such or any preceding implementation form of the first aspect, the first and second devices being stations operating in a peer-to-peer communications mode.

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

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

According to a second aspect, a method for communicating between a first device and a second device is provided. The first and second devices operating in a contention based

communications system, and the method implemented by the second device. The method includes receiving, by the second device, from the first device, a first transmission over a first shared channel, the first transmission being part of a sequence of transmissions, obtaining, by the second device, 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, by the second device, to the first device, a response to the first transmission in accordance with the first TXOP, and receiving, by the second device, from the first device, a second transmission in accordance with an availability of the shared channels, the second transmission being part of the sequence of transmissions.

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

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

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

In a fourth implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, the first transmission being a TCP segment, the response to the first transmission being a TCP acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission.

In a fifth implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, further comprising obtaining, by the second device, a second TXOP on the first shared channel by winning a second channel contention on the first shared channel, and transmitting, by the second device, to the first device, a response to the second transmission in accordance with the second TXOP.

In a sixth implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, the first and second devices being stations operating in a peer-to-peer communications mode. In a seventh implementation form of the method according to the second aspect as such or any preceding implementation form of the second aspect, the first device being an access point (AP) and the second device being a non-AP station.

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

According to a third aspect, a multi-link (ML) communicating device is provided. The ML communicating device includes a first radio frequency (RF) chain configured to send and receive data over a first shared channel, a second RF chain configured to send and receive data over a second shared channel, a demux/mux unit operatively coupled to the first and second RF chains, the demux/mux unit configured to selectively route data between the first and second RF chains and a media access control (MAC) layer entity of the ML communicating device in accordance with a criteria for selecting a channel from the first and second shared channels when transmitting the data and in accordance with addresses associated with the data when receiving the data, and an interface unit operatively coupled to the MAC layer entity and a high layer entity of the ML communicating device, the interface unit configured to receive data from the higher layer entity for transmission over the selected channel and to deliver data received from the first and second shared channels to the higher layer entity.

In a first implementation form of the ML communicating device according to the third aspect as such, further comprising a first physical (PHY) layer entity operatively coupled to the first RF chain and the demux/mux unit, the first PHY layer entity configured to prepare data for transmission over the first RF chain and process data received over the first RF chain, and a second PHY layer entity operatively coupled to the second RF chain and the demux/mux unit, the second PHY layer entity configured to prepare data for transmission over the second RF chain and process data received over the second RF chain.

In a second implementation form of the ML communicating device according to the third aspect as such or any preceding implementation form of the third aspect, the high layer entity being co located with the ML communicating device.

In a third implementation form of the ML communicating device according to the third aspect as such or any preceding implementation form of the third aspect, the addresses comprising MAC addresses or portions of MAC addresses.

In a fourth implementation form of the ML communicating device according to the third aspect as such or any preceding implementation form of the third aspect, the first shared channel being a master channel and the second shared channel being a slave channel. According to a fourth aspect, a first ML communicating device is provided. The first ML communicating device includes one or more processors, and a non-transitory memory storage comprising instructions that, when executed by the one or more processors, cause the first ML communicating device to obtain a first TXOP on a first shared channel by winning a first channel contention on the first shared channel, transmit, to a second ML communicating device, a first transmission in accordance with the first TXOP, the first transmission being part of a sequence of transmissions, receive, from the second ML communicating device, a response to the first transmission, the response being received over a second shared channel, the first shared channel and the second shared channel operating on different radio frequency carriers, obtain a second TXOP by winning a second channel contention, and transmit, to the second ML communicating device, a second transmission 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 communicating device according to the fourth aspect as such, the second TXOP being on the second shared channel and the second channel contention being won on the second shared channel. In a second implementation form of the first ML communicating device according to the fourth aspect as such or any preceding implementation form of the fourth aspect, the response to the first transmission indicating a failure in a reception of a third transmission occurring prior to the first transmission, the second transmission being a retransmission of the third transmission.

In a third implementation form of the first ML communicating device according to the fourth aspect as such or any preceding implementation form of the fourth aspect, the first transmission being a TCP segment, the response to the first transmission being a TCP acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission.

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

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

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

According to a fifth aspect, a first ML communicating device is provided. The first ML communicating device includes one or more processors, and a non-transitory memory storage comprising instructions that, when executed by the one or more processors, cause the first ML communicating device to receive, from the second ML communicating device, a first

transmission over a first shared channel, the first transmission being part of a sequence of transmissions, obtain 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, transmit, to the second ML

communicating device, a response to the first transmission in accordance with the first TXOP, and receive, from the second ML communicating device, a second transmission in accordance with an availability of the shared channels, the second transmission being part of the sequence of transmissions.

In a first implementation form of the first ML communicating device according to the fifth aspect as such, the first response indicating a failure in a reception of a third transmission, the third transmission occurring before the first transmission, and the second transmission being a retransmission of the third transmission. In a second implementation form of the first ML communicating device according to the fifth aspect as such or any preceding implementation form of the fifth aspect, the first transmission being a TCP segment, the response to the first transmission being a TCP acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission. In a third implementation form of the first ML communicating device according to the fifth aspect as such or any preceding implementation form of the fifth aspect, the instructions further cause the first ML communicating device to obtain a second TXOP on the first shared channel by winning a second channel contention on the first shared channel, and transmit, to the second ML communicating device, a response to the second transmission in accordance with the second TXOP. An advantage of a preferred embodiment is that there are no restrictions on the communication direction (i.e., downlink or uplink) of any shared channel. Any available shared channel can be dynamically used, e.g., on first-come-first serve basis, for transmitting data or a response to data in either downlink or uplink direction. Hence, responses to data received can be sent back without interrupting nor deferring to the reception of subsequent data in the opposite direction. Reducing the queuing delay for transmitting upper layer protocol responses (such as TCP ACKs) allows the transmitting device to not only move its transmission window (which is used for congestion control purpose) forward so as to release subsequent data for transmission more quickly but also increase the size of the transmission window (until reaching a limit) so that more data can be transmitted while the respective upper layer acknowledgments are pending. As a result, the upper layer throughput is ramped up more rapidly to the highest throughput that potentially can be supported by the end-to-end path.

BRIEF DESCRIPTION OF THE DRAWINGS

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

Figure lA illustrates an example communications system consisting of an infrastructure BSS;

Figure lB illustrates an example 802.11 network with stations communicating over aggregated shared channels;

Figure 2 illustrates an example data transmission sequence between conventional 802.11- complaint devices;

Figure 3 illustrates another example data transmission sequence between the conventional 802.11-complaint devices utilizing a burst transmission;

Figure 4 illustrates yet another example data transmission sequence between the conventional 802.11-complaint devices involving sending transmission control protocol (TCP) data;

Figure 5 illustrates example block diagrams of two devices communicating with one another using two contention based TDD channels to achieve flexible full-duplex communications according to example embodiments presented herein;

Figure 6 illustrates a block diagram of DEMUX/MUX unit according to example embodiments presented herein; Figure 7 illustrates detailed example higher layer entities according to example embodiments presented herein;

Figure 8A illustrates a format of an 802.11 data signal carrying higher layer data or higher layer response according to example embodiments presented herein;

Figure 8B illustrates a frame format of an 802.11 media access control (MAC) layer control frame carrying an acknowledgement (ACK) according to example embodiments presented herein;

Figure 8C illustrates a frame format of an 802.11 MAC layer control frame carrying a block ACK request (BAR), block ACK (BA), or negative ACK (NACK) according to example embodiments presented herein;

Figure 9 illustrates a diagram of a first example embodiment of the flexible full-duplex communications enabled by using multiple contention based TDD channels according to example embodiments presented herein;

Figure 10 illustrates a diagram of a second example embodiment of the flexible full-duplex communications enabled by using multiple contention based TDD channels according to example embodiments presented herein;

Figure 11 illustrates a diagram of a third example embodiment of the flexible full-duplex communications enabled by using multiple contention based TDD channels according to example embodiments presented herein;

Figure 12 illustrates a flow diagram of example operations occurring in a Sender according to example embodiments presented herein;

Figure 13 illustrates a flow diagram of example operations occurring in a Recipient according to example embodiments presented herein;

Figure 14 illustrates an example communication system according to example embodiments described herein;

Figures 15A and 15B illustrate example devices that may implement the methods and teachings according to this disclosure; and

Figure 16 illustrates a block diagram of a computing system that may be used for implementing the devices and methods disclosed herein. DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

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

The IEEE Standard 802.11-2016 is a set of media access control (MAC) layer and physical (PHY) layer specifications for implementing wireless local area network (LAN) or wireless fidelity (Wi Fi) communication in the 2.4, 5, 6, and 60 GHz frequency bands. A basic service set (BSS) provides the basic building-block of an 802.11 wireless LAN. In an infrastructure mode of

802.11, a single access point (AP), together with all associated stations (STAs), forms a BSS. The AP acts as a master to control the STAs within that BSS. A station (STA) may also be referred to as a device, a user equipment, a terminal, a node, and so forth. An AP may also be referred to as a network controller, a base station, a wireless router (due to a router co-located with the AP, the router providing a connection to a network), and so on. The simplest infrastructure BSS consists of one AP and one STA.

Figure lA shows an example communications system 100 consisting of an infrastructure BSS. Communications system 100 includes an access point (AP) 105 that is serving a plurality of stations, such as STAs 110, 112, 114, 116, and 118. Access point 105 controls certain aspects (such as radio frequency channel, transmission power limit, authentication, security, etc.) of communications with or among its associated stations. Generally speaking, in communications system 100, wireless resources for both uplink (station to access point) and downlink (access point to station) transmissions are accessed by transmitters based on a distributed contention mechanism commonly referred to as carrier sensing multiple access with collision avoidance (CSMA/CA). However, access point 105 still may influence the access to a shared channel by assigning different access priorities to different STAs or different types of traffic streams.

An example distributed channel contention process involves a sender detecting that the shared channel is idle for a pre-specified time period known as the distributed inter-frame space (DIFS), and, as a result of the detecting of the shared channel being idle for a DIFS, setting a back-off timer to a random value. The sender counts down the back-off timer towards zero at a uniform rate as long as the shared channel remains idle. The sender will temporarily suspend the counting down when the shared channel becomes busy, e.g., when another device wins the channel contention and begins to transmit, and will resume the counting down of its back-off timer after the shared channel has again become idle for a DIFS. When the back-off timer reaches zero (or some other specified value), the sender determines that it has won the channel contention and begins to transmit over the shared channel.

Conventional 802.11-compliant STAs use time division duplexing (TDD) to achieve full-duplex communications with one another, wherein an STA uses different time periods to transmit or receive over a same half-duplex shared channel. In general, channels may also be referred to as links. Figure lB illustrates an example 802.11 network 150 with devices communicating over aggregated shared channels. Network 150 includes devices, including device 151 and device 152, communicating over an aggregated shared channel 160. The devices may be APs, STAs, or a combination of AP and STA. Aggregated shared channel 160 comprises a plurality of shared channels (e.g, 802.11 shared channels), including shared channel 161, 162, and 163. As referred to herein, a shared channel is different from another shared channel when the channels are established over different radio frequencies. In an embodiment, transmissions are transmitted over different shared channels without duplicating one another. In an embodiment,

transmissions are transmitted over different shared channels with at least some of the transmissions being duplicated and transmitted over multiple different shared channels. The transmission of duplicated transmissions over multiple different shared channels helps to improve reliability with redundant transmissions, for example.

Figure 2 illustrates an example data transmission sequence 200 between the conventional 802.11-complaint devices. As shown in Figure 2, Sender 210, which is the STA having a sequence of data (frames or transmissions) to transmit, operates in a transmitting mode to transmit the first data (frame or transmission) 230 of the sequence of data after winning a channel contention, and then, switches to a receiving mode to receive the first acknowledgment (ACK) frame 232 from Recipient 220, which is the intended receiving STA of the sequence of data, the first ACK frame 232 acknowledging a correct reception of the first data 230 by

Recipient 220. Recipient 220 operates in the receiving mode when Sender 210 transmits the first data 230, and operates in the transmitting mode when Sender 210 receives the first ACK frame 232. Therefore, both Sender 210 and Recipient 220 are STAs that are capable of both transmitting and receiving. The terms of sender and recipient are used to emphasize the logical roles that these STAs respectively play with regards to transmitting or receiving a specific data. An STA can be a sender for one data and a recipient for another data at the same time.

The short inter-frame space (SIFS), e.g., SIFS 240, which is the time gap between the first data 230 and first ACK frame 232 provides sufficient time for Sender 210 and Recipient 220 to switch between the transmitting and receiving modes. After receiving the first ACK frame 232, Sender 210 initiates another channel contention procedure, and after winning that channel contention, switches to the transmitting mode to transmit the second data 245 in the sequence of data, and then, switches to the receiving mode to receive the second ACK frame 247, and so on and so forth. The DIFS plus random back-off (BO) period 250, which is the time gap between the first ACK frame 232 and the second data 245, includes the time for Sender 210 to detect the channel being idle for a DIFS so as to initiate the random back-off and to perform the back-off, so as to win the channel contention, as well as the time for Sender 210 and Recipient 220 to switch between the transmitting and receiving modes. The random back-off involves setting the back-off timer to a random value and then counting down the back-off timer at a uniform rate towards zero, as described previously.

As shown in Figure 2, Sender 210 cannot transmit a subsequent data before the ACK for the current data is received, therefore delaying the transmission of the subsequent data. To overcome this issue, 802.11 supports a burst transmission mode, wherein a sender transmits a burst of data without stopping for the ACK frames in between (but with the SIFS remaining in between), and at the end of the burst, transmits a block ACK request (BAR) frame to solicit a block ACK (BA) frame from the recipient, the BA frame including a bitmap indicating whether each of the data in the burst has been received by the recipient correctly or not.

Figure 3 illustrates an example data transmission sequence 300 between the conventional 802.11-complaint devices utilizing the burst transmission. As show in Figure 3, Sender 310 transmits a burst consisting of three data (e.g., Data 325, 327, and 329) and a BAR frame 335, with SIFSs in between. In response to the BAR frame 335, Recipient 320 transmits a BA frame 340 indicating whether each of the three data in the burst has been received correctly or not. However, if Recipient 320 misses a data early in the burst, Sender 310 would be unaware of the situation until the BA frame 340 is received, not only delaying the retransmission of the lost data but also causing either out-of-order delivery or head-of-line (HOL) blocking. HOL blocking refers to a condition wherein subsequently received data are held up from being delivered to a destination or higher layer entity, due to a data sent earlier in the sequence being lost, so as to recover the lost data before all data are delivered in-order. HOL blocking can severely affect the transmission control protocol (TCP) throughput.

Figure 4 illustrates an example data transmission sequence 400 between the conventional 802.11-complaint devices involving sending TCP data. As shown in Figure 4, Sender 410 has data in the form of TCP Segments to be transmitted to Recipient 420, both Sender 410 and Recipient 420 comprising 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 handling the processing at the IP layer. The detailed processing performed by the IP entity is intentionally omitted herein for simplicity. First, the 802.11 module of Sender 410 transmits, to Recipient 420, data frame 425 encapsulating a first TCP segment, e.g., TCP Seg. 1 in Figure 4. In response to receiving data frame 425, the 802.11 module of Recipient 420 transmits, to Sender 410, ACK frame 427 acknowledging the reception of data frame 425. And at the TCP layer, in response to receiving the first TCP segment, the TCP entity of Recipient 420 generates a first TCP ACK, e.g., TCP ACK 1 in Figure 4, for the 802.11 module of Recipient 420 to transmit back to Sender 410. The 802.11 module of Recipient 420 then transmits, to Sender 410, data frame 429 encapsulating the first TCP ACK. In response to receiving data frame 429, the 802.11 module of Sender 410 transmits, to Recipient 420, ACK frame 431 acknowledging the reception of data frame 429. And 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 (such as TCP Reno), the size of the congestion window limiting the maximal number of unacknowledged

TCP segments that may be in transit end-to-end, and as a result of the increasing its congestion window, releases next two TCP segments, e.g., TCP Seg. 2 and 3, for the 802.11 module of Sender 410 to transmit to Recipient 420.

Then, the 802.11 module of Sender 410 transmits, to Recipient 420, a first burst consisting of data frame 433 encapsulating TCP Seg. 2, data frame 435 encapsulating TCP Seg. 3, and BAR frame 437, with SIFSs in between. In response to receiving BAR frame 437, the 802.11 module of Recipient 420 transmits, to Sender 410, BA frame 439 indicating whether each of data frames 433 and 435 has been received correctly or not. Recipient 420 further transmits, to Sender 410, a second burst consisting of data frame 441 encapsulating TCP ACK 2, data frame 443 encapsulating TCP ACK 3, and BAR frame 445, and in response, receives from Sender 410, BA frame 447 indicating whether each of data frames 441 and 443 has been received correctly or not. At the TCP layer, receiving TCP ACKs 2 and 3 causes the TCP entity of Sender 410 to further increase the size of its congestion window by 2 segments, and release next four TCP segments for transmission if there are four or more TCP segments pending for transmission, and so on so forth.

As shown in Figure 4, TCP ACK 2 (to be encapsulated in data frame 441) may have arrived at the 802.11 module of Recipient 420 for transmission soon after data frame 433 encapsulating TCP Seg. 2 is received, but data frame 441 cannot be transmitted until the transmission of the first burst by Sender 410 is completed. As the size of TCP congestion window of Sender 410 is ramped up, each subsequent burst transmission of Sender 410 may involve more and more TCP segments. Hence, TCP ACKs generated later by Recipient 420 may encounter more and more queuing delay prior to being actually transmitted, because the shared channel, which is utilized in TDD fashion, hasn’t been cleared from a previous transmission, e.g., a long burst

transmission from Sender 410. The delays in delivering those TCP ACKs will dampen the ramp up rate of the size of TCP congestion window of Sender 410, and as a result, limiting the achievable TCP throughput of Sender 410. In summary, TDD and long burst transmissions used by conventional 802.111 systems may limit the ramp up rate of the TCP throughput.

According to an example embodiment, to overcome the issues associated with the transmission of data sequences, apparatus and methods for aggregating multiple contention based TDD channels to achieve flexible full-duplex communications between devices are provided herein. The multiple contention based TDD channels operate on different radio frequency (RF) carriers that maybe within a same frequency band or from different frequency bands, such as 2.4 GHz, 5 GHz, 60 GHz, etc. Whether within the same frequency band or not, the different radio frequency carriers of the different shared channels are sufficiently separated such that a device capable of such multi-link operation can transmit in one shared channel and receive in another shared channel at the same time without causing interference to one another.

The apparatus and methods allow a data-transmitting device (i.e., a sender) to receive a response to currently transmitted data, such as a response at the MAC layer (e.g., ACK or BA frames) or at a higher layer (e.g., TCP ACKs), without interrupting the transmission of subsequent data or the response being deferred for the transmission of subsequent data. The apparatus and methods also allow a data-receiving device (i.e., a recipient) to send a response to a currently received data, such as a response at the MAC layer (e.g., ACK or BA frames) or at a higher layer (e.g., TCP ACKs), without interrupting the reception of subsequent data or the transmission of the response being deferred to such receptions. The apparatus and methods further allow frequency and time resources of any channel of the multiple channels between the data-transmitting device and the data-receiving device be used dynamically for transmitting data or response to the data in any direction so as to minimize not only the transmission durations of the data or the responses but also the transmission queuing delay of the responses.

For example, a first device (a sender) may transmit at least some data of a traffic stream to a second device (a recipient) over a first contention based TDD channel (a first shared channel) and at least some other data of the same traffic stream to the second device over a second contention based TDD channel (a second shared channel), e.g., on first-come-first-serve basis. Furthermore, the second device may transmit, over the first shared channel, at least some responses generated at the MAC layer (e.g., ACK or BA frames) or a higher layer (e.g., TCP ACKs) responsive to the data received from the first device, and over the second shared channel, at least some other responses at the MAC layer or the higher layer responsive to the data received from the first device, e.g., on first-come-first-serve basis. For another example, the first device may transmit a burst of data of the traffic stream to the second device over the first shared channel, while receiving a response from the second device over the second shared channel, which occurs without interrupting the transmission of the burst of data over the first shared channel or having the response being deferred to the transmission of the burst of data over the first shared channel.

Figure 5 illustrates a communications system 500 highlighting example block diagrams of two devices communicating with one another using multiple contention based TDD channels to achieve flexible full-duplex communications. As shown in Figure 5, multi-channel or multi-link (ML) Device 1505 comprises STAi 506 and STA2507, with STAi 506 and STA2507 operating on Channel 1508 and Channel 2 509, respectively. ML Devices 1505 and 2510 are shown in Figure 5 as communicating over Channels 1508 and 2 509. As used herein, the acronym ML represents multi-link, however, because link and channel are synonymous, ML also represents multi-channel. However, example embodiments are operable with ML Devices communicating over more than two channels.

STAi 506 and STA2507 can be realized as two independent radio communications modules (RCMs) and are identified with MAC addresses of MAC_Addressi and MAC_Address2, respectively, wherein MAC_Addressi and MAC_Address2 may be same or different. ML Device 2 510 comprises STA3 511 and STA4512, with STA3 511 and STA4512 operating on Channel 1 508 and Channel 2509, respectively. STA3 511 and STA4512 can be realized as two

independent RCMs and are identified with MAC addresses of MAC_Address3 and

MAC_Address4, respectively, wherein MAC_Address3 and MAC_Address4 maybe same or different. ML Devices 1505 and 2 510 maybe an access point (AP) device and a non-AP STA device (such as a client device), respectively, wherein the AP device is an infrastructure equipment providing the non-AP STA device with access to a network. Similarly, ML Devices 1 505 and 2 510 may be a non-AP STA device and an AP device, respectively. Alternatively, ML

Devices 1505 and 2510 may be two peer devices operating in a peer-to-peer (P2P) or ad-hoc communications mode. ML Devices 1505 and 2510 may initially perform an association and authentication process with one another and establish shared secret keys by exchanging management messages over a first channel, e.g., Channel 1508 by using STAi 506 and STA3 511, respectively, as shown in Figure 5. In this situation, Channel 1508 operates as the master channel. STAi 506 and STA3 511 operate as the master RCMs. Then, ML Devices 1505 and 2 510 may configure their respective STA2 507 and STA4512, to add Channel 2 509 for exchanging data of a traffic stream using channel aggregation, such traffic stream being referred to as an ML traffic stream. In this situation, Channel 2 509 operates as a slave channel, and STA2 507 and STA4512 operate as slave RCMs.

Adding a slave channel to enable the channel aggregation maybe configured on a per traffic stream basis or a per device basis. The PHY entity of a slave RCM, such as PHY entity 522 or PHY entity 532, when receiving radio signal carrying a PHY protocol data unit (PPDU), may optionally perform PPDU filtering based on whether a partial identifier in the PHY header of the received PPDU matches one of at least one or more pre-configured partial identifiers. When the slave channel (e.g., Channel 2509) is configured, the PHY entities of the slave RCMs may be configured to accept received PPDUs with the PHY header containing the partial identifier assigned to the respective Master RCM (e.g., STAi 506 and STA3 511).

For example, the PHY entity 522 of STA2507 may be configured to accept received PPDUs with the PHY header containing the partial identifier assigned to STAi 506, and the PHY entity 532 of STA4512 may be configured to accept received PPDUs with the PHY header containing the partial identifier assigned to STA3 511. In addition, if STA2507 and STA4512 are also used for exchanging data of a concurrent non-ML traffic stream between ML Devices 1505 and 2510, the PHY entity 522 of STA2 507 may be configured to accept received PPDUs with the PHY header containing the partial identifier assigned to STA2 507, and the PHY entity 532 of STA4 512 may be configured to accept received PPDUs with the PHY header containing the partial identifier assigned to STA4512. Channel 1508 and Channel 2 509 refer to the shared wireless medium (WM) operating over different radio frequencies. Master channel and slave channel also refer to channels, but with emphasis being placed on the logical role of the channels in the link aggregation operations. Furthermore, the discussion presents Channel 1508 as the master channel and Channel 2509 as the slave channel. However, the example embodiments presented herein are operable with either of the two channels being the master channel and the remaining channel being the slave channel. Differences between the master channel and slave channel (and between the master RCM and slave RCM) include that there is only one master channel (and therefore one master RCM on both sides of the ML), while there may be one or more slave channels (and therefore one or more slave RCMs on the both sides).

According to an example embodiment, 802.11 data frames carrying (higher layer) data of the ML traffic stream, management frames (such as 802.11 action frames) carrying management messages associated with the channel aggregation used on the ML traffic stream, and control frames (such as ACK, BAR, and BA frames) are processed by the MAC entities of the master RCMs on both ends of the ML for transmitting and receiving purposes, respectively. This is independent of which channel (i.e., master channel or slave channel) is actually used in the transmitting and receiving of each of these frames. Therefore, all the data, management, or control frames carry a MAC header that includes the MAC addresses of the master RCMs, such as MAC_Addressi and MAC_Address3, in the receiver address (RA) field and transmitter address (TA) field, or vice versa, depending on which way the frame is transmitted. The RA field is also referred to as Address 1 (or Ai) field, and the TA field is also referred to as Address 2 (or A2) field. When data confidentiality or integrity protection is required, only the security keys shared between the master RCMs (such as STAi 506 and STA3 511) are used for protecting these frames.

Another difference between the master channel and slave channel (and between the master RCM and slave RCM) is that the master RCMs provide the interface (i.e., a data anchor point) with the higher layers for all data of the ML traffic stream. As shown in Figure 5, ML Device 1 505 interfaces with its higher layers, via the MAC service access point (M-SAP) 516 of STAi 506, to obtain higher layer data (e.g., IP packets encapsulating TCP segments) of the ML traffic stream destined to ML Device 2 510 and to deliver higher layer responses (e.g., IP packets encapsulating TCP ACKs) received from ML Device 2 510. Meanwhile, ML Device 2 510 interfaces with its higher layers, via the M-SAP 521 of STA3 511, to obtain the higher layer responses destined to ML Device 1 505 and to deliver the higher layer data of the ML traffic stream received from ML Device 1 505. The MAC entities and M-SAPs of STA2 507 and STA4 512, which are shown as the shaded areas in Figure 5, may not be used for processing data nor used as the data anchor points for this ML traffic stream. However, in other example

embodiments, the MAC entities and M-SAPs of STA2 507 and STA4 512 maybe utilized, e.g., when STA2 507 and STA4 512 are used for exchanging data of a concurrent non-ML traffic stream between ML Devices 1 505 and 2 510. As shown in Figure 5, a de-multiplex (DEMUX) and multiplex (MUX) unit (e.g., DEMUX/MUX units 530 and 535) is added between the MAC and PHY layers across Channel 1508 and Channel 2 509, in ML Devices 1505 and 2510, respectively. In the transmitting direction, for each frame generated by the MAC entity of the master RCM associated with the ML traffic stream, the DEMUX/MUX unit selects a channel among the multiple channels, such as

Channels 1508 and 2509, for the pending transmission, and forwards the frame to the PHY entity associated with the selected channel for executing the transmission. In the receiving direction, the DEMUX/MUX unit aggregates frames associated with the ML traffic stream received over Channels 1508 and 2509, and delivers them to the MAC entity of the master RCM for processing, as if the frames were all received over the master channel (e.g., Channel 1).

Figure 5 illustrates a situation where two devices are communicating with one another using multiple contention based TDD channels. However, the example embodiments presented herein are operable in a situation where one device simultaneously communicates with two or more other devices. In this situation, ML Device 1505 may communicate with ML Device 2 510 with Channel 1505 as a master channel and Channel 2 509 as a slave channel, while ML Device 1505 may communicate with a ML Device 3 with Channel 2 509 as a master channel and Channel 1 505 as a slave channel. In this situation, DEMUX/MUX unit 530 selects channels for frames destined for ML Device 2510 or ML Device 3, or frames from ML Device 2510 or ML Device 3. In this situation, DEMUX/MUX unit 530 is capable of selecting channels in order to support communications with two or more devices.

Figure 6 illustrates a block diagram of DEMUX/MUX unit 600. DEMUX/MUX unit 600 may be an example embodiment of the DEMUX/MUX units 530 and 535 as shown in Figure 5.

DEMUX/MUX unit 600 includes interfaces for a master channel 605 and one or more slave channels 607. As shown in Figure 6, DEMUX/MUX unit 600 includes interface 610 interfacing with the MAC entity of the master RCM (e.g., the MAC Header and CRC Creation and A-MPDU

Aggregation unit of the MAC entity of the master RCM) for obtaining frames generated by the MAC entity of the master RCM, interface 612 interfacing with the MAC entity of the master RCM (e.g., the Block Ack Scoreboarding unit of the MAC entity of the master RCM) for delivering frames received by the PHY entities of the master and slave RCMs, interfaces 620 and 626 interfacing with the transmitting (TX) paths of the PHY entities of the master and slave RCMs, respectively, for delivering frames to the selected PHY entities for transmission, interfaces 622 and 624 interfacing with the receiving (RX) paths of the PHY entities of the master and slave RCMs, respectively, for obtaining frames received by these PHY entities, an ML Monitoring and Selection unit 630, a Frame Distribution unit 632, A-MPDU De-aggregation and MAC Header and CRC Validation units 634 and 636, and Address Filtering units 638 and 640. DEMUX/MUX unit 600 may further include interfaces 614 and 616 interfacing with the receiving and transmitting paths of the MAC entity of the slave RCM, respectively.

Interfaces 614 and 616 are not used for data of the ML traffic stream. However, if there is another concurrent traffic stream of the ML device that is configured over Channel 2 (the slave channel) that is not using channel aggregation (i.e., a non-ML traffic stream), transmitted data of that non-ML traffic stream may pass transparently through DEMUX/MUX unit 600 via interfaces 616 and 626 (shown as the downward dot-line arrow in Figure 6), and received data of that non-ML traffic stream may pass transparently through DEMUX/MUX unit 600 via interfaces 624 and 614 (shown as the upward dot-line arrow in Figure 6). Although, only two channels (denoted as master channel and slave channel) are shown in Figure 6, DEMUX/MUX unit 600 may provide the distribution and aggregation functionality for more than two channels.

In the transmitting direction (shown as downward pointing solid-line arrows) of the ML traffic stream, a sequence of frames generated by the MAC entity of the master RCM enters

DEMUX/MUX unit 600 via interface 610. ML Monitoring and Selection unit 630 selects one channel (or more than one channel for redundancy purposes) among the multiple channels, over which a next frame is to be transmitted. The selection of the channel (or the channels) may be based on availability of the channels. In a situation when more than one channel is available, ML Monitoring and Selection unit 630 may select the channel from the more than one channel in accordance with a performance history of the channels, error rates of the channels, utilization of the channels, and so on. ML Monitoring and Selection unit 630 may prioritize a frame to be the next frame in the queue to be transmitted. For example, a frame to be re-transmitted may have a higher priority to be the next frame. For another example, a frame encapsulating a higher layer response, e.g., a TCP ACK, may have a higher priority to be the next frame. Frames encapsulating a TCP ACK may be recognized by a well-known fixed size of the TCP ACK, for example. MPDU Distribution unit 632 forwards the next frame to the PHY entity of the RCM on the selected channel(s).

In the receiving direction (shown as upward pointing solid-line arrows) of the ML traffic stream, frames received over the multiple channels enter DEMUX/MUX unit 600 via interface 622, if received over the master channel 605, or via interface 624, if received over the slave channel 607. Then, A-MPDU De-aggregation and MAC Header and CRC Validation units 634 and 636 performs A-MPDU de-aggregation and MAC header and CRC validation on the frames received over their respective channels to ensure that the frames received are valid frames. Then, Address Filtering units 638 and 640 may perform frame filtering based on the MAC address(es) in the MAC headers of the respective received frames. For example, the frame filtering maybe based on a value in the RA field in the MAC header matching the MAC address of the receiving master RCM. Alternatively, the frame filtering may be based on a value in the TA field in the MAC header matching the MAC address of the transmitting master RCM, with which the receiving master RCM has configured the channel aggregation for the ML traffic stream. Yet alternatively, the frame filtering may be based on both the RA and TA values being matched. Address Filtering units 638 and 640 pass on the (matched) frames to the MAC entity of the master RCM through interface 612 for the conventional MAC processing as if all these frames were received over the master channel 605.

Figure 7 illustrates detailed example higher layer entities 700. Higher layer entities 700 maybe an embodiment of the higher layers entities shown in Figure 5. As shown in Figure 7, higher layer entities 700 may include a logical link control (LLC) sub-layer entity 705, which sub-layer, together with the MAC sub-layer, 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, and an application layer (also referred to as Layer 7) entity 715. A popular protocol used in the network layer is the internet protocol (IP), for example. A popular protocol used in the transport layer is the transmission control protocol (TCP), for example.

If an ML device (such as ML Device 1505 or 2510) is a client device (e.g., a mobile phone or a UE), the high layers entities above the ML device are usually co-located with the ML device. On the other hand, if an ML device is an infrastructure equipment connected with the network, such as an AP device, the higher layers entities above the infrastructure ML device may not all be co- located with the infrastructure ML device. For example, the application layer entity 720 and transport layer entity 715, as shown in Figure 7, above the infrastructure ML device may be implemented at a network server that is remote from the local area network where the infrastructure ML device and the client ML device are situated. Furthermore, the network layer entity 710 may be implemented at gateways that are co-located with the infrastructure ML device and the network server hosting the application, respectively, and at a number of routers situated along the data-transmission path between the gateways.

Figure 8A illustrates a format of an 802.11 data signal 800 conveying higher layer data or higher layer response. For example, a TCP segment (the higher layer data) or TCP ACK (the higher layer response) is encapsulated in an IP packet as its payload, the IP packet being encapsulated in an 802.11 data frame (also referred to as MAC protocol data unit or MPDU) as the payload of the data frame, the data frame being encapsulated in an 802.11 PPDU as the payload of the PPDU. Data signal 800 includes a PHY header 805, a MAC header 807, an IP header 809, an IP payload 811, and cyclic redundancy check (CRC) field 813. PHY header 805, MAC header 807, and IP header 809 contain control information for respective protocol entities processing data signal 800. IP payload 811 contains information, such as the TCP segment or TCP ACK discussed above. CRC field 813 includes CRC information used in checking the integrity of data signal 800.

Figure 8B illustrates a frame format of an 802.11 MAC layer control frame 825 carrying an ACK frame. Control frame 825 includes a PHY header 830, a MAC header 832, and a CRC field 834. The information needed to acknowledge the received data frame, e.g., the MAC address of the data-sender (i.e., the intended recipient of the ACK), and the sequence number (SN) and fragment number (FN) in the received data frame, are included in the MAC header 832. The PHY header 830 may include a partial identifier of the intended recipient in order to facilitate the PPDU filtering that may optionally be performed by the recipient.

Figure 8C illustrates a frame format of an 802.11 MAC layer control frame 850 carrying a BAR, BA, or negative ACK (NACK) indication. Control frame 850 includes a PHY header 855, a MAC header 857, a payload field 859, and a CRC field 861. The payload field 859 includes the BAR, BA, or NACK information. The BAR, BA, and NACK frames share a similar frame format but differ in the detailed contents in the payload field 859 (i.e., BAR, BA, or NACK information). A type subfield in the payload field 859 indicates which variant (i.e., BAR, BA, or NACK) is being carried in the control frame 850.

Figure 9 illustrates a diagram 900 of a first example embodiment of the flexible full-duplex communications enabled by using multiple contention based TDD channels, wherein, without interrupting on-going data reception, a data-receiving device (i.e., a Recipient 907) sends unsolicited NACK indicating a lost data to a data-transmitting device (i.e., a Sender 905) to enable early re-transmission of the lost data. For example, as shown in Figure 9, Sender 905 is an AP device consisting of APi and AP2 operating over Channels 1 910 and 2 912, respectively, and Recipient 907 is a non-AP STA device consisting of STAi and STA2 operating over Channels 1 910 and 2 912, respectively. Herein, the AP device is referred to as the ML-AP device (Sender 905) and the non-AP STA device is referred to as the ML-STA device (Recipient 907) to avoid confusion with the individual components within. The ML-AP device (Sender 905) first uses APi to send burst of data to the ML-STA device (Recipient 907) over Channel 1 910, which is the master channel. The ML-STA device (Recipient 907) uses STAi to receive the burst of data over Channel 1 910. Having received Data 1 920 and Data 3 924 but not Data 2 922, the ML-STA device (Recipient 907) determines that Data 2 922 is lost, because the data are always transmitted in sequence. Without interrupting the on-going reception of the burst of data over Channel 1 910 and without waiting for the burst to finish or an explicit request (e.g., the BAR 926 in Figure 9) from the ML-AP device (Sender 905), the ML- STA device (Recipient 907) uses the MAC entity of STAi to generate an unsolicited NACK frame 928 including an indication that Data 2 922 is lost, then the ML-STA device (Recipient 907) uses its DEMUX/MUX unit to select Channel 2 912 for transmitting NACK frame 928, and based thereon, uses the PHY entity of STA2 to execute the transmission of NACK frame 928 to AP2 over Channel 2 912.

The NACK frame 928 may be a new Control frame, an unsolicited BA frame, a new variant of BA frame, or a null data packet (NDP) frame with a new high-throughput (HT) Control variant, for example. The NACK frame 928 includes information identifying the lost data, e.g., the SN of the lost data frame or a bitmap with a bit corresponding to the lost data being a value conveying the negative acknowledgement, so that strict timing between the NACK frame 928 and the lost data frame is not required. As soon as the lost data is determined, the NACK frame 928 is prepared by the MAC entity of STAi (which is the master RCM of the ML-STA device (Recipient 907)) as if the NACK frame 928 is to be transmitted over Channel 1 910, with the MAC header of the

NACK frame 928 including the MAC address of APi in the RA field and the MAC address of STAi in the TA field, for example.

When the NACK frame 928 arrives at the DEMUX/MUX unit of the ML-STA device (Recipient 907) for transmission, Channel 1 910 is still being used by the ML-AP device (Sender 905) for transmitting the data burst and therefore isn’t a valid choice for the ML Monitoring and

Selection unit within the DEMUX/MUX unit to select from. That leaves Channel 2 912 as the only choice in this particular example. Therefore, as soon as the ML Monitoring and Selection unit within the DEMUX/MUX unit determines that Channel 2 912 is idle, the Frame

Distribution unit within the DEMUX/MUX unit routes the NACK frame 928 to the PHY entity of STA2 for transmission. The PHY entity of STA2 adds a PHY header to the NACK frame 928 to form a PPDU for transmission over Channel 2 912. Meanwhile, the ML-STA device (Recipient 907) delivers Data 1 920 to higher layers above the ML-STA device (Recipient 907) via M-SAP of STAi, while holding onto Data 3 924, resulting in HOL blocking (but less severe than holding Data 3~6 it otherwise would have to if not sending the NACK). The PHY header added may also contain a partial identifier of APi.

While APi sends Data 4 930 over Channel 1 910, the PHY entity of AP2 receives the PPDU carrying the NACK frame 928 over Channel 2 912. The PHY entity of AP2 has been configured to accept the partial identifier of APi and therefore passes on the PHY payload (the NACK frame 928) to the DEMUX/MUX unit of the ML-AP device (Sender 905), which forwards the NACK frame 928 to the MAC entity of APi, because the RA field in the MAC header carries the MAC address of APi. Therefore, the NACK frame 928 was received by the MAC entity of APi as if the NACK frame 928 was received over Channel 1. As a result, the MAC entity of APi is informed that Data 2 922 is lost and schedules a re-transmission of Data 2 (shown as either Data 2 Re-Tx 932 or Data 2 Re-Tx 936) as the next in the queue. The ML-AP device (Sender 905) may prioritize the re-transmission of Data 2 (where the re-transmission of Data 2 is shown as Data 2 Re-Tx 932) over Channel 1 910 by deferring Data 5 934 or use AP2 to re-transmit Data 2 over Channel 2 912 (where the re-transmission of Data 2 is shown as dashed Data 2 Re-Tx 936) without deferring Data 5 934. Then, the ML-STA device (Recipient 907) receives the re transmitted Data 2 (either frame 932 or frame 936) and delivers Data 2~4 to the higher layers above the ML-STA device (Recipient 907) in-order, earlier than it otherwise be able to if the ML- STA device (Recipient 907) had not sent the NACK frame 928, as shown in Figure 9. If the NACK frame 928 had not been sent, HOL blocking would have occurred with greater severity, e.g., Data 3~6 would be held until a retransmission of Data 2 922 is received by the ML-STA device (Recipient 907) after the BA frame 938 is received by the ML-AP device (Sender 905).

Figure 10 illustrates a diagram 1000 of a second example embodiment of the flexible full-duplex communications enabled by using multiple contention based TDD channels, wherein any channel of the multiple channels can be used for transmitting/ receiving either data or response (at either the MAC layer or the TCP layer) to data in any direction, as long as that channel and frame for that direction are available. In this example embodiment, the ML-AP device (Sender 1005) comprises APi and AP2 operating over Channels 1 1010 and 2 1012, respectively, and the ML-STA device (Recipient 1007) comprises STAi and STA2 operating over Channels 1 1010 and 2 1012, respectively. As shown in Figure 10, the ML-AP device (Sender 1005) first uses APi to send data frame 1020 encapsulating TCP Seg. 1 to the ML-STA device (Recipient 1007) over Channel 1 1010. The ML-STA device (Recipient 1007) uses STAi to receive it and send back an ACK frame 1022 over Channel 1 1010. After the ML-STA device (Recipient 1007) delivers the received TCP Seg. 1 to the TCP entity above the ML-STA device (Recipient 1007), the TCP entity generates TCP ACK 1 for the ML-STA device to send back to the ML-AP device (Sender 1005). When data frame 1024, which is generated by the MAC entity of STAi and encapsulates TCP ACK 1, arrives at the DEMUX/MUX unit of the ML-STA device (Recipient 1007), Channel 1 1010 is being used by APi for sending, to STAi, the ACK frame 1022 acknowledging the reception of data frame 1020, while Channel 2 1012 is idle. This leaves Channel 2 1012 as the first available choice for transmitting data frame 1024 encapsulating TCP ACK 1. Hence, the ML Monitoring and Selection unit of the DEMUX/MUX unit of the ML-STA (Recipient 1007) selects Channel 2 1012, and based there on, the Frame Distribution unit forwards data frame 1024 encapsulating TCP ACK 1 to the PHY entity of STA2 for transmission. Furthermore, in response to the transmission, the PHY entity of STA2 receives an ACK frame 1026 from AP2, without interrupting the on-going transmission over Channel 1 1010 or waiting for the on-going transmission to complete.

As described before, TCP ACK 1 is obtained from the higher layer entities through the M-SAP of STAi. Data frame 1024 encapsulating TCP ACK 1 is generated by the MAC entity of STAi as if it was to be transmitted over Channel 1 1010, independent of which channel data frame 1024 encapsulating TCP ACK 1 is actually transmitted. So, the MAC header of data frame 1024 contains the MAC address of APi in the RA field and the MAC address of STAi in the TA field. Also, because the PHY entity of AP2 has been configured to accept PPDUs with the PHY header containing the partial identifier of APi, the PHY entity of AP2 passes on the PHY payload (i.e., data frame 1024) to the DEMUX/MUX unit of the ML-AP device (Sender 1005), which further forwards data frame 1024 to the MAC entity of APi for further processing. Then, the MAC entity of APi delivers the IP packet encapsulating TCP ACK 1 to the higher layer entities above the ML- AP device (Sender 1005) via the M-SAP of APi.

Receiving TCP ACK 1 by the TCP entity above the ML-AP device (Sender 1005) results in the TCP entity increasing the size of its transmission window (which is used for congestion control) by 1 segment, and based thereon, delivers two more TCP segments to the ML-AP device (Sender 1005) for transmission to the ML-STA device (Recipient 1007). For example, TCP Seg. 2 and TCP Seg. 3 arrive at the ML-AP device (Sender 1005). As shown in Figure 10, the ML-AP device (Sender 1005) uses APi to send a first burst consisting of data frames 1028 and 1030

encapsulating TCP Segs. 2 and 3, respectively, and a BAR frame 1032 to STAi over Channel 1 1010, because Channel 1 1010 is available, and as a result, receive a BA frame 1040. When STAi receives these TCP segments and delivers them to the TCP entity above the ML-STA device (Recipient 1007), the TCP entity generates TCP ACKs 2 and 3, respectively, for the ML-STA device (Recipient 1007) to transmit back to the ML-AP device (Sender 1005). When the IP packet encapsulating TCP ACK 2 arrives at the ML-STA device (Recipient 1007) for transmission, Channel 1 1010 is being used for transmitting a data frame 1030 encapsulating TCP Seg. 3, while Channel 2 1012 is idle. So, the ML-STA device (Recipient 1007) uses the PHY entity of STA2 to transmit a data frame 1034 (which is generated using the MAC entity of STAi and encapsulates TCP ACK 2) to AP2, and in response, to receive an ACK frame 1038 from AP2, both over Channel 2 1012 without interrupting the on-going transmission over Channel 1 1010 or waiting for the on-going transmission to complete.

When the IP packet encapsulating TCP ACK 3 arrives at the ML-STA device (Recipient 1007) for transmission, Channel 1 1010 is being used for transmitting the BA frame 1040 within the first burst, while Channel 2 1012 becomes idle as soon as the transmission of the ACK frame 1038 (for the data frame 1034 encapsulating TCP ACK 2) is finished. So, Channel 2 1012 is the first available choice for transmitting the IP packet encapsulating TCP ACK 3, and based thereon, the ML-STA device (Recipient 1007) uses the PHY entity of STA2 to send a data frame 1036 (which is generated using the MAC entity of STAi and encapsulates TCP ACK 3) to AP2, and in response, to receive an ACK frame 1042 from AP2, both over Channel 2 1012 without interrupting the on-going transmission over Channel 1 1010 nor waiting for the on-going transmission to complete.

Receiving TCP ACKs 2 and 3 by the TCP entity above the ML-AP device (Sender 1005) may cause the TCP entity to further increase the size of its transmission window by 2 segments, and based thereon, deliver four more TCP segments to the ML-AP device (Sender 1005) for transmission, e.g., TCP Segs. 4 and 5 arrive at the ML-AP device (Sender 1005) in response to TCP ACK 2, and TCP Segs. 6 and 7 arrive at the ML-AP device in response to TCP ACK 3.

When the IP packets encapsulating TCP Segs. 4 and 5 arrive at the ML-AP device (Sender 1005), Channel 2 1012 is being used for transmitting the ACK frame 1042 for data frame 1036 (which encapsulates TCP ACK 3), while Channel 1 1010 becomes idle as soon as the transmission of the

BA frame 1040 in the first burst is finished. So, Channel 1 1010 is the first available choice for transmitting the IP packets encapsulating TCP Segs. 4 and 5, and based thereon, the ML-AP device uses APi to send a second burst consisting of data frames 1044 and 1046 encapsulating TCP Segs. 4 and 5, respectively, and a BAR frame 1048 to STAi, and in response, to receive a BA frame 1056 from STAi, all over Channel 1 1010.

When the IP packets encapsulating TCP Segs. 6 and 7 arrive at the ML-AP device (Sender 1005), Channel 1 1010 is being used for transmitting the second burst, while Channel 2 1012 becomes idle as soon as the transmission of the ACK frame 1042 for data frame 1036 (which encapsulates TCP ACK 3) is finished. So, Channel 2 1012 is the first available choice for transmitting the IP packets encapsulating TCP Segs. 6 and 7, and based thereon, the ML-AP device (Sender 1005) uses the PHY entity of AP2 to send a third burst (which is generated using the MAC entity of APi and consists of data frames 1050 and 1052 encapsulating TCP Segs. 6 and 7, and a BAR frame 1054) to STA2, and in response, to receive a BA frame 1058 from STA2, all over Channel 2 1012.

When STAi delivers the IP packets encapsulating TCP Segs. 4 and 5 to the higher layer entities via its M-SAP, the TCP entity above the ML-STA device (Recipient 1007) generates TCP ACKs 4 and 5, respectively, to be returned to the ML-AP device (Recipient 1007). When TCP ACK 4 arrives at the ML-STA device (Recipient 1007) for transmission, both channels are busy.

Eventually, Channel 1 1010 becomes available first, after the transmission of the second burst is finished. So, the ML-STA device (Recipient 1007) uses STA 1 to transmit data frame 1060 encapsulating TCP ACK 4 to APi, and in response, to receive an ACK frame 1064 from APi, both over Channel 1 1010. When TCP ACK 5 arrives at the ML-STA device (Recipient 1007) for transmission, both channels are busy. Eventually, Channel 2 1012 becomes available first, after the transmission of the third burst is finished. So, the ML-STA device (Recipient 1007) uses the PHY entity of STA 2 to transmit data frame 1062 (which is generated using the MAC entity of STAi and encapsulates TCP ACK 5) to AP2, and in response, to receive an ACK frame from AP2, both in Channel 2. The ACK frame for TCP ACK 5 is omitted in Figure 10 due to a lack of space.

As shown in Figure 10, the flexible full-duplex scheme allows data (e.g., TCP segments) in one direction and corresponding feedbacks (at both MAC layer, as well as those at a higher layer, such as Transport layer) in the opposite direction to be transmitted at any channel among the multiple channels, on a first-come-first-serve basis, thereby reducing the transmission queuing delay. Comparing to the cases illustrated in Figure 4, reducing the transmission queuing delays helps TCP entities to increase the size of their transmission window faster, and as a result, allow TCP throughput to be ramped up more quickly, because the size of the TCP transmission window, as a congestion control mechanism, limits the maximal number of unacknowledged TCP segments that may be in transit end-to-end.

Figure 11 illustrates a diagram 1100 of a third example embodiment of the flexible full-duplex communications enabled by using multiple contention based TDD channels. The third example embodiment is similar to the second embodiment shown in Figure 10. However, there are differences. As shown in Figure 10, the ML-AP device (Sender 1005) transmits data frames 1044 and 1046 (encapsulating TCP Segs. 4 and 5, respectively), and a BAR frame 1148, all over Channel 1 1010. However, in Figure 11, before the ML-AP device (Sender 1105) begins the actual transmission of data frame 1146 (encapsulating TCP Seg. 5) or the planned BAR frame 1148 over Channel 1 1110, TCP Segs. 6 and 7 also arrive at the ML-AP device (Sender 1105) for

transmission, as a result of TCP ACK 3 being delivered to the TCP entity above the ML-AP device (Sender 1105). Based thereon, the ML-AP device (Sender 1105) expands the originally planned second burst by adding data frames 1150 and 1152 (encapsulating TCP Segs. 6 and 7, respectively), after data frame 1146 (encapsulating TCP Seg. 5) and before the BAR frame 1148. Meanwhile, Channel 2 1112 becomes available after the ACK frame 1156 for data frame 1154 (encapsulating TCP ACK 3) is transmitted. Therefore, after distributing the data frame 1146 (encapsulating TCP Seg. 5) to Channel 1 1110, the DEMUX/MUX unit of the ML-AP device (Sender 1105) distributes the data frame 1150 (encapsulating TCP Seg. 6) to Channel 2 1112, then the data frame 1152 (encapsulating TCP Seg. 7) to Channel 1 1110, then the BAR frame 1148 to Channel 2 1112, for transmission, all based on the first-come-first-serve policy. The BAR frame 1148 (in the second burst) is a request for acknowledgements for the data frames 1144- 1152 (encapsulating TCP Segs. 4-7, respectively). In response, a BA frame 1158 is received over Channel 2 1112 indicating whether each of data frames 1144-1152 (encapsulating TCP Segs. 4-7, respectively) is received by the ML-STA device (Recipient 1107) correctly or not.

Before the ML-STA device (Recipient 1107) transmits the BA frame 1158, IP packets

encapsulating TCP ACKs 4-7 arrive at the ML-STA device (Recipient 1107). The ML-STA device (Recipient 1107) may form, using the MAC entity of STAi (its master RCM), a third burst of its own, consisting of data frames (frames 1160, 1162, 1164, and 1166) encapsulating TCP ACKs 4~7, respectively, and a BAR frame 1168 for transmission. The DEMUX/MUX unit of the ML-STA device (Recipient 1107) distributes the data frame 1160 (encapsulating TCP ACK 4) to a first available channel, e.g., Channel 1 1110, then the data frame 1162 (encapsulating TCP ACK 5) to a first available channel, e.g., Channel 2 1112, then the data frame 1164 (encapsulating TCP ACK 6) to a first available channel, e.g., Channel 1 1110, then the data frame 1166 (encapsulating TCP ACK 7) to a first available channel, e.g., Channel 2 1112, then the BAR frame 1168 to a first available channel, e.g., Channel 1 1110, for transmission, all based on the first-come-first-serve policy. The BAR frame 1168 (in the third burst) is a request for acknowledgements for the data frames 1160-1166 (encapsulating TCP ACKs 4~7, respectively). In response, a BA frame 1170 is received over Channel 1 1110 indicating whether each of the data frames 1160-1166

(encapsulating TCP ACKs 4-7, respectively) is received by the ML-AP device (Sender 1105) correctly or not. In an alternative embodiment (not shown in Figure 11), the ML-STA device (Recipient 1107) may aggregate TCP ACKs 4-7 into one MPDU by using an aggregated MAC service data unit (A-MSDU), transmits the MPDU and receives an ACK frame over Channel 1 mo. In yet another alternative embodiment (also not shown in Figure n), the ML-STA device (Recipient 1107) may aggregate TCP ACKs 4-7 into one aggregated MPDU (A-MPDU), transmits the A-MPDU and a BAR frame, and receives a BA frame over Channel 1 1110.

Figure 12 illustrates a flow diagram of example operations 1200 occurring in a Sender.

Operations 1200 may be indicative of operations occurring in a Sender as the Sender

communicates using flexible full-duplex communications according to the example

embodiments presented herein.

Operations 1200 begin with the Sender obtaining a first transmission opportunity (TXOP) on a shared channel (block 1205). As discussed previously, obtaining a TXOP involves the Sender determining which shared channels of a plurality of shared channels are available and selecting the shared channel from shared channels that are available. For example, the Sender may determine if a shared channel is available by first performing a clear channel assessment (CCA) on the shared channel to determine that the shared channel has been idle for a DIFS, then setting a back-off timer with a random value, then counting down the back-off timer towards zero at a uniform rate as long as the shared channel remains idle, suspending the counting down when the shared channel becomes busy and resuming the counting down when the shared channel has become idle for a DIFS again, and determining that the shared channel is ready for transmission when the back-off timer reaches zero. In a situation where there are no shared channels available, the Sender may wait until one or more shared channels become available. Alternatively, the Sender may defer the transmission of the first transmission and try again at a later time.

If there is only a single shared channel available, the Sender selects the only shared channel available. In a situation when there are multiple available shared channels, the Sender may apply a selection rule to select the shared channel. The Sender may apply one or more selection rules to select the shared channel. Examples of the selection rule includes, but are not limited to: traffic on the shared channels; type of shared channel (e.g., master channel, or slave channel); priority of the shared channels; performance guarantees of the shared channels (e.g., Quality of Service (QoS) guarantees); error rates of the shared channels; successful transmission rates of the shared channels; failed transmission rates of the shared channels; historical performance information of the shared channels; bandwidth of the shared channels; and so on. In addition, the Sender may utilize its own shared channel selection information to select the shared channel. As an example, the Sender may select a shared channel upon which it has successfully transmitted in the past. As another example, the Sender may avoid a shared channel upon which it has unsuccessfully transmitted in the past. Furthermore, the communicating devices may share their shared channel selection information to help their neighbors select shared channels.

The Sender transmits a first transmission in accordance with the first TXOP (block 1207). The first transmission may be a transmission of a sequence of transmissions. In other words, the first transmission is a part of a transmission burst. The first transmission is transmitted on the shared channel selected by the Sender in block 1205.

The Sender receives a first response (block 1209). The first response maybe received on a shared channel that was available at the time that the first response was transmitted by the Recipient. In other words, the first response was received on a shared channel that was selected based on the availability of the shared channel.

The Sender obtains a second TXOP (block 1211). The second TXOP is obtained in accordance with the availability of the shared channels, in a manner similar to the description of the Sender obtaining the first TXOP. The Sender transmits a second transmission in accordance with the second TXOP (block 1213). The second transmission maybe a transmission of the sequence of transmissions. In other words, the second transmission is a part of the transmission burst. The second transmission is transmitted on the shared channel selected by the Sender in block 1211.

Figure 13 illustrates a flow diagram of example operations 1300 occurring in a Recipient.

Operations 1300 maybe indicative of operations occurring in a Recipient as the Recipient communicates using flexible full-duplex communications according to the example

embodiments presented herein.

Operations 1300 begin with the Recipient receiving a first transmission (block 1305). The first transmission may be received on a shared channel that was available at the time that the first transmission was transmitted by the Sender. In other words, the first transmission was received on a shared channel that was selected based on the availability of the shared channel.

The Recipient obtains a first TXOP (block 1307). As discussed previously, obtaining a TXOP involves the Recipient determining which shared channels of a plurality of shared channels are available (i.e., performing a CCA on the shared channel to determine that the shared channel has been idle for a DIFS, then setting a back-off timer with a random value, then counting down the back-off timer towards zero at a uniform rate as long as the shared channel remains idle, suspending the counting down when the shared channel becomes busy and resuming the counting down when the shared channel has become idle for a DIFS again, and determining that the shared channel is ready for transmission when the back-off timer reaches zero), and selecting the shared channel from shared channels that are ready for transmission. In a situation where there are no shared channels available, the Recipient may wait until one or more shared channels become available. Alternatively, the Recipient may defer the transmission of the first transmission and try again at a later time.

If there is only a single shared channel available, the Recipient selects the only shared channel available. In a situation when there are multiple available shared channels, the Sender may apply a selection rule to select the shared channel. The Recipient may apply one or more selection rules to select the shared channel. Examples of the selection rules are as discussed previously.

The Recipient transmits a first response in accordance with the first TXOP (block 1309). The first response may be an acknowledgement to the reception of the first transmission, for example. The first response maybe an acknowledgement to the reception of a transmission received prior to the reception of the first transmission, for example. The first response may be a response at the MAC layer (e.g., ACK or BA frames) or at a higher layer (e.g., TCP ACKs). The first response is transmitted on the shared channel selected by the Recipient in block 1307.

The Recipient receives a second transmission (block 1311). The second transmission maybe received on a shared channel that was available at the time that the second transmission was transmitted by the Sender. In other words, the second transmission was received on a shared channel that was selected based on the availability of the shared channel.

Although the discussion presented herein focuses on examples using IEEE 802.11 radio access technology, the embodiment techniques described herein can also be applied to other radio access technologies utilizing wake-up radio or pre-configured duty-cycle as means to reduce power consumption of a radio communications module, such as 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), etc.

Figure 14 illustrates an example communication system 1400. In general, the system 1400 enables multiple wireless or wired users to transmit and receive data and other content. The system 1400 may 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, the communication system 1400 includes electronic devices (ED) i4ioa-i4ioc, radio access networks (RANs) i42oa-i42ob, a core network 1430, a public switched telephone network (PSTN) 1440, the Internet 1450, and other networks 1460. Stations and WUR-capable stations are examples of EDs, and wireless local area networks (WLANs) are examples of RANs. While certain numbers of these components or elements are shown in Figure 14, any number of these components or elements may be included in the system 1400.

The EDs i4ioa-i4ioc are configured to operate or communicate in the system 1400. For example, the EDs 14103-14100 are configured to transmit or receive via wireless or wired communication channels. Each ED i4ioa-i4ioc represents any suitable end user device and may include such devices (or may be referred to) as a user equipment or device (UE), wireless transmit/ 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 device.

The RANs i42oa-i42ob here include base stations I470a-i470b, respectively. APs are examples of base stations. Each base station I470a-i470b is configured to wirelessly interface with one or more of the EDs i4ioa-i4ioc to enable access to the core network 1430, the PSTN 1440, the Internet 1450, or the other networks 1460. For example, the base stations 14.70a-14.70b may include (or be) one or more of several well-known devices, such as a base transceiver station (BTS), a Node-B (NodeB), an evolved NodeB (eNodeB), a Home NodeB, a Home eNodeB, a site controller, an AP, or a wireless router. The EDs 14103-14100 are configured to interface and communicate with the Internet 1450 and may access the core network 1430, the PSTN 1440, or the other networks 1460.

In the embodiment shown in Figure 14, the base station 1470a forms part of the RAN 1420a, which may include other base stations, elements, or devices. Also, the base station 1470b forms part of the RAN 1420b, which may include other base stations, elements, or devices. Each base station i47oa-i47ob operates to transmit or receive wireless signals within a particular geographic region or area, sometimes referred to as a "cell." In some embodiments, multiple- input multiple-output (MIMO) technology may be employed having multiple transceivers for each cell.

The base stations I470a-i470b communicate with one or more of the EDs 14103-14100 over one or more air interfaces 1490 using wireless communication channels. The air interfaces 1490 may utilize any suitable radio access technology.

It is contemplated that the system 1400 may use multiple channel access functionality, including such schemes as described above. In particular embodiments, the base stations and EDs implement LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and wireless protocols may be utilized.

The RANs I420a-i420b are in communication with the core network 1430 to provide the EDs i4ioa-i4ioc with voice, data, application, Voice over Internet Protocol (VoIP), or other services. Understandably, the RANs i42oa-i42ob or the core network 1430 may be in direct or indirect communication 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 the other networks 1460). In addition, some or all of the EDs 14103-14100 may include functionality for communicating with different wireless networks over different wireless channels using different wireless technologies or protocols. Instead of wireless communication (or in addition thereto), the EDs may communicate via wired communication channels to a service provider or switch (not shown), and to the Internet 1450.

Although Figure 14 illustrates one example of a communication system, various changes may be made to Figure 14. For example, the communication system 1400 could include any number of EDs, base stations, networks, or other components in any suitable configuration.

Figures 15A and 15B illustrate example devices that may implement the methods and teachings according to this disclosure. In particular, Figure 15A illustrates an example ED 1510, and Figure 15B illustrates an example base station 1570. These components could be used in the system 1400 or in any other suitable system.

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

The ED 1510 also includes at least one transceiver 1502. The transceiver 1502 is configured to modulate data or other content for transmission by at least one antenna or NIC (Network

Interface Controller) 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 ED 1510 and to wake up another 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 processing signals received wirelessly or by wire. Each antenna 1504 includes any suitable structure for transmitting or receiving wireless or wired signals. One or multiple transceivers 1502 could be used in the ED 1510, and one or multiple antennas 1504 could be used in the ED 1510. Although shown as a single functional unit, a transceiver 1502 could also be implemented using at least one transceiver and at least one separate receiver, wherein the at least one transceiver and the at least one separate receiver are capable of being separately powered on or off in order to facilitating power saving in accordance with various embodiments described herein. Although shown as a single functional unit, a processing unit 1500 could 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 separately powered on or off in order to facilitating power saving in accordance with various embodiments described herein.

The ED 1510 further includes one or more input/output devices 1506 or interfaces (such as a wired interface to the Internet 1450). The input/output devices 1506 facilitate interaction with a user or other devices (network communications) in the network. 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.

In addition, the ED 1510 includes at least one memory 1508. The memory 1508 stores instructions and data used, generated, or collected by the ED 1510. For example, the memory 1508 could store software or firmware instructions executed by the processing unit(s) 1500 and data used to reduce or eliminate interference in incoming signals. Each memory 1508 includes any suitable volatile or non-volatile storage and retrieval device(s). Any suitable type of memory maybe used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and the like. Although shown as a single functional unit, a memory 1508 could 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 are capable of being separately powered on or off in order to facilitating power saving in accordance with various embodiments described herein As shown in Figure 15B, the base station 1570 includes at least one processing unit 1550, at least one transceiver 1552, which includes functionality for a transmitter and a receiver, one or more antennas 1556, at least one memory 1558, and one or more input/output devices or interfaces 1566. A scheduler, which would be understood by one skilled in the art, is coupled to the processing unit 1550. The scheduler could be included within or operated separately from the base station 1570. The processing unit 1550 implements various processing operations of the base station 1570, such as signal coding, data processing, power control, input/output processing, or any other functionality. The processing unit 1550 can also support the methods and teachings described in more detail above. Each processing unit 1550 includes any suitable processing or computing device configured to perform one or more operations. Each processing unit 1550 could, for example, include a microprocessor, microcontroller, digital signal processor, field programmable gate array, or application specific integrated circuit.

Each transceiver 1552 includes any suitable structure for generating signals for wireless or wired transmission to one or more EDs or other devices. Each transceiver 1552 further includes any suitable structure for processing signals received wirelessly or by wire from one or more EDs or other devices. Although shown combined as a transceiver 1552, a transmitter and a receiver could be separate components. Each antenna 1556 includes any suitable structure for transmitting or receiving wireless or wired signals. While a common antenna 1556 is shown here as being coupled to the transceiver 1552, one or more antennas 1556 could be coupled to the transceiver(s) 1552, allowing separate antennas 1556 to be coupled to the transmitter and the receiver if equipped as separate components. Each memory 1558 includes any suitable volatile or non-volatile storage and retrieval device(s). Each input/output device 1566 facilitates interaction with a user or other devices (network communications) 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.

Figure 16 is a block diagram of a computing system 1600 that may be used for implementing the devices and methods disclosed herein. For example, the computing system can be any entity of UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system 1600 includes a processing unit 1602. The processing unit includes a central processing unit (CPU) 1614, memory 1608, and may further include a mass storage device 1604, a video adapter 1610, and an I/O interface 1612 connected to a bus 1620.

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 comprise any type of electronic data processor. The memory 1608 may comprise 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 an embodiment, the memory 1608 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.

The mass storage 1604 may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus 1620. The mass storage 1604 may comprise, for example, one or more of a solid state drive, hard disk drive, a magnetic disk drive, or an optical disk drive.

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 illustrated, 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 maybe coupled to the processing unit 1602, and additional or fewer interface cards maybe utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) maybe used to provide an interface for an external device.

The processing unit 1602 also includes one or more network interfaces 1606, which may comprise wired channels, such as an Ethernet cable, or wireless channels to access nodes or different networks. The network interfaces 1606 allow the processing unit 1602 to communicate with remote units via the networks. For example, the network interfaces 1606 may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In an embodiment, the processing unit 1602 is coupled to a local- area network 1622 or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities.

It should be appreciated that one or more steps of the embodiment methods provided herein may be performed by corresponding units or modules. For example, a signal may be transmitted by a transmitting unit or a transmitting module. A signal may be received by a receiving unit or a receiving module. A signal may be processed by a processing unit or a processing module. Other steps maybe performed by a power control unit or module, or a waking unit or module. The respective units or modules maybe hardware, software, or a combination thereof. For instance, one or more of the units or modules may be an integrated circuit, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

Although the present disclosure 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

WHAT IS CLAIMED IS:

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

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

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

receiving, by the first device, from the second device, a response to the first transmission, 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, by the first device, a second TXOP by winning a second channel contention; and

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

2. The method of claim l, the second TXOP being on the second shared channel and the second channel contention being won on the second shared channel.

3. The method of any one of claims 1-2, the response to the first transmission indicating a failure in a reception of a third transmission occurring prior to the first transmission, the second transmission being a retransmission of the third transmission.

4. The method of claim 3, the response to the first transmission being received prior to a request for the first response is transmitted by the first device.

5. The method of any one of claims 1-2, the first transmission being a transmission control protocol (TCP) segment, the response to the first transmission being a TCP acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission.

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

7. The method of any one of claims 1-6, the first and second devices being stations operating in a peer-to-peer communications mode.

8. The method of any one of claims 1-6, the first device being an access point (AP) and the second device being a non-AP station.

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

10. A method for communicating between a first device and a second device, the first and second devices operating in a contention based communications system, the method

implemented by the second device, the method comprising:

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

obtaining, by the second device, 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, by the second device, to the first device, a response to the first transmission in accordance with the first TXOP; and

receiving, by the second device, from the first device, a second transmission in accordance with an availability of the shared channels, the second transmission being part of the sequence of transmissions.

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

12. The method of any one of claims 10-11, the response indicating a failure in a reception of a third transmission, the third transmission occurring before the first transmission, and the second transmission being a retransmission of the third transmission.

13. The method of claim 12, the response to the first transmission being transmitted before a request for the response to the first transmission is received by the second device.

14. The method of any one of claims 10-11, the first transmission being a transmission control protocol (TCP) segment, the response to the first transmission being a TCP

acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission.

15. The method of any one of claims 10-13, further comprising obtaining, by the second device, a second TXOP on the first shared channel by winning a second channel contention on the first shared channel; and transmitting, by the second device, to the first device, a response to the second transmission in accordance with the second TXOP.

16. The method of any one of claims 10-15, the first and second devices being stations operating in a peer-to-peer communications mode.

17. The method of any one of claims 10-15, the first device being an access point (AP) and the second device being a non-AP station.

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

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

a first radio frequency (RF) chain configured to send and receive data over a first shared channel;

a second RF chain configured to send and receive data over a second shared channel; a demux/mux unit operatively coupled to the first and second RF chains, the

demux/ mux unit configured to selectively route data between the first and second RF chains and a media access control (MAC) layer entity of the ML communicating device in accordance with a criteria for selecting a channel from the first and second shared channels when transmitting the data and in accordance with addresses associated with the data when receiving the data; and

an interface unit operatively coupled to the MAC layer entity and a high layer entity of the ML communicating device, the interface unit configured to receive data from the higher layer entity for transmission over the selected channel and to deliver data received from the first and second shared channels to the higher layer entity.

20. The ML communicating device of claim 19, further comprising:

a first physical (PHY) layer entity operatively coupled to the first RF chain and the demux/ mux unit, the first PHY layer entity configured to prepare data for transmission over the first RF chain and process data received over the first RF chain; and

a second PHY layer entity operatively coupled to the second RF chain and the demux/mux unit, the second PHY layer entity configured to prepare data for transmission over the second RF chain and process data received over the second RF chain.

21. The ML communicating device of any one of claims 19-20, the high layer entity being co located with the ML communicating device.

22. The ML communicating device of any one of claims 19-21, the addresses comprising MAC addresses or portions of MAC addresses.

23. The ML communicating device of any one of claims 19-22, the first shared channel being a master channel and the second shared channel being a slave channel.

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

one or more processors; and

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

obtain a first transmission opportunity (TXOP) on a first shared channel by winning a first channel contention on the first shared channel,

transmit, to a second ML communicating device, a first transmission in accordance with the first TXOP, the first transmission being part of a sequence of transmissions, receive, from the second ML communicating device, a response to the first transmission, the response being received over a second shared channel, the first shared channel and the second shared channel operating on different radio frequency carriers,

obtain a second TXOP by winning a second channel contention, and transmit, to the second ML communicating device, a second transmission in accordance with the second TXOP, the second transmission being part of the sequence of transmissions.

25. The first ML communicating device of claim 24, the second TXOP being on the second shared channel and the second channel contention being won on the second shared channel.

26. The first ML communicating device of any one of claims 24-25, the response to the first transmission indicating a failure in a reception of a third transmission occurring prior to the first transmission, the second transmission being a retransmission of the third transmission.

27. The first ML communicating device of any one of claims 24-25, the first transmission being a transmission control protocol (TCP) segment, the response to the first transmission being a TCP acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission.

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

29. The first ML communicating device of any one of claims 24-28, the first and second ML communicating devices being stations operating in a peer-to-peer communications mode.

30. The first ML communicating device of any one of claims 24-28, the first device being an access point (AP) and the second device being a non-AP station.

31. The first ML communicating device of any one of claims 24-28, the first ML

communicating device being a non-AP station and the second device being an AP.

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

one or more processors; and

receive, from the second ML communicating device, a first transmission over a first shared channel, the first transmission being part of a sequence of transmissions,

obtain 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,

transmit, to the second ML communicating device, a response to the first transmission in accordance with the first TXOP, and

receive, from the second ML communicating device, a second transmission in accordance with an availability of the shared channels, the second transmission being part of the sequence of transmissions.

33. The first ML communicating device of claim 32, the first response indicating a failure in a reception of a third transmission, the third transmission occurring before the first

transmission, and the second transmission being a retransmission of the third transmission.

34. The first ML communicating device of any one of claims 32-33, the first transmission being a transmission control protocol (TCP) segment, the response to the first transmission being a TCP acknowledgement indicating a success in a reception of the first transmission, and the second transmission being transmitted after the first transmission.

35. The first ML communicating device of any one of claims 32-33, the instructions further cause the first ML communicating device to obtain a second TXOP on the first shared channel by winning a second channel contention on the first shared channel, and transmit, to the second ML communicating device, a response to the second transmission in accordance with the second TXOP.