Edca queue for rta packets

Abstract

A wireless local area network (WLAN) uses enhanced distributed channel access (EDCA) in an EDCA queue system to support real-time application (RTA) packets, which are delay sensitive, and non-RTA packets on a network supporting carrier sense multiple access / collision avoidance (CSMA / CA). At least one new access category (AC) and associated transmit queue is created to queue RTA packets, while non-RTA packets are queued to the original transmit queues in the EDCA queue system. A new EDCA function (EDCAF) is created for the new access category (AC) transmit queue for RTA packets, where the RTA queue is able to contend for the channel before the expected RTA packet arrives.

Description

[0001] REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Patent Application Serial No. 17 / 099,261, filed November 16, 2020, which is incorporated by reference herein in its entirety. This application also claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 013,776, filed April 22, 2020, which is incorporated by reference herein in its entirety.

[0003] STATEMENT REGARDING FEDERALLY ASSISTED RESEARCH AND DEVELOPMENT

[0004] NOT APPLICABLE

[0005] STATEMENT AS TO COPYRIGHT

[0006] A portion of the material in this patent document is subject to copyright protection under the copyright laws of the United States and other countries. The owner of the copyright rights has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the United States Patent and Trademark Office publicly available file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner hereby TECHNICAL FIELD

[0007] The technology of the present disclosure relates generally to wireless network communications, and more specifically to prioritizing real-time application packets communicated over a wireless network. BACKGROUND

[0008] Current wireless technologies using CSMA / CA focus on high throughput network performance but do not support enhanced low latency capabilities. This creates a large technical gap because more and more applications, such as real-time applications (RTAs), require low latency performance but are being transmitted over protocols that are designed only to achieve high throughput levels.

[0009] Data generated by an RTA is referred to as RTA traffic and will be packetized at a transmitter station (STA) as an RTA packet. Additionally, data generated by a non-time sensitive application is referred to as non-RTA traffic and will be packetized at a transmitter STA as a non-RTA packet.

[0010] RTA packets require low latency due to the high and timely delivery requirement of RTA packets. An RTA packet is typically valid only if it is delivered within a certain time period. In carrier sense multiple access / collision avoidance (CSMA / CA) wireless technology, a STA can use enhanced distributed channel access (EDCA) to give higher priority to high priority traffic, thus increasing the probability of sending earlier than low priority traffic. However, these prior arts still cannot meet the timeliness requirement of RTA packets because they cannot minimize the latency of sending RTA packets.

[0011] Thus, there is a need to handle RTA packets with reduced latency. The present disclosure meets this need and provides additional benefits over the prior art. SUMMARY

[0012] The present disclosure separates the sending queue of RTA packets from the sending queue of non-RTA packets, while non-RTA packets can still use the regular sending queue defined in the enhanced distributed channel access (EDCA) queue system of IEEE 802.11.

[0013] A station (STA) is able to distinguish between RTA packets and non-RTA packets, and RTA packets are given higher priority than other packets except network control (NC) packets. Thus, RTA packets will typically be sent earlier than other packets except NC packets. If there is an internal access conflict for an RTA packet with an NC packet within the station, the NC packet gets channel access. Otherwise, the RTA packet gets channel access when there is an internal access conflict.

[0014] The presently disclosed protocol does not increase the contention window of RTA packets when there is an access conflict, so that RTA packet retransmission does not incur further latency penalty. In addition, when contending for channel access for an RTA packet, the contention can be done / started before the RTA packet arrives from the upper layer (e.g., application layer) of the protocol.

[0015] In the following parts of the specification, other aspects of the technology described herein will be presented, in which detailed explanations are used to fully disclose preferred embodiments of the technology, rather than to limit them. BRIEF DESCRIPTION OF DRAWINGS

[0016] The technology described herein will be more fully understood from the following detailed description, taken in conjunction with the accompanying drawings, in which:

[0017] FIG. 1 is a queue flow diagram of a reference model of enhanced distributed channel access (EDCA) queues in IEEE 802.11.

[0018] Figure 2is a hardware block diagram of a wireless station hardware in accordance with at least one embodiment of the present disclosure.

[0019] Figure 3 is a network topology diagram, shown as an example and not a limitation, as a multi- basic service set (BSS) scenario, each BSS having one access point (AP) and multiple stations (STAs), in accordance with at least one embodiment of the present disclosure.

[0020] Figure 4 is a data field diagram of a RTA traffic specification (TSPEC) element in accordance with at least one embodiment of the present disclosure.

[0021] Figure 5 is a data field diagram of a RTA traffic stream (TS) element in accordance with at least one embodiment of the present disclosure.

[0022] Figure 6 is a communication sequence diagram between a system management entity (SME) layer and a medium access control (MAC) layer in a non-AP station and between a system management entity (SME) layer and a medium access control (MAC) layer in an AP station, in accordance with at least one embodiment of the present disclosure.

[0023] Figure 7 is a queue flow diagram of an enhanced (augmented) EDCA queue system in accordance with at least one embodiment of the present disclosure.

[0024] Figure 8A and Figure 8B is a flow diagram of a low latency (LL) EDCA function (LLEDCAF) in accordance with at least one embodiment of the present disclosure.

[0025] Figure 9 is a flow diagram of an internal collision avoidance mechanism within an enhanced EDCA queue system in accordance with at least one embodiment of the present disclosure.

[0026] Figure 10 is a communication sequence diagram representing a case where a STA gains channel access to transmit a RTA packet in accordance with at least one embodiment of the present disclosure.

[0027] Figure 11 is a communication sequence diagram representing a case where a RTA transmission is not allowed to start due to an internal collision in accordance with at least one embodiment of the present disclosure.

[0028] Figure 12 is a communication sequence diagram representing a case where a RTA transmission is allowed to start when an internal traffic collision occurs in accordance with at least one embodiment of the present disclosure.

[0029] Figure 13is a queue flow diagram of a first implementation of an enhanced EDCA queue system that supports low latency RTA packet traffic in accordance with at least one embodiment of the present disclosure.

[0030] Figure 14 is a queue flow diagram of a second implementation of an enhanced EDCA queue system that supports low latency RTA packet traffic in accordance with at least one embodiment of the present disclosure.

[0031] Figure 15 is a flow diagram of a station determining from which transmit queue in a VO access class a packet will be transmitted in accordance with at least one embodiment of the present disclosure.

[0032] Figure 16 is a flow diagram of a station determining from which transmit queue in a VI access class a packet will be transmitted in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION

[0033] 1. Introduction to the Reference Model EDCA Queue System

[0034] EDCA is defined in the IEEE 802.11e standard to meet Wi-Fi quality of service (QoS) requirements. It classifies traffic into different access categories (ACs) according to priority. Higher priority ACs have shorter average channel contention times, enabling their traffic to access the channel more frequently. Each AC has its own transmit queue to order packets in the queue for transmission. When there is a large amount of traffic in an AC, the packets in the queue have to wait to get channel access one by one. The waiting time of packets in the queue can be quite large, resulting in increased packet latency.

[0035] Figure 1 illustrates the reference model of the EDCA queue system in IEEE 802.11. The system contains six transmit queues in four access categories (ACs). Each AC uses the EDCA function (EDCAF) to contend for channel access when transmitting packets from its corresponding transmit queue.

[0036] The six transmit queues are voice (VO), alternate voice (A_VO), alternate video (A_VI), video (VI), best effort (BE), and background (BK). Each transmit queue decides the transmission order of packets in the queue.

[0037] The four ACs are voice (VO), video (VI), best effort (BE), and background (BK). Each AC has an EDCA function (EDCAF) to provide channel contention functionality. An internal collision avoidance mechanism is used when multiple EDCA tries to access the channel at the same time. When an internal collision occurs, the higher priority EDCAF gets channel access.

[0038] Table 1 lists the UP-to-AC (UP-to-AC) mapping used in the EDCA queues of IEEE 802.11. The second and third columns represent the user priority of the traffic and its corresponding designation in IEEE 802.1D. In each row, the traffic will be queued in the corresponding transmit queue and access category in order of user priority. The priority increases from the top row to the bottom row. The higher the priority, the higher the probability that the traffic will be transmitted earlier.

[0039] 2. Problem Statement

[0040] Current wireless communication systems using CSMA / CA do not differentiate between RTA packets and non-RTA packets, and all packets use the same random channel access scheme according to CSMA / CA.

[0041] The EDCA queue system based on CSMA / CA classifies traffic flows into different ACs according to priority. On average, higher priority packets have shorter backoff times to access the channel earlier compared to lower priority packets. However, it is not guaranteed that higher priority packets are always transmitted first, especially when RTA packet traffic needs the channel.

[0042] The EDCA queue system based on CSMA / CA does not consider the worst-case delay of packet transmission. The waiting time of packets in the current queue system can significantly affect the worst-case delay.

[0043] 3. Contributions of the Disclosure

[0044] To reduce the RTA packet delay caused by the queue system, the present disclosure adds at least one new transmit queue in the EDCA queue system that is dedicated only to RTA packets. Due to the coexistence of RTA traffic and non-RTA traffic, the task of adding an RTA transmit queue in the EDCA queue system is more challenging. The challenges in this process can be summarized as: (1) distinguishing between RTA packets and non-RTA packets; (2) pushing RTA packets into the RTA transmit queue and non-RTA packets into the non-RTA transmit queue (i.e., the EDCA queue); (3) coordinating channel access between the RTA and non-RTA transmit queues; and (4) handling internal conflicts between queues trying to gain access to the channel.

[0045] The use of one or more RTA transmit queues takes into account the time-critical nature of RTA traffic and minimizes its delay by reducing the waiting time of RTA traffic in the transmit queue, where RTA traffic and non-RTA traffic coexist in a wireless network.

[0046] By utilizing the proposed techniques, the STA is able to differentiate between RTA packets and non-RTA packets, and separate the transmission queues for RTA packets and non-RTA packets, while non-RTA packets can still use the regular transmission queues defined in the EDCA queue system of IEEE 802.11.

[0047] The present disclosure provides RTA packets with higher priority compared to other packets except for network control (NC) packets. That is, RTA packets are given a higher probability of being transmitted earlier compared to other packets except for NC packets. If there is an internal collision between an RTA packet and an NC packet, the NC packet gains channel access. Otherwise, when an internal collision occurs, the RTA packet gains channel access.

[0048] The present disclosure is configured to not increase the contention window of RTA packets when the RTA packets are prevented from being transmitted due to an internal collision. The present disclosure is configured to allow channel access to be fought for before the RTA packet arrives in order to transmit the RTA packet.

[0049] 4. Station embodiments and topologies

[0050] 4.1. STA hardware embodiments

[0051] Figure 2 An example embodiment 10 of a WLAN station is illustrated with external I / O 14 of bus 16 having an entering station circuit 12 with a CPU 18 and RAM 20 for executing a wireless network communication protocol and for storing data. The host 12 houses at least one modem 22 coupled to at least one RF module 24, 28 connected to one or more antennas 26a, 26b, 26c ~ 26n and 29 for communicating, such as on a sub-6 GHz (6 GHz and below) band (e.g., 2.4, 5, 6 GHz), and / or through millimeter wavelengths (mmW). In the example shown, the RF antenna 29 is an omni-directional antenna. For example, the RF module 24 is shown with multiple antennas to support beamforming for transmitting and receiving on the band. In this way, the STA can use multiple sets of beam patterns to transmit signals. It should be appreciated that while the example illustrates sub-6 GHz communications, the teachings of the present disclosure can support any desired band.

[0052] Bus 14 allows various devices to be connected to the CPU, such as to sensors, actuators, etc. Instructions from memory 20 are executed on processor 18 to execute a program that implements a communication protocol, the execution of which enables the STA to function as an Access Point (AP) station or a non-AP (regular) station (STA). It should also be appreciated that the programming is configured to operate in different modes (source, transmitter, intermediary, destination, receiver, first AP, other AP, non-AP station associated with the first AP, station associated with the other AP, coordinator, co-ordinated, etc.) depending on its role in the current communication context.

[0053] 4.2. Network Topology Example

[0054] Figure 3 A network scenario (topology) 30 is illustrated, which is used by way of example and not limitation for the following operational discussion of the present disclosure. The scenario provides a topology to help explain the operations described herein, without limiting the use of the teachings herein to any particular network scenario.

[0055] In this example scenario, a region 32, here depicted as a room (e.g., a conference room), or a similar compartment of a building, or an interior of a building, can be seen, which can also have openings (e.g., doors / windows) 34 that are not relevant to the present description. In the scenario of the present disclosure, there are at least one Basic Service Set (BSS) and associated stations (STAs). This particular example represents two BSSs. A first BSS is depicted with STA0 36 as an AP and STA1 38, STA2 40, STA3 42, and STA4 44 as associated non-AP STAs. A second BSS is represented with STA5 46 as an AP and STA6 48 and STA7 49 as non-AP STAs. Each STA can communicate with other STAs in the same BSS. All STAs can use CSMA / CA for random channel access.

[0056] All STAs in this example are considered to execute (run) both applications that require low latency communication and applications that utilize best effort communication. Data generated by applications that require low latency communication is referred to as RTA traffic and is packetized as RTA packets at the transmitter STA; while data generated by non-time sensitive applications is referred to as non-RTA traffic and is packetized as non-RTA packets at the transmitter STA. Thus, a transmitter STA is considered to generate both RTA and non-RTA traffic for communication. The locations of the STAs and their transmission links are as shown.

[0057] STA uses EDCA to queue RTA and non-RTA packets into different transmit queues and contend for the channel for each transmit queue. STA increases one or more transmit queues in EDCA to queue only RTA packets. RTA packets are queued into transmit queues for RTA packets only, while non-RTA packets are queued into original transmit queues in EDCA.

[0058] 5. RTA traffic classification

[0059] 5.1. RTA information element

[0060] Figure 4 An example embodiment 50 illustrating the contents in RTA traffic specification (TSPEC) element is shown. The STA sending the RTA-TSPEC element during the RTA-TS setup procedure is denoted as the sender STA. The RTA-TSPEC element has the following fields.

[0061] (a) The element ID field indicates the type of element, here exemplified as the RTA-TSPEC element.

[0062] (b) The length field indicates the length of the RTA-TSPEC element.

[0063] (c) The RTA-TS info field contains the traffic stream information as shown in Figure 5

[0064] (d) The nominal MSDU size field as defined in TSPEC element in IEEE 802.11 can be set by the AP or non-AP STA to indicate the nominal size of MSDU or A-MSDU belonging to the traffic stream (TS) under this RTA-TSPEC. When the AP receives this field, it can use this field to schedule transmissions to meet the QoS requirement of this RTA-TS. As an example and not limitation, the nominal number of MSDU or A-MSDU belonging to the TS under this RTA-TSPEC generated per second can be calculated by the average data rate divided by the nominal MSDU size; it can be used to determine the average overhead (e.g., PLCP preamble, MAC header) required to transmit these MSDU or A-MSDU and estimate the total transmission time of this overhead.

[0065] ​(e) The Maximum MSDU Size field as defined in the TSPEC element in IEEE 802.11 can be set by the AP or non-AP STA to indicate the maximum size of MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. When the AP receives this field, it can use this field to schedule transmissions to meet the QoS requirements of the TS. As an example and not a limitation, the minimum number of MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC generated per second can be determined by the minimum data rate divided by the maximum MSDU size; it can be used to calculate the minimum overhead (e.g., PLCP preamble, MAC header) required to transmit these MSDUs or A-MSDUs and estimate the total transmission time of this overhead.

[0066] (f) The Minimum MSDU Size field can be set by the AP or non-AP STA to indicate the minimum size of MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. When the AP receives this field, it can use this field to schedule transmissions to meet the QoS requirements of the TS. As an example and not a limitation, the maximum number of MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC generated per second can be determined using the maximum data rate divided by the minimum MSDU size; it can be used to calculate the maximum overhead (e.g., PLCP preamble, MAC header) required to transmit these MSDUs or A-MSDUs and estimate the total transmission time of this overhead.

[0067] (g) The Minimum Data Rate field as defined in the TSPEC element in IEEE 802.11 can be set by the AP or non-AP STA to indicate the minimum data rate specified by the MAC Service Access Point (SAP) for transmitting MSDUs or A-MSDUs belonging to the RTA-TS under this RTA-TSPEC. When the AP receives this field, it can use its information to schedule transmissions to meet the QoS requirements of the TS. As an example and not a limitation, the minimum amount of data required to be transmitted per nominal service interval is given by (minimum data rate * nominal service interval). The minimum transmission time should be arranged by the STA to transmit the minimum amount of data during each nominal service interval.

[0068] (h) The Average Data Rate field, as defined in the TSPEC element in IEEE 802.11, can be set by the AP or non-AP STA to indicate the average data rate specified by the MAC Service Access Point (SAP) for transmitting MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. When the AP receives this field, it can use this information to schedule transmissions to meet the QoS requirements of the RTA-TS. By way of example and not limitation, the STA should ensure that it has sufficient available channel resources (e.g., bandwidth) to transmit data generated at the average data rate. In other words, the available bandwidth should be greater than the average data rate.

[0069] (i) The Peak Data Rate field, as defined in the TSPEC element in IEEE 802.11, can be set by the AP or non-AP STA to indicate the maximum data rate specified by the MAC SAP for transmitting MSDUs or A-MSDUs belonging to the RTA-TS under this RTA-TSPEC. When the AP receives this field, it can use information from this field to schedule transmissions to meet the QoS requirements of the TS. By way of example and not limitation, the maximum amount of data that needs to be transmitted per nominal service interval is (Peak Data Rate * Nominal Service Interval). The transmission time scheduled by the STA for transmitting packets belonging to the TS should be less than the time to transmit the maximum amount of data during each nominal service interval.

[0070] (j) The Burst Size field, as defined in the TSPEC element in IEEE 802.11, can be set by the AP or non-AP STA to indicate the maximum burst time for MSDUs or A-MSDUs belonging to the RTA-TS under this RTA-TSPEC to be generated consecutively at the peak data rate. When the AP receives this field, it can use information from this field to schedule transmissions to meet the QoS requirements of the RTA-TS. By way of example and not limitation, the current service interval will be shorter when a burst occurs. However, the service interval will not be shortened beyond the value given by (Peak Data Rate / Minimum Data Rate - 1) * Maximum Burst Size.

[0071] (k) The Service Start Time field, as defined in the TSPEC element in IEEE 802.11, can be set by the AP or non-AP STA to indicate the start time of the first service period (SP). When the AP receives this field, it can use information from this field to schedule transmissions to meet the QoS requirements of the TS. By way of example and not limitation, the STA can know when other STAs start generating data belonging to the TS under this RTA-TSPEC because the first service period (SP) should start at the service interval after the service start time.

[0072] (l) The service end time field can be set by the AP or non-AP STA to indicate the time at which the TS is deleted. When the AP receives this field, it can use the information in this field to schedule transmissions to meet the QoS requirements of the TS. As an example and not a limitation, the STA can determine when other STAs stop generating data belonging to the TS under this RTA-TSPEC because there will be no service period after the service end time.

[0073] (m) The inactivity interval field as defined in the TSPEC element in IEEE 802.11 can be set by the AP or non-AP STA to indicate the amount of time in which no MSDU arrival or transmission belonging to the TS is allowed before the TS is deleted. If no MSDU arrival or transmission belonging to the TS occurs within this inactivity interval, the AP or non-AP STA receiving this field deletes the active TS.

[0074] (n) The MSDU lifetime field can be set by the AP or non-AP STA to indicate the lifetime of MSDUs belonging to the TS under this RTA-TSPEC. If the deterministic service field is set to "1" and an MSDU or A-MSDU has not been successfully transmitted within its lifetime since it arrived at the MAC layer, the MSDU or A-MSDU should be discarded. If the traffic is periodic and the STA has not transmitted or received any MSDU or A-MSDU belonging to the TS under this RTA-TSPEC within the MSDU lifetime plus the maximum service interval, the receiver STA knows that at least one MSDU or A-MSDU is missing. The MSDU lifetime should be less than the inactivity interval but greater than the maximum service interval.

[0075] (o) The deterministic service field indicates whether a TS is generated for the RTA session. This field can be as short as 1 bit indication as shown in the example. When a TS is generated for the RTA session, then the field is set to the first state, e.g., "1"; otherwise, it is set to the second state, e.g., "0".

[0076] (p) The delay bound field as defined in the TSPEC element in IEEE 802.11 indicates the maximum time allowed to transmit an MSDU or A-MSDU belonging to the TS under this RTA-TSPEC since its arrival at the MAC. The non-AP sets this field to request the AP to guarantee the delay of the MSDU or A-MSDU belonging to the TS under this RTA-TSPEC. The AP receives this field and estimates whether it can meet the request. The AP sets this field to indicate the delay bound it can provide. When the non-AP STA receives this field, it either accepts the delay bound provided by the AP or renegotiates with the AP.

[0077] (q) The reliability field indicates the packet loss requirement for MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. The non-AP sets this field to request the AP to guarantee the packet loss for MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. The AP receives this field and estimates whether it can meet the request. The AP sets this field to indicate the packet loss it can provide. When the non-AP receives this field, it either accepts the reliability provided by the AP or renegotiates with the AP.

[0078] (r) The jitter field indicates the jitter requirement for the delivery of MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. The non-AP sets this field to request the AP to guarantee the jitter requirement for MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. The AP receives this field and estimates whether it can meet the request. To meet the request, the difference between the maximum service interval and the minimum service interval should be less than the jitter value. The AP sets this field to indicate the jitter requirement it can provide. When the non-AP receives this field, it either accepts the jitter provided by the AP or renegotiates with the AP.

[0079] (s) The nominal service interval field indicates the nominal / average time between the start times of two consecutive SPs. This field is valid when the traffic type subfield in the RTA-TS information is set to the first state (e.g., "1"). The non-AP sets this field to request the AP to guarantee that the service intervals for MSDUs or A-MSDUs belonging to the TS are per the RTA-TSPEC. The AP receiving this field can estimate whether it can meet the request. The AP sets this field to indicate the nominal service interval it can provide. When the non-AP receives this field, it either accepts the jitter provided by the AP or renegotiates with the AP.

[0080] (t) The minimum service interval field, as defined in the TSPEC element in IEEE 802.11, is set by the AP to indicate the minimum time between the start times of two consecutive service periods (SPs). The non-AP receiving this field will expect the time between the start times of two consecutive SPs to be greater than the minimum service interval. This field should of course contain a value corresponding to a time interval shorter than the one given by the nominal service interval.

[0081] (u) The maximum service interval field, as defined in the TSPEC element in IEEE 802.11, is set by the AP to indicate the maximum time between the start times of two consecutive SPs. The non-AP receiving this field will expect the time between the start times of two consecutive SPs to be less than the maximum service interval. This field should contain an interval value greater than the nominal service interval.

[0082] (v) The Minimum PHY Rate field as defined in the TSPEC element in IEEE 802.11 is set by the AP to indicate the lowest PHY rate used to transmit MSDUs or A-MSDUs belonging to the RTA-TS under this RTA-TSPEC. Non-APs receiving this field will not transmit MSDUs or A-MSDUs belonging to the RTA-TS under this RTA-TSPEC with a PHY rate lower than the minimum PHY rate.

[0083] (w) The Excess Bandwidth Allowance field as defined in the TSPEC element in IEEE 802.11 is set by the AP to indicate the ratio of the bandwidth used to transmit MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC and their retransmissions to the bandwidth used to transmit the MSDU or A-MSDU once at the minimum PHY rate. Non-APs receiving this field can use the extra bandwidth indicated in this field for their retransmissions.

[0084] (x) The Medium Time field as defined in the TSPEC element in IEEE 802.11 is set by the AP to indicate the time allowed to access the medium in each nominal service interval for transmitting MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. Non-APs receiving this field will use the medium time in each nominal service interval for transmitting MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC. This time should guarantee the time to transmit at the minimum PHY rate all MSDUs or A-MSDUs belonging to the TS under this RTA-TSPEC generated in each nominal service interval.

[0085] Figure 5 Figure illustrates an example embodiment 60 of the RTA-TS information subfield contained in the RTA-TSPEC element shown in Figure 4 Figure 1. The RTA-TS information field contains traffic flow information with the following subfields.

[0086] (a) The Traffic Type subfield is used by the STA to set this subfield to a first state, e.g., "1", to indicate that the traffic is periodic; otherwise, the subfield is set to a second state, e.g., "0", to indicate that the traffic is not periodic. If the STA receives this subfield set to the first state, e.g., "1", through the RTA-TSPEC element, it can use the nominal service interval in the RTA-TSPEC element to represent the average interval of two consecutive service periods.

[0087] (b) The TSID subfield as defined in the TS Info field of the TSPEC element in IEEE 802.11 is used by the STA to set the ID number to identify the RTA-TS. For example, this field can be set to 0-15 to indicate the TID of the traffic belonging to the TS under the RTA-TSPEC element.

[0088] (c) The Direction subfield is used by the STA to set this subfield to indicate whether the direction of data transmission of the RTA-TS is uplink, downlink, direct link, or bidirectional link. If the STA receives this subfield, it only needs to measure the link in the indicated direction for TS setup.

[0089] (d) The Access Policy subfield is used by the STA to set this subfield to indicate the method to obtain channel access, such as EDCA or other methods. When the STA receives this subfield, it shall follow the access policy to obtain channel access for data transmission of the RTA-TS. It is possible that when the access policy is EDCA, the TSID field can be set to 0-15 to indicate the TID.

[0090] (e) The Aggregate subfield indicates whether this subfield is valid, which only occurs when the Schedule field is set to the first state (e.g., "1") and the Access Policy subfield is set to EDCA, otherwise the field is set to the second state, e.g., "0". This subfield can be as small as 1 bit indication, as shown in the example, or can be a larger data structure. If the STA is the non-AP originator of the RTA-TS setup, it sets this field to the first state, e.g., "1", to request aggregate scheduling, or sets this field to the second state, e.g., "0", to not request aggregate scheduling; and the receiver STA decides whether to provide this service. If the STA is the AP, it sets this field to the first state, e.g., "1", to provide aggregate scheduling, or it sets this field to the second state, e.g., "0", to not provide aggregate scheduling, and the receiver STA shall follow the decision made by the AP.

[0091] (f) The APSD subfield provides an indicator, such as 1 bit indication, to indicate whether to use automatic power save delivery (PS). When this subfield is set to the first state (e.g., "1"), then the MSDUs or A-MSDUs belonging to the RTA-TS are transmitted with automatic PS delivery, otherwise the subfield is set to the second state, e.g., "0".

[0092] (g) RTA Priority subfield indicates the RTA priority of the MSDU or A-MSDU belonging to the RTA-TS. RTA priority can only be used to compare the importance between RTA packets. It is different from the user priority defined in IEEE 802.1D. All RTA packets can share the same IEEE 802.1D user priority.

[0093] (h) TSInfo ACK Policy subfield indicates whether an acknowledgement (ACK) is needed and which form of ACK will be utilized. For example, in at least one embodiment, it can have options such as selecting a normal ACK, no ACK, or block ACK (BA). The STA sets this subfield to share this information with other STAs.

[0094] (i) Retry Policy subfield indicates how the MSDU or A-MSDU belonging to the RTA-TS will be retransmitted. For example, this field can be implemented as a 1-bit indication to indicate whether unsolicited retries will be used. If unsolicited retries are allowed, the sender STA sets this subfield to a first state, e.g., "1", otherwise sets this subfield to a second state, e.g., "0". The receiver STA can follow the retry policy.

[0095] (j) Scheduling subfield provides an indication such as a 1-bit indication to indicate whether the transmission of the MSDU or A-MSDU belonging to the RTA-TS is scheduled. If the transmission is scheduled, the sender sets this subfield to a first state, e.g., "1"; otherwise sets this subfield to a second state, e.g., "0". The receiver STA is configured to follow the scheduling to transmit or receive the MSDU or A-MSDU belonging to the RTA-TS.

[0096] When the sender STA transmits the RTA-TSPEC element in the ADDRTATS Request frame, it sets the fields in the RTA-TSPEC element that represent the specification and QoS requirements of the RTA-TS. The sender STA is configured to set all the fields in the RTA-TSPEC element except the fields between the spare bandwidth allowed field and the medium time field. The receiver STA that receives the ADDRTATS Request frame can evaluate whether it has enough resources to meet the requirements of the RTA-TS using the parameters of the fields in the element. If the requirements can be met, the receiver can accept the RTA-TS setup; otherwise, the receiver STA should reject the RTA-TS setup.

[0097] When the sender STA sends the RTA-TSPEC element in the ADDRTATS response frame and the RTA-TS setup is accepted, the sender STA shall set all fields in the RTA-TSPEC element. The parameters of the fields in the RTA-TSPEC element represent the final parameter settings in the RTA-TSPEC element for the RTA-TS between the originator STA and the recipient STA.

[0098] When the sender STA sends the element in the ADDRTATS response frame and the RTA-TS setup is rejected with suggested changes, in at least one embodiment, the sender STA sets all fields in the RTA-TSPEC element except the fields between the excess bandwidth allowed field and the medium time field. The parameters of the fields in the RTA-TSPEC element represent the suggested parameter settings in the RTA-TSPEC element for the RTA-TS. The recipient STA can use the suggested RTA-TSPEC element to request another RTA-TS setup.

[0099] When the sender STA sends the RTA-TSPEC element in the ADDRTATS reservation request frame, the parameters of the fields in the RTA-TSPEC element represent the specification and requirements of the RTA-TS requested from the upper layer. The recipient STA shall continue the RTA-TS setup procedure and set the same parameters of the RTA-TSPEC element in its ADDRTATS request frame.

[0100] It should be appreciated that other data structures can be used to convey the information needed to differentiate RTA traffic from non-RTA traffic, as well as the other functions described above, without departing from the teachings of the present disclosure.

[0101] 5.1.2. Example of using RTA traffic classification

[0102] Figure 6 An example embodiment 70 illustrating the message exchange with RTA traffic classification is shown. RTA traffic can be classified during the setup of an RTA traffic stream (RTA-TS). The figure shows an example of the message exchange between two STAs when an originator non-AP STA initiates an RTA traffic stream (RTA-TS) setup procedure with a recipient STA. The RTA-TS setup procedure can be the same as the TS setup in IEEE 802.11, except that the RTA-TS uses the RTA-TSPEC element during the procedure, while the TS uses the TSPEC element. The RTA-TS can be considered as a dedicated TS for RTA traffic.

[0103] (1) The initiator STA, which is exemplified as but not limited to a non-AP STA, decides to initiate a RTA-TS setup procedure with a recipient STA, which is exemplified in this case as an AP or a non-AP STA. The SME 72 of the initiator STA performing the loop 80 sends an MLME-ADDRTATS.request message 82 to its MAC 74. When the MAC of the initiator STA receives the MLME-ADDRTATS.request message, it collects the information in the MLME-ADDRTATS.request message and sends an ADDRTATS request frame 84 to the MAC 76 of the recipient STA. The MAC of the recipient STA receives the frame and generates an MLME-ADDRTAT.indication message 86 to its SME 78.

[0104] (2) Subsequently, the SME of the recipient STA sends an MLME-ADDRTATS.response message 88 containing the result of the RTA-TS setup to its MAC 76. Then, the MAC of the recipient STA sends an ADDRTATS response frame 90 to the MAC 74 of the initiator STA. The MAC of the initiator STA receives the frame and sends an MLME-ADDRTAT.confirm message 92 to its SME 72. Then, the initiator knows whether the RTA-TS setup is successful or not.

[0105] (3) If the RTA-TS setup fails, the initiator STA can receive the suggested parameters of the RTA-TSPEC element from the ADDRTATS response frame. The initiator STA can repeat the procedure as explained in steps 1 and 2 to re-negotiate the RTA-TS setup. This loop can happen multiple times. If the RTA-TS setup fails while there are no suggested parameters of the RTA-TSPEC element from the ADDRTATS response frame, the TS setup fails and no further negotiation is allowed.

[0106] (4) The messages used in the RTA-TS setup procedure can be the same as those used in the TS setup, except that the TSPEC element is replaced by the RTA-TSPEC element.

[0107] When a RTA-TS is setup, traffic can be classified by matching the TCLAS information of the RTA-TS. When traffic belongs to a RTA-TS, it is RTA traffic. The user priority of the RTA traffic can be indicated by the RTA-TS to which the traffic belongs. When a RTA-TS is setup, the user priority of the RTA traffic can be set in the UP field of the TCLAS element in the ADDRTATS request / response frame. Otherwise, the traffic is non-RTA traffic.

[0108] 6. Reference Model

[0109] Figure 7 An example embodiment 110 of a reference model illustrating the RTA enhanced EDCA queue system. The queue system receives MSDUs including their UP and RTA (e.g., an indication indicating whether the MSDU is an RTA packet) information 112 to a mapping function 114 of transmission queues and access categories, and the queue system consists of seven transmission queues in five access categories (ACs), each access category (AC) having an EDCA function (EDCAF) 132, 134, 136, 138, and 140 for the access channel 142.

[0110] The seven transmission queues are RTA voice (R_VO) 116, voice (VO) 118, alternate voice (A_VO) 120, alternate video (A_VI) 122, video (VI) 124, best effort (BE) 126, and background (BK) 128. Each transmission queue decides the order of transmission of packets in its queue.

[0111] The five ACs are low latency (LL), voice (VO), video (VI), best effort (BE), and background (BK). Each AC has an EDCA function (EDCAF) to provide the function of channel contention.

[0112] When RTA and non-RTA traffic (i.e., MSDUs as shown in the figure) arrives, the traffic is mapped to transmission queues based on user priority (UP) and RTA information (e.g., an indication indicating whether the traffic is RTA). The enhanced EDCA queue system can use traffic to AC mapping option 1 or option 2 as listed in Table 2 and Table 3, respectively.

[0113] The R_VO transmission queue uses the LL EDCAF to gain channel access as explained in Figure 8A and Figure 8B The VO and A_VO transmission queues use the VO EDCAF to gain channel access. The VI transmission queue uses the VI EDCAF to gain channel access. The VO and A_VO transmission queues use the VO EDCAF to gain channel access. The BE transmission queue uses the BE EDCAF to gain channel access. The BK transmission queue uses the BK EDCAF to gain channel access.

[0114] EDCFs can gain channel access at the same time and internal collision occurs. There is an internal collision avoidance mechanism to avoid interval collision between EDCFs as explained later in Figure 9 .

[0115] 6.1. Traffic to AC mapping (option 1)

[0116] Table 2 lists Option 1 for traffic to AC mapping. We assume that all RTA traffic is marked as UP 6 only. When traffic with UP 6 is RTA, then the traffic is queued in the R_VO transmit queue and uses LL EDCAF for channel contention. For example, traffic belonging to RTA-SP with user priority 6 indicated in the TCLAS element and using EDCA channel access can be queued to the R_VO transmit queue. Non-RTA traffic uses the same traffic to AC mapping as defined in IEEE 802.11 protocol.

[0117] As shown in the table, RTA traffic has higher priority than voice (VO) traffic specified in IEEE 802.1D and has lower priority than network control (NC) traffic specified in IEEE 802.1D.

[0118] 6.2. UP and RTA to AC mapping (Option 2)

[0119] Table 3 lists Option 2 for traffic to AC mapping. We assume that RTA traffic can be marked as any UP. When traffic is RTA, then the traffic is queued in the R_VO transmit queue and uses LL EDCAF for channel contention. For example, traffic belonging to RTA-TS and using EDCA channel access is queued in the R_VO transmit queue. Non-RTA traffic uses the same traffic to AC mapping as defined in IEEE 802.11 protocol. As shown in the table, RTA traffic has higher priority than voice (VO) traffic specified in IEEE 802.1D and has lower priority than network control (NC) traffic specified in IEEE 802.1D. The UP of RTA traffic can be used as the internal access category priority.

[0120] 6.3. Low latency EDCAF

[0121] Low latency EDCA function (LL EDCAF) is the channel contention function for packets in the R_VO transmit queue. CW[LL] represents the contention window size for the LL EDCAF. CWmin[LL] represents the minimum contention window size for the LL EDCAF. CWmax[LL] represents the maximum contention window size for the LL EDCAF. In at least one or more embodiments, the sizes of CWmin[LL] and CWmax[LL] can be made the same as the minimum and maximum contention window sizes of the VO EDCAF, respectively.

[0122] Figure 8A and Figure 8B Figure illustrates an example embodiment 150 of performing LL EDCAF channel contention to transmit a packet from the LL transmit queue. The process starts at 151. Figure 8ACW[LL] is reset to CWmin[LL] at 156, and the retry count is reset to 0. It should be noted that when the LL EDCAF contends for the channel without a packet having arrived, the LL queue will be empty at this time. The LL EDCAF then begins contending for the channel and counting down the backoff time at 158.

[0123] A check is made at 160 to determine whether the packet has arrived before the LL EDCAF counts its backoff down to 0. If the packet has not arrived, then in at least one embodiment, execution returns to block 156, and the LL EDCAF resets its contention window to CWmin[LL] and restarts the backoff. Otherwise, if the packet has arrived before the LL EDCAF counts the backoff time down to 0, then execution transfers to block 162, and the LL EDCAF checks for internal collisions with other EDCAFs. With respect to Figure 3 The process of the internal collision check is explained. After the LL EDCAF checks for internal collisions with other EDCAFs, then a check is made at 164 to determine whether the LL EDCAF will gain channel access. If it does not gain channel access, then execution returns to block 158, where the STA is illustrated as restarting the backoff without changing its contention window size. Otherwise, if it does gain channel access, then execution transfers to Figure 8B block 168 in FIG. 1, the STA transmits the packet from the R_VO transmit queue. A check is made at 170 to determine whether the packet transmission was successful. If the packet transmission was successful, then the end 176 is transmitted. Otherwise, it can be seen that execution transfers to block 172, where the STA increments its retry count for this packet, such as by 1. A check is made at 174 to determine whether the retry count exceeds the retry limit. If the retry limit is exceeded, then the packet is discarded, and execution transfers to the end 176. Otherwise, if the retry limit is not exceeded, then execution transfers to Figure 8A block 166 in FIG. 1, and the LL EDCAF doubles the contention window size until the contention window size reaches CWmax[LL], and contends for the channel again at block 158.

[0124] 6.4. Internal collision avoidance for the LL EDCAF

[0125] Figure 9Figure 13 illustrates an example embodiment 190 of the enhanced EDCA queue system internal collision avoidance mechanism. Execution begins at 192, and then a check is made at 194 to determine if the LL EDCAF is involved in an internal collision. If the STA is not involved in an internal collision, then execution can proceed to block 200 to follow the IEEE 802.11 EDCA queue internal collision avoidance mechanism.

[0126] If at block 194 the LL EDCAF is involved in an internal collision, then a check is made at block 196 to determine if the R_VO transmit queue is empty. If the R_VO transmit queue is empty, then execution proceeds to block 198 where the LL EDCAF does not gain channel access, and execution proceeds to block 200 to follow the original IEEE 802.11 EDCA queue internal collision avoidance mechanism.

[0127] However, if the LL EDCAF is involved in an internal collision and the R_VO queue is not empty, then execution proceeds to block 202 to check if the collision is between the LL and the VO. If the collision is not a collision with the VO, and the R_VO transmit queue is not empty, then execution proceeds to block 208 where the LL EDCAF gains channel access, and processing ends at 210.

[0128] If at block 202 it is determined that the LL EDCAF is involved in an internal collision with the VO EDCAF, and the R_VO transmit queue is not empty, then execution proceeds to block 204 to check what type of packet the VO EDCAF is trying to transmit. If the VO EDCAF is trying to transmit a network control (NC) packet, then execution proceeds to block 206 where the VO EDCAF gains channel access. Otherwise, if the VO is not contending for an NC packet, then execution proceeds to block 208 where the LL EDCAF gains channel access.

[0129] 6.5. Example of STA gaining channel access for RTA packet transmission

[0130] Figure 10 Figure 13 illustrates an example embodiment 190 of the enhanced EDCA queue system internal collision avoidance mechanism. Execution begins at 192, and then a check is made at 194 to determine if the LL EDCAF is involved in an internal collision. If the STA is not involved in an internal collision, then execution can proceed to block 200 to follow the IEEE 802.11 EDCA queue internal collision avoidance mechanism.

[0131] The sender STA1 has an RTA packet 238 that is ready to be sent. No other packets arrive at the transmit queue of STA1 before the RTA packet is successfully sent. If the RTA packet is ready to be sent, the LL EDCAF starts contending 240 for the channel and counts down the backoff. In this case, the backoff counts down to zero, but the RTA packet does not arrive at the R_VO transmit queue 242, so STA1 resets the contention window and starts the backoff again 243. The contention window of the LL EDCAF is not increased. At this time, STA2 also contends for the channel through backoff 244.

[0132] While STA1 is counting down the backoff, before the backoff counts down to zero, when STA1 senses that another STA (e.g., STA2 shown in the figure) is transmitting 248 on the channel and the STA1 CCA indicates busy 246, the backoff is suspended. During the transmission of STA2, the RTA packet arrives at the LL transmit queue 250 for STA1. After the transmission of STA2 is complete and an ACK 252 is received from the AP, then STA1 finishes the backoff and STA1 gets channel access and sends the RTA packet transmission 254 as its initial (first) attempt. As shown in the figure, the first attempt fails because the ACK timeout period expires 256 without receiving an ACK from the AP. STA1 doubles its contention window and backs off 258 and gets the channel to make a retransmission 260 of the RTA packet and this time an ACK 262 is received from the AP. Note that if STA1 gets channel access and holds the TXOP duration, then multiple RTA packets can be sent within the TXOP.

[0133] 6.6. Example of RTA transmission not allowed due to internal collision

[0134] Figure 11 An example embodiment 270 of an RTA transmission not allowed to start due to internal collision is illustrated. The figure depicts the interaction between the sender STA1 and its LL EDCAF 272, VO EDCAF 274, other EDCAF 276 and the receiver STA0 (AP) 278. Note that in the enhanced EDCA queue system, the other EDCAF is represented as the EDCAF other than LL and VI.

[0135] The transmit queue in STA1 is empty. However, an RTA packet is expected to arrive soon in the LL EDCAF 280, thus performing a LL EDCAF backoff 282. When the LL EDCAF and the other EDCAF count down their backoffs to zero at the same time, the other EDCAF gets channel access to transmit a packet 288. At this time, the R_VO transmit queue is empty and the RTA packet has not arrived. During the packet transmission, an NC packet arrives in the VO EDCAF 290, and an RTA packet arrives in the LL EDCAF 292. After the ongoing transmission completes, with the AP returning an ACK 294, then both the LL EDCAF and the VO EDCAF contend for the channel. Thus, the LL EDCAF restarts its backoff 296 with the contention window set to CWmin[LL], while the VO EDCAF starts its backoff 298 with the contention window set to CWmin[VO], and an internal collision occurs 300.

[0136] When the LL EDCAF and the VO EDCAF count down their backoffs to zero at the same time, the VO EDCAF gets channel access to transmit a packet 302, since the packet is an NC packet. After the NC packet transmission completes, with the ACK 304 being received, then the LL EDCAF restarts its backoff 306, and it does not increase its contention window. Thus, the RTA packet is transmitted 308, and the AP returns an ACK 310. Note that if STA1 gets channel access and reserves the TXOP duration, then multiple RTA packets can be transmitted within the TXOP.

[0137] 6.7. Example of RTA transmission allowed despite internal collision

[0138] Figure 12 An example embodiment 330 is illustrated that allows the start of an RTA transmission when an internal collision occurs. The figure depicts the interaction between the transmitter STA1 and its LL EDCAF 332, VO EDCAF 334, other EDCAF 336, and the receiver STAO (AP) 338. In the enhanced EDCA queue system, the other EDCAF is represented as the EDCAF other than LL and VO. Since an RTA packet is expected to arrive soon 340, the LL EDCAF starts a backoff 342, while the other EDCAF has a packet and starts a backoff 344.

[0139] An internal collision occurs 348 between the LL EDCAF and another EDCAF. If the LL transmit queue is not empty, the LL EDCAF is allowed to start its transmission 350. In the figure, it can be seen that the first RTA packet arrives 346 at or before the collision, so the LL EDCAF starts transmitting. During the transmission, a VO packet arrives 352. After the RTA transmission 350 is complete, here considered to be after the ACK 356 (or similarly after an ACK timeout), the LL, VO, and other EDCAFs all contend for the channel by backoff 358, 360, 362, respectively.

[0140] When an internal collision occurs between the LL EDCAF and the VO EDCAF, then the LL EDCAF is allowed to start transmitting even if the R_VO transmit queue is not empty, since the VO EDCAF is to transmit a VO packet. Thus, it can be seen that the second RTA packet is transmitted 364, and the transmission is completed by receiving an ACK 368 from STA0. Note that if the STA reserved a TXOP duration for the second RTA packet during the transmission of the first RTA packet, the STA can transmit the second RTA packet without backoff. If the STA is starting a new TXOP or needs to contend again for any other reason, backoff can be required.

[0141] During the transmission of the second RTA packet, the other EDCAFs find the CCA busy 366. The VO EDCAF and the other EDCAFs then contend by backoff 370, 372, resulting in an internal collision 376, and the VO EDCAF gains the channel to transmit its initial VO packet 374, which can be seen to complete after returning an ACK 378.

[0142] 6.8. EDC Queues for RTA

[0143] 6.8.1. First Alternate EDCA Queue for RTA

[0144] Figure 13Figure illustrates an example embodiment 390 of an alternative RTA enhanced EDCA queue for RTA. Packets enter as MSDUs including UP and RTA information 392, mapped 394 to transmit queues 410 in different access categories (ACs). A new transmit queue, R_VO 398, is added to the queue system with regular queues VO 396, A_VO 400, A_VI 402, VI 404, BE 406, and BK 408. It will be seen that the queues are coupled to EDCA functions (EDCAFs) with internal collision avoidance. In this case, the VO queues are coupled to a VO EDCAF 412, the VI queues are coupled to a VI EDCAF 414, the BE queues are coupled to a BE EDCAF 416, and the BK queues are coupled to a BK EDCAF 418; each of these EDCAFs is coupled to a channel 420.

[0145] In this disclosure, no new EDCAF or AC is added in the system. The R_VO transmit queue 398 shares the VO EDCAF 412 with the VO transmit queue and the A_VO transmit queue. This queue system can use the traffic-to-AC mapping of Option 1 or Option 2 as shown in Table 2 or Table 3 to map traffic to transmit queues. R_VO has a lower priority than A_VO but a higher priority than VO. Therefore, the probability that a packet in the R_VO transmit queue will be transmitted earlier than a packet in the VO transmit queue is higher. The probability that a packet in the A_VO transmit queue will be transmitted earlier than a packet in the R_VO transmit queue is higher. The other EDCA and its associated transmit queues are identical to the EDCA queue system defined in IEEE 802.11. Since there is no new AC or EDCAF, the internal collision avoidance procedure can proceed as defined in IEEE 802.11.

[0146] It is possible that when the R_VO transmit queue is not empty, the VO EDCAF can contend for the channel as the LLEDCAF as shown in Figure 8A and Figure 8B

[0147] 6.8.2. Second alternative EDCA queue for RTA

[0148] Figure 14 Figure illustrates an example embodiment 430 of another alternative EDCA queue for RTA, which contains two new transmit queues, R_VO 438 and R_VI 444, added to the queue system.

[0149] ​The packets enter as MSDUs including UP and RTA information 432, mapped 434 to transmit queues 452 in different access categories (ACs). Now see that the queue system has VO 436, R_VO 438, A_VO 440, A_VI 442, R_VI 444, VI 446, BE 448, and BK 450. It will be seen that the queues are coupled to EDCA functions (EDCAFs) with internal collision avoidance. In this case, the VO queues are coupled to a VO EDCAF 454, the VI queues are coupled to a VI EDCAF 456, the BE queues are coupled to a BE EDCAF 458, and the BK queues are coupled to a BK EDCAF 460; each of these EDCAFs is coupled to a channel 462.

[0150] No new EDCAFs or ACs are added to the system. The R_VO transmit queue 438 shares the VO EDCAF 454 with the VO transmit queue 436 and the A_VO transmit queue 440. The R_VI transmit queue 444 shares the VI EDCAF 456 with the A_VI transmit queue 442 and the VI transmit queue 446. This queue system can use traffic to AC mapping option 3 as shown in Table 4. R_VO has lower priority than A_VO but higher priority than VO. Thus, the probability that a packet in the R_VO transmit queue will be transmitted earlier than a packet in the VO transmit queue is higher. Also, the probability that a packet in the A_VO transmit queue will be transmitted earlier than a packet in the R_VO transmit queue is higher.

[0151] R_VI has higher priority than A_VI and VI. Thus, the probability that a packet in the R_VI transmit queue will be transmitted earlier than a packet in the A_VI transmit queue and the VO transmit queue is higher. The other EDCA and its associated transmit queue can be identical to the EDCA queue system defined in IEEE 802.11. Since no new ACs or EDCAFs exist, the internal collision avoidance procedure can be identical to that defined in IEEE 802.11.

[0152] It is possible that, when the R_VO transmit queue is not empty, the VO EDCAF can contend for the channel as a LL EDCAF as shown in Figure 8A and Figure 8B It is possible that, when the R_VI transmit queue is not empty, the VI EDCAF can contend for the channel as a LL EDCAF as shown in Figure 8A and Figure 8B .

[0153] 6.9. Traffic to AC mapping (option 3)

[0154] Table 4 lists the option 3 of traffic to AC mapping. When traffic with UP 6 is RTA (e.g., traffic belonging to RTA-TS with UP 6 and using EDCA channel access), then the traffic is queued in the R_VO transmit queue. When traffic with UP 5 is RTA (e.g., traffic belonging to RTA-TS with UP 5 and using EDCA channel access), then the traffic is queued in the R_VI transmit queue. Non-RTA traffic uses the same traffic to AC mapping as defined in IEEE 802.11 protocol. As shown in the table, RTA traffic with UP 6 has higher priority than voice (VO) traffic specified in IEEE 802.1D, and has lower priority than network control (NC) traffic specified in IEEE 802.1D. RTA traffic with UP 5 has higher priority than video (VI) traffic and controlled load (CL) traffic specified in IEEE 802.1D.

[0155] 6.10. Transmit priority among transmit queues

[0156] Figure 15 Figure illustrates an example embodiment 470 of how a STA decides to transmit packets from which transmit queue. The process starts at 472, at 474, the VO EDCAF in the alternate EDCA queue of the RTA gets channel access. At 476, it is checked whether the A_VO queue is empty. If the A_VO transmit queue is not empty, then a transition is made to block 478, the STA first transmits packets in the A_VO transmit queue, and then the process ends 486. Otherwise, if at block 476, the A_VO transmit queue is empty, then a check is made at 480 to determine whether the R_VO transmit queue is empty. If the R_VO transmit queue is not empty, then a transition is made to block 484, the STA first transmits packets in the R_VO transmit queue, and then the process ends 486. If both the A_VO and R_VO transmit queues are empty, then a transition is made to block 482, the STA first transmits packets in the VO transmit queue, and then the process ends 486.

[0157] Figure 16An example embodiment 490 of a STA determining from which transmit queue to send a packet is illustrated. The process begins at 492, and at 494, the VI EDCAF in the standby EDCA queue of the RTA has channel access. A check is made whether the R_VI transmit queue is empty. If the R_VI transmit queue is not empty, then a transition block 498 is executed, and the STA first transmits the packets in the R_VI transmit queue. Otherwise, if at block 496 it is determined that the R_VI transmit queue is empty, then a check 500 is executed, which determines whether the VI queue is empty. If the VI transmit queue is not empty, then at block 504, the STA first transmits the packets in the VI transmit queue. Otherwise, if the R_VI and VI transmit queues are empty, then a block 502 is reached, and the STA first transmits the packets in the A_VI transmit queue. After transmission, the process ends 506 for that packet.

[0158] 7. General Embodiments

[0159] The enhancements described in the present technology can be readily implemented in a variety of wireless communication stations. It should also be appreciated that a wireless network communication station is preferably implemented to include one or more computer processor devices (e.g., CPUs, microprocessors, microcontrollers, computer-enabled ASICs, etc.) and associated memory (e.g., RAM, DRAM, NVRAM, FLASH (flash memory), computer-readable media, etc.) storing instructions, such that the programming (instructions) stored in the memory are executed on the processor to perform the steps of the various processing methods described herein.

[0160] For simplicity of illustration, the computer and storage devices are selectively depicted because one of ordinary skill in the art will recognize that computer devices are used to perform the steps involving digital wireless communications. The present technology is non-limiting to memory and computer-readable media, so long as the memory and computer-readable media are non-transitory, such that they do not constitute transitory electronic signals.

[0161] Embodiments of the technology can be illustrated with reference to flow charts of methods and systems in accordance with embodiments of the technology, and / or can also be implemented as processes, algorithms, steps, operations, formulas, or other computational descriptions of computer program products to illustrate. In this regard, each block or step of a flow chart, and combinations of blocks (and / or steps) in a flow chart, and any process, algorithm, step, operation, formula, or computational description, can be implemented by various means, such as hardware, firmware, and / or software including one or more computer program instructions embodied on computer-readable program code. As will be realized by those skilled in the art, any such computer program instructions can be executed on one or more computer processors (including without limitation 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 functions specified.

[0162] Accordingly, blocks of the flow charts, and processes, algorithms, steps, operations, formulas, or computational descriptions illustrated herein support combinations thereof for performing the specified functions, combinations of steps for performing the specified functions, and computer program instructions (such as embodied on computer-readable program code logic) for performing the specified functions. It should also be understood that each block of the flow charts, and any processes, algorithms, steps, operations, formulas, or computational descriptions illustrated herein, and combinations thereof, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer-readable program code.

[0163] It should be realized that the wording at the beginning and end of these flow charts, such as "start" and "stop," do not imply that instructions are limited to a particular routine, or that it has an actual start and stop. The instructions can be executed without limitation within various routines, tasks, slices, threads, etc., and these steps can be combined with steps that perform other functions, or can be extended to provide additional functionality, without departing from the teachings of the present disclosure.

[0164] Furthermore, these computer program instructions, such as embodied in computer readable program code, can also be stored in one or more computer readable memory or storage devices, which can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory or storage devices produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. The computer program instructions can also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the flowchart block or blocks, procedure, algorithm, steps, operations, formulas or computational descriptions.

[0165] It should also be appreciated that the term "program" or "executable program" as used herein refers to one or more instructions that can be executed by one or more computer processors to perform one or more functions described herein. The instructions can be embodied in software, firmware, or a combination of software and firmware. The instructions can be stored locally on a device in non-transitory media, or can be stored remotely, such as on a server, or the instructions can be stored in whole or in part locally and remotely. The remotely stored instructions can be downloaded (pushed) to the device by a user initiation, or automatically based on one or more factors.

[0166] It should also be appreciated that the terms processor, hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously herein to refer to a device capable of executing instructions and communicating with input / output interfaces and / or peripheral devices, and the terms processor, hardware processor, computer processor, CPU, and computer are intended to include one or more devices, single-core and multicore devices, and variations thereof.

[0167] In accordance with the description herein, it should be appreciated that the present disclosure encompasses a number of embodiments including, but not limited to, the following:

[0168] 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit as a first wireless station, the wireless communication circuit configured to wirelessly communicate with at least one other wireless station on a wireless local area network (WLAN) in a reception area of the first wireless station over at least one channel; (b) a processor of the first wireless station, the processor configured to enable the first wireless station to communicate with the other wireless station over at least one channel on the WLAN; (c) a non-transitory memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform one or more steps comprising: (d)(i) causing the wireless communication circuit to operate as a wireless local area network (WLAN) station configured to transmit real-time application (RTA) packets and non-real-time application (non-RTA) packets over a WLAN supporting carrier sense multiple access / collision avoidance (CSMA / CA) using enhanced distributed channel access (EDCA) in an EDCA queue system, wherein RTA traffic and non-RTA traffic coexist, and wherein RTA traffic is given a higher transmit priority than lower priority traffic; (d)(ii) distinguishing between RTA packets and non-RTA packets; and (d)(iii) creating at least one associated transmit queue to queue RTA packets, while non-RTA packets are queued to original transmit queues in the EDCA queue system.

[0169] 2. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuitry of a first wireless station configured to wirelessly communicate with at least one other wireless station on a local area network (WLAN) in a reception area of the first wireless station over at least one channel; (b) a processor of the first wireless station configured to enable the first wireless station to communicate with other stations over a WLAN; (c) a non-transitory memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform one or more steps comprising: (d)(i) operating the first wireless station configured to transmit real-time application (RTA) packets and non-real-time application (non-RTA) packets over at least one channel on a WLAN supporting carrier sense multiple access / collision avoidance (CSMA / CA) using enhanced distributed channel access (EDCA) in an EDCA queue system, wherein RTA traffic and non-RTA traffic coexist, and wherein RTA traffic is given a higher transmit priority than lower priority traffic; (d)(ii) distinguishing between RTA packets and non-RTA packets and establishing an RTA traffic stream (TS) for RTA traffic; (d)(iii) creating at least one new access category (AC) and at least one associated transmit queue to queue RTA packets, wherein non-RTA packets are queued to original transmit queues in the EDCA queue system, wherein queued RTA packets have a higher probability of being transmitted earlier than non-RTA packets; and (d)(iv) creating a new EDCA function (EDCAF) for the new access category (AC) transmit queue of RTA packets, wherein the RTA queue can contend for the channel before an expected RTA packet arrives.

[0170] 3. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuitry of a first wireless station configured to wirelessly communicate with at least one other wireless station on a wireless local area network (WLAN) in a reception area of the first wireless station over at least one channel; (b) a processor of the first wireless station configured to enable the first wireless station to communicate with the other stations over at least one channel on the WLAN; (c) a non-transitory memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform one or more steps comprising: (d)(i) operating the first wireless station configured to transmit real-time application (RTA) packets and non-real-time (non-RTA) packets over a WLAN supporting carrier sense multiple access / collision avoidance (CSMA / CA) using enhanced distributed channel access (EDCA) in an EDCA queue system, wherein real-time application (RTA) traffic and non-RTA traffic coexist; (d)(ii) distinguishing between RTA packets and non-RTA packets; (d)(iii) allowing an EDCA F to contend for a channel before an RTA packet arrives in a queue in order to send the RTA packet; (d)(iv) re-contending for the channel if the EDCA F for the RTA packet has counted backoff to 0 and determines that the RTA packet has not arrived in the EDCA queue without gaining a TXOP; and (d)(v) gaining a TXOP when the EDCA F for the RTA packet counts backoff down to 0 and determines that the RTA packet has arrived in the EDCA queue.

[0171] 4. 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 station on a local area network (WLAN) in its reception area over at least one channel; (b) a processor coupled to the wireless communication circuitry within a station configured to operate on the WLAN; (c) a non-transitory memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) causing the wireless communication circuitry to operate as a wireless local area network (WLAN) station configured to support communicating real-time application (RTA) packets and non-RTA packets over a network supporting carrier sense multiple access / collision avoidance (CSMA / CA) using enhanced distributed channel access (EDCA) in an EDCA queue system, wherein real-time application (RTA) traffic and non-RTA traffic coexist and RTA traffic is given a higher transmit priority than lower priority traffic; (d)(ii) distinguishing real-time application (RTA) packets from non- real-time application (non-RTA) packets and establishing an RTA traffic stream (TS) for RTA traffic; (d)(iii) creating at least one new access category (AC) and at least one associated transmit queue to queue RTA packets, while non-RTA packets are queued to original transmit queues in the EDCA queue system, such that queued RTA packets have a higher probability of being transmitted earlier than non-RTA packets; and (d)(iv) wherein the station creates a new EDCA function (EDCAF) for the new access category (AC) transmit queue of RTA packets, wherein the RTA queue can contend for the channel before an expected RTA packet arrives.

[0172] 5. 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 station on a local area network (WLAN) in its reception area over at least one channel; (b) a processor coupled to the wireless communication circuitry within a station configured to operate on the WLAN; (c) a non-transitory memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) causing the wireless communication circuitry to operate as a wireless local area network (WLAN) station configured to support the transmission of real-time application (RTA) packets and non-real-time packets over a carrier sense multiple access / collision avoidance (CSMA / CA) enabled network using enhanced distributed channel access (EDCA) in an EDCA queue system, wherein real-time application (RTA) traffic and non-RTA traffic coexist and RTA traffic is given higher transmission priority than lower priority traffic; (d)(ii) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets; (d)(iii) creating at least one associated transmission queue to queue RTA packets while non-RTA packets are queued to original transmission queues in the EDCA queue system; (d)(iv) mapping RTA packets to the associated transmission queue based on user priority of the RTA packets.

[0173] 6. A method of wireless communication in a network, the apparatus comprising: (a) causing wireless communication circuitry to operate as a station on a wireless local area network (WLAN), the station on the WLAN configured to support the transmission of real-time application (RTA) packets and non-real-time packets over a carrier sense multiple access / collision avoidance (CSMA / CA) enabled network using enhanced distributed channel access (EDCA) in an EDCA queue system, wherein real-time application (RTA) traffic and non-RTA traffic coexist and RTA traffic is given higher transmission priority than lower priority traffic; (b) distinguishing real-time application (RTA) packets from non-real-time application (non-RTA) packets; (c) creating at least one new access category (AC) and at least one associated transmission queue to queue RTA packets while non-RTA packets are queued to original transmission queues in the EDCA queue system; and (d) wherein the station creates new EDCA functions (EDCFs) for the new access category (AC) transmission queues of RTA packets, wherein the RTA queues can contend for the channel before the expected RTA packets arrive; and (e) wherein the method is performed by a processor executing instructions stored on a non-transitory medium.

[0174] 7. A wireless communication apparatus that performs transmission of packets in which CSMA / CA and EDCA queue systems are applied, real-time application (RTA) traffic and non-RTA traffic coexist in the system / apparatus, comprising: (a) a STA differentiating RTA traffic and non-RTA traffic; (b) the STA creating a new transmit queue to queue RTA packets while non-RTA packets are queued to original transmit queues in the EDCA queue system; and (c) the STA creating a new EDCAF (i.e., a new AC) for the new transmit queue of RTA packets, the new EDCAF being able to contend for the channel before the RTA packets arrive.

[0175] 8. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, further perform one or more steps comprising differentiating RTA traffic and non-RTA traffic, further comprising performing establishing an RTA traffic stream (TS) for RTA traffic.

[0176] 9. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, further perform one or more steps comprising transmitting RTA packets from the new transmit queue for RTA packets with a higher probability earlier than non-RTA packets are transmitted.

[0177] 10. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, further perform one or more steps comprising transmitting non-RTA packets earlier than RTA packets with a higher probability only if the non-RTA packets have a higher user priority than the RTA packets.

[0178] 11. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, further perform one or more steps comprising causing the EDCAF of the RTA queue to transmit network control (NC) packets earlier than RTA packets when an internal collision occurs.

[0179] 12. The apparatus or method of any preceding embodiment, wherein the instructions, when executed by the processor, further perform one or more steps comprising causing the EDCAF of the RTA queue to transmit RTA packets earlier than non-RTA packets other than network control (NC) packets when an internal collision occurs.

[0180] 13. The apparatus or method of any preceding embodiment, wherein a station that differentiates RTA traffic and non-RTA traffic can establish an RTA-TS for RTA traffic.

[0181] 14. The apparatus or method of any preceding embodiment, wherein the first station creating a new transmit queue for RTA packets transmits RTA packets before non-RTA packets with a higher probability when RTA packets and non-RTA packets have the same user priority.

[0182] 15. The apparatus or method of any preceding embodiment, wherein the first station creating a new transmit queue for RTA packets transmits non-RTA packets before RTA packets with a higher probability only if the non-RTA packets have a higher user priority than the RTA packets.

[0183] 16. The apparatus or method of any preceding embodiment, wherein the first station creating a new EDCAF for RTA queues can transmit network control (NC) packets before RTA packets when an internal collision occurs.

[0184] 17. The apparatus or method of any preceding embodiment, wherein the first station creates a new EDCAF for RTA queues, and transmits RTA packets before non-RTA packets other than NC packets when an internal collision occurs.

[0185] As used herein, the singular forms "a", "an", and "the" can include plural referents unless the context clearly dictates otherwise. Unless expressly stated to the contrary, use of the singular form in reference to an object in the specification and claims is not intended to limit the scope to a single object unless explicitly stated otherwise.

[0186] As used herein, the phrase "at least one of A, B, and / or C" indicates that A, B, or C, or any combination thereof, can be present. As used herein, the phrase "at least one of... in a list of elements" indicates that at least one of the elements in the list is present, which includes any possible combination of the listed elements.

[0187] Reference within this specification to "an embodiment", "at least one embodiment", or "one embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The various instances of the phrase "in at least one embodiment" do not necessarily all refer to the same embodiment, or to the same instance of an embodiment. Embodiment language should be interpreted in context with the claim language to determine the scope of each claim.

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

[0189] As used herein, the terms "approximately," "about," "substantially" and "largely" are used to describe and account for small variations. When used in connection with an event or circumstance, these terms can refer to instances in which the event or circumstance occurs exactly, as well as instances in which the event or circumstance occurs approximately. When used in connection with a numerical value, these terms can refer to a range of variation of less than or equal to ±10% of that 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, "substantially" aligned can 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°.

[0190] In addition, quantities, ratios and other numerical values are sometimes presented herein in a range format. It is to be understood that the use of such range format is merely for convenience and brevity and should be interpreted - in a flexible manner to include not only the numerical values explicitly recited as the limits of the range, but also to include all the individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly recited. For example, a range of about 1 to about 200 should be interpreted to include not only the explicitly recited limits of about 1 and about 200, but also the individual numbers such as 2, 3 and 4, and the sub-ranges such as 10 to 50, 20 to 100, etc. In this manner, all of the numerical values and sub-ranges within the range are to be considered as being expressly stated in this application.

[0191] While the specification contains many specifics, these should not be construed as limiting the scope of the disclosure but as merely providing illustrations of some of the embodiments of the present disclosure. Thus, it should be apparent that the scope of the disclosure is intended to encompass other embodiments which can become apparent to those skilled in the art upon reading the present specification.

[0192] All structural and functional equivalents to the elements of the various embodiments described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether these disclosure elements are explicitly recited in the claims. The claims are to be construed as encompassing the equivalents of the elements disclosed throughout this disclosure, as such equivalents are known or later come to be known to those of ordinary skill in the art. None of the elements described throughout this disclosure are to be construed as being dedicated to the public regardless of whether these disclosure elements are explicitly recited in the claims. No admission is made that any of the elements described throughout this disclosure are or were part of the common general knowledge of those of ordinary skill in the art.

[0193] Table 1

[0194] UP to AC mapping used in IEEE 802.11 reference EDCA queues

[0195]

[0196] Table 2

[0197] UP to AC mapping (Option 1)

[0198]

[0199] BK = Background, BE = Best Effort, EE = Extremely Effort, CL = Control Load, VI = Video, VO = Voice, NC = Network Control, LL = Low Latency Table 3

[0200] UP & RTA to AC mapping (Option 2)

[0201]

[0202] BK = Background, BE = Best Effort, EE = Extremely Effort, CL = Control Load, VI = Video, VO = Voice, NC = Network Control, LL = Low Latency

[0203] Table 4

[0204] Traffic to AC mapping (Option 3)

[0205]

[0206] BK = Background, BE = Best Effort, EE = Extremely Effort, CL = Control Load, VI = Video, VO = Voice, NC = Network Control, LL = Low Latency

Claims

1. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit as a first wireless station, the wireless communication circuit configured to wirelessly communicate with at least one other wireless station on a wireless local area network (WLAN) in a reception area of the first wireless station over at least one channel; (b) a processor of the first wireless station, the processor configured to enable the first wireless station to communicate with the other wireless station over at least one channel on the WLAN; (c) a non-transitory memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform steps comprising: (i) causing the wireless communication circuit to operate as a wireless local area network (WLAN) station configured to transmit real-time application (RTA) packets and to transmit non-real-time application (non-RTA) packets over a WLAN supporting carrier sense multiple access / collision avoidance (CSMA / CA) using enhanced distributed channel access (EDCA) in an EDCA queue system, wherein RTA traffic and non-RTA traffic coexist, and wherein RTA traffic is given a higher transmit priority than lower priority traffic; (ii) distinguishing between RTA packets and non-RTA packets by establishing RTA traffic streams (TSs) for RTA traffic and based on identifying whether a packet belongs to an RTA TS; and (iii) creating at least one associated transmit queue for queuing RTA packets, while non-RTA packets are queued to a plurality of other transmit queues in the EDCA queue system, the plurality of other transmit queues in the EDCA queue system including a voice queue, a reserve voice queue, a reserve video queue, a video queue, a best effort queue, and a background queue, wherein packets are mapped to respective queues based on user priority and an indication indicating whether the packet belongs to an RTA TS, such that voice packets having the same user priority but different RTA indications are queued in different queues, wherein in the event that the at least one associated transmit queue for queuing RTA packets is not empty, when an EDCA function (EDCAF) for controlling the at least one associated transmit queue for queuing RTA packets collides with EDCAFs for controlling the voice queue and the reserve voice queue, the EDCAF for controlling the voice queue and the reserve voice queue gains channel access if the EDCAF for controlling the voice queue and the reserve voice queue is to transmit a network control (NC) packet, otherwise, the EDCAF for controlling the at least one associated transmit queue for queuing RTA packets gains channel access.

2. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform one or more steps comprising transmitting RTA packets from the new transmit queue for RTA packets with a higher probability of being transmitted earlier than non-RTA packets.

3. The apparatus of claim 2, wherein the instructions, when executed by the processor, further perform one or more steps comprising: sending non-RTA packets earlier than RTA packets with a higher probability only if the non-RTA packets have a higher user priority than the RTA packets.

4. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform one or more steps comprising: causing the EDCA function (EDCAF) of the RTA queue to send network control (NC) packets earlier than RTA packets when an internal collision occurs.

5. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform one or more steps comprising: causing the EDCA function (EDCAF) of the RTA queue to send RTA packets earlier than non-RTA packets other than network control (NC) packets when an internal collision occurs.

6. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: allowing the EDCA function (EDCAF) to contend for the channel before the RTA packet arrives at the queue in order to send the RTA packet; recontending for the channel if the EDCAF for the RTA packet has counted backoff to 0 and determines that the RTA packet has not arrived at the EDCA queue without gaining the TXOP; and gaining the TXOP when the EDCAF for the RTA packet counts backoff down to 0 and determines that the RTA packet has arrived at the EDCA queue.

7. The apparatus of claim 6, wherein the instructions, when executed by the processor, further perform one or more steps comprising: sending the RTA packet from the new transmit queue for the RTA packet with a higher probability earlier than non-RTA packets are sent.

8. The apparatus of claim 7, wherein the instructions, when executed by the processor, further perform one or more steps comprising: sending non-RTA packets earlier than RTA packets with a higher probability only if the non-RTA packets have a higher user priority than the RTA packets.

9. The apparatus of claim 6, wherein the instructions, when executed by the processor, further perform one or more steps comprising: causing the EDCAF of the RTA queue to send network control (NC) packets earlier than RTA packets when an internal collision occurs.

10. The apparatus of claim 6, wherein the instructions, when executed by the processor, further perform one or more steps comprising: causing the EDCAF of the RTA queue to send RTA packets earlier than non-RTA packets other than network control (NC) packets when an internal collision occurs. ​

Images