阅读说明：本技术 用于实时应用的立即重传方案 (Immediate retransmission scheme for real-time applications ) 是由 忻良骁 M·阿布欧埃尔首德 迫田和之 于 2020-06-10 设计创作，主要内容包括：一种无线通信电路,被配置为在其接收区域中通过无线局域网(WLAN)进行通信,以传送实时应用(RTA)分组以及非实时(非RTA)分组。响应于执行能够绕过竞争信道接入的需要和/或在信道接入之前不等待从接收者返回的通知的情况下的立即重传方案,RTA分组重传以较低的时延被执行。在其它情况下,RTA分组在不增大竞争时间窗口的情况下竞争重传接入。(A wireless communication circuit configured to communicate over a Wireless Local Area Network (WLAN) in its reception area to communicate real-time application (RTA) packets and non-real-time (non-RTA) packets. RTA packet retransmission is performed with lower latency in response to executing an immediate retransmission scheme that can bypass the need for contending for channel access and/or without waiting for a notification to return from the recipient prior to channel access. In other cases, the RTA packet contends for retransmission access without increasing the contention time window.)

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

(a) wireless communication circuitry configured to wirelessly communicate with at least one other Wireless Local Area Network (WLAN) station in its reception area;

(b) a processor coupled to the wireless communication circuitry within a station, configured to operate over a WLAN; and

(c) a non-transitory memory storing instructions executable by a processor;

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

(i) operating the wireless communication circuitry as a WLAN station configured to support communication of real-time application (RTA) packets that are sensitive to communication delay and non-real-time packets;

(ii) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets by pre-negotiation, or packet header information, or a combination of pre-negotiation and packet header information;

(iii) performing retransmission of non-real-time application (non-RTA) packets using carrier sense multiple access/collision avoidance (CSMA/CA); and

(iv) retransmission of at least a portion of a real-time application (RTA) packet is performed in response to bypassing contention for channel access and/or without waiting for a notification to return from a recipient prior to channel access.

2. The apparatus of claim 1, wherein the instructions, when executed by a processor, perform one or more steps comprising: a notification is received from the recipient of a packet success or packet error.

3. The apparatus of claim 2, wherein the instructions, when executed by the processor, perform the bypassing contention channel access in response to retransmitting real-time application (RTA) packets without contending for channel access immediately upon receiving notification of the RTA packets from a recipient.

4. The apparatus of claim 2:

wherein the station operates as an Access Point (AP) on the network; and

wherein the instructions, when executed by a processor, perform one or more steps comprising: a subset of the subcarriers is assigned to a plurality of individual users.

5. The apparatus of claim 4, wherein the instructions, when executed by a processor, perform the assigning the subset of subcarriers by utilizing Orthogonal Frequency Division Multiple Access (OFDMA).

6. The apparatus of claim 5, wherein the instructions, when executed by the processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) and embed retransmission scheduling information in the notification.

7. The apparatus of claim 4, wherein the instructions, when executed by the processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) utilizing separate resource blocks assigned by the AP.

8. The apparatus of claim 1, wherein the instructions, when executed by a processor, perform one or more steps comprising: when a real-time application (RTA) packet lifetime expires, retransmission of the packet is terminated.

9. The apparatus of claim 1, wherein the notification comprises an Acknowledgement (ACK) indicating that the packet was received correctly and a Negative Acknowledgement (NACK) indicating that the packet was received in error.

10. The apparatus of claim 1, wherein the instructions, when executed by a processor, perform one or more steps comprising: real-time application (RTA) packets are transmitted multiple times without waiting for a notification to be returned from the recipient.

11. The apparatus of claim 1, wherein the instructions, when executed by a processor, perform one or more steps comprising: scheduling retransmission of real-time application (RTA) packets after initial transmission of the RTA packets.

12. The apparatus of claim 1, wherein the instructions, when executed by the processor, perform steps further comprising: real-time application (RTA) packets are retransmitted using a lower bit rate Modulation and Coding Scheme (MCS) than at the initial transmission.

13. The apparatus of claim 1, wherein the instructions, when executed by the processor, perform steps further comprising: retransmission of a second portion of a real-time application (RTA) packet is performed in response to performing collision avoidance without increasing a contention time window length.

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

(a) wireless communication circuitry configured to wirelessly communicate with at least one other Wireless Local Area Network (WLAN) station in its reception area;

(b) a processor coupled to the wireless communication circuitry within a station, configured to operate over a WLAN; and

(c) a non-transitory memory storing instructions executable by a processor;

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

(i) operating the wireless communication circuitry as a WLAN station configured to support communication of real-time application (RTA) packets that are sensitive to communication delay and non-real-time packets;

(ii) transmitting the packet to the receiver and receiving a notification from the receiver of packet success or packet error;

(iii) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets by pre-negotiation, or packet header information, or a combination of pre-negotiation and packet header information;

(iv) performing retransmission of non-real-time application (non-RTA) packets using carrier sense multiple access/collision avoidance (CSMA/CA);

(v) performing a retransmission of at least a portion of a real-time application (RTA) packet in response to bypassing contention for channel access and/or without waiting for a notification to return from a recipient prior to channel access; and

(vi) when a real-time application (RTA) packet lifetime expires, retransmission of the packet is terminated.

15. The apparatus of claim 14, wherein the instructions, when executed by the processor, perform the bypassing contention channel access in response to retransmitting real-time application (RTA) packets immediately without contention after receiving notification of a real-time application (RTA) packet error from a recipient.

16. The apparatus of claim 15:

wherein the station operates as an Access Point (AP) on the network; and

wherein the instructions, when executed by a processor, perform one or more steps comprising: a subset of the subcarriers is assigned to a plurality of individual users.

17. The apparatus of claim 16, wherein the instructions, when executed by a processor, perform the assigning the subset of subcarriers by utilizing Orthogonal Frequency Division Multiple Access (OFDMA).

18. The apparatus of claim 17, wherein the instructions, when executed by a processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) and embed retransmission scheduling information in the notification.

19. The apparatus of claim 16, wherein the instructions, when executed by the processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) utilizing separate resource blocks assigned by the AP.

20. The apparatus of claim 14, wherein the notification comprises an Acknowledgement (ACK) indicating that the packet was received correctly and a Negative Acknowledgement (NACK) indicating that the packet was received in error.

21. The apparatus of claim 14, wherein the instructions, when executed by a processor, perform one or more steps comprising: real-time application (RTA) packets are transmitted multiple times without waiting for a notification to be returned from the recipient.

22. The apparatus of claim 14, wherein the instructions, when executed by a processor, perform one or more steps comprising: scheduling retransmission of real-time application (RTA) packets after initial transmission of the RTA packets.

23. The apparatus of claim 14, wherein the instructions when executed by the processor perform steps further comprising: real-time application (RTA) packets are retransmitted using a lower bit rate Modulation and Coding Scheme (MCS) than at the initial transmission.

24. The apparatus of claim 14, wherein the instructions when executed by the processor perform steps further comprising: retransmission of a second portion of a real-time application (RTA) packet is performed in response to performing collision avoidance without increasing a contention time window length.

25. A method of performing wireless communication, comprising:

(a) operating the wireless communication circuitry as a WLAN station configured to support communication of real-time application (RTA) packets that are sensitive to communication delay and non-real-time packets;

(b) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets by pre-negotiation, or packet header information, or a combination of pre-negotiation and packet header information;

(c) performing retransmission of non-real-time application (non-RTA) packets using carrier sense multiple access/collision avoidance (CSMA/CA); and

(d) retransmission of at least a portion of a real-time application (RTA) packet is performed in response to bypassing contention for channel access and/or without waiting for a notification to return from a recipient prior to channel access.

Technical Field

The technology of the present disclosure relates generally to wireless communication stations, and more particularly to Wireless Local Area Network (WLAN) stations that communicate a combination of real-time and non-real-time traffic.

Background

Current wireless technologies that use carrier sense multiple access/collision avoidance (CSMA/CA) focus on high overall network throughput, but they lack the low latency capability to properly support real-time applications (RTA).

RTA requires low latency communication and uses best effort communication. Data generated from an RTA is referred to as RTA traffic and is packaged as an RTA packet at a transmitter Station (STA), while data generated from a non-time sensitive application is referred to as non-RTA traffic and is packaged as a non-RTA packet at the transmitter STA.

RTA packets require low latency due to high timeliness requirements (real-time) for packet delivery. An RTA packet is valid only if it can be delivered within a certain period of time.

Due to the random channel access scenario, STAs need to sense and contend for channel access before transmitting each packet. Obtaining short channel contention times, while speeding up channel access, increases the probability of packet collisions. The delay inherent in packet collisions is still large due to the channel contention time required for each retransmission. To avoid packet collisions and improve packet delivery success rates, STAs retransmit packets after a longer channel contention period following packet collisions, which further delays the packets.

Thus, there is a need for enhanced handling of real-time application (RTA) packets. The present disclosure satisfies this need and provides additional benefits over the prior art.

Disclosure of Invention

An enhanced WLAN communication apparatus/method for eliminating channel contention delay for each retransmission of a real-time application (RTA) packet. In an immediate retransmission scheme, a Station (STA) node retransmits an RTA packet with minimal channel contention time to reduce the delay of the packet.

The task of applying an immediate retransmission scheme for RTA packets in CSMA/CA systems is more challenging due to the coexistence of RTA traffic and non-RTA traffic. The challenges in this process can be summarized as: (a) identifying an RTA packet from the non-RTA packets; (b) obtaining channel access of the RTA packet with minimum contention; and (c) transmitting the RTA packet before its lifetime expires (initial transmission and any required retransmissions).

The disclosed immediate retransmission scheme for RTA packets takes into account the time-efficient elements of RTA traffic and minimizes packet latency in wireless networks where RTA and non-RTA traffic coexist. The prior art cannot perform retransmissions that meet the timeliness requirements of many RTA packets.

Other aspects of the technology described herein will be set forth in the following portions of the specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon.

Drawings

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

fig. 1 is a flowchart of retransmission under CSMA/CA.

Fig. 2 is a data field diagram of a WLAN data frame.

Fig. 3 is a diagram of data fields of a WLAN ACK frame.

Fig. 4 is a data field diagram of a HE-SU PPDU frame.

Fig. 5 is a communication sequence diagram for retransmission in CSMA/CA using a double-sized contention window.

Fig. 6 is a communication sequence diagram for retransmission in CSMA/CA, in which packets are discarded in response to a retry limit.

Fig. 7 is a data field diagram of a HE-MU PPDU frame.

Fig. 8 is a data field diagram of a HE-TB PPDU frame.

Fig. 9 is a diagram of data fields of a trigger frame.

Fig. 10 is a data field diagram of a common information field of a trigger frame.

Fig. 11 is a data field diagram of a user information field of a trigger frame.

Fig. 12 is a data field diagram of a trigger related user information field of the MU-BAR.

Fig. 13 is a diagram of the data fields of a block ack (ba) frame.

Fig. 14 is a communication sequence diagram of retransmission in CSMA/CA in downlink of an OFDMA system.

Fig. 15 is a communication sequence diagram of retransmission in CSMA/CA in uplink of an OFDMA system.

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

Fig. 17 is a network topology diagram illustrating an example of a topology addressed in accordance with at least one embodiment of the present disclosure.

Fig. 18 is a layered communication diagram of RTA and non-RTA traffic communications in the Open Systems Interconnection (OSI) model in accordance with at least one embodiment of the present disclosure.

Fig. 19 is a layered communication diagram illustrating pre-negotiation for RTA traffic communication in accordance with at least one embodiment of the present disclosure.

Fig. 20 is a flow diagram of identifying RTA packets at the transmitter side in accordance with at least one embodiment of the present disclosure.

Fig. 21 is a data field diagram of fields within an RTA session identification in accordance with at least one embodiment of the present disclosure.

Fig. 22 is a layered communication diagram illustrating the exchange of header information between the APP layer and the MAC layer in accordance with at least one embodiment of the present disclosure.

Fig. 23 is a flow diagram of identifying RTA packets at a recipient side in accordance with at least one embodiment of the present disclosure.

Fig. 24 is a communication sequence diagram illustrating dropping of an RTA packet in response to the occurrence of a packet lifetime expiration in accordance with at least one embodiment of the present disclosure.

Fig. 25 is a data field diagram of an RTA control field in accordance with at least one embodiment of the present disclosure.

Fig. 26 is a data field diagram of an HE-SU-RTA packet format in accordance with at least one embodiment of the present disclosure.

Fig. 27 is a data field diagram of an RTA-ACK/NACK packet format for notification in Single User (SU) mode according to at least one embodiment of the present disclosure.

Fig. 28 is a data field diagram of an HE-MU-RTA packet format in accordance with at least one embodiment of the present disclosure.

Fig. 29 is a data field diagram of a field within an RTA announcement trigger frame according to at least one embodiment of the present disclosure.

Fig. 30 is a data field diagram of an "RTA retransmission schedule" field in accordance with at least one embodiment of the present disclosure.

Fig. 31 is a data field diagram of an RTA-BA packet format in accordance with at least one embodiment of the present disclosure.

Fig. 32A and 32B are flow diagrams for transmitting RTA and non-RTA packets in single user mode according to at least one embodiment of the present disclosure.

Fig. 33 is a flow diagram of RTA packet retransmission in Single User (SU) mode in accordance with at least one embodiment of the present disclosure.

Fig. 34A and 34B are flow diagrams for receiving RTA and non-RTA packets in Single User (SU) mode according to at least one embodiment of the present disclosure.

Fig. 35 is a communication sequence diagram illustrating RTA packet retransmission without contention after initial transmission in accordance with at least one embodiment of the present disclosure.

Fig. 36 is a communication sequence diagram illustrating RTA packet retransmission without contention after initial transmission failure in accordance with at least one embodiment of the present disclosure.

Fig. 37 is a communication sequence diagram illustrating RTA packet retransmission without increasing contention window in accordance with at least one embodiment of the present disclosure.

Fig. 38 is a communication sequence diagram for hybrid retransmission in Single User (SU) mode according to at least one embodiment of the present disclosure.

Fig. 39A and 39B are flow diagrams for transmitting RTA and non-RTA packets in a multi-user (MU) downlink mode according to at least one embodiment of the present disclosure.

Fig. 40A and 40B are flow diagrams for receiving RTA and non-RTA packets in a multi-user (MU) downlink mode according to at least one embodiment of the present disclosure.

Fig. 41 is a communication sequence diagram of RTA packet retransmission in multi-user (MU) downlink OFDMA in accordance with at least one embodiment of the present disclosure.

Fig. 42 is a communication sequence diagram for multi-user (MU) downlink OFDMA MU-BAR failure in accordance with at least one embodiment of the present disclosure.

Fig. 43 is a communication sequence diagram without immediate retransmission of non-RTA packets in multi-user (MU) downlink OFDMA in accordance with at least one embodiment of the present disclosure.

Fig. 44A and 44B are flow diagrams of transmitting RTA and non-RTA packets in a multi-user (MU) uplink mode according to at least one embodiment of the present disclosure.

Fig. 45A and 45B are flow diagrams for receiving RTA and non-RTA packets in a multi-user (MU) uplink mode according to at least one embodiment of the present disclosure.

Fig. 46 is a communication sequence diagram for immediate retransmission of RTA packets in multi-user (MU) uplink OFDMA in accordance with at least one embodiment of the present disclosure.

Fig. 47 is a communication sequence diagram illustrating RTA-TF and RTF-BA failures in multi-user (MU) uplink OFDMA in accordance with at least one embodiment of the present disclosure.

Fig. 48 is a communication sequence diagram for non-RTA packet retransmission in multi-user (MU) uplink OFDMA in accordance with at least one embodiment of the present disclosure.

Detailed Description

Retransmission scheme in CSMA/CA systems

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

Fig. 1 illustrates an example of a CSMA/CA retransmission scheme. In CSMA/CA systems, this process is performed before each transmission and retransmission, where STAs must sense the channel and set a back-off time to contend for channel access. The back-off time is determined by a uniform random variable between zero and the size of the Contention Window (CW). After the STA waits for the back-off time and senses that the channel is idle, it transmits a packet. If the STA does not receive an ACK before the timeout, retransmission of the packet is required. Otherwise, the transmission is deemed successful.

When retransmission is required, the STA checks the number of retransmissions of the packet and if the number of retransmissions exceeds a retry limit, discards the packet and does not schedule retransmission. Otherwise, one or more retransmissions are scheduled. If a retransmission is scheduled, another back-off time is needed to contend for channel access for this retransmission. If the size of the contention window does not reach the upper limit (CW limit) of the contention window, the STA increases the CW and performs a return to the top, so the STA sets another back-off time according to the new size of the Contention Window (CW). The STA waits for a back-off time for retransmission, etc.

Fig. 2 illustrates a data frame format in a conventional WLAN system. The "frame control" field indicates the type of frame. The "duration" field contains Network Allocation Vector (NAV) information for CSMA/CA channel access. The "Receiver Address (RA)" field contains the address of the receiver of the frame. The "Transmitter Address (TA)" field contains the address of the STA that transmitted the frame. The "sequence control" field contains the fragment number and sequence number of the packet.

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

FIG. 4 illustrates the HE Single User (SU) PPDU format in IEEE 802.11ax for single user transmission in IEEE 802.11 ax. It is noted that PPDU stands for physical layer convergence procedure protocol data unit. The PPDU frame contains the PSDU plus the PHY header and preamble. The HE-SU PPDU frame contains the following fields: (a) L-STF: a non-HT short training field; (b) L-LTF: a non-HT long training field; (c) L-SIG: a non-HT SIGNAL field; (d) RL-SIG: a repeated non-HT SIGNAL field; (e) HE-SIG-A: HE SIGNAL A fields; (f) HE-STF: HE short training field; (g) HE-LTF: HE long training field; (h) data: a data field carrying a PSDU; (i) PE: a packet extension field.

Fig. 5 illustrates a scenario in which retransmission is performed using a double-sized contention window in CSMA/CA, in which the back-off time increases due to retransmission. The data frame and the ACK frame use the formats as shown in fig. 2 and 3, respectively. The frames are packed using a packet format as shown in fig. 4. After the initial transmission of the transmitter transmission packet, it does not receive an ACK before a timeout. Then it sets another back-off time, whereby the size of the contention window is n slots. After waiting for the back-off time, the transmitter STA retransmits the packet for the first time. However, this retransmission also fails in this example. The transmitter STA needs to retransmit the packet and set a back-off time to contend for channel access again. This time, the size of the contention window is doubled due to retransmissions, i.e. 2 x n slots. The expected back-off time is also doubled due to the contention window size. The second retransmission is successful because it received an ACK before timing out.

Fig. 6 illustrates a scenario in which a packet is dropped due to a retry limit in CSMA/CA, this example showing that the packet is dropped after the number of retransmissions exceeds the retry limit. Let us denote the retry limit by R. The data frame and the ACK frame use the formats as shown in fig. 2 and 3, respectively. The frames are packed using the packet format as shown in fig. 4. As shown in fig. 6, after an initial transmission of a packet fails, a transmitter STA retransmits that packet multiple times. However, no one retransmission is successful. After R retransmissions (including the initial transmission), the number of retransmissions exceeds the retry limit. The transmitter STA stops retransmitting that packet and that packet is discarded.

1.2. Multi-user transmission

Multi-user transmissions are available in wireless networks, such as IEEE 802.11. Starting with IEEE 802.11ax, networks support multi-user transmission in both uplink and downlink modes. The multi-user transmission in IEEE 802.11ax includes a MIMO mode and an OFDMA mode, which may be used alone or together.

IEEE 802.11ax uses a multi-user transmission packet format, such as shown in fig. 1 and 2, to transmit data in a multi-user mode. When multiple users transmit or receive a multi-user transmission packet, all users share the same Physical Layer Convergence Protocol (PLCP) header of the multi-user transmission packet. Each user then uses a separate resource block (including Resource Unit (RU) allocation, MCS, etc.) to transmit or receive the data carried by the multi-user transmission packet.

IEEE 802.11ax defines a number of PLCP Protocol Data Unit (PPDU) formats for transmitting packets in different multi-user transmission scenarios, as listed below.

Fig. 7 illustrates the HE multi-user (MU) PPDU format in IEEE 802.11ax for downlink multi-user transmission. In contrast to the single-user PPDU format shown in fig. 4, this adds an HE-SIG-B field in its format, which provides separate resource block allocation information for each user.

Fig. 8 illustrates a HE Trigger (TB) based PPDU format for uplink multi-user transmission. The fields in the HE TB PPDU format are the same as those in the HE single-user PPDU format except that the HE-STF field is 8 μ s.

Fig. 9 illustrates the contents of the trigger frame format in IEEE 802.11 ax. The "frame control" field indicates the type of frame. The "duration" field contains NAV information for CSMA/CA channel access. The "RA" field contains the address of the recipient of the frame. The "TA" field contains the address of the STA transmitting the frame.

Fig. 10 illustrates a "common information" field, which includes information of all allocated STAs.

Fig. 11 illustrates a "user information" field, which includes information of each STA.

The "common information" field and the "user information" field provide each user with separate resource block allocation information.

Fig. 12 illustrates a "trigger-related user information" field in a trigger frame of a multi-user (MU) Block ACK Request (BAR). The trigger frame shown in fig. 9 may be transmitted as a multi-user block ACK request (MU-BAR) by setting the trigger type in the "common information" field to "2". When the trigger frame is an MU-BAR, the contents of the "trigger related user information" field (as shown in fig. 11) in the trigger frame are as shown in fig. 12.

Fig. 13 illustrates the contents of a block ack (ba) frame format in a conventional WLAN system. The "frame control" field indicates the type of frame. The "duration" field contains NAV information for CSMA/CA channel access. The "RA" field contains the address of the recipient of the frame. The "TA" field contains the address of the STA transmitting the frame. The "BA control" field indicates a policy of block ACK. The "BA info" field contains the transmitted feedback.

Fig. 14 illustrates a CSMA/CA retransmission scheme in the downlink of an OFDMA system as an example of downlink multi-user transmission using OFDMA. The transmitter AP transmits data to its receivers 1, 2, 3 and 4 using the HE MU PPDU format. After completing the initial transmission, the AP transmits a multi-user block acknowledgement request (MU-BAR) to all recipients. The receiver then sends a block ack (ba) back to the AP. The AP decides whether to retransmit the packet to the receivers 1, 3, 4 based on the content in the BA. It contends for the channel and waits for the back-off time. The first retransmission occurs after the AP gains channel access.

Fig. 15 illustrates a CSMA/CA retransmission scheme in the uplink of an OFDMA system, showing an example of uplink multi-user transmission using OFDMA. The AP first transmits a trigger frame to all transmitters 1, 2, 3 and 4. The transmitter receives the trigger frame and starts initial transmission using the resource blocks allocated by the trigger frame. The multi-user transmission packet uses the HE-TB PPDU format. The AP receives the packet from the transmitter and sends a BA frame to report the correctness of the transmission. Here, only packets carrying data from transmitter 2 are received correctly. Retransmissions need to be scheduled for transmitters 1, 3 and 4. The AP contends for the channel and waits for a back-off time to gain channel access. The retransmission then proceeds in the same manner as the initial transmission.

2. Question statement

Current wireless communication systems using CSMA/CA do not recognize whether a packet is an RTA packet or a non-RTA packet, and handle all packets with the same retransmission scheme under CSMA/CA. The retransmission scheme in CSMA/CA aims at reducing the probability of packet collisions, while the latency of packets is not a major concern. As shown in the section discussing the existing IEEE 802.11 protocol, each retransmission requires STAs to contend for the channel over an extended contention window, which can significantly increase the delay of packet transmission.

The retransmission scheme in CSMA/CA does not take into account the timeliness of the packets. As shown in existing systems, the sender STA retransmits the packet until it is received by the receiver STA or until the retransmission exceeds a retry limit. However, an RTA packet has a lifetime within which it must be transmitted. That is, the RTA packet must be transmitted or retransmitted within a certain time.

The retransmission scheme of CSMA/CA is more complicated in multi-user transmission. The RTA traffic and the non-RTA traffic may be integrated in the same multi-user transmission packet. When a multi-user transmission packet contains both RTA traffic and non-RTA traffic, the retransmission of that packet may or may not contain RTA traffic, which has an impact on retransmission scheduling. Retransmission schemes using multi-user transmission (such as OFDMA) provide greater resource allocation flexibility in packet retransmissions.

3. Summary of the contributions of the disclosure

By utilizing the disclosed techniques, a STA is able to identify RTA packets and non-RTA packets. The disclosed techniques allow for timeliness of RTA traffic because RTA packets have a given lifecycle to transmit. The STA schedules retransmission of the RTA packet according to the life cycle of the RTA packet.

The disclosed techniques separate the retransmission scheme for RTA packets from non-RTA packets and use the conventional retransmission scheme defined in CSMA/CA for non-RTA packets.

The disclosed techniques define an immediate retransmission scheme for RTA traffic to minimize channel contention time. In some use cases, the channel contention time is completely eliminated. By using this scheme, the delay of the RTA packet is reduced.

The disclosed techniques are compatible with OFDMA systems. By operating Resource Unit (RU) allocation with other adaptive machines, such as rate control, the transmission gains more diversity effect to increase the packet delivery rate.

4. Example embodiments

STA hardware configuration

Fig. 16 illustrates an example embodiment 10 of a STA hardware configuration showing an I/O path 12 into a hardware block 13, with a Computer Processor (CPU)16 and memory (RAM)18 coupled to a bus 14, the bus 14 being coupled to the I/O path 12 giving STA external I/O, such as to sensors, actuators, etc. Instructions from the memory 18 are executed on the processor 16 to execute a program implementing a communication protocol that is executed to allow the STA to perform the functions of a "new STA" or one of the STAs already in the network. It should also be appreciated that programming is configured to operate in different modes (source, intermediate, destination, Access Point (AP), etc.) depending on its role in the current communication context.

The STA may be configured with a single modem and single Radio Frequency (RF) circuitry, or it may be configured with multiple modems and multiple RF circuits, as depicted by way of example and not limitation in fig. 16.

In this example, the host machine is shown configured with a millimeter wave (mmW) modem 20, the mmW modem 20 coupled to Radio Frequency (RF) circuitry 22a, 22b, 22c to couple to multiple antennas 24a-24n, 26a-26n, 28a-28n to transmit and receive frames with neighboring STAs. In addition, it can also be seen that the host machine has a modem 30 below 6GHz that is coupled to Radio Frequency (RF) circuitry 32 that is coupled to antenna(s) 34.

Thus, this host machine is shown configured with two modems (multiband) and their associated RF circuitry for providing communication over two different frequency bands. By way of example and not limitation, the intended directional communication band is implemented with a mmW band modem and its associated RF circuitry for transmitting and receiving data in the mmW band. Another frequency band, commonly referred to as the discovery band, includes sub-6 GHz modems and their associated RF circuitry for transmitting and receiving data in the sub-6 GHz frequency band.

Although three RF circuits are shown for the mmW band in this example, embodiments of the present disclosure may be configured with a modem 20 coupled to any number of RF circuits. In general, the use of a large number of RF circuits will result in a wider coverage of the antenna beam direction. It should be appreciated that the number of RF circuits and the number of antennas utilized is determined by the hardware constraints of the particular device. Some of the RF circuitry and antennas may be disabled when the STA determines that communication with a neighboring STA is not necessary. In at least one embodiment, the RF circuitry includes a frequency converter, array antenna controller, etc., and is connected to a plurality of antennas that are controlled to perform beamforming for transmission and reception. In this manner, a STA may transmit signals using multiple sets of beam patterns, each beam pattern direction being considered an antenna sector.

It can thus be seen that the host machine houses a modem that transmits/receives data frames with neighboring STAs. The modem is connected to at least one RF module to generate and receive physical signals. The RF module(s) include a frequency converter, an array antenna controller, and other necessary circuitry. The RF module(s) are connected to a plurality of antennas that are controlled to perform beamforming for transmission and reception. In this manner, the STA may transmit signals using multiple sets of beam patterns.

4.2. Example STA topology for consideration

Fig. 17 illustrates an example network topology (scenario) 50 as an aid to the goal of explaining the disclosed technology. By way of example and not limitation, this example assumes that there are 8 STAs in the conference room that consist of two Basic Service Sets (BSSs). Each STA may communicate with other STAs in the same BSS. All STAs use CSMA/CA for random channel access. The first BSS depicts STA 052 and non-AP stations STA 154, STA 256, STA 358, and STA 460 operating as an Access Point (AP). The second BSS, together with STA 664, STA 766, depicts STA 562 as an AP.

All STAs in this example are considered to support (run) applications that require low latency communication and applications that utilize best effort communication. Data generated from applications requiring low latency communication is referred to as Real Time Application (RTA) traffic and will be packetized into RTA packets at the transmitter STA. Also, data generated from non-time sensitive applications is referred to as non-RTA traffic and is packaged as non-RTA packets at the transmitter STA. Thus, the transmitter STA generates both RTA traffic and non-RTA traffic for communication. The location of the STAs and their transmission links are as shown in this example network topology.

When a STA transmits a non-RTA packet, the STA may follow the conventional CSMA/CA scheme. When an STA transmits an RTA packet and that packet collides, the STA schedules packet retransmission with minimal channel contention. One goal of the disclosed techniques is to reduce latency of RTA traffic.

STA layer model

Fig. 18 illustrates an example embodiment 70 of RTA and non-RTA traffic communications in the OSI model. In this section, a STA layer model for traffic communication is explained. As shown in this example, two STAs, STA 172 and STA 274, generate RTA and non-RTA traffic 80, 82 and communicate with each other with RTA packets 84 and non-RTA packets 86. The whole process is explained below.

Both RTA traffic and non-RTA traffic are generated by the APP layers 76a, 78a of the transmitter STAs. The APP layer of the transmitter STA passes RTA traffic and non-RTA traffic to the MAC layers 76c, 78c via (through) the intermediate layers 76b, 78 b. The MAC layers 76c, 78c and PHY layers 76d, 78d append additional signal fields in the MAC header and PLCP header to the packet, and the packet is transmitted through the PHY layers of the network.

The receiver STA receives packets at the PHY layer, decodes and sends them to its MAC layer if the packets are decoded correctly, after which the data is fed to its APP layer through (via) intermediate layers.

4.4. Mechanism for identifying RTA and non-RTA packets

The disclosed techniques classify packets in a wireless communication system as either RTA or non-RTA. The RTA packet is retransmitted for the packet using an immediate retransmission scheme, and the non-RTA packet may use a conventional CSMA/CA scheme. To this end, the STA recognizes an RTA packet and a non-RTA packet at the MAC layer. This process is described in this section.

According to the STA layer model shown in fig. 18, it is possible for the MAC layer of the transmitter STA to recognize RTA traffic and non-RTA traffic from an upper layer and packetize them into an RTA packet and a non-RTA packet, respectively. This section provides details of how the transmitter STA identifies RTA traffic using pre-negotiation.

According to the STA layer model shown in fig. 18, a transmitter STA transmits a packet to a receiver STA through a PHY layer of a network. When the receiver STA receives a packet at the MAC layer, it can identify an RTA packet and a non-RTA packet based on information embedded in the MAC header or PLCP header. This section provides details on how the recipient STA identifies the RTA packet based on PLCP or MAC header information.

RTA traffic must be transmitted within a given lifecycle to ensure the validity of the data. In other words, if the recipient does not receive RTA traffic before this lifecycle expires, the RTA traffic is invalid and may be discarded. The STA packetizes the RTA traffic into RTA packets for transmission over the PHY layer. Thus, the RTA packet also has a life cycle for transmission. This section provides details on how STAs should deal with the expiration of the RTA packet lifecycle.

4.4.1. Pre-negotiation

RTA often generates traffic periodically, as well as image-to-connection communication. The communication established by an application between STAs towards an RTA connection is called an RTA session. It is possible that a STA may have multiple RTA sessions in the network. Each STA according to the present disclosure is able to properly manage those RTA sessions.

Prior to the RTA session beginning to transmit RTA traffic, a pre-negotiation occurs between the transmitter STA and the receiver STA to establish a connection. During the pre-negotiation, the transmitter STA and the receiver STA record an RTA session, which identifies information that can be used to identify RTA traffic at the MAC layer of the transmitter side and RTA packets at the MAC layer of the receiver side.

As shown in fig. 18, when the APP layer passes traffic to the MAC layer on the transmitter side, the middle layer adds header information to the traffic. When the MAC layer of the transmitter STA receives traffic from the upper layer, it extracts header information from the upper layer and looks up (searches) an RTA session record created by pre-negotiation. If the header information matches one of the RTA sessions in the record, then the traffic is RTA; otherwise, the traffic is treated as non-RTA. Header information that may be used to identify RTA traffic is listed in table 1. In this section, details of the pre-negotiation are described.

It is also possible for the receiver STA to classify RTA packets and non-RTA packets by channel resources (such as time, frequency, and other metrics) used for packet transmission based on the pre-negotiation results. When a packet is received using the channel resources granted for the RTA packet, the STA then identifies it as an RTA packet. Otherwise, that packet is a non-RTA packet. This scenario will be used when packets are transmitted in multi-user uplink mode, as described in section 4.6.2.2.

Fig. 19 illustrates an example embodiment 90 of pre-negotiation of RTA traffic packets at the transmitter side 100 and the receiver side 102. It should be appreciated that one pre-negotiation establishes one RTA session and may be used for all RTA packets generated by that RTA session. The figure illustrates a pre-negotiation to establish an RTA session between two STAs in the STA layer model as seen in figure 18. The transmitter STA 92 is shown with a layer APP 96a, an intermediate layer 96b, a MAC layer 96c, and a PHY layer 96d, and the receiver STA 94 with the same layer APP 98a, intermediate layer 98b, MAC layer 98c, and PHY layer 98 d. The process of pre-negotiation is explained below.

Referring to fig. 19, the following steps are seen. The APP layer 96a of the transmitter 92 requests 104 resource (e.g., time, channel) negotiation. Thus, on the transmitter STA side, the APP layer starts an RTA session and requests negotiation of channel resources (such as time and bandwidth) for its RTA traffic transmission. This negotiation request is transmitted from a management entity in the APP layer to a management entity residing in the MAC layer.

The MAC layer of the transmitter STA receives the negotiation request from the upper layer and checks 106 the resource availability at its side. Also, it records RTA session identification information provided by an upper layer for identifying RTA traffic in the session. The record of identification information may be selected from the information listed in table 1, such as TCP/UDP port number, type of service, etc. If the resource is not available, it may reject the request from the upper layer or renegotiate with the upper layer.

If the MAC layer discovery resources of the transmitter STA are available, it sends 108 a negotiation request frame to the MAC layer of the receiver STA. The negotiation frame contains identification information of the RTA session so that the recipient can record and use it later. The negotiation frame is similar to the packet format shown in section 4.5.2.

After the MAC layer of the receiver STA receives the negotiation request frame, it first informs 110 its APP layer that it is ready to receive RTA packets by sending a negotiation request from the management entity in the MAC layer to the management entity in the APP layer. If the APP layer is not available for RTA transmission, the negotiation will fail.

The recipient's APP layer grants availability of resources at its layer and sends 112 this information from the management entity in the APP layer to the management entity residing in the MAC layer.

The MAC layer of the receiver STA then checks 114 on its side the resource availability. If resources are not available, the MAC layer may reject or renegotiate. The MAC layer of the receiver STA collects all negotiation information on its side and reports 116 it to the MAC layer of the transmitter.

The MAC layer of the transmitter receives the negotiation result and forwards 118 it to its APP layer. If the negotiation is successful, the APP layer may begin transmitting RTA traffic using the resources granted by both STAs.

The MAC layer of the transmitter STA recognizes RTA traffic and non-RTA traffic by header information from an upper layer according to an RTA session record created by pre-negotiation. When the APP layer generates RTA traffic, the RTA traffic is passed to its MAC layer along with header information provided by the intermediate layers. By looking up the RTA session record created by the pre-negotiation, the transmitter STA can use that header information to identify and package the RTA traffic into RTA packets at the MAC layer.

Fig. 20 illustrates an example embodiment 130 of identifying RTA packet traffic at the transmitter side. The routine starts 132 and the MAC layer of the transmitter STA receives traffic 134 from the upper layers. The MAC layer extracts 136 information for identifying RTA traffic embedded by the upper layer and checks header information of the upper layer (such as the type of service and TCP/UDP port number).

The MAC layer of the transmitter STA compares 138 the header information from the upper layers with the RTA session record created by the pre-negotiation. The header information is checked 140. If the header information from the upper layer matches one of the RTA sessions in the record, block 144 is reached where the traffic is determined to be RTA traffic, otherwise block 142 is reached where the traffic is determined to be non-RTA traffic. The process then ends 146.

4.4.2. Packet header information

Fig. 21 illustrates an example embodiment 150 of an RTA session identification information format. When the transmitter STA generates an RTA packet, it adds an "additional signal" field in the PLCP or MAC header. When the "additional signal" field contains RTA session identification information, the receiver STA can use the RTA session identification information in the PLCP or MAC header to distinguish RTA packets from non-RTA packets at the MAC layer. One example of RTA session identification information is shown.

Fig. 22 illustrates an example embodiment 170 of a header information exchange 180, 182 between the APP and MAC layers. The transmitter STA 172 is considered to have an APP layer 176a, an intermediate layer 176b, a MAC layer 176c, and a PHY layer 176 d. The receiver STA 174 is seen to have the same layers, APP layer 178a, intermediate layer 178b, MAC layer 178c, and PHY layer 178 d.

The figure depicts details of how this process works between two STAs in the STA layer model. The APP layer of the transmitter STA generates 184RTA traffic and passes it to the MAC layer. Header information (such as a "type of service" field and a TCP/UDP port number) is added to the traffic as it is passed through the intermediate layers.

When the MAC layer of the transmitter STA receives RTA traffic from an upper layer, it extracts header information (such as the type of service and TCP/UDP port number) from the traffic. The MAC layer identifies 186 that the traffic is an RTA by looking up RTA session records created by prior art techniques.

Then, the MAC layer of the transmitter STA packages the traffic into an RTA packet 180 and embeds the type of service and the TCP/UDP port number in the MAC header or the PLCP header as RTA session identification information. One example of RTA session identification information is shown in fig. 21. Next, the transmitter STA sends 188 the RTA packet to the receiver STA that receives the packet 182.

When the recipient STA receives the RTA packet at its MAC layer, it may identify 189 the RTA packet based on the RTA session identification information in the PLCP or MAC header.

Fig. 23 illustrates an example embodiment 190 of a process of identifying an RTA packet at the MAC layer at the receiver side. The process begins 192 and the receiver receives the packet at the PHY layer 194. As explained in fig. 22, the MAC header or PLCP header of the RTA packet includes identification information of the RTA session. Referring again to FIG. 23, a check 196 is made to determine if the identifying information is present. If the identification information is present, then execution moves to block 200 because the recipient STA has determined that the packet is an RTA packet. Otherwise, if the information does not exist, then execution moves from block 196 to block 198 because the packet has been determined to be a non-RTA packet. The process then ends 202.

4.4.3.RTA packet lifecycle expiration

Initially, as shown in fig. 6, when the number of retransmissions of a packet exceeds a retry limit, the packet stops being retransmitted. The packet is then discarded. In contrast, the transmission lifetime of an RTA packet is limited. When the life cycle of an RTA packet expires, the retransmission of that RTA packet stops and the packet is discarded.

RTA traffic has a life cycle that represents the time during which information of a packet (traffic) is considered valid. The life cycle of an RTA packet is used to ensure that the RTA traffic carried by the packet is valid when the receiver STA receives the packet. Thus, the life cycle of the RTA packet should not be longer than the life cycle of the RTA traffic. In the simplest case, the two life cycles may be set to the same value.

Fig. 24 illustrates an example embodiment 210 of dropping an RTA packet due to expiration of a packet lifetime, particularly if retransmission of the RTA packet is not scheduled due to expiration of the packet lifetime. The figure depicts a transmitter STA 212 and a receiver STA 214. When a transmitter STA transmits an RTA packet, it sets a lifetime 216 to transmit that packet. The initial transmission is seen at 218. In the figure, a value G1 represents a short interframe space (SIFS), G2 represents a DCF interframe space (DIFS), and G3 represents an ACK timeout. Before performing any retransmission of the RTA packet, the transmitter STA checks whether the lifetime of the packet has expired. If the lifetime has expired, no retransmission is scheduled and that packet is discarded. In this example, after a period 213(G2+ G3) between events 220 and 222, the transmitter performs a backoff 214 and then the STA transmits the first retransmission 216 because the packet lifetime has not expired. Thereafter, it checks the lifetime of the packet and in this example finds that it has expired 218, so it stops retransmitting and discards the packet.

On the receiver side, the RTA packet may be stored in a buffer before the expiration of the packet lifetime. When the packet lifetime expires, the receiver should delete that packet from the buffer because the RTA traffic in the packet is no longer valid.

RTA packet format

4.5.1. "RTA packet control" field

The "RTA control" field may be used to identify RTA packets, pre-negotiate, and retransmit schedules. In an immediate retransmission scheme, the "RTA control" field is used for three purposes.

The receiver STA may send an ACK or NACK to inform the transmitter STA of the correctness of the received packet based on the "RTA control" field information. The "RTA control" field contains retransmission scheduling information for an RTA packet. The "RTA control" field decides the type of Hybrid automatic repeat request (Hybrid ARQ or HARQ) for the RTA packet. When a packet is transmitted multiple times (i.e., retransmitted), the receiver STA may store the received signal of the multiple packet transmissions in a buffer. HARQ applies an error detection and correction method to a signal of a received packet having the same packet ID and successfully decodes the packet.

Fig. 25 illustrates an example embodiment 230 of the contents of the RTA field with the following subfields. (a) "Length" is the length of the "RTA control" field. (b) The "source address" is the address of the transmitter STA. (c) The "destination address" is the address of the recipient STA. It may also be the address of the receiver STA, AID, or other type of identifying information. (d) The "packet ID" is the identification of the packet. Packets with the same packet ID carry the same RTA traffic in the packet. (e) The "notify request" is a one-bit indication of whether the transmitter STA requests notification. When this bit is set to a first state (e.g., logic "1"), a notification is requested after the packet transmission is complete, and the receiver STA sends a notification back to the transmitter STA to report the correctness of the packet transmission; otherwise, the bit is set to a second state (e.g., a logical "0"). (f) The "a" field, which in this example is a one-bit field, is referred to as a more retransmission, which indicates whether another retransmission is scheduled after this transmission. Setting the bit to a first state (e.g., a logical "1") indicates that there is a retransmission; otherwise, the bit is set to a second state (e.g., a logical "0"). (g) The "traffic type" indicates that the type of traffic may be RTA traffic, non-RTA traffic, or other types of traffic. (h) The "RTA session ID" is identification information of the RTA session, which may use the information listed in table 1. (i) The "priority value" indicates the priority of the RTA traffic. (j) The "bandwidth requirement" indicates the bandwidth required for RTA transmission. (k) The "packet lifetime" indicates the lifetime of this packet to the expiration time. (l) The "periodic time" is the periodic time at which the RTA traffic generates packets. (m) "HARQ type" is an indication of the Hybrid Arq (HARQ) type used. HARQ operation may also be disabled by setting this field.

The transmitter STA sends an "RTA control" field to inform the receiver STA of the arrival of the RTA packet and its retransmission scheme. There are two methods for exchanging the "RTA control" field information between STAs.

The "RTA control" field is carried by the PLCP header of the RTA data packet. The "RTA control" field is transmitted by a trigger frame before transmitting the RTA data packet. The transmitter STA may embed an "RTA control" field in the PLCP header of the RTA packet. The benefit of using the PLCP header is to obtain the highest probability that the receiving STA will successfully decode the "RTA control" field. This is because the PLCP header has the best resilience to noise and interference during transmission. By embedding the "RTA control" field in the PLCP header, the receiver can often still obtain RTA control information even if the MAC frame cannot be successfully decoded.

4.5.2. Single user data packet

Fig. 26 illustrates an example embodiment 250 of an HE-SU-RTA packet format for RTA data transmission in single-user mode. The fields L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, HE-LTF, PE are identical to the conventional HE-SU PPDU format shown in FIG. 4. The 14 th bit of HE-SIG-a1 is reserved and set to a first state (e.g., a logic "1") in the normal format. In this case, this bit is set to a second state (e.g., a logical "0") to indicate the presence of the RTA-SIG field. In single-user mode, the RTA-SIG field contains only one "RTA control" field. The data frame uses the same format as shown in fig. 2.

4.5.3. Single user notification grouping

Fig. 27 illustrates an example embodiment 270 of an RTA-ACK/NACK packet frame format for notification in single user mode. This packet format is used as a notification packet in single-user mode to report the correctness of the RTA single-user data packet transmission.

The fields L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, HE-LTF, PE are identical to the conventional HE-SU PPDU format shown in FIG. 4. (a) The "frame control" field indicates the type of frame. (b) The "duration" field contains NAV information for CSMA/CA channel access. (c) The "RA" field contains the address of the recipient of the frame. (d) The "NACK (not acknowledged) indication" field is a one-bit indication that informs whether the frame is an ACK or NACK. Setting this bit to a first state (e.g., a logical "1") indicates that the notification frame is a NACK and the packet was not received correctly; otherwise, the bit is set to a second state (e.g., a logical "0") to indicate that the notification frame is an ACK (acknowledgement).

4.5.4 Multi-user data packet

Fig. 28 illustrates an example embodiment 290 of an HE-MU-RTA packet format for transmitting a multi-user transmission packet in a multi-user downlink mode. The fields L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, PE are exactly the same as in the conventional HE-MU PPDU format as shown in FIG. 7. Note that the HE-SIG-B field provides separate resource block allocation information for each user. The 7 th bit of HE-SIG-a2 is reserved and set to a first state (e.g., a logical "1") in the normal format. In this case, this bit is set to a second state (e.g., a logical "0") to indicate the presence of the RTA-SIG field.

In the multi-user mode, the RTA-SIG field contains a plurality of "RTA control" fields. The "number of RTA controls" field indicates the number of "RTA controls" fields in the RTA-SIG field. The data frame uses the same format as shown in fig. 2. The data frames carry RTA traffic and non-RTA traffic for each user.

RTA announce trigger frame

When gaining channel access to transmit multi-user transmission packets carrying RTA traffic, one STA may transmit an RTA announcement trigger frame (RTA-TF) to other STAs before transmitting the RTA packets. The RTA-TF contains RTA control information to inform the STA of the reception rules of the subsequent RTA packet transmission.

Fig. 29 illustrates an example embodiment 310 of an RTA advertisement trigger frame (RTA-TF) for RTA data transmission in multi-user mode. As shown, the RTA-TF embeds an "RTA control" field in its MAC frame. The RTA-TF can carry a retransmission schedule for the packet. An RTA-TF may be used to request RTA traffic from a particular RTA session. By parsing the RTA session information (e.g., the "RTA session ID" field in the "RTA control" field), the recipient STA requests RTA traffic from a particular RTA session.

The retransmission scheduling carried by the RTA-TF is only effective for the retransmission of the RTA packet in the same channel access time period; so that the RTA-TF will be retransmitted each time the STAs compete and gain channel access for RTA traffic.

Since the retransmission schedule with the "RTA control" field is transmitted before the transmission of the RTA packet, the RTA packet can use a conventional HE-TB packet format as shown in fig. 8. As explained in section 4.4.1, the receiver STA treats packets received using the channel resources granted for the RTA session as RTA packets. The fields L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, HE-LTF, PE are identical to the conventional HE-TB PPDU format shown in FIG. 8.

The "RTA announcement" field indicates the MAC frame of the packet. The "frame control" field indicates the type of frame. The "duration" field contains Network Allocation Vector (NAV) information for CSMA/CA channel access. The "RA" field contains the address of the recipient of the frame. The "TA" field contains the address of the STA transmitting the frame. The following fields represent the initial transmission schedule for the packet.

The "common information" field and the "user information" field are identical to fig. 10 and 11, respectively. These two fields contain separate resource block allocation information. The "number of RTA controls" field indicates the number of "RTA controls" fields following this field. The "RTA control" field is shown in fig. 25.

Fig. 30 illustrates an example embodiment 330 of the "RTA retransmission schedule" field. The "number of retransmissions" field indicates the number of retransmission schedules included in this field. The "retransmission schedule" field provides the retransmission schedule for each time. The "length value" within the field indicates the length of the "schedule" field. The "common information" field and the "user information" field are identical to those shown in fig. 10 and 11, respectively. The "number of RTA controls" field indicates the number of "RTA controls" fields following this field. The "RTA control" field is shown in fig. 25.

The RTA-TF may indicate whether the RTA packet transmission is from a transmitter or a receiver by parsing the source address field and the destination address field of the RTA control field in the frame. When the receiver sends an RTA-TF, only the transmitter needs to transmit packets according to the transmission and retransmission schedule in the "RTA announce" field. When the transmitter sends an RTA-TF, it waits until it receives an ACK from the receiver and then transmits the RTA packet according to the transmission schedule in the "RTA announce" field.

4.5.6. Multi-user notification frame

In at least one embodiment, the RTA retransmission schedule as shown in fig. 30 is embedded in the block ACK frame when more retransmissions need to be scheduled after the STA completes the transmission and retransmission schedule in the RTA-TF.

Fig. 31 illustrates an example embodiment 350 of the contents of an RTA block ACK frame (RTA-BA). The fields L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, HE-LTF, PE are identical to the conventional HE-TB PPDU format shown in FIG. 8. The "RTA BA" field indicates the MAC frame of the packet. The "frame control" field indicates the type of frame. The "duration" field contains NAV information for CSMA/CA channel access. The "RA" field contains the address of the recipient of the frame. The "TA" field contains the address of the STA transmitting the frame. The "BA control" field indicates a policy of block ACK. The "BA info" field contains the transmitted feedback.

4.6. Immediate retransmission scheme

In this section, the processing of packet transmission and retransmission is described in a scenario where RTA traffic and non-RTA traffic coexist and consider both single-user and multi-user modes.

4.6.1. Single user mode

4.6.1.1. flow diagram of RTA packet Transmission in SU mode

Fig. 32A and 32B illustrate an example embodiment 370 of actions taken by a transmitter STA when an immediate retransmission scheme is applied to the STA in single user mode. The process starts 372 to transmit packets in single user mode and then the MAC layer of the STA first waits 374 for traffic from upper layers to arrive. It then runs 376 a clear channel assessment process to obtain channel access for packet transmission. Before transmitting the packet, the MAC layer of the transmitter STA identifies 378 whether the traffic is an RTA or a non-RTA by checking header information from upper layers. This process may follow the flow chart shown in fig. 20, for example. If the header information matches one of the existing RTA session records created by the pre-negotiation, then this traffic is considered RTA traffic. If the header information does not match any existing RTA session, then this traffic is considered non-RTA traffic.

If the check at block 380 determines that the traffic is non-RTA, then execution moves to block 388 and the transmitter STA transmits the packet using the conventional HE-SU packet format and following the conventional CSMA/CA scheme before ending the routine in block 398 in fig. 32B. If the traffic is an RTA, execution moves from block 380 to block 382 in FIG. 32A, and the transmitter STA generates an HE-SU-RTA packet to transmit the traffic. When generating the HE-SU-RTA packet, the transmitter STA sets parameters in the "RTA control" field of the PLCP header. The transmitter STA then determines 384 whether to retransmit that RTA packet multiple times immediately after the initial transmission.

If the transmitter STA determines to transmit the packet multiple times, then execution moves to block 386, which resets the parameters in the "RTA control" field of the PLCP header for each retransmission so that the receiver STA may know the retransmission schedule, where execution moves to block 400 in fig. 32B. For example, in all transmissions except the last retransmission, the "more retransmission" field will be set to "1", and the "notification request" field will be set to "0", while the "more retransmission" field of the last retransmission will be set to "0". The "notify request" field of the last retransmission will be set based on the decision made by the transmitter STA. Depending on the setting of the "RTA control" field information in the PLCP header, the transmitter STA does not wait for any notification from the receiver STA in block 400 of fig. 32B until the last packet retransmission is complete. Otherwise, if it is determined at block 384 of fig. 32A that there are not multiple transmissions, then execution moves to block 390 of fig. 32B, where the transmitter STA completes the initial packet transmission.

In either case of RTA traffic, execution will move from block 390 or 400 to block 392 to determine whether the transmitter STA will wait for a notification, i.e., an RTA-ACK or an RTA-NACK, after either multiple transmissions or an initial transmission. This information can be shared between the transmitter and the receiver by setting the notify request field in the last transmission of the HE-SU-RTA packet. If the transmitter STA has not waited for a notification, the transmission of this packet ends and processing reaches end 398. Otherwise, the transmitter STA waits for a notification from the receiver STA and moves to block 394 to determine if the transmitter STA received the RTA-ACK before the timeout, if it did receive the RTA-ACK, the packet transmission was successful and execution ends up 398 without retransmission. If, however, the STA does not receive an ACK, block 396 is reached where the life cycle of the RTA packet is checked. If the packet lifetime expires, no retransmission is required, the packet is dropped and processing ends 398. Otherwise, block 402 is reached, where the retransmission is scheduled with minimum contention time, after which execution moves back to block 392.

Fig. 33 illustrates an example embodiment 410 of a retransmission scheme for RTA packets in single user mode. The figure describes details of how retransmissions of RTA packets are scheduled using the same HE-SU-RTA packet format as shown in block 402 of figure 32B. The process starts at 412 in fig. 33 and a check is performed 414 as to whether an RTA-NACK is received. If the RTA-NACK is not received before a timeout, the transmitter STA sets a back-off time for contention channel access, and a Contention Window (CW) that determines the amount of back-off time is not increased as in the conventional CSMA/CA scheme, but is allowed to decrease. The transmitter STA then waits 416 a back-off time based on the contention window size before execution reaches block 418. If it is determined at block 414 that an RTA-NACK is received, execution moves directly to block 418, because the transmitter STA remains occupied with the channel, so the transmitter STA immediately retransmits the RTA packet without channel contention.

After gaining channel access, the transmitter STA determines whether notification is required after the last retransmission 418. This information can be embedded in the PLCP header of the last transmission by setting the notify request field in the RTA control field, as explained with reference to fig. 25. The transmitter STA then determines 420 whether to retransmit the packet multiple times or only once. If the transmitter STA decides to retransmit multiple times, execution reaches block 422 and the STA resets the parameters of the "RTA control" field in the PLCP header for each retransmitted packet. Then at block 424, the transmitter STA does not wait for any notification from the receiver STA until the last packet retransmission is complete, with the "more retransmission" field set to "1" and the "notify request" field set to "0" in all retransmissions except the last retransmission. The "more retransmission" field of the last retransmission will be set to "0". The "notify request" field for the last retransmission will be set according to the decision made in block 418. The process ends at block 426.

However, if the STA decides to retransmit once in block 420, then it sets the parameters in the "RTA control" field of the PLCP header for the retransmission at block 428, then it retransmits 430 the packet without channel contention, and the process ends 426. The "notify request" field for the retransmission will be set based on the decision made at block 418.

Fig. 34A and 34B illustrate an example embodiment 450 of a process for receiving RTA and non-RTA packets in single user mode. The figure describes how a STA receives a packet 452 in single user mode. When the transmitter STA transmits an RTA packet, it embeds "RTA control" field information in the PLCP header using the HE-SU-RTA packet format as shown in fig. 26. When the receiver STA receives that packet in single user mode, it first detects 454 the PCLP header of the packet at the PHY layer in fig. 34A. The receiver STA identifies 456 whether this packet is an RTA or a non-RTA based on the presence of the "RTA control" field in its PLCP header; according to the process explained with respect to fig. 23. If the "RTA control" field is not present, then it is determined 458 that the packet is a non-RTA packet, execution reaches block 468 and receives it following a conventional CSMA/CA scheme, and execution ends 478 in FIG. 34B.

Otherwise, if the "RTA control" field is present, then the packet is determined to be an RTA packet at block 458 and execution proceeds to block 460, where the STA extracts the information in the "RTA control" field from the RTA-SIG field in the PLCP header. Based on the source and destination addresses, the STA determines 462 whether it is the intended recipient of the packet. If the STA is not the intended recipient, then processing ends at 478 in fig. 34B and it discards the packet.

However, if it is determined at block 462 in fig. 34A that the recipient STA is the intended recipient, then it parses the "HARQ type" field in the "RTA control" field in block 464 to decide which type of HARQ to use to decode this packet; but HARQ may be disabled at this step. Once the recipient STA knows the type of HARQ, it applies HARQ to decode 466 that packet through its previous transmissions before reaching block 470 in fig. 34B. The previous transmission of that packet is stored in a buffer. They have the same packet ID as the currently transmitted packet.

After decoding the packet, the receiver STA checks the "notify request" field in the "RTA control" field at 470 in fig. 34B. If the "notify request" field is found to be set to "1" in the "RTA control" field, a check is performed 472 as to whether the packet was received correctly. If it is received correctly, at block 474 an RTA-ACK notification is sent back to the transmitter STA and the packet is dropped 476 from the buffer before the process ends 478.

Otherwise, if it is determined at block 472 that the packet was not received correctly, the receiver STA sends 480 an RTA-NACK and checks 482 the packet lifetime. If the packet lifetime has expired, execution moves to block 476 and it drops the packet from the buffer before ending 478. Otherwise, if block 482 determines that the packet lifetime has not expired, it stores 484 the packet in a buffer for future decoding and the process ends.

Returning to block 470, if the "notify request" field in the "RTA control" field is set to "0", then the receiver STA does not send a notification and checks 486 the "more retransmissions" field in the "RTA control" field. If it is determined that there are more retransmissions, it reaches block 484 and stores the packet in a buffer for future decoding. Otherwise, if there are no more retransmissions, execution reaches block 482, which checks the packet lifetime to decide whether to drop the packet from the buffer or store the packet in the buffer, as discussed above.

4.6.1.2. Examples of the invention

In this section, a number of examples are provided to explain the processing of the retransmission scheme for RTA packets in single user mode. All examples use the network topology shown in fig. 17. The RTA packet may use the HE-SU-RTA packet format as shown in fig. 26. The notification packet may use an RTA-ACK/NACK packet format as shown in fig. 27.

Fig. 35 illustrates an example embodiment 490 of an RTA retransmission process performed contention-free after an initial transmission. Thus, the figure depicts immediate retransmission of an RTA packet after initial transmission is performed in single-user mode. The figure depicts communication between a transmitter 492, which is a STA5(AP), and a receiver 494, which is a STA 6.

This scenario occurs when a STA decides to retransmit an RTA packet multiple times, as shown in 384, 386, 400, 392, and 394 of fig. 32A and 32B. The transmitter STA resets the parameters of the "RTA control" field in the PLCP header of each retransmitted packet and thus retransmits them without waiting for a notification before the last transmission. A notification is requested after the last packet retransmission and the transmission is ended after receiving the RTA-ACK. It should be appreciated that when an STA transmits an RTA packet multiple times in succession, it is possible to add interframe space (such as SIFS) between two sequential packet transmissions (such as between an initial RTA transmission and a first RTA retransmission).

The transmitter STA transmits the RTA packet using the HE-SU-RTA packet format as shown in fig. 26. The "RTA control" field information is embedded in the PLCP header of the RTA packet that controls the retransmission scheme.

In the example of fig. 35, initial RTA transmission 496 and first RTA transmission 498 set the "notify request" field to "0" and the "more retransmission" field to "1" in the "RTA control" field to indicate that more retransmissions follow the current transmission and do not request notification. The second RTA transmission 500 sets the "notification request" field to "1" and the "more retransmissions" field to "0" to indicate that no more retransmissions follow and request notification. Based on the information of those fields, the receiver STA will not send a notification to the transmitter STA until the end 502 of the second RTA transmission 500.

Based on the source address and destination address in the "RTA control" field, the receiver STA determines whether it is an intended receiver and stores the packet transmission signal in a buffer. It is noted that if the lifetime in the "RTA control" field expires, those packet transmission signals will be removed from the buffer.

According to the "HARQ type" field embedded in the "RTA control" field of the packet PLCP header, the receiver STA can decode the packet using the received signals of three packet transmissions having the same packet ID in the "RTA control" field.

Then, as shown in the example, after a short interframe space (SIFS) Gl 506, the receiver STA sends 508 an RTA-ACK frame at time 504 to report the correctness of the packet transmission requested by the second RTA transmission 500. If the packet is in error, the receiver STA will instead send an RTA-NACK frame.

Fig. 36 illustrates an example embodiment 510 of an immediate RTA retransmission in single user mode without contention after an initial transmission failure. This example explains how RTA packet retransmissions are dynamically scheduled between a transmitter 512, illustrated as STA5(AP), and a receiver 514, illustrated as STA6, according to notification feedback.

The RTA packet transmits the RTA packet using the HE-SU-RTA packet format as shown in fig. 26. The "RTA control" field information is embedded in the PLCP header of the RTA packet that controls the retransmission scheme. The initial RTA transmission follows the flow chart shown in (390, 392, 394, 396 and 402) of fig. 32A and 32B.

Referring again to fig. 36, the transmitter STA sends an initial transmission 516, which ends at 518. After delay G1522, the receiver starts 520 transmitting the notification, but note that instead of the RTA-ACK, the receiver STA transmits RTA-NACK 523, whose transmission ends 524. The transmitter STA checks the lifetime of the packet. Since the life cycle of the packet has not expired, the transmitter STA starts 526 the first RTA retransmission 530 of the transmitted packet after the SIFS delay G1528, which is complete 532.

The transmitter STA then uses a retransmission scheme as shown in blocks 414, 418, 420, 428 and 430 of fig. 33. Referring again to fig. 36, since the transmitter STA receives an RTA-NACK for the initial RTA transmission from the receiver STA, the channel remains occupied.

The first time the transmission ends 532, a G1 delay 536 occurs, and then the receiver transmits 534 another RTA-NACK 537, which ends 538. An RTA-NACK is received by the transmitter, which shows that this first RTA retransmission also failed as well as the initial RTA transmission.

Immediately after SIFS delay G1542, the transmitter STA starts 540 a second RTA retransmission 544. This time, the transmitter STA decides to retransmit multiple times 544, 546 (twice in this example) without waiting for notification, as explained in blocks 418, 420, 422 and 424 of fig. 33.

Referring again to fig. 36, if the "notify request" field in the "RTA control" field is set to "0" in the third RTA retransmission, the transmission ends 548 after the last RTA retransmission (the third retransmission in this example).

The receiver STA decodes the packet using HARQ, the type of HARQ being indicated in the PLCP header of the packet. In at least one embodiment, the recipient STA stores all received packet transmissions in a buffer for decoding using HARQ. Each time the receiver STA receives an RTA packet, it may proceed to decode it with respect to the previous transmission stored in the buffer.

Fig. 37 illustrates an example embodiment 550 of RTA retransmission without increasing the size (duration) of the contention window. This example depicts RTA retransmission when a notification is not received as expected. Communications are depicted between a transmitter 552 (illustrated as AP STA5) and a receiver 554 (illustrated as STA 6). Initially, for conventional 802.11, as shown in fig. 5, when a transmitter STA contends for channel access for retransmission, the contention window increases and extends the back-off time for channel contention. In this case, the disclosed retransmission scheme does not increase the contention window by the transmitter STA, as this is an RTA packet retransmission, and in fact the present disclosure is configured to allow the contention window to decrease toward obtaining channel access more quickly.

In the example of fig. 37, the RTA packet uses the HE-SU-RTA packet format as shown in fig. 26. Referring to fig. 37, when a transmitter STA transmits an initial RTA packet 556, it sets a "notification request" field to "1" in the PLCP header. Then after the end of the transmission 558, the transmitter STA may expect a notification from the receiver STA after transmitting the packet.

As shown in blocks 414 and 416 of fig. 33, channel contention for RTA packet retransmission occurs when the transmitter STA does not receive the notification but it sets the "notification request" field to "1" in the PLCP header of the packet.

Thus in fig. 37, after time 558 of the initial transmission 556, there is no response over the combined period G2(DIFS) plus G3(ACK timeout) 562, which ends 560. A backoff 564 is performed followed by a first RTA retransmission 566, which ends 568. Again, there is no response over period G2+ G3572, at its end 570 the transmitter immediately performs another backoff 574 and performs a second RTA retransmission 576, which ends 578. Thus, in this example, two retransmissions are scheduled in case of channel contention. The contention window for the second RTA retransmission may be less than or equal to the contention window for the first retransmission. In this example, after a G1(SIFS) delay 582, the receiver begins transmitting 580 a RTA-ACK 584 because it has received the second RTA retransmission 576.

The size of the contention window for RTA retransmissions may be preset (predetermined in response thereto) by a pre-negotiation as shown in section 4.4.1. Those parameters may also be dynamically calculated based on channel conditions, packet lifecycle, and similar condition metrics.

Fig. 38 illustrates an example embodiment 590 of a retransmission scheme for mixed traffic in single user mode when the network has both RTA and non-RTA packets to transmit. This example describes how multiple STAs (illustrated as transmitter STA 7592, transmitter STA 6594, and receiver STA 5596) handle retransmission schemes for RTA and non-RTA packets.

As explained for blocks 378, 380, 388, and 382 in fig. 32A and 32B, the STA distinguishes RTA traffic and non-RTA traffic and generates RTA packets and non-RTA packets, respectively. When a STA transmits an RTA packet, it embeds RTA control information in its PLCP header using the HE-SU-RTA packet format as shown in fig. 26. The recipient STA may also identify that the packet is an RTA packet based on the presence of an "RTA control" field in the received packet.

When a transmitter STA transmits an RTA or non-RTA packet, it contends for the channel. As shown in fig. 38, the transmitter STA 6594 and STA 7592 contend for channel access for initial transmissions of RTA packets and non-RTA packets, respectively (see backoff of 598, 599).

While one transmitter STA is transmitting, the other STAs sense the channel status and set CCA to busy. In this example, after backoff 598(CW set to n slots), transmitter STA7 gains channel access and transmits initial non-RTA transmission 600, and transmitter STA6 senses the channel and sets CCA to busy 602. The receiver does not respond within interval G2+ G3606, where STA7 and STA6 both contend for the channel, performing backoff 608a (CW set to 2 × n slots), 608b (CW set to m slots), respectively. Thus, since the non-RTA packet 600 requires retransmission, the transmitter STA 7592 re-contends for the channel with its contention window doubled (CW set to 2 × n slots). This follows the conventional CSMA/CA retransmission scheme.

In this case, STA6 acquires the channel because it has a shorter backoff set based on its attempt to send an RTA packet and starts an initial RTA transmission 612, then the transmitter STA7 senses the channel and sets the CCA to busy 610. See G1(SIFS) period 616, after which RTA-NACK 618 is transmitted by the receiver STA5(AP) 596. After the delay G1 interval 622, the transmitter STA 6594 receives the RTA-NACK 618 and immediately begins the first RTA retransmission 624 without contention, while the transmitter STA 7592 is still in the CCA busy state 610. After delay 628, receiver STA 5596 sends RTA-ACK 630 to indicate that it received the transmission. Thus, when transmitter STA 6594 transmits RTA packet 612, it follows an immediate retransmission scheme when sending first RTA retransmission 624.

The retransmission scheme switches on a packet basis, so it can be seen that after RTA-ACK 630, both STA 7592 and STA 6594 attempt to gain channel access, both of which attempt to transmit non-RTA packets 634, 648, respectively. Thus, when the transmitter STA6 transmits an RTA packet, it uses the immediate retransmission scheme, but when it transmits a non-RTA packet, it switches back to using the CSMA/CA scheme. Thus both STA 7592 and STA 6594 perform backoff 632a, 632b (CW set to n slots) and in this case STA7 gains access and transmits the first non-RTA retransmission 634 and STA6 sensing the channel busy sets CCA busy status 635. After a G1(SIFS) delay 638, the receiver STA 5596 sends an ACK 640. STA 6594 then begins contending for the channel with backoff 642, but both STA7 and STA6 sense that the channel is now busy due to transmissions from other stations and both enter CCA busy states 644a, 644b, after which STA6 contends with backoff 646, then transmits its initial non-RTA transmission 648.

4.6.2. Multi-user mode

This section describes the application of the disclosed techniques to multi-user transmission. It should be appreciated that applying this technique to multi-user transmission is more complex than single-user transmission for a number of reasons including the following. Multi-user transmission supports simultaneous transmission for multiple users on the uplink and downlink. One multi-user transmission packet may contain both RTA and non-RTA traffic. For example, in IEEE 802.11ax, uplink multi-user transmission is triggered by the receiver STA (i.e., AP). Thus, the disclosed protocol is configured to handle conditions that arise due to the fact that channel bandwidth allocation is flexible and dynamically adjusted.

The disclosed techniques include the following features to conform to and leverage the benefits of multi-user transmissions. The retransmission scheme is selected by the type of traffic (e.g., RTA or non-RTA) carried by the multi-user retransmission packet. This decision is made based on feedback from the notification.

Multi-user transmission packets can carry both RTA and non-RTA traffic for multiple users. A multi-user transmission packet is an RTA packet when it carries RTA traffic. non-RTA traffic carried by RTA multi-user transport packets also follows an immediate retransmission scheme. When retransmitting a multi-user transmission packet, the AP can reassign individual resource blocks to achieve greater diversity effect. The disclosed techniques may be applied to any type of multi-user transmission, including OFDMA and MIMO.

4.6.2.1. Multi-user downlink mode

In a multi-user downlink scenario, an AP is the transmitter and the STAs associated with that AP are the receivers.

4.6.2.1.1. flow chart for packet transmission in MU downlink mode

Fig. 39A and 39B illustrate an example embodiment 650 for transmitting RTA and non-RTA packets in MU downlink mode and explain details of actions taken by a transmitter STA when an immediate retransmission scheme is applied to multi-user downlink transmissions.

When the AP intends to transmit a packet 652 in the multi-user downlink mode in fig. 39A, its MAC layer first receives 654 traffic from an upper layer. The AP then performs (runs) a Clear Channel Assessment (CCA)656 to gain channel access for its transmissions. The MAC layer of the AP may identify 658RTA traffic and non-RTA traffic (as described in fig. 20) by comparing header information from upper layers with RTA session records created by pre-negotiation. The AP makes 660 a determination whether the upcoming packet will contain RTA traffic in the upcoming multi-user transmission.

If the upcoming multi-user transmission carries only non-RTA traffic, then execution moves to block 668 and the AP performs packet transmission and retransmission using conventional CSMA/CA scheme and the process ends 684 in FIG. 39B.

If it is determined at block 660 in fig. 39A that some traffic in the upcoming multi-user transmission is an RTA, then execution moves to block 662 where the STA creates an "RTA control" field for each RTA and non-RTA element of the traffic. When the AP creates an "RTA control" field for non-RTA traffic, the AP indicates that it is a non-RTA in the "traffic type" field of the "RTA control" field. Next, the AP assigns 664 separate resource blocks, such as Resource Units (RUs), Modulation and Coding Schemes (MCS), etc., to each traffic in the upcoming multi-user transmission. The AP then generates 666 multi-user transmission packets using the HE-MU-RTA packet format (as shown in fig. 28). The "RTA control" field and the individual resource block allocation information are embedded in the PCLP header of the HE-MU-RTA packet. The packetized data frame may be encoded using HARQ.

The AP transmits the packet at 670 in fig. 39B in the multi-user mode using the resource blocks allocated in the PLCP header of the HE-MU-RTA packet. Each RTA and non-RTA packet is carried by a "data frame" field in the HE-MU-RTA packet and is transmitted using an allocated separate resource block.

In at least one embodiment, after the AP finishes transmitting the multi-user transmission packet, it may wait 672 for a notification according to a "notify request" field in the "RTA control" field of the packet. If a notification request is performed, such as by setting the "notification request" field to "1", the AP expects to receive a notification (e.g., BA) from the recipient and execution proceeds to block 674 where the AP sends an MU-BAR for the notification request from the recipient.

If the AP is waiting 676 for notification (e.g., BA) but does not receive it before a timeout, then execution reaches block 678 where it retransmits the packet by contending for channel access. In this case, the contention window is not increased but allowed to decrease.

If the AP receives the notification as determined at block 676, it checks 680 if a retransmission is needed. When the "more retransmission" field in RTA control is set to "1" or the BA reports that the packet was not received correctly, retransmission is required. If no retransmission is needed, the process ends 684. Otherwise, if retransmission is required, the lifetime of the traffic carried by the packet is checked 682. If the lifecycle has expired, then the RTA traffic will be dropped and the process ends 684. Otherwise, for traffic whose lifecycle has not expired, rescheduling is performed for the retransmission, depicted as performing moving back to block 660 in FIG. 39A. If its number of retransmissions does not exceed the retry limit, non-RTA traffic will be included in the retransmission. At block 660, the AP checks whether the retransmission carries RTA traffic and will schedule another multi-user transmission, and so on.

Fig. 40A and 40B illustrate an example embodiment 690 for receiving RTA and non-RTA packets in MU downlink mode, which describes details of how STAs receive RTA and non-RTA packets in multi-user downlink mode. When the receiver STA receives the packet 692 in the multi-user downlink mode, it first detects 694 the PLCP header of the packet at the PHY layer. The recipient STA parses the PLCP header and determines 696 whether an "RTA control" field is included in the PLCP header. Then, it is checked 698 at the receiver STA whether the packet is an RTA or a non-RTA (described with respect to fig. 23).

If the "RTA control" field is not in the PLCP header, then the multi-user packet does not contain RTA traffic and execution moves to block 708 where the receiver STA is configured to receive the packet following the conventional CSMA/CA scheme and execution ends at 718 in FIG. 40B.

Otherwise, if the "RTA control" field is detected in the PLCP header, then it is determined 698 that the multi-user packet contains RTA traffic and the receiver STA parses 700 the "RTA control" field and finds any "RTA control" fields that belong to it. In response to the comparison to the source and destination addresses, the STA determines 702 whether the "RTA control" field belongs to it and whether it is the intended recipient of the packet. If no "RTA control" field belongs to the receiver STA, then the receiver STA is not the intended receiver and it discards the packet and the process ends at 718 in FIG. 40B.

Otherwise, if at least one "RTA control" field belongs to the recipient STA, then the recipient STA is the intended recipient and execution reaches block 704. All RTA control information is then extracted from this "RTA control" field. It continues to receive 704 packets using the individual resource blocks allocated in the PLCP header. Once the receiver STA receives the entire packet, it decodes 706 the packet through its previous transmissions (if they exist in the buffer) according to the "HARQ type" field in the "RTA control" field. HARQ may also be disabled according to information in the "HARQ type" field.

A decision block 710 is reached in fig. 40B where a determination is made as to whether the packet was received without error. If not, the receiver STA discards 712 all received signals for the packet from the buffer since HARQ decoding is no longer required. The receiver STA then checks 714 the "notify request" field in the "RTA control" field.

Otherwise, if the packet is found to be received in error at decision block 710, the receiver STA checks 720 the packet lifetime. If the packet lifetime expires, then execution moves to block 712 where the currently received packet transmission, as well as any previous transmissions for that packet, are dropped from the buffer. Otherwise, if the packet lifetime has not expired, then execution reaches block 722 and the station stores the received signal for the current packet transmission in a buffer and checks 724 the "more retransmissions" field in the "RTA control" field. If there are more retransmissions, the current transmission ends 718 and the receiver STA should be ready to receive the next transmission of this packet.

However, if it is determined at block 724 that no more retransmissions follow, the receiver STA checks the "notify request" field in the "RTA control" field at block 714. If the indicator bit for that field is set to "0," then no notification is requested and processing ends 718. Otherwise, the receiver STA sends a block ack (ba)716 after receiving the MU-BAR from the AP and the process ends 718.

4.6.2.1.2. Multiple examples of hybrid RTA and non-RTA traffic

This section illustrates three examples of hybrid RTA and non-RTA traffic transmission using multi-user downlink OFDMA. In these examples, one multi-user transmission packet contains both RTA traffic and non-RTA traffic. However, the retransmission schedule may be different based on "RTA control" field information in the multi-user transmission packet.

All of these examples are based on the example network topology described by way of example and not limitation in fig. 17. The multi-user transmission packet containing the RTA traffic may use the HE-MU-RTA packet format as shown in fig. 28. A multi-user transmission packet containing only non-RTA traffic may use a conventional HE-MU packet format as shown in fig. 7, while all other packets may use a conventional packet format.

Fig. 41 illustrates an example embodiment 730 of a retransmission scheme for RTA packets in MU downlink OFDMA to indicate that an immediate retransmission scheme is applied when RTA traffic requires retransmission of packets in multi-user downlink mode. The figure depicts communication between first transmitter STA0(AP)732, receiver STA 1734, receiver STA 2736, receiver STA 3738, and receiver STA 4740.

Initial transmissions 742 are transmitted by the AP 732 to its STAs (non-APs), including the stations shown in the figure. This process follows the logic of the flow chart in fig. 39A and 39B. The multi-user transmission packet may use the HE-MU-RTA packet format as shown in fig. 28. The PLCP header of the HE-MU-RTA packet contains separate resource block allocation information and "RTA control" field information.

As shown in the diagram of initial transmission 742, Resource Units (RUs) 1, 3, 4 are used to transmit RTA traffic, while RU2 is used to transmit non-RTA traffic. The receiver STA detects the "RTA control" field in the PLCP header of the HE-MU-RTA packet. Then, the receiver STA receiving the traffic uses the allocated resource blocks indicated in the PLCP header and decodes them according to the HARQ type in the "RTA control" field. After completing the HE-MU-RTA packet transmission, the AP transmits the multi-user BAR 746, and the receiver STAs send BAs 748a, 748b, 748c, and 748d, respectively, to report the correctness of the initial transmission. From these Block Acknowledgements (BAs), STA 0732 determines 750 that the packet to STA2 was received correctly and that retransmissions must be scheduled for receivers 1, 3, and 4.

As explained with respect to block 680 of fig. 39B, from the BA received from the recipient, the AP recognizes that the RTA packets of recipients 1, 3 and 4 need to be retransmitted. Referring again to fig. 41, the AP of STA 0732 checks the lifetime of the packet for each RTA traffic and immediately retransmits the packet without channel contention. In this case, the transmitter AP retransmits twice without waiting for a notification. This follows the logic of the flow chart blocks 672, 680, and 682 in fig. 39B by setting the "more retransmission" field in the "RTA control" field to "1" in the first retransmission 752 seen in fig. 41 before the end 756 of the transmission and setting the "more retransmission" field in the "RTA control" field to "0" in the second retransmission 754. The notify field in both retransmissions is set to "0" so that there is no MU-BAR and BA exchange between the AP and the recipient STA.

For each retransmission, the transmitter AP assigns a separate resource block to obtain more diversity. Each retransmission assigns a different RU to a user. Also, as shown by the second retransmission, the MCS may be adjusted during the retransmission. The first retransmission is shown as RU1 containing RTA traffic for recipient 4, RU2 having RTA traffic for recipient 1, and RU4 having RTA traffic for recipient 3. The second retransmission is illustrated as RU1 containing RTA traffic for recipient 3, RU2 having RTA traffic for recipient 4, and RU3 and RU4 having RTA traffic for recipient 1 having a different MCS.

Fig. 42 illustrates an example embodiment 770 of handling MU-BAR failure in downlink multi-user OFDMA to indicate that an AP must re-contend for the channel to perform RTA packet retransmission when an exchange of MU-BAR and BA between the AP and a recipient STA fails in multi-user downlink mode. Similar to the previous figures, fig. 42 depicts communications between a first transmitter STA0(AP)772, a receiver STA 1774, a receiver STA 2776, a receiver STA 3778, and a receiver STA 4780.

Initial transmission 782 is transmitted by AP STA 0772 to its STAs (non-APs). This process follows the logic of the flow diagram blocks 672, 674, 676 and 678 in fig. 39B. The AP transmits the multi-user transmission packet using the HE-MU-RTA packet format as shown in fig. 28. The PLCP header of the HE-MU-RTA packet contains channel resource block allocation and "RTA control" field information. As shown by way of example and not limitation in the foregoing fig. 41, RUs 1, 3, 4 are shown for transmitting RTA traffic, while RU2 is used for transmitting non-RTA traffic. The receiver detects the "RTA control" field in the PLCP header of the HE-MU-RTA packet, receives the packet using the allocated resource blocks indicated in the PLCP header, and decodes it according to the HARQ type in the "RTA control" field. After completing the HE-MU-RTA packet transmission, the AP transmits MU-BAR 784 in fig. 42, but receives BA 786 only from recipient 2778.

After waiting for the BA, STA0 determines 787 that no BAs were received from recipients 1, 3, and 4, whereas from the BA received from recipient 2, its non-RTA traffic was transmitted correctly, but other RTA traffic was not transmitted correctly. In response, the AP needs to schedule retransmissions for RTA traffic. As depicted by block 676 in fig. 39B, the AP in the example of fig. 42 must contend (re-contend) for channel access again by waiting for a back-off time 788 (where CW is set to n slots) and access the channel for a first retransmission 790, followed by a MU-BAR 792.

After completing the first retransmission, STA0 determines 794 that the same communication failure occurred as in the initial transmission. This time, the contention window for the back-off time is not increased, but allows the contention window for RTA packet retransmissions to be reduced. STA 0772 contends for the channel with backoff 796 (where CW is equal to or less than n) and accesses the channel to send a second retransmission 798. The transmission ends 800 after the second retransmission, since no notification is requested and no more retransmissions are scheduled.

Fig. 43 illustrates an example embodiment 810 without immediate retransmission for non-RTA packets in MU downlink OFDMA. Similar to the previous figures, fig. 43 depicts communications between a first transmitter STA0(AP)812, a receiver STA 1814, a receiver STA 2816, a receiver STA 3818, and a receiver STA 4820.

This figure illustrates an example where the retransmission contains only non-RTA traffic. This scenario is depicted in blocks 660, 668 of FIG. 39A. Referring back to fig. 43, an initial transmission 822 is transmitted by the AP812 to its STAs (non-APs), followed by the MU-BAR 824. As shown, RUs 1, 3 are used to transmit 822 non-RTA traffic and RUs 2, 4 are used to transmit RTA traffic. Upon notification (i.e., BA)826a, 826b, 826c, and 826d returned from the recipient, the AP recognizes 828 that all RTA traffic was successfully received. However, non-RTA traffic for receiver 1 requires retransmission. According to block 668 in fig. 39A, the AP in the example of fig. 43 switches to using the CSMA/CA scheme and contends for the channel again with the back-off time 830 and continues to retransmit 832 non-RTA traffic for the receiver 1814 after the channel access.

4.6.2.2. Multi-user uplink mode

In the multi-user uplink mode, the AP may receive packets from multiple STAs simultaneously. Specifically, the AP, which is the recipient in the uplink, initiates transmission between the STA and the AP by sending a trigger frame to all the transmitter STAs. The transmitter STA transmits the packet after receiving the trigger frame.

4.6.2.2.1. flow chart of grouping in MU uplink class mode

Fig. 44A and 44B illustrate an example embodiment 850 for transmitting RTA and non-RTA packets in MU uplink mode to show details of actions taken by a transmitter STA when an immediate retransmission scheme is applied to multi-user uplink transmissions.

When STAs transmit packets 852 in the multi-user uplink mode, the MAC layer of those STAs first receives 854 traffic from upper layers. As depicted in fig. 20, the MAC layer of the transmitter STA may identify 856RTA and non-RTA traffic by comparing header information from upper layers with RTA session records created by pre-negotiation, where such identification of RTA traffic is seen at the transmitter side in block 858.

Before the STAs transmit these packets, they receive a trigger frame from the AP 858. A check 860 is performed as to whether the trigger frame contains any "RTA control" fields. If the trigger frame does not contain any "RTA control" field, then the trigger frame is a conventional trigger frame as shown in FIG. 9, the transmitter STA transmits 864 the packet in FIG. 44 following the conventional CSMA/CA scheme and execution reaches the end of processing 880 in FIG. 44B. If the trigger frame contains an "RTA control" field, as determined at block 860, then the multi-user transmission contains RTA traffic and the trigger frame is in an RTA-TF format, as previously shown in FIG. 29.

The transmitter STA then extracts the "RTA control" field information for the initial transmission. If there is an "RTA retransmission Schedule" field after the "RTA control" field, the AP schedules multiple retransmissions. The total number of retransmissions is set 862 and is denoted by N to be equal to the number of retransmissions in the "RTA retransmission" field plus one (i.e., the initial transmission).

The transmitter STA then transmits the packet multiple times after the initial transmission and with the retransmission schedule provided in the RTA-TF. During this portion of the process, a check 866 is made to determine if more transmissions are needed (e.g., N is still greater than 0). In the event that there are more transmissions remaining, execution reaches block 868 and the transmitter STA retrieves traffic to transmit according to the RTA-TF. If the traffic is an RTA, the transmitter STA retrieves the traffic from the RTA session whose RTA session ID is indicated in the RTA-TF. The transmitter STA then encodes the packet using the HARQ type declared in the RTA-TF by 870. The multi-user packet uses the conventional HE-TB format as described in fig. 8 to generate 872MU packets in fig. 44B using the HE-TB format. The RTA traffic within the HE-TB packet carries traffic for the RTA session declared in the RTA-TF. The transmitter STA transmits 874 the HE-TB packet using the separate resource block assigned by the RTA-TF. The retransmission of the packet completes multiple transmissions with the same type of information embedded in the "RTA retransmission Schedule" field in the RTA-TF and decrements 876 the retransmission counter to determine if another retransmission should be performed before returning to block 866.

After the transmitter STAs complete all transmissions and retransmissions of the RTA-TF schedule, they may receive RTA-BA packets from the AP. Thus, if the check at block 866 indicates that there are no more retransmissions, then execution reaches block 878, which determines whether an RTA-BA with an "RTA retransmission schedule" field is received. If an RTA-BA with a retransmission schedule is received, execution moves to block 862 of FIG. 44A so that the transmitter STA may retransmit the packet at blocks 868, 870, and 872 according to the retransmission schedule in the RTA-BA. Since there is no initial transmission information in the RTA-BA packet, the number of retransmissions N is equal to the number of retransmissions in the RTA retransmission field. If it is determined at block 866 that the required number of retransmissions has reached zero and no RTA-BA with a retransmission schedule has been received, as determined at block 878, then the process ends 880.

Fig. 45A and 45B illustrate an example embodiment 890 for receiving RTA and non-RTA packets in MU uplink mode, describing details of how an AP receives multi-user packets carrying RTA and non-RTA traffic in uplink mode. When the AP decides to receive packet 892 in multi-user uplink mode, it checks 894 the RTA session record created by pre-negotiation. From the pre-negotiation record, the AP determines 894 whether it should receive some traffic for the RTA session.

If there is no RTA traffic to receive, block 896 is reached and before the 934 process of FIG. 45B ends, the AP performs a clear channel assessment to obtain channel access, sends a normal trigger frame 898, and receives 900 packets carrying non-RTA traffic following the CSMA/CA scheme.

If the check 894 in fig. 45A determines that the AP has RTA traffic to receive, then it embeds individual resource block allocation information, "RTA control" field and retransmission schedule in the RTA-TF packet at block 902. The AP then evaluates 904 the channel conditions and sends 906 an RTA-TF packet to the transmitter STA. If the AP does not detect 908 the PLCP header of the multi-user transmission packet from the transmitter STA before a timeout, then the RTA-TF transmission fails, as seen at block 910, and the AP must wait for the back-off time and execution moves to block 904 where it re-contends for channel access and retransmits the RTA-TF packet. It should be noted in block 910 that the contention window for the back-off time does not increase, but it may be decreased.

Otherwise, if the AP detects the start of multi-user uplink transmission before a timeout at block 908, it receives 912 traffic using the individual resource blocks allocated in the RTA-TF packet. As long as the check at block 914 indicates more retransmissions in the RTA-TF, the AP will continue to receive packets at block 912.

After the AP receives all transmissions and retransmissions of the packet from the transmitter STA, then a loop moves from blocks 912, 914 to block 916 in fig. 45B where it begins decoding the packet using the type of HARQ indicated in the RTA-TF packet. A check 918 determines whether all RTA packets have been correctly received by the AP. If it receives all packets correctly, then execution reaches a block where it discards 920 the received signal for that packet from the buffer and checks 922 the "notify request" field in the last retransmission schedule embedded in the RTA-TF packet. If it is determined at block 922 that there is no notification request, then the process ends 934. Otherwise, the STA transmits 924RTA-BA without a retransmission schedule before ending 934.

If not all packets are received correctly, then execution returns to check 918, and then execution reaches block 926, and the AP stores 928 the received signal of the packet in the buffer and removes 928 from the packet in the buffer the portion of RTA traffic whose lifetime expired. The AP also determines 930 whether to schedule more retransmissions for those packets in the buffer. If more retransmissions are needed, the AP sends 932 the RTA-BA packet with the retransmission schedule embedded therein to all transmitter STAs and execution moves back to block 908 in fig. 45A where it may begin receiving retransmissions. If it is determined at block 930 that there are no more retransmissions to be scheduled, then execution reaches block 922, where the AP checks the "notify request" field embedded in the last retransmission schedule in the RTA-TF packet.

When the AP checks 922 the "notify request" field embedded in the last retransmission schedule in the RTA-TF packet, if the "notify request" field is set to "0", then the transmission ends 934; otherwise, the AP transmits 924 an RTA-BA packet to the transmitter STA without the embedded retransmission schedule.

4.6.2.2.2. Example of hybrid RTA/non-RTA for MU uplink OFDMA

By way of example and not limitation, this section describes three examples of hybrid RTA and non-RTA traffic transmission using multi-user uplink OFDMA. In these examples, it should be noted that one multi-user transmission packet may contain both RTA traffic and non-RTA traffic and is based on the network topology example seen in fig. 17. The multi-user transport packet uses a conventional HE-TB packet format, as shown in fig. 8. The retransmission schedule may be transmitted by the receiver AP to the transmitter STA using an RTA-TF packet as shown in fig. 29 or an RTA-BA packet as shown in fig. 31.

Fig. 46 illustrates an example embodiment 950 of an immediate retransmission scheme for RTA traffic in MU uplink OFDMA as an example of how immediate retransmissions are scheduled in a multi-user uplink scenario using OFDMA. The figure depicts communication between a first transmitter STA0(AP)952, a receiver STA 1954, a receiver STA 2956, a receiver STA 3958, and a receiver STA 4960.

This example occurs when the AP has RTA traffic to receive 894, sends 906 the RTA-TF packet to the transmitter STA, receives the packet 912 from the transmitter STA, and sends 932 an RTA-BA packet with a retransmission schedule to retransmit the packet, according to previously described fig. 45A and 45B.

Referring again to fig. 46, the AP determines from the RTA session record created from the pre-negotiation that it has RTA traffic to receive. It transmits 962 an RTA-TF packet to trigger the initial transmission. The RTA-TF contains transmission and retransmission scheduling information, as well as RTA session identification information (such as including an RTA session ID).

The transmitter STA receives RTA-TF packets from the AP and determines whether to transmit packets carrying RTA traffic or non-RTA traffic based on traffic type information and RTA session ID information in the RTA-TF. The RTA traffic comes from an RTA session whose session ID is embedded in RTA-TF packets. The transmitter STAs also determine which resource block they should use to transmit the packet. In this example, transmitters STA1, 2, and 4 use RU1, 2, and 4, respectively, to transmit RTA traffic, while transmitter STA3 uses RU3 to transmit non-RTA traffic. These initial transmissions 964a, 964b, 964c, and 964d to the AP are shown with their headers. The multi-user transport packet uses the HE-TB packet format.

After the initial transmission is complete, the AP determines 966 that it correctly received RTA traffic from transmitter 2 but failed traffic from other transmitters, so that the traffic sent by transmitters STA1, 4 is RTA and the traffic sent by transmitter STA3 is non-RTA. Since there is RTA traffic to retransmit, the AP sends an RTA-BA packet 968 with a retransmission schedule. In this example case, two retransmissions are scheduled in the RTA-BA, but the programming can be set to any desired number of retransmissions. The resource blocks for each retransmission are reassigned by the AP to achieve more diversity. The transmitter STA receives the RTA-BA.

Retransmission is then performed by STA 1954, STA 3958, and STA 4960 according to the retransmission schedule embedded in the RTA-BA packet, which the transmitter STA retransmits twice using the logic seen in blocks 866, 870, 872, 874, and 876 in fig. 44B. Referring again to fig. 46, a first retransmission 970a, 970b, 970c is seen, followed by a second retransmission 972a, 972b, 972c, and the transmission ends 974.

The AP receives the first and second retransmissions following the retransmission schedule in the RTA-BA packet as shown at 912, 914 in fig. 45A. The AP decodes the packet using the packet signal received from the three transmissions of fig. 46 according to the HARQ type indicated in the RTA-BA. Since no notification is requested, the transmission ends 974.

Fig. 47 illustrates an example embodiment 990 of handling RTA-TF and RTA-BA failures in MU uplink OFDMA, illustrating how an AP reacts when an RTA-TF or RTA-BA packet is not successfully transmitted in multi-user uplink mode using OFDMA. The figure depicts communication between a first receiver STA0(AP)992 and a group of transmitters including a transmitter STA 1994, a transmitter STA 2996, a transmitter STA 3998, and a transmitter STA 41000.

This scenario follows blocks 908, 910 in the flow diagram of fig. 45A. When the RTA-TF or RTA-BA packet is not successfully transmitted, the AP must re-contend for the channel and re-transmit the RTA-TF packet.

The AP sets 1002 the life cycle of the RTA packets from transmitters 1, 2 and 4. From the RTA session record created by the pre-negotiation, the AP has RTA traffic to receive and it transmits RTA-TF packet 1004 to trigger initial transmissions 1006a, 1006b, 1006c, and 1006 d. The RTA-TF contains transmission and retransmission scheduling information. RTA session information (such as an RTA session ID) is also embedded in the schedule.

The transmitter STA receives the RTA-TF packet from the AP. And according to the traffic type information and the RTA session identification information in the RTA-TF, the STA of the transmitter determines whether to transmit RTA traffic or non-RTA traffic. The RTA traffic comes from an RTA session whose session ID is embedded in RTA-TF packets. The RTA-TF also informs the transmitter STAs which resource block they should use to transmit traffic. In this example, transmitters STA1, 2, and 4 transmit RTA traffic using RU1, 2, and 4, respectively. The transmitter STA3 transmits non-RTA traffic using RU 3. The multi-user transport packet uses the HE-TB packet format.

After the initial transmission is complete, the AP determines 1008 that RTA traffic from transmitter 2 has been correctly received but traffic from other transmitters fails. Failed transmissions include RTA traffic transmitted from STA 1994 and STA 41000, as well as non-RTA traffic transmitted by the transmitter STA 3998. Meanwhile, the lifetime of the traffic from the transmitter STA4 expires, the receiver AP drops the traffic from the packet in the buffer and does not schedule retransmission for that traffic. Since there is still RTA traffic to retransmit, the AP sends an RTA-BA packet 1010 containing a retransmission schedule.

However, the AP determines 1012 that it has not received a packet from the transmitter STA after transmitting the RTA-BA packet and must re-contend for the channel and wait for the back-off time 1014(CW set to m slots). After the AP regains channel access, it again sends an RTA-TF packet 1016 to the transmitter STA.

The AP determines 1018 that it has not received a packet after retransmitting the RTA-TF, whereby the AP re-contends for the channel 1020 with the back-off time without increasing the contention window (CW set to less than or equal to m slots). The AP reassigns individual resource blocks and embeds that information in the RTA-TF packet 1022 that it retransmits. This time, the transmitter STA receives the RTA-TF and sends the first retransmission of the packet 1024a, 1024b using the individual resource blocks reassigned in the RTA-TF packet. The AP successfully receives the packet from the transmitter STA and sends an RTA-BA packet 1026 without a retransmission schedule to inform the transmitter STA that the transmission was successful.

Fig. 48 illustrates an example embodiment 1030 of a retransmission scheme for non-RTA packets in MU uplink OFDMA to show an example explaining how multi-user transmission packets are retransmitted in uplink multi-user mode of an OFDMA system when only non-RTA traffic retransmissions are required. The figure depicts communication between a first receiver STA0(AP)1032 and a set of transmitters, including a transmitter STA 11034, a transmitter STA 21036, a transmitter STA 31038, and a transmitter STA 41040.

As shown in blocks 894, 896, 898, and 900 of fig. 45A, the AP initiates multi-user uplink transmissions following the conventional CSMA/CA scheme.

From the RTA session record created by the pre-negotiation, the AP has RTA traffic to receive, so it is seen in FIG. 48 that RTA-TF packet 1042 is transmitted to trigger the initial transmission. The RTA-TF contains transmission and retransmission scheduling information, including an embedded RTA session ID.

The transmitter STA receives the RTA-TF packet from the AP and decodes its information. According to the information in the RTA-TF, the transmitter STA determines whether to transmit packets carrying RTA traffic or non-RTA traffic. RTA traffic is data generated by an RTA session whose session ID is embedded in an RTA-TF packet. The STAs also identify which resource block they should use to transmit packets. In this example, the transmitter STAs 21036 and 41040 use RU2 and RU4, respectively, to transmit packets carrying RTA traffic, while the transmitter STAs 11034 and 31038 use RU1 and RU3, respectively, to transmit packets carrying non-RTA traffic. The multi-user transport packet uses the HE-TB packet format.

After the initial transmissions 1043a, 1043b, 1043c, and 1043d are complete, the AP determines 1044 that it has correctly received traffic from the transmitters of STA2 and STA4 but failed traffic from other transmitters. Traffic transmitted by transmitters STA2 and STA4 is RTA, while traffic transmitted by transmitters STA1 and STA3 is non-RTA. Since there is no need to retransmit RTA traffic, the AP transmits an RTA-BA packet 1046 without a retransmission schedule. If the AP needs to schedule retransmission for non-RTA traffic, it re-contends for the channel with the back-off time 1048(CW set to n slots) and sends a regular trigger frame 1050 after accessing the channel to retransmit the non-RTA traffic.

The transmitter STA l and STA3 receive the trigger frame and retransmit the packet carrying the non-RTA traffic as a first retransmission 1052a, 1052 b. The AP receives the non-RTA packet and sends back BA 1054 to report the correctness of the received packet.

5. General scope of the embodiments

The enhancements described in the proposed techniques can be readily implemented within various wireless communication station circuitry. It should also be appreciated that the wireless communication station is preferably implemented to include one or more computer processor devices (e.g., CPU, microprocessor, microcontroller, computer-enabled ASIC, etc.) and associated memory (e.g., RAM, DRAM, NVRAM, FLASH, computer-readable media, etc.) that store instructions, wherein the programming (instructions) stored in the memory is executed on the processor to perform the steps of the various processing methods described herein.

For simplicity of illustration, the computer and memory devices are not depicted in the figures, as one of ordinary skill in the art will recognize that steps related to the operation and control of the wireless communication station are performed using computer devices, particularly in executing communication protocols. In terms of memory and computer readable media, the presented techniques are non-limiting as long as they are non-transitory and thus do not constitute transitory electronic signals.

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

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

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

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

It will also be appreciated that as used herein, the terms processor, computer processor, Central Processing Unit (CPU), and computer are used synonymously to refer to devices capable of executing instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, computer processor, CPU, and computer are intended to include single or multiple devices, single and multiple core devices, and variations thereof.

As will be appreciated from the description herein, the present disclosure encompasses multiple embodiments including, but not limited to, the following:

1. an apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured to wirelessly communicate with at least one other Wireless Local Area Network (WLAN) station in its reception area; (b) a processor coupled to the wireless communication circuitry within a station, configured to operate over a WLAN; and (c) a non-transitory memory storing instructions executable by the processor; (d) wherein the instructions, when executed by a processor, perform one or more steps comprising: (d) (ii) operating the wireless communication circuitry as a WLAN station configured to support communication of real-time application (RTA) packets that are sensitive to communication delay and non-real-time packets; (d) (ii) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets by pre-negotiation, or packet header information, or a combination of pre-negotiation and packet header information; (d) (iii) performing retransmission of non-real time application (non-RTA) packets using carrier sense multiple access/collision avoidance (CSMA/CA); and (d) (iv) performing retransmission of at least a portion of the real-time application (RTA) packet in response to bypassing the process of contending for channel access and/or without waiting for a notification to return from the recipient prior to channel access.

2. An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured to wirelessly communicate with at least one other Wireless Local Area Network (WLAN) station in its reception area; (b) a processor coupled to the wireless communication circuitry within a station, configured to operate over a WLAN; and (c) a non-transitory memory storing instructions executable by the processor; (d) wherein the instructions, when executed by a processor, perform one or more steps comprising: (d) (ii) operating the wireless communication circuitry as a WLAN station configured to support communication of real-time application (RTA) packets that are sensitive to communication delay and non-real-time packets; (d) (ii) transmitting the packet to the recipient and receiving a notification back from the recipient of packet success or packet error; (d) (iii) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets by pre-negotiation, or packet header information, or a combination of pre-negotiation and packet header information; (d) (iv) performing retransmission of non-real time application (non-RTA) packets using carrier sense multiple access/collision avoidance (CSMA/CA); (d) (v) performing a retransmission of at least a portion of a real-time application (RTA) packet in response to bypassing contention for channel access and/or without waiting for a notification to return from a recipient prior to channel access; and (d) (vi) terminating retransmission of a real-time application (RTA) packet when the packet lifetime expires.

3. A method of performing wireless communication, comprising: (a) operating the wireless communication circuitry as a WLAN station configured to support communication of real-time application (RTA) packets that are sensitive to communication delay and non-real-time packets; (b) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets by pre-negotiation, or packet header information, or a combination of pre-negotiation and packet header information; (c) performing retransmission of non-real-time application (non-RTA) packets using carrier sense multiple access/collision avoidance (CSMA/CA); and (d) performing a retransmission of at least a portion of the real-time application (RTA) packet in response to bypassing the process of contending for channel access and/or without waiting for a notification to return from the recipient prior to channel access.

4. A method of performing wireless communication, comprising: (a) identifying an RTA packet and a non-RTA packet in a wireless Station (STA); (b) scheduling retransmission of the RTA packet based on the lifecycle of the RTA packet in consideration of timeliness of the RTA traffic and the RTA packet having a specified transmission lifecycle; (c) separating the retransmission scheme of the RTA packet from the non-RTA packet, while the non-RTA packet can still be transmitted using any desired scheme, including the conventional retransmission scheme defined in CSMA/CA; (d) defining an immediate retransmission scheme for RTA traffic to minimize or eliminate channel contention time, thereby reducing RTA packet delay; and (e) wherein the method is compatible with OFDMA systems and by operating resource unit allocation with other adaptive machines including rate control, the transmission gains more diversity effect to increase packet delivery rate.

5. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform one or more steps comprising: a notification is received from the recipient of a packet success or packet error.

6. The apparatus or method of any preceding embodiment, the instructions when executed by the processor to perform the process of bypassing contended channel access in response to retransmitting a real-time application (RTA) packet without contending for channel access immediately upon receiving notification of the RTA packet from a recipient.

7. The apparatus or method of any preceding embodiment, wherein the station operates as an Access Point (AP) on the network; and wherein the instructions, when executed by a processor, perform one or more steps comprising: a subset of the subcarriers is assigned to a plurality of individual users.

8. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform the assigning the subset of subcarriers by utilizing Orthogonal Frequency Division Multiple Access (OFDMA).

9. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) and embed retransmission scheduling information into the notification.

10. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) utilizing separate resource blocks assigned by the AP.

11. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform one or more steps comprising: when a real-time application (RTA) packet lifetime expires, retransmission of the packet is terminated.

12. The apparatus or method of any preceding embodiment, wherein the notification comprises an Acknowledgement (ACK) indicating that the packet was received correctly and a Negative Acknowledgement (NACK) indicating that the packet was received in error.

13. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform one or more steps comprising: real-time application (RTA) packets are transmitted multiple times without waiting for a notification to be returned from the recipient.

14. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform one or more steps comprising: scheduling retransmission of real-time application (RTA) packets after initial transmission of the RTA packets.

15. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform steps further comprising: real-time application (RTA) packets are retransmitted using a lower bit rate Modulation and Coding Scheme (MCS) than at the initial transmission.

16. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform steps further comprising: retransmission of a second portion of a real-time application (RTA) packet is performed in response to performing collision avoidance without increasing a contention time window length.

17. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform the process of bypassing contention channel access in response to retransmitting real-time application (RTA) packets immediately without contention after receiving notification of a real-time application (RTA) packet error from a recipient.

18. The apparatus or method of any preceding embodiment, wherein the station operates as an Access Point (AP) on the network; and wherein the instructions, when executed by a processor, perform one or more steps comprising: a subset of the subcarriers is assigned to a plurality of individual users.

19. The apparatus of claim 16, wherein the instructions, when executed by the processor, perform the assigning the subset of subcarriers by utilizing Orthogonal Frequency Division Multiple Access (OFDMA).

20. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) and embed retransmission scheduling information into the notification.

21. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform Orthogonal Frequency Division Multiple Access (OFDMA) utilizing separate resource blocks assigned by the AP.

22. The apparatus or method of any preceding embodiment, wherein the notification comprises an Acknowledgement (ACK) indicating that the packet was received correctly and a Negative Acknowledgement (NACK) indicating that the packet was received in error.

23. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform one or more steps comprising: real-time application (RTA) packets are transmitted multiple times without waiting for a notification to be returned from the recipient.

24. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform one or more steps comprising: scheduling retransmission of real-time application (RTA) packets after initial transmission of the RTA packets.

25. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform steps further comprising: real-time application (RTA) packets are retransmitted using a lower bit rate Modulation and Coding Scheme (MCS) than at the initial transmission.

26. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, perform steps further comprising: retransmission of a second portion of a real-time application (RTA) packet is performed in response to performing collision avoidance without increasing a contention time window length.

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

As used herein, the term "group" refers to a collection of one or more items. Thus, for example, a group of items may include a single item or multiple items.

As used herein, the terms "substantially" and "about" are used to describe and explain minor variations. When used in conjunction with an event or circumstance, the terms can refer to the exact instance in which the event or circumstance occurs, as well as instances in which it occurs similarly. When used in conjunction with a numerical value, the term can refer to a range of variation that is less than or equal to ± 10% of the numerical value, such as less than or equal to ± 5%, less than or equal to ± 4%, less than or equal to ± 3%, less than or equal to ± 2%, less than or equal to ± 1%, less than or equal to ± 0.5%, less than or equal to ± 0.1%, or less than or equal to ± 0.05%. For example, "substantial" alignment may refer to a range of angular variation of less than or equal to ± 10 °, such as less than or equal to ± 5 °, less than or equal to ± 4 °, less than or equal to ± 3 °, less than or equal to ± 2 °, less than or equal to ± 1 °, less than or equal to ± 0.5 °, less than or equal to ± 0.1 °, or less than or equal to ± 0.05 °.

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

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

The phrase construct (such as "A, B and/or C") within the present disclosure describes any combination in which A, B or C, or items A, B and C, may be present. A construct indicating a group of elements such as "at least one" followed by a listing of elements indicates the presence of at least one of the group elements, including any possible combination of the listed elements (where applicable).

Reference in the specification to "an embodiment," "at least one embodiment," or similar embodiment language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the various embodiment phrases do not necessarily all refer to the same embodiment, or to particular embodiments that differ from all other described embodiments. The embodiments language should be construed to mean that a particular feature, structure, or characteristic of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method.

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

TABLE 1

Header information for identifying RTA traffic on the transmitter side

Layer(s)	Header information
		APP	RTA session id, RTA session name, signature
Transmission of	TCP/UDP port number
		Network	IP address of source and destination, type of service