JP7679488B2 - Sharing EDCA TXOP with RTA traffic - Google Patents

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63/168,434, filed March 31, 2021, which is incorporated herein by reference in its entirety.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
N/A

Notification of copyrighted material
Portions of the material in this patent document may be subject to copyright protection under the copyright laws of the United States and other countries. The copyright owner has no objection to the copying by any third party of the patent document or the patent disclosure as it appears in the U.S. Patent and Trademark Office public files or records, but otherwise reserves all copyright rights. The copyright owner does not hereby waive any of its rights to have this patent document maintained in secrecy, including, but not limited to, the right pursuant to 37 CFR §1.14.

The technology disclosed herein relates generally to wireless network communications using Enhanced Distributed Channel Access (EDCA) that defines multiple Access Categories (ACs), and specifically to enabling real-time application (RTA) packet transmissions to utilize transmission opportunity (TXOP) sharing to reduce latency.

Current wireless 802.11 technology using CSMA/CA focuses on high throughput performance of the network, but does not adequately support low latency traffic such as that required by real-time applications (RTA) that transmit RTA frames. Low latency is required due to the high timeliness requirement that each RTA frame is only valid if delivered within a certain time. RTA traffic also encounters problems when using Enhanced Distributed Channel Access (EDCA), which defines multiple access categories (AC).

Therefore, there is a need to enhance RTA traffic sharing handling of TXOPs when using EDCA. The present disclosure fulfills this need and provides further advantages.

Current wireless communication systems using Enhanced Distributed Channel Access (EDCA) do not distinguish RTA packets from non-RTA packets, and therefore all packets under EDCA use the same TXOP sharing rules. The present disclosure is configured to increase the flexibility of RTA packet transmission when utilizing EDCA transmission opportunity (TXOP) sharing to reduce latency. The disclosed protocol provides the following key advantages: (a) STAs can share the TXOP of the primary AC to transmit RTA frames when there are pending frames from the primary AC, and (b) consider fairness between the transmission of frames from the primary AC and the transmission of RTA frames from non-primary ACs.

Further aspects of the technology described herein will become apparent in the remainder of this specification, and this detailed description is intended to fully disclose the preferred embodiments of the technology without limiting them.

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

FIG. 1 is a data field diagram of the TSPEC element contents defined in IEEE 802.11. FIG. 1 is a data field diagram of a TS information element defined in IEEE 802.11. FIG. 1 is a data field diagram of the TCLAS element defined in IEEE 802.11. FIG. 1 is a data field diagram of a TCLAS processing element defined in IEEE 802.11. FIG. 1 is a data field diagram of the HE Multi-User (MU) PPDU format used for downlink multi-user transmission as defined in IEEE 802.11. FIG. 1 is a data field diagram of the HE trigger-based (TB) PPDU format used for uplink multi-user transmission as defined in IEEE 802.11. FIG. 1 is a data field diagram of a trigger frame (TF) defined in IEEE 802.11. FIG. 1 is a data field diagram of the common information field of the TF defined in IEEE 802.11. FIG. 1 is a data field diagram of the user information field of a trigger frame (TF) defined in IEEE 802.11. This is a data field diagram of the trigger-dependent user information field of the MU-BAR trigger frame (TF) defined in IEEE 802.11. FIG. 1 is a data field diagram of a Block ACK (BA) frame defined in IEEE 802.11. FIG. 1 is a data field diagram of a buffer status request (BSR) frame defined in IEEE 802.11. 1 is a communication diagram of downlink multi-user transmission using OFDMA as utilized in IEEE 802.11. 1 is a communication diagram of uplink multi-user transmission utilizing Orthogonal Frequency Division Multiple Access (OFDMA) as defined in IEEE 802.11. 1 is a communication diagram of uplink multi-user transmission utilizing Orthogonal Frequency Division Multiple Access (OFDMA) as defined in IEEE 802.11. FIG. 1 is a transmission queue diagram of the reference model for EDCA (Enhanced DCF Channel Access) defined in IEEE 802.11. FIG. 1 is a communication diagram for executing a channel access procedure of EDCA defined in IEEE 802.11. FIG. 2 is a hardware block diagram of wireless station hardware in accordance with at least one embodiment of the present disclosure. FIG. 2 is a hardware block diagram of a station configuration, such as that included in multilink device hardware, in accordance with at least one embodiment of the present disclosure. A topology of a WLAN having seven STAs, six of which are in three MLDs, in accordance with at least one embodiment of the present disclosure. 1 is a communication diagram for terminating or modifying an LLTS in accordance with at least one embodiment of the present disclosure. FIG. 2 is a data field diagram of an LLTS request frame in accordance with at least one embodiment of the present disclosure. FIG. 2 is a data field diagram of an LLTS descriptor field format in accordance with at least one embodiment of the present disclosure. FIG. 2 is a data field diagram of RTA-TSPEC field contents in accordance with at least one embodiment of the present disclosure. FIG. 13 is a data field diagram of an optional sub-element carrying an upper layer stream ID, in accordance with at least one embodiment of the present disclosure. FIG. 2 is a data field diagram of an optional sub-element that carries LLTS/TID to link mapping in accordance with at least one embodiment of the present disclosure. FIG. 2 is a data field diagram of an LLTS response frame in accordance with at least one embodiment of the present disclosure. FIG. 2 is a data field diagram of an LLTS status field in accordance with at least one embodiment of the present disclosure. FIG. 1 is a flow diagram for distinguishing between RTA and non-RTA traffic in accordance with at least one embodiment of the present disclosure. FIG. 1 is a flow diagram of TXOP sharing for transmitting RTA traffic from a non-primary AC work in accordance with at least one embodiment of the present disclosure. FIG. 2 is a transmission queue diagram of an EDCA queue of AP1 or MLD1 in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 transmits RTA frames from non-primary ACs only during a TXOP, in accordance with at least one embodiment of the present disclosure. FIG. 13 is a transmission queue diagram of another EDCA queue state of AP1 or MLD1 in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 transmits an RTA frame from a higher priority non-primary AC before a frame from a primary AC during a TXOP, in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 first transmits an RTA frame from a primary AC, then transmits an RTA frame from a non-primary AC, and then transmits a non-RTA frame from the primary AC during a TXOP, in accordance with at least one embodiment of the present disclosure. FIG. 2 is a communication diagram in which AP1 transmits an RTA frame from a non-primary AC that has a lower priority than the primary AC, in accordance with at least one embodiment of the present disclosure. FIG. 13 is a transmission queue diagram of a third example of an EDCA queue state for AP1 or MLD1 in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by a request to transmit the RTA frame from the non-primary AC, in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by the delay requirement of the RTA frame from the primary AC, in accordance with at least one embodiment of the present disclosure. FIG. 11 is a communication diagram illustrating another example in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by the delay requirement of the RTA frame from the primary AC, in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by the transmission requirements of the RTA frame from the primary AC, in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 limits the time of TXOP sharing, in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 shares a TXOP after transmitting a certain number of frames from a primary AC, in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 shares a TXOP after transmitting frames from a primary AC for a certain period of time, in accordance with at least one embodiment of the present disclosure. FIG. 2 is a data field diagram of a frame conveying a dedicated time parameter setting in accordance with at least one embodiment of the present disclosure. FIG. 11 is a transmission queue diagram of a fourth example of an EDCA queue state for AP1 or MLD1 in accordance with at least one embodiment of the present disclosure. FIG. 1 is a communication diagram in which AP1 transmits an MU OFDMA PPDU and, for each user, RTA frames from non-primary ACs are transmitted earlier than frames from the primary AC, in accordance with at least one embodiment of the present disclosure. FIG. 13 is a communication diagram of TXOP sharing when an AP transmits RTA frames from non-primary ACs in a MU PPDU later than RTA frames from the primary AC, but earlier than non-RTA frames from the primary AC for each user, in accordance with at least one embodiment of the present disclosure.

1. Introduction Real-time applications (RTA) require low latency and use best-effort communication. Data originating from RTA is referred to as RTA traffic and is packetized as RTA frames at a transmitting station (STA). Data originating from non-time-sensitive applications is also referred to herein as non-RTA traffic and is packetized as non-RTA frames at a transmitting STA that forwards packets carrying the frames over a channel (link) to a receiving STA.

RTA traffic is encapsulated on a frame-by-frame basis upon arrival at the EDCA queue. Frames carrying RTA traffic are represented by RTA frames, and frames carrying non-RTA traffic are represented by non-RTA frames. A packet may contain one or more frames and be transmitted over a link or channel. The AC associated with the EDCAF that has acquired the EDCA TXOP is called the primary AC.

Since RTA frames are only valid if delivered within a certain time, they require low latency due to the high timeliness requirement for delivery. One solution in CSMA/CA wireless technology is to increase the opportunities for STAs to transmit RTA frames, for example by using a high priority AC for transmitting RTA frames.

Due to the random channel access scenario, STAs need to sense the channel and contend for channel access rights before transmitting each frame. In EDCA, STAs can use the short channel contention time of the high-priority AC to accelerate channel access. However, it is possible that a low-priority AC may access the channel earlier than a high-priority AC. The delay in transmitting an RTA frame from a high-priority AC is due to the TXOP time obtained by the low-priority AC.

The STA can transmit the RTA frame using the TXOP time acquired by the low-priority AC to avoid the delay caused by the TXOP time acquired by the low-priority AC. The task of sharing the TXOP of the primary AC to transmit frames from the non-primary AC is difficult due to the coexistence of RTA and non-RTA traffic. The challenge of this process can be summarized as (a) distinguishing between RTA and non-RTA traffic and sharing the TXOP of the primary AC to transmit RTA packets from the non-primary AC in the presence of untransmitted packets from the primary AC.

2. Current 802.11 Operation 2.1. TSPEC Element Figure 1 shows the contents of the TSPEC element defined in IEEE 802.11, which has the following fields: Element ID indicates the type of element, which in this case indicates that it is a TSPEC element. Length field indicates the length of the TSPEC element. TS Info field indicates traffic stream information, and has the subfields shown in Figure 2. Nominal MSDU Size field indicates the nominal size of MSDU or A-MSDU belonging to TS under this TSPEC. Maximum MSDU Size field indicates the maximum size of MSDU or A-MSDU belonging to TS under this TSPEC. The Minimum Service Interval field indicates the minimum time between the start times of two consecutive Service Periods (SPs). The Maximum Service Interval field indicates the maximum time between the start times of two consecutive SPs. The Inactivity Interval field indicates a time interval during which no MSDUs arrive or are transmitted belonging to a TS before the TS is deleted. The Suspension Interval field indicates a time interval during which no MSDUs arrive or are transmitted belonging to a TS before the generation of a QoS(+) CF-Poll for the TS is stopped.

The Service Start Time field contains the start time of the first SP. The Minimum Data Rate field indicates the minimum data rate for transmitting MSDUs or A-MSDUs belonging to a TS under this TSPEC, as specified by the MAC SAP. The Mean Data Rate field indicates the average data rate for transmitting MSDUs or A-MSDUs belonging to a TS under this TSPEC, as specified by the MAC SAP. The Peak Data Rate field indicates the maximum data rate for transmitting MSDUs or A-MSDUs belonging to a TS under this TSPEC, as specified by the MAC SAP. The Burst Size field indicates the maximum burst at the peak data rate of MSDUs or A-MSDUs belonging to a TS under this TSPEC. The Delay Bound field indicates the maximum time allowed for transmitting an MSDU or A-MSDU belonging to a TS under this TSPEC. The Minimum PHY Rate field indicates the minimum PHY rate for transmitting an MSDU or A-MSDU belonging to a TS under this TSPEC. The Surplus Bandwidth Allowance field indicates the ratio of the bandwidth used for transmitting and retransmitting an MSDU or A-MSDU belonging to a TS under this TSPEC to the bandwidth used for transmitting this MSDU or A-MSDU once at the minimum PHY rate. The Medium Time field indicates the time allowed for accessing the medium. The DMG Attributes field is present when the TSPEC applies to a Directional Multi-Gigabit (DMG) BSS.

Figure 2 shows the contents of the TS information field defined in IEEE 802.11. The Traffic Type field specifies whether the traffic is periodic or not. The TSID field indicates an ID number for identifying the TS. The Direction field specifies the direction of data transmission. The Access Policy field specifies the method for acquiring channel access rights. The Aggregation field specifies whether an aggregation schedule is required. The APSD field indicates whether automatic PS distribution is used. The User Priority field indicates the user priority of the MSDU or A-MSDU belonging to the TS. The TSInfo Ack Policy field indicates whether an ACK is required and what form of ACK should be used. The Schedule field indicates the type of schedule.

2.2 TCLAS Element Figure 3 shows the contents of the TCLAS element defined in IEEE 802.11. The Element ID field indicates the type of element, which in this case is a TCLAS element. The Length field indicates the length of the TSPEC element. The User Priority field indicates the user priority from higher layers. The Frame Classifier field indicates how to classify frames from higher layers.

2.3 TCLAS Processing Element Figure 4 shows the contents of the TCLAS processing element defined in IEEE 802.11. The Element ID field indicates the type of element, which in this case is a TCLAS processing element. The Length field indicates the length of the TCLAS processing element. The Processing field indicates how to classify traffic from higher layers when multiple TCLAS elements exist.

2.4 Multi-user transmission In wireless networks such as IEEE 802.11, multi-user transmission is available. From IEEE 802.11ax onwards, networks can support multi-user transmission on both the uplink and downlink. Multi-user transmission in IEEE 802.11ax includes MIMO and OFDMA modes, which can be used alone or together.

IEEE 802.11ax transmits data in a multi-user mode using a multi-user transmission packet format as shown in Figures 5 and 6. When multiple users transmit or receive a multi-user transmission packet, all users share the same PLCP header of the multi-user transmission packet. Then, each user transmits or receives data carried by the multi-user transmission packet using an individual resource block including RU allocation and MCS, etc.

IEEE 802.11ax specifies several PLCP Protocol Data Unit (PPDU) formats for transmitting packets in different multi-user transmissions, which are described below. PLCP is an acronym for PHY Layer Convergence Protocol.

Figure 5 shows the HE Multi-User (MU) PPDU format used for downlink multi-user transmission in IEEE 802.11ax. These fields are shown as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, Data, and PE.

Figure 6 shows the HE Trigger-Based (TB) PPDU format used for uplink multi-user transmission in IEEE 802.11ax. The fields of the HE TB PPDU format are identical to those of the HE Single-User PPDU format, except that the HE-STF field is 8 μs. These fields are denoted as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, HE-LTFs, Data, and PE.

Figure 7 shows the contents of a trigger frame (TF). The frame control field indicates the type of frame. The duration field contains NAV information used 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 that sent the frame. The Common Info field contains information for all assigned STAs as shown in Figure 8 below. The User Info field contains information for each STA as shown in Figure 9. The Common Info and User Info fields provide individual resource block allocation information for each user.

Figure 8 shows the common information field of the trigger frame shown in Figure 7. The subfields of the common information field are Trigger Type, Length, Cascading Indication, CS Required, BW, GI and LTF Type, MU MIMO LTF Mode, Number of HE-LTF Symbols, LDPC Extra Symbol Segment (STBC), AP TX Power, Packet Extension, Spatial Reuse, and IEEE 802.11b. These are shown as Reuse, Doppler, GI and LTF type, HE-SIG-A Reserved, Reserved, and Trigger Dependent Common Info.

Figure 9 shows the User Information field of the trigger frame shown in Figure 7, which has the following subfields: AID12, RU Allocation, Coding Type, MCS, DCM, SS Allocation, Target RSSI, Reserved, and Trigger Dependent Common Info.

The trigger frame shown in Figure 7 can be sent 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 a MU-BAR, the contents of the trigger-dependent user information field (shown in Figure 9) in the trigger frame are as shown in Figure 10.

Figure 10 shows the trigger-dependent user information field in the trigger frame for MU-BAR, showing the subfields BAR control and BAR information.

Figure 11 shows the contents of a Block ACK (BA) frame with the following subfields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used 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 that sent the frame. The BA Control field indicates the Block ACK policy. The BA info field contains the feedback of the transmission.

FIG. 12 shows the contents of a Buffer Status Request (BSR) frame with the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used 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 that sent the frame. The HT Control field indicates the variant of the BSR control subfield. The Format Indication field is used to indicate the format of the HT control field. When B0 and B1 are set to the first state (e.g., "1"), it indicates that the HT control field uses the HE format. This field is followed by the A-Control field. The A-Control field carries the buffer status report. The Control ID field indicates that the BSR is carried in the control information field. The Control Information field carries a variant of the BSR control subfield. The ACI Bitmap field indicates the access category for which the buffer status is reported. The Delta TID field indicates the number of TIDs for which the buffer status is reported. The ACI High field indicates the access category reported in the Queue Size High field. The Scaling Factor field indicates the units of the Queue Size High and Queue Size All fields. The Queue Size High field indicates the queue size of the AC indicated in the ACI High in units of the Scaling Factor. The Queue Size All field indicates the queue size of the AC indicated in the ACI Bitmap, also in units of the Scaling Factor.

Figure 13 shows an example of downlink multi-user transmission using OFDMA. The transmitting AP transmits a data packet to its receivers 1, 2, 3 and 4 using the HE MU PPDU format. After the AP finishes the first transmission, it sends a multi-user block ACK request (MU-BAR) to all receivers. Then, each receiver sends a block ACK (BA) back to the AP. According to the content of the BA, the AP decides to retransmit the packet to receivers 1, 3 and 4. The AP contends for the channel and waits for a given backoff time. The first retransmission occurs after the AP acquires channel access rights.

Figures 14A and 14B show an example of uplink multi-user transmission using OFDMA. The AP first sends a Buffer Status Report Request (BSRP) trigger frame to all senders 1, 2, 3, and 4. The senders then receive the BSRP trigger frame and send a Buffer Status Report (BSR) back to the AP. The AP then sends a trigger frame to all senders 1, 2, 3, and 4. In the trigger frame, channel resources are allocated based on the BSR received from the STAs. The senders receive the trigger frame and start their first transmission using the resource blocks allocated by the trigger frame. The multi-user transmission packets use the HE-TB PPDU format. The AP receives the packets from the senders and sends a BA frame to report whether the transmission was received correctly.

2.5. EDCA System Figure 15 shows a reference model of EDCA queues (Enhanced DCF Channel Access) in IEEE 802.11. This system includes six transmission queues and four access categories (ACs). Each AC competes for channel access rights using EDCA functions (EDCAF) so that packets in its corresponding transmission queue can be transmitted. Six transmission queues are shown as Voice (VO), Alternative Voice (A_VO), Alternative Video (A_VI), Video (VI), Best Effort (BE) and Background (BK). Each transmission queue determines the transmission order of packets in the queue.

The four ACs shown are Voice (VO), Video (VI), Best Effort (BE) and Background (BK). Each AC has an EDCA function (EDCAF) that provides channel contention capabilities. When multiple EDCAFs attempt to access the channel simultaneously, an internal collision avoidance mechanism is used. In the event of an internal collision, the EDCAF with the higher priority will gain channel access rights.

Table 1 lists the UP-AC mapping used in IEEE 802.11 EDCA queues. The second and third columns represent the user priority of the traffic and its corresponding IEEE 802.1D designation. In each row, traffic is added to the corresponding transmission queue and access category according to the user priority. Priority increases from the top row to the bottom row. Higher priority traffic has a higher probability of being transmitted early.

Figure 16 shows the implementation of the EDCA channel access procedure. As shown, we also compare the EDCA channel access when using only the Distributed Coordination Function (DCF).

When using DCF only, the STA can access the channel immediately and the medium is free for longer than the DCF interframe space (DIFS). Otherwise, the STA contends for the channel using CSMA/CA. After the STA senses the channel is idle for DIFS time, it starts counting down the backoff as long as the medium is idle. The number of backoff slots is randomly selected between zero and the contention window. The STA pauses the backoff countdown when a CCA busy occurs, e.g., the channel is busy. Once the backoff counts down to zero, the STA can start transmitting packets.

In EDCA, if the medium is free for longer than the arbitration interval frame transmission (AIFS) time of the AC, each EDCAF, as shown in FIG. 15, can immediately access the channel to acquire channel access rights. Note that AIFS[i] in the figure represents the AIFS time of AC i, which represents a given AC. Otherwise, each EDCAF uses CSMA/CA to contend for channel access rights for each AC that is trying to acquire channel access rights. After a STA senses that the channel is idle for the AIFS time, it starts counting down the backoff as long as the medium is idle. The number of backoff slots is randomly selected between zero and the contention window size. When a CCA busy occurs, e.g., the STA senses that the channel is busy, it pauses the backoff countdown. When the STA counts down the backoff to zero, it starts transmitting packets for that AC. Note that multiple EDCAFs can also contend for the channel at the same time. For example, as shown in FIG. 16, the EDCAFs of AC i and AC j (representing any two ACs) can contend for the channel at the same time.

When an internal collision occurs, the higher priority EDCAF wins channel access and the lower priority EDCAF doubles its contention window. An AC, if it is a VO or VI, can reserve a contention-free period, such as a TXOP, to transmit packets. The maximum duration of a TXOP is called the TXOP limit.

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

2.6. TXOP Sharing in IEEE 802.11ax
A STA may share a TXOP to transmit RTA frames from non-primary ACs only if all frames from the primary AC have been transmitted or if the STA transmits a MU PPDU. If frames from lower priority non-primary ACs are included in a MU DL MIMO PPDU (VHT MU PPDU) with a TXVECTOR parameter NUM_USERS greater than 1, these frames do not increase the duration of the PPDU beyond the duration required for the transmission of the primary AC's frames and any frames from the higher priority AC. If frames from higher or lower priority non-primary ACs are included in the HE MU PPDU by the AP, these frames do not increase the duration of the HE MU PPDU beyond the duration required for the transmission of the primary AC's frames and any frames from the higher priority AC. For a given user in a VHT/HE MU PPDU, any frames from the primary AC must be transmitted first, followed by any frames from the next higher priority AC.

3. Problem Statement Current wireless communication systems using EDCA do not distinguish between RTA and non-RTA frames, and all packets use the same TXOP sharing rule. This disclosure describes a mechanism that provides STAs with the flexibility to use a specific TXOP sharing mechanism for RTA packets to reduce latency.

4. Contributions of the Present Disclosure By utilizing the present disclosure, a STA can share the TXOP of a primary AC to transmit an RTA frame when no frames from the primary AC are being transmitted. In at least one preferred embodiment, the disclosed protocol considers "fairness" (fair channel usage) between the transmission of frames of the primary AC and the transmission of RTA frames from non-primary ACs.

5. EMBODIMENT 5.1. STA AND MLD HARDWARE CONFIGURATION Figure 17 shows an example embodiment 10 of STA hardware configured to execute the protocol of the present disclosure. An external I/O connection 14 is coupled to an internal bus 16 on which a CPU 18 and memory (e.g., RAM) 20 are preferably connected for executing a program(s) implementing the communication protocol. The host machine contains at least one modem 22 supporting communications coupled to at least one RF module 24, 28 each connected to one or more antennas 29, 26a, 26b, 26c-26n. RF modules with multiple antennas (e.g., antenna arrays) allow beamforming to be performed during transmission and reception. In this manner, the STA can transmit signals using multiple sets of beam patterns.

The bus 14 can connect various devices such as sensors and actuators to the CPU. On the processor 18, instructions are executed from the memory 20 to execute a program implementing a communication protocol that is executed to enable the STA to perform the functions of an access point (AP) station or a normal station (non-AP STA). It should also be understood that this programming is configured to operate in different modes (TXOP owner, TXOP sharing participant, source, intermediate, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinatee, etc.) depending on what role it plays in the current communication situation. Thus, the illustrated STA HW is configured with at least one modem and associated RF circuitry to provide communication on at least one band, such as the sub-6 GHz band and/or the mmW band.

Also, multiple instances of station hardware as shown can be combined into a multi-link device (MLD), which typically has a processor and memory to coordinate activity, although each STA in the MLD does not necessarily need a separate CPU and memory.

Figure 18 shows an example embodiment 40 of a Multi-Link Device (MLD) hardware configuration. The MLD has multiple STAs attached to it, each operating on a different frequency link. The MLD has external I/O 41 access to applications, which connects to an MLD management entity 48 with a CPU 62 and memory (e.g., RAM) 64 to allow the execution of a program(s) that implements a communication protocol at the MLD level. The MLD can distribute tasks to and collect information from each of its attached stations, STA1 42, STA2 44 to STA N 46, and share the information between its attached STAs.

In at least one embodiment, each STA in the MLD has its own CPU 50 and memory (RAM) 52, which are coupled through a bus 58 to at least one modem 54 connected to at least one RF circuit 56 having one or more antennas 60a, 60b, 60c-60n. This disclosure is primarily concerned with the sub-6 GHz band with omnidirectional antennas. The modem in combination with the RF circuit and associated antenna(s) transmits/receives data frames to/from nearby STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with the antennas.

It should be understood that each STA in an MLD does not necessarily require its own processor and memory, as they may share resources with each other and/or with the MLD management entity depending on the particular MLD implementation. It should be understood that the above MLD diagram is provided by way of example and not by way of limitation, and that the present disclosure may operate with a wide variety of MLD implementations.

5.2. STA Topology Considered In order to better illustrate the objectives of the disclosed technology, a certain network scenario is utilized in the embodiment.

19 shows an example topology (network scenario) 70 by way of example and not limitation. This topology is shown only to illustrate the purpose of the proposed technology and is not intended to limit it to a particular STA configuration. In this example topology, assume that there are seven stations (STAs) in an area (e.g., illustrated as a conference room), six of which are associated with three MLDs 72, 74, and 76. AP1 80 and AP2 82 belong to multi-link device (MLD) #1 72, STA1 84 and STA4 86 belong to MLD #2 74, and STA3 88 and STA5 90 belong to MLD #3 76. STA2 78 can be, for example, a non-AP STA operating on link 1 92, or a single-link MLD (i.e., a special MLD with only one STA operating on one link). STA1, STA2, and STA3 are associated with AP1 via links 1 94a and 96a, and STA4 and STA5 are associated with AP2 via links 2 94b and 96b.

Each STA and its associated AP can communicate with each other. Note that two BSSs can also be considered the same BSS because the two APs belong to the same MLD. In this example, we assume that all STAs use EDCA for random channel access on all links.

5.3 Differentiation Between RTA and Non-RTA Traffic 5.3.1 Low-Latency Traffic Stream (LLTS) Operation In this section, we introduce a mechanism called Low-Latency Traffic Stream (LLTS) to differentiate between RTA and non-RTA traffic. In general, LLTS can be utilized to differentiate traffic streams with special QoS requirements, such as delay, jitter and/or reliability, from other traffic.

In many cases, RTA generates traffic periodically as connection-oriented communication between STAs, referred to herein as RTA sessions. A STA may have multiple RTA sessions in a network. The STA may correctly manage these RTA sessions and apply the correct transmission scheme to the RTA packets of an RTA session. By way of example and not limitation, a low latency traffic stream (LLTS) may be utilized to identify the RTA traffic of an RTA session from upper layers.

20 illustrates an example embodiment 110 of terminating or modifying an LLTS, it being understood that this process can also be utilized for other LLTS operations, including modifying or deleting an LLTS. The STA interaction model can be the same as that defined in the IEEE 802.11 standard. The originator can be either an AP or a non-AP STA, and the recipient can also be either an AP or a non-AP STA. For simplicity, the LLTS configuration procedure in this section assumes that the originator in this example is a non-AP STA and the recipient is an AP. The figure shows the SME 112 and MLME 114 of the non-AP STA, and the MLME 116 and SME 118 of the AP.

A non-AP STA or MLD decides to initiate an LLTS setup procedure with an AP or AP MLD. The station management entity (SME) of the non-AP STA or MLD sends an MLME-LLTS.request message 120 (as shown in Table 3) to its MAC sublayer management entity (MLME). Upon receiving the MLME-LLTS.request message, the MLME of the non-AP STA collects the information in the MLME-LLTS.request message and sends an LLTS request frame 122 to the AP.
The AP's MLME receives the frame and generates an MLME-LLTS.indication message 124 (as shown in Table 4) to its own SME or to an SME of its MLD.

Next, the SME of the AP processes the LLTS request of the AP MLD (126) and sends an MLME-LLTS. response message 130 (as shown in Table 5) containing the LLTS setting result to that MLME. The MLME of the AP then sends an LLTS response frame 132 to the non-AP STA. The MLME of the non-AP STA receives the frame and sends an MLME-LLTS. confirm message 134 (as shown in Table 6) to that SME or to the SME of the MLD to which it belongs. As a result, the non-AP can confirm (recognize or determine) whether the LLTS setting was successful from the information contained in this message.

The AP or AP MLD may decide to modify or terminate the LLTS with a non-AP STA or MLD. The SME of the AP or the SME of the AP MLD sends an MLME-LLTS-TERM. request message 136 (as shown in Table 7) to the MLME of the AP or the MLME of the AP to which it belongs. When the MLME of the AP receives the MLME-LLTS-TERM. request message, it collects the information in the MLME-LLTS-TERM. request message and sends an LLTS response frame 138 to the non-AP STA. The MLME of the non-AP STA receives the frame and generates an MLME-LLTS-TERM. indication message 140 (as shown in Table 8) to the SME. The non-AP then knows that the LLTS has been terminated or modified.

The RTA traffic of an RTA session can be classified by the LLTS configuration. During the LLTS configuration procedure, the TCLAS element and the TCLAS process element are exchanged. If the upper layer information of the traffic matches the information in the RTA-TSPEC element as shown in Figure 23, the traffic from the upper layer is considered to be RTA traffic of the RTA session.

In at least one embodiment, the QoS requirements of the RTA session traffic are shared between the AP and non-AP STAs by exchanging RTA-TSPEC elements during the LLTS configuration procedure. The LLTS configuration can also be used to check whether the AP and non-AP STAs have sufficient resources to support RTA traffic transmission.

LLTS request frames and LLTS response frames for the same LLTS configuration procedure can also be sent over different links.

21 illustrates an example embodiment 150 of an LLTS request frame format utilized herein. The Frame Control field indicates the type of frame. The Duration field contains NAV information used for CSMA/CA channel access. The Address 1 field contains the address of the recipient of the frame. The Address 2 field contains the address of the STA that sent the frame. The Address 3 field contains the BSSID. The Sequence control field indicates the sequence number of the frame. The HT control field indicates further control information for the frame. The Action field indicates the action to be taken if it is an LLTS request frame, and has the subfields outlined below.

The Category and QoS Action fields indicate the type of action field, which in this case indicates that the action field is an LLTS request frame. The Dialog Token field specifies the LLTS request transaction and, in at least one embodiment, can be set to an integer that identifies the LLTS request frame. When the receiver receives this token field, it should respond with an LLTS response frame using the same dialog token. The Action field contains an LLTS request element with an Element ID indicating the type of element (in this example, indicating that it is an LLTS request element), a Length subfield indicating the length of the LLTS request element, and a subfield called LLTS Descriptor List indicating the sequence of LLTS descriptor fields. Each LLTS descriptor field is set to indicate an LLTS configuration request for traffic according to a particular specification and classification information. Once this information is received, the receiving STA, aware of the traffic specification and classification information, can decide whether to accept or reject the LLTS establishment request.

FIG. 22 illustrates an example embodiment 170 of the LLTS Descriptor field format. The LLID field provides an identification of the low latency transmission service, in which the non-AP STA sets a number representing the LLTS. The AP can receive this number and use it to identify the LLTS set by the non-AP STA. In at least one embodiment or mode, this field is reserved by non-AP STAs and can only be set by the AP. This field can be a Stream Classification Service (SCS) ID as defined in IEEE 802.11. The LL Length field contains the length of the LLTS Descriptor field. The Request Type field is set to indicate the type of LLTS descriptor. If the non-AP STA or MLD sets the Request Type field to "Add", it requests to add a new LLTS. The receiving AP or AP MLD should respond with whether or not it accepts the addition of the new LLTS.

When a non-AP STA or MLD sets the Request Type field to "Change", it requests to change an existing LLTS. When the AP or AP MLD receives this field, it can use the LLID to discover the LLTS. The AP or AP MLD can then accept or reject the change to the parameters of this LLTS.

If a non-AP STA or MLD sets the request type to "Remove", it requests that an existing LLTS be removed. When an AP or AP MLD receives this field, it can use the LLID to find and remove the LLTS.

The TCLAS field is the same as the TCLAS element defined in IEEE 802.11. The STA or MLD sets this field to indicate the traffic information from the higher layer. If the traffic is downlink and the higher layer information of the traffic matches the TCLAS information, the STA or MLD can use this information to identify the RTA traffic under this LLTS that arrived from this higher layer. The LLTS Descriptor field can contain multiple TCLAS fields.

The TCLAS Processing field is identical to the TCLAS processing element defined in IEEE 802.11. If multiple TCLAS fields are present in the LLTS descriptor field, the non-AP STA sets this field to indicate the rule for identifying RTA traffic using multiple TCLAS fields. When the AP receives this field in the LLTS descriptor field, it knows that multiple TCLAS fields can be used to identify traffic from higher layers.

The RTA-TSPEC field is set by a non-AP STA to indicate the specifications and QoS requirements of the RTA traffic under the LLTS. Upon receiving this field, the AP can use the information in this field to decide whether to grant or reject the LLTS request. This field also contains information on the traffic direction (e.g., uplink, downlink, peer-to-peer, or bidirectional) under this LLTS. The AP can also indicate the channel resources that can be allocated for the transmission of the RTA traffic under this LLTS.

The Optional Subelements field is set by the STA to indicate additional requests or information for traffic under this LLTS. When the AP receives this field, it can take into account the information in the optional subelements to decide whether to accept or reject the LLTS. Some examples of optional subelements are shown in Figures 24 and 25.

Figure 23 shows an example embodiment 190 of the RTA-TSPEC field contents. The TSPEC field can be identical to the TSPEC element defined in IEEE 802.11. The STA sets this field to indicate the TSID of the RTA traffic under the LLTS, traffic characteristics and partial QoS requirements for the RTA traffic under this RTA-TSPEC. With some exceptions, the TSID field in the TS information field of the TSPEC element can be set to a value between 0-7, or 0-15, or 8-15.

The RTA Attributes field indicates further QoS requirements for RTA traffic under this RTA-TSPEC. This field can appear with or within a TSPEC element only when LLTS is implemented in both the STA and the AP.

The Reliability field is set by the STA to indicate the packet loss requirement of the RTA traffic of the RTA-TSPEC. Upon receiving this field, the AP should estimate the resource allocation for the transmission of the RTA traffic under this RTA-TSPEC such that the packet loss of the RTA traffic under this RTA-TSPEC is less than the packet loss indicated in the Reliability field.

The reliability field can be set to the value of the packet error rate of the RTA traffic under this RTA-TSPEC. The AP should ensure that after accepting the LLTS of the RTA traffic, the packet error rate of the RTA traffic is not higher than the value set in the field. For example, if this field is set to 5%, the AP can have up to 5 RTA frames fail to transmit out of 100 RTA frames. The AP can reject the LLTS setting request if it cannot guarantee this packet error rate level.

Alternatively, the reliability field can be set to the value of the packet delivery ratio of the RTA traffic under this RTA-TSPEC. The AP should ensure that after accepting the LLTS of the RTA traffic, the packet delivery ratio of the RTA traffic does not fall below the value set in the field. For example, if the AP sets this field to 95%, it must successfully transmit at least 95 RTA frames out of 100 RTA frames. The AP can reject the LLTS setting request if it cannot guarantee this level of packet delivery ratio.

The Jitter field is set by the STA to indicate the jitter requirement of the RTA traffic under this RTA-TSPEC. Upon receiving this field, the AP estimates the resource allocation for the transmission of the RTA traffic under this RTA-TSPEC so that the jitter requirement of the RTA traffic under this RTA-TSPEC can be met.

The jitter field can be utilized in combination with the delay bound field of the original TSPEC element to indicate the average delay requirement of the RTA traffic under this RTA-TSPEC element. For example, if the delay bound field is set to 15 ms and the jitter field is set to 5 ms, then the average delay requirement of the RTA traffic under this RTA-TSPEC element is (delay bound-jitter) = 15 ms-5 ms = 10 ms. In one alternative, the average delay requirement of the RTA traffic under this RTA-TSPEC element is (delay bound-jitter/2) = 15 ms-5 ms/2 = 12.5 ms. The AP should ensure that the average delay of the RTA traffic under this RTA-TSPEC is less than the average delay requirement to meet the jitter requirement.

The MSDU Lifetime field indicates the time that an MSDU can be stored in the queue. If the Deterministic Service field is set to the first state (e.g., "1"), the STA sets this field to indicate the MSDU or A-MSDU lifetime of the RTA traffic under this RTA-TSPEC. If the STA receives this field and the Deterministic Service field is set to the first state (e.g., "1"), the MSDU or A-MSDU is discarded if it is not successfully transmitted within the MSDU lifetime. If the Deterministic Service field is set to the second state (e.g., "0"), this field is reserved. Note that this field can be replaced by the Delay Bound field in the TSPEC element.

The Deterministic Service field is set by the STA to indicate whether an MSDU for RTA traffic under this RTA-TSPEC is to be discarded when its expiration time expires. If the STA sets this field to a first state (e.g., "1"), an MSDU for RTA traffic under this RTA-TSPEC is to be discarded when its expiration time expires. Otherwise, the STA sets this field to a second state (e.g., "0"). If the STA receives this field set to the first state (e.g., "1"), an MSDU for RTA traffic under this RTA-TSPEC is to be discarded when its expiration time expires, as indicated in the MSDU Expiry Time field. If the STA receives this field set to "0", the MSDU Expiry Time field is reserved.

Figure 24 shows an example embodiment 210 of an optional sub-element carrying a higher layer stream ID. The Sub-element ID field contains the type of the sub-element, in this case an optional sub-element under the LLTS Request element. The Length field indicates the length of the optional sub-element field. The Higher Layer Stream ID field indicates the higher layer stream ID from the higher layer. The STA sets this field in the frame so that the receiver of this field can map the current LLTS to a higher layer traffic flow.

FIG. 25 illustrates an example embodiment 230 of an optional sub-element that carries an LLTS/TID-to-link mapping. The Sub-element ID field indicates the type of sub-element, in this case an optional sub-element under the LLTS Request element. The Length field indicates the length of the optional sub-element field. The LLTS level link mapping field provides a mechanism for determining the type of link mapping to be used. In at least one embodiment, this field may include a one-bit indication. When this field is set to a first state (e.g., "1"), the LLTS/TID-to-link mapping field is to use an LLTS-to-link mapping where the LLTS in the mapping is the LLTS indicated in the LLTS descriptor field. When this field is set to a second state (e.g., "0"), the LLTS/TID-to-Link Mapping field is to use a TID-to-Link mapping where the TID is the TID of the LLTS indicated in the LLTS Descriptor field.

The LLTS/TID to Link mapping field indicates the LLTS/TID to link mapping. The STA sets this field to indicate the links on which traffic under the LLTS can be transmitted. This field contains the following subfields:

The LLID field includes an identification of the low latency transmission service. A non-AP STA sets a number representing the LLTS. The AP can receive this number and use it to identify the LLTS set by the non-AP STA. This field can identify the stream classification service (SCS) defined in IEEE 802.11. The Number of Links field is set to indicate the number of link ID fields in the LLTS/TID to link mapping field. The Link ID field is set to indicate the links on which the traffic of the LLTS can be transmitted. One or more link ID fields can be used, and this example shows multiple (1 to n) link ID fields. The STA can set this field to indicate which link the traffic under this LLTS should be transmitted on when sending the LLTS/TID to link mapping in the LLTS request frame.

26 illustrates an example embodiment 250 of an LLTS response frame. The Frame Control field indicates the type of frame. The Duration field contains NAV information used for CSMA/CA channel access. The Address 1 field contains the address of the recipient of the frame. The Address 2 field contains the address of the STA that sent the frame. The Address 3 field contains the BSSID. The Sequence control field indicates the sequence number of the frame. The HT control field indicates further control information for the frame. The Action field indicates the action to be taken in the case of an LLTS request frame. The Action field includes the following subfields:

The Category and QoS Action subfields indicate the type of action field, which in this case is present in an LLTS response frame. The Dialog Token subfield specifies the LLTS response transaction, and in at least one embodiment, can be set to an integer that identifies the LLTS response frame. If the LLTS response frame is a response to an LLTS request frame, this field should be set the same as the LLTS request frame. Upon receiving this field, the receiver recognizes that the LLTS response frame is a response to an LLTS request frame with the same dialog token.

The Action field also contains an LLTS response element. The format of the LLTS request element is as follows: The Element ID field indicates the type of element, in this case an LLTS response element. The Length field indicates the length of the LLTS response element. The LLTS Status List field contains a series of LLTS status fields. Each LLTS status field is set to indicate the LLTS configuration response for traffic under a particular specification and classification information. Once the receiving STA receives this information, it can determine the result of the LLTS configuration of the RTA traffic or the modification of the existing LLTS.

FIG. 27 illustrates an example embodiment 270 of the LLTS Status field. The LLID field includes an identification of a low latency transmission service. The LL Length field includes the length of the LLTS Status field. The Response Type field is set to indicate the type of LLTS configuration result. If the AP sets the Response Type field to "Accept", it accepts the LLTS configuration request from the non-AP STA. Upon receiving this field, the non-AP STA can determine whether the LLTS configuration is successful. If the AP sets the Response Type field to "Modified", it modifies the existing LLTS with the non-AP STA. Upon receiving this field, the non-AP STA can determine that the LLTS with the corresponding LLID has been modified by the AP. The non-AP STA can accept the modification or start another LLTS to negotiate with this AP. If the AP sets the response type field to "Denied", it rejects the LLTS setup request from the non-AP STA. If the non-AP STA receives this field, it can start another LLTS setup with the AP. If the AP sets the response type to "Terminate", it terminates the existing LLTS with the non-AP STA. If the non-AP STA receives this field, it should recognize that the LLTS for the corresponding LLID has ended and delete the LLTS. Note that this field can be the same as the Status Code field defined in IEEE 802.11.

The TCLAS field can be the same as the TCLAS element defined in IEEE 802.11. The AP sets this field to indicate the information of the traffic from the upper layer. When a non-AP STA receives this field, it can use this information to identify the traffic under TTLS arriving from the upper layer if it is uplink. The LLTS status field can contain multiple TCLAS fields.

The TCLAS processing field can be identical to the TCLAS processing element defined in IEEE 802.11. If multiple TCLAS fields are present in the LLTS status field, the AP sets this field to indicate the rules for identifying RTA traffic using multiple TCLAS fields. When a non-AP STA receives this field in the LLTS status field, it can determine how to identify traffic from higher layers using multiple TCLAS fields.

The RTA-TSPEC field may be identical to the RTA-TSPEC element defined in FIG. 23. The AP sets this field to indicate the specifications and QoS requirements of the RTA traffic. Upon receiving this field, a non-AP STA knows that an LLTS decision is being made for traffic under the RTA-TSPEC. This field also contains information on the direction (e.g., uplink, downlink, peer-to-peer, or bidirectional) of the RTA traffic under this LLTS. The AP may also indicate the channel resources that may be allocated for the transmission of the RTA traffic of this LLTS.

The Optional Sub-elements field is set by the AP to indicate additional information or configuration for the traffic of this LLTS. Some examples of optional sub-elements are shown in Figures 24 and 25.

5.3.2. Differentiating RTA Traffic Figure 28 illustrates an example embodiment 310 for differentiating between RTA and non-RTA traffic. When the MAC layer of a STA or MLD receives traffic from a higher layer (312), a check is made to determine whether the traffic from the higher layer belongs to an existing LLTS (314). If the traffic is from a higher layer that belongs to an existing LLTS, then in block 316, it is registered that this traffic is RTA traffic that belongs to that LLTS. On the other hand, if the traffic from the higher layer does not belong to an existing LLTS, then in block 318, it is registered that this traffic is non-RTA traffic.

5.3.3. LLTS Examples Table 9 shows examples of LLTS (e.g., LLTS1-LLTS6). The originator column in the table indicates the STA or MLD that initiates the LLTS setup procedure, i.e., sends an LLTS request frame. The recipient column represents the STA or MLD that receives the LLTS request frame and sends an LLTS response frame. For example, the second row of the table represents an LLTS with LLID equal to 1, e.g., LLTS1. The originator of this LLTS is STA2, and the recipient can be AP1 or MLD1. The direction column relates to the direction of the LLTS. If it is downlink, the RTA traffic of this LLTS is sent from AP1 (or MLD1) to STA2, while in the case of uplink, it is in the reverse direction, and the TID of this LLTS is 8 and the user priority (UP) is 6, as exemplified. The Link column indicates over which link (eg, Link 1 and/or Link 2) the traffic under this LLTS is transmitted.

STAs can identify LLTSs by tuples of LLTS information such as <LLID, originator>, <LLID, recipient> or <LLID, originator, recipient>. The AP or AP MLD can use a unique LLID for each LLTS in its BSS, allowing each STA to use the LLID to identify LLTSs in the BSS by LLID alone, or can use the <LLID, BSSID> tuple to identify LLTSs in the BSS and OBSS.

5.4 TXOP Sharing for Transmitting RTA Packets 5.4.1 Flowchart The procedure of TXOP sharing for transmitting RTA frames from a non-primary AC will now be described. Compared with the current TXOP sharing rules in IEEE 802.11ax, the disclosed technology enables a STA to share the TXOP of the primary AC to transmit RTA frames from a non-primary AC even if there are untransmitted frames from the primary AC.

Figure 29 illustrates an example embodiment 330 of TXOP sharing for transmitting RTA traffic from a non-primary AC. RTA traffic is encapsulated on a frame-by-frame basis upon arrival at the EDCA queue. Frames carrying RTA traffic are denoted as RTA frames, and frames carrying non-RTA traffic are denoted as non-RTA frames. One or more frames may be included in a packet and transmitted over a link or channel. The AC associated with the EDCAF that has acquired the TXOP is called the primary AC.

Once the STA acquires a TXOP for the primary AC (332), a decision is made as to whether to share the TXOP to transmit frames from a non-primary AC during this TXOP (334).

If the STA determines not to share the TXOP to transmit a non-RTA frame from a non-primary AC, then in block 338, the frame 340 may be transmitted according to the current TXOP sharing rules defined in IEEE 802.11ax.

On the other hand, if the STA decides to share its TXOP to transmit an RTA frame from a non-primary AC, it may transmit the RTA frame from the non-primary AC even if there is an untransmitted frame from the primary AC (336). Then, in block 340, the STA transmits a frame from the non-primary AC(s) during the TXOP.

If a station decides to share the TXOP to transmit an RTA frame from a non-primary AC, note the following: The non-primary AC in block 336 can only represent an AC that has a higher priority than the primary AC. The RTA frame from the non-primary AC in this case can only represent an expiring frame (e.g., the frame will expire before the end of the TXOP).

The following sequences are possible during a TXOP:

(1) The STA shall/may transmit all/part of the RTA frame from the non-primary AC first, followed by the frame from the primary AC. The STA may follow, for example, any one of the following rules: (a) The RTA frame from the non-primary AC with a higher priority than the primary AC shall/may transmit first, followed immediately by the frame from the primary AC. (b) The RTA frame from the primary AC shall/may transmit first, followed by the RTA frame from the non-primary AC with a higher priority than the primary AC, followed by the non-RTA frame from the primary AC. (c) The RTA frame(s) from the non-primary AC with a higher priority than the primary AC that is a retransmission shall/may transmit first, followed by the frame from the primary AC.

(2) The STA may transmit RTA frames from non-primary ACs with lower priority than the primary AC only if: (a) these RTA frames are about to expire (e.g., the frames expire before the end of the TXOP), and/or (b) all frames from the primary AC have been transmitted, and/or (c) this low-priority AC previously shared a TXOP with the primary AC. For example, in case (2)(c), this low-priority AC shall have shared a TXOP with the primary AC at the current periodic time, such as a beacon interval. The TXOP sharing time with this low-priority AC must not be longer than the TXOP time that the low-priority AC shared with the primary AC during the current periodic time.

(3) The STA treats an RTA frame from a non-primary AC that has a higher priority than the primary AC in the same way as an RTA frame from the primary AC. In addition, the STA can also treat an RTA frame from a non-primary AC that has a higher priority than the primary AC as an RTA frame from the primary AC.

(4) When a STA transmits an MU PPDU (e.g., an MU PPDU for MU-MIMO or MU-OFDMA), it may include RTA frames and non-RTA frames from high or low priority non-primary ACs in the MU PPDU.

(a) The duration of the MU PPDU may be determined by the transmission and delay requirements of the specific frames in the MU PPDU. If other frames are included in the MU PPDU, they may not increase the duration of the MU PPDU beyond this requirement. For example, the specific frames may be (i) frames or RTA frames from the primary AC only, and/or (ii) RTA frames from all non-primary ACs, or from non-primary ACs with higher priority than the primary AC, or from the non-primary AC with the highest priority in the MU PPDU.

(b) For a given user (i.e., the STA receiving the MU PPDU), RTA frames from non-primary ACs with higher priority than the primary AC shall/may be transmitted earlier than frames from the primary AC. For example, (i) any RTA frames from the primary AC shall/may be transmitted first, followed by any RTA frames from higher priority ACs, followed by any non-RTA frames from the primary AC; (ii) any RTA frames from higher priority ACs shall/may be transmitted first, followed immediately by any frames from the primary AC; (iii) any frames from the primary AC shall/may be transmitted first, followed immediately by any frames from the higher priority AC; (iv) frames with shorter expiration times (e.g., MSDU expiration times) shall/may be transmitted first.

(5) The STA ensures to allocate some channel resources for transmitting frames from the primary AC during the TXOP. For example, the rules during the TXOP are as follows: (a) The STA shall not transmit frames from non-primary ACs until one or more frames from the primary AC are transmitted. (b) The STA shall limit the duration of TXOP sharing for transmitting RTA frames from non-primary ACs. For example, the STA limits the time of TXOP sharing (in units of the length of the TXOP period, such as 0.3 ms, or a percentage of the TXOP period, such as 20%) per TXOP or per periodic time (e.g., beacon interval). The AP can set this time limit in the associated STAs. (c) The STA shall not transmit an RTA frame from a non-primary AC until a certain amount of TXOP time (in units of the length of the TXOP period, e.g., 0.3 ms, or a percentage of the TXOP period, e.g., 20%) indicated by the dedicated time has been used to transmit frames from the primary AC, or until all frames (or all RTA frames) from the primary AC have been transmitted. (d) The STA shall not transmit an RTA frame from a non-primary AC until a certain amount of frames from the primary AC, e.g., as indicated by a dedicated byte (e.g., in bytes), have been transmitted, or until all frames (or all RTA frames) from the primary AC have been transmitted. (e) The STA shall follow the TXOP sharing rules defined in IEEE 802.11ax for a certain period of time indicated by the dedicated time (in units of the length of the TXOP period, e.g., 0.3 ms, or a percentage of the TXOP period, e.g., 20%) after the start time of the TXOP.

(6) During special channel periods such as R-TWT SP defined in IEEE 802.11be, the STA treats RTA frames from non-primary ACs as if they were from the primary AC.

5.4.2. Examples This section provides several examples that explain how STAs share the TXOP of the primary AC to transmit RTA frames from non-primary ACs. Network topologies for these examples are shown in FIG. 19. The traffic classification process between RTA and non-RTA can be the same or similar to the LLTS operation described in Section 5.3 or any other traffic classification procedure. As an example, we assume that each STA or MLD in the network topology has a traffic flow of RTA as shown in Table 9. The traffic under LLTS can be queued in the EDCA queue according to the UP-to-AC mapping shown in Table 1. Note that the UP of the traffic under LLTS is indicated as the UP shown in Table 9 in the LLTS configuration.

Figure 30 shows an example embodiment 350 of the state of the EDCA queue for AP1 or MLD1. A frame (MSDU, UP, RTA) is mapped (352) and placed in the queue.

AC_VO queue 354 represents an EDCA queue for AC VO, illustrated here as having three RTA frames under LLTS1, illustrated here as AC_VO(1) through AC_VO(3).

AC_VI queue 356 represents the EDCA queue for AC VI, shown here as having two RTA frames under LLTS2, exemplified here as AC_VI(1) and AC_VI(2), and one non-RTA frame, exemplified here as AC_VI(3).

AC_BE queue 358 represents the EDCA queue for an AC BE shown to have three non-RTA frames, illustrated as AC_BE(1) through AC_BE(3).

The AC_BK queue 360 represents the EDCA queue of AC BK, which is illustrated as being empty with no frames present in the queue.

These queues connect to EDCAFs 362, 364, 366 and 368 which compete for channel 370.

Figure 31 shows an example embodiment 390 where AP1 transmits RTA frames from non-primary ACs only during the TXOP. The figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during the TXOP 400. The EDCA queue state of AP1 or MLD1 is shown in Figure 30.

This example assumes the queue state when AP1 initiates an EDCA TXOP and no new frames arrive during the EDCA TXOP. Also assume that when the queue state is that of MLD1, MLD1 does not transmit on other links during the TXOP shown in this example.

When AP1 gets a TXOP 400 for the VI, it transmits RTA frames, illustrated as AC_VO(1) 404, AC_VO(2) 410, and AC_VO(3) 416, from the AC_VO queue along with their respective preambles 402, 408, and 414, to STA2. As shown in this example, AP1 transmits RTA frames from the AC_VO queue only during the TXOP. STA2 generates block acknowledgements 406, 412, and 418 upon receipt of each of these transmissions.

Note that AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

32 illustrates another example embodiment 430 of EDCA queue states for AP1 or MLD1. Frames are mapped (432) into the queues shown. As shown, AC_VO queue 434 represents an AC VO EDCA queue with one RTA frame under LLTS1, exemplified as AC_VO(1), and one non-RTA frame, exemplified as AC_VO(2). AC_VI queue 436 represents an AC VI EDCA queue with one RTA frame under LLTS2, exemplified as AC_VI(1), and one non-RTA frame, exemplified as AC_VI(2). AC_BE queue 438 represents an AC BE EDCA queue with one RTA frame under LLTS3, exemplified as AC_BE(1), and one non-RTA frame, exemplified as AC_BE(2). AC_BK queue 440 represents an EDCA queue for AC BK with no frames in the queue. Below each queue are respective EDCA functions 442, 444, 446, and 448 for acquiring and transmitting on channel 450.

Figure 33 shows an example embodiment 470 in which AP1 transmits RTA frames from higher priority non-primary ACs before frames from the primary AC during the TXOP. The figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during the TXOP 400. The EDCA queue state for AP1 or MLD1 is shown in Figure 32, and this example assumes the queue state when AP1 starts the TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. It also assumes that if the queue state is that of MLD1, MLD1 does not transmit on other links during the TXOP shown in this example.

When AP1 gets a TXOP 400 for the VI, it first transmits an RTA frame from the AC_VO queue, exemplified as AC_VO(1) 474, to STA2. It then transmits an RTA frame from the AC_VI queue, exemplified as AC_VI(1) 480, to STA1, followed by a non-RTA frame from the AC_VI queue, exemplified as AC_VI(2) 486, to STA3. Each of these transmissions is shown with its respective preamble 472, 478, and 484. The receiving station responds with a block acknowledgement (BA) 476, 482, and 488.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

Figure 34 shows an example embodiment 510 in which AP1 transmits an RTA frame from the primary AC first during the TXOP, followed by an RTA frame from a non-primary AC, followed by a non-RTA frame from the primary AC. The EDCA queue state of AP1 or MLD1 is as shown in Figure 32, assuming the queue state when AP1 starts the TXOP 400, and assuming that no new frames arrive during the EDCA TXOP. Also assume that when the queue state is that of MLD1, MLD1 does not transmit on other links during the example TXOP.

When AP1 acquires TXOP 400 for the VI, it first transmits an RTA frame from the AC_VI queue, exemplified as AC_VI(1) 514, to STA1. Next, it transmits an RTA frame from the AC_VO queue, exemplified as AC_VO(1) 520, to STA2. Next, it transmits a non-RTA frame from the AC_VI queue, exemplified as AC_VI(2) 526, to STA3.

Each of these transmissions is shown with a respective preamble 512, 518, 524. The receiving station responds with a block acknowledgement (BA) 516, 522, and 528.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

Figure 35 illustrates an example embodiment 530 in which AP1 transmits an RTA frame from a non-primary AC with lower priority than the primary AC. This figure shows the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400. The EDCA queue state of AP1 or MLD1 is shown in Figure 32, assuming the queue state when AP1 starts TXOP 400, and assuming no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP shown in this example.

When AP1 acquires a TXOP for VI, it first transmits an RTA frame from the AC_VI queue, exemplified as AC_VI(1) 534, to STA1. Next, it transmits an RTA frame from the AC_VO queue, exemplified as AC_VO(1) 540, to STA2. Next, it transmits an RTA frame from the AC_BE queue, exemplified as AC_BE(1) 546, to STA3 because of an upcoming expiration 550, which occurs before the end time of the TXOP.

Each of these transmissions is shown with a respective preamble 532, 538, and 544. The receiving station responds with a block acknowledgement (BA) 536, 542, and 548.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

Figure 36 shows an example embodiment 570 illustrating a third example of EDCA queue states for AP1 or MLD1. Frames are mapped (432) into the queues shown. AC_VO queue 574 has one RTA frame AC_VO(1) under LLTS1 and one non-RTA frame AC_VO(2). AC_VI queue 576 has two RTA frames under LLTS2 and one non-RTA frame AC_VI(3). AC_BE queue 578 has three non-RTA frames. AC_BK queue 580 has no frames in the queue.

Below each queue are shown respective EDCA functions 582, 584, 586 and 588 configured to acquire channel 590 and transmit on channel 590.

37 illustrates an example embodiment 610 in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, with the duration of the MU PPDU determined by a request to transmit the RTA frame from the non-primary AC. The figure illustrates the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400.

The EDCA queue state for AP1 or MLD1 is shown in Figure 36, which assumes the queue state when AP1 starts TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is for MLD1, it is assumed that MLD1 is not transmitting on other links during the TXOP shown in this example.

When AP1 acquires TXOP 400 for VI, it transmits MU OFDMA PPDUs (614) carrying an RTA frame from AC_VI to the queue of STA1, exemplified as AC_VI(1), an RTA frame from AC_VO to STA2, exemplified as AC_VO(1), and a non-RTA frame from the AC_VO queue to STA3, exemplified as AC_VI(3). Note that the duration of the MU OFDMA PPDU is determined by the duration of frame AC_VO(1), not the durations of frames AC_VI(1) and AC_VI(3).

AP1 then transmits another MU OFDM PPDU of 620 including an RTA frame from the AC_VI queue, illustrated as AC_VI(2), and non-RTA frames, illustrated as AC_VO(2) and AC_BE(2), in accordance with the IEEE 802.11 TXOP sharing rules.

Note that this and subsequent examples show short frames that are padded.

The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU. As a result, each frame of the MU PPDU is transmitted on behalf of a different RU through a different spatial stream. In this figure, the required feedback such as ACK or BA for the MU PPDU is also changed to feedback for the MU MIMO PPDU.

Transmissions 614 and 620 are shown with their respective preambles 612 and 618. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 616.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

38 illustrates an example embodiment 630 in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, with the duration of the MU PPDU being determined by the delay requirement of the RTA frame from the primary AC. The figure illustrates the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400.

The EDCA queue state for AP1 or MLD1 is shown in Figure 36, which assumes the queue state when AP1 starts TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, when the queue state is for MLD1, it is assumed that MLD1 is not transmitting on other links during the illustrated TXOP.

When AP1 acquires TXOP 400 of VI, it transmits MU OFDMA PPDUs (636) carrying an RTA frame from the AC_VI queue to STA1, exemplified as AC_VI(1), an RTA frame from the AC_VO queue to STA2, exemplified as AC_VO(1), and a non-RTA frame from the AC_VO queue to STA3, exemplified as AC_VI(3). Note that the duration of the MU OFDMA PPDU is determined by the duration of frame AC_VO(1), shown as expiration 638, and the duration of the MU OFDMA PPDU cannot exceed the maximum duration (validity period) 632 of frame AC_VI(1).

It can then be seen that AP1 transmits (644) another MU OFDM PPDU including an RTA frame from the AC_VI queue, exemplified as AC_VI(2), and non-RTA frames, exemplified as AC_VO(2) and AC_BE(2), in accordance with the IEEE 802.11 TXOP sharing rules.

The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, where each frame of the MU PPDU is transmitted through a different spatial stream on behalf of a different RU. The required feedback, such as ACK or BA, for the MU PPDU is also changed to feedback for the MU MIMO PPDU.

Transmissions 636 and 644 are shown with their respective preambles 634 and 642. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

39 illustrates another example embodiment 650 in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, with the duration of the MU PPDU being determined by the delay requirement of the RTA frame from the primary AC. This figure illustrates the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in FIG. 36 assumes the queue state when AP1 starts TXOP 400, and assumes that no new frames arrive during the EDCA TXOP. Furthermore, assume that when the queue state is that of MLD1, MLD1 does not transmit on other links during the TXOP shown in this example.

When AP1 obtains TXOP 400 for VI, it transmits MU OFDMA PPDUs (636) carrying an RTA frame from the AC_VI queue to STA1, exemplified as AC_VI(1), an RTA frame from the AC_VO queue to STA2, exemplified as AC_VO(1), and a non-RTA frame from the AC_VO queue to STA3, exemplified as AC_VI(3). Note that the duration 632 of the MU OFDMA PPDU is determined by the duration of frame AC_VO(1), but the duration of the MU OFDMA PPDU and expected feedback (e.g., BA) cannot exceed the validity period 652 of frame AC_VI(1), shown as expiration 652.

AP1 transmits another MU OFDM PPDU to STA1 carrying an RTA frame from the AC_VI queue, illustrated as AC_VI(2), and non-RTA frames, illustrated as AC_VO(2) and AC_BE(2), in accordance with the IEEE 802.11 TXOP sharing rules (644).

The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, where each frame in the MU PPDU is transmitted over a different spatial stream on behalf of a different RU. In this case, the required feedback such as ACK or BA for the MU PPDU is also changed to the feedback used for the MU MIMO PPDU.

Transmissions 636 and 644 are shown with their respective preambles 634 and 642. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

Figure 40 illustrates an example embodiment 670 in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, with the duration of the MU PPDU determined by the transmission requirements of the RTA frame from the primary AC. The figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in FIG. 36 assumes in this example the queue state of AP1 when AP1 starts TXOP 400, and assumes that no new frames arrive during the EDCA TXOP. Furthermore, assume that when the queue state is that of MLD1, MLD1 does not transmit on other links during the TXOP.

When AP1 obtains TXOP 400 for VI, it transmits (672) an MU OFDMA PPDU carrying an RTA frame from the AC_VI queue to STA1, exemplified as AC_VI(1), a non-RTA frame from the AC_VI queue to STA2, exemplified as AC_VO(2), and a non-RTA frame from the AC_VO queue to STA3, exemplified as AC_VI(3). Frame AC_VO(1) is not included in the first MU OFDMA PPDU because it is longer than the duration of frame AC_VI(1).

AP1 then transmits (674) another MU OFDM PPDU carrying RTA frame AC_VI(2), RTA frame AC_VO(1) and non-RTA frame AC_BE(2). The duration of frame AC_VO is shorter than the duration of frame AC_VI(2).

The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, where each frame in the MU PPDU is transmitted over a different spatial stream on behalf of a different RU. The required feedback such as ACK or BA for the MU PPDU is also changed to the feedback required for the MU MIMO PPDU.

Transmissions 672 and 674 are shown with their respective preambles 634 and 642. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

Figure 41 illustrates an example embodiment 710 in which AP1 limits the time of TXOP sharing. This figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in Figure 36 assumes the queue state when AP1 starts TXOP400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP.

When AP1 acquires TXOP 400 of VI, it first transmits an RTA frame from the AC_VI queue STA1, exemplified as AC_VI(1) (712). Next, AP1 transmits an RTA frame from the AC_VO queue, exemplified as AC_VO(1) to STA2 (716). After finishing transmitting frame AC_VO, AP1 finishes utilizing the maximum TXOP sharing time 714 during the current TXOP.

Next, AP1 transmits a frame from the AC_VI queue, illustrated as AC_VI(2), to STA1 (718).

Transmissions 712, 714, and 718 are shown with their respective preambles 632. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

Figure 42 illustrates an example embodiment 750 in which AP1 shares the TXOP after transmitting a certain number of frames from the primary AC. The figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during the TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in Figure 36 assumes the queue state when AP1 starts TXOP400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP.

As shown, AP1 must transmit a certain amount of frames from primary AC VI, indicated by dedicated_bytes, after the start of the TXOP before it can share the TXOP for transmission. AP1 can share the TXOP with RTA frames from non-primary ACs after the total bytes of frames from the primary AC exceed dedicated_bytes, even if there are untransmitted frames from the primary AC.

When AP1 gets a TXOP 400 for the VI, it first transmits RTA frames from AC_VI queues, exemplified as AC_VI(1) and AC_VI(2), to STA1 (754 and 756). AP1 then spends more than the dedicated time during the TXOP transmitting frames from the primary AC VI. AP1 then shares the TXOP to transmit RTA frames from the AC_VO queue, exemplified as AC_VO(1) (758).

AP1 can transmit a frame carrying information such as that shown in FIG. 44 to set the dedicated time for each STA.

Transmissions 754, 756, and 758 are shown with their respective preambles 632, and each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

AP1 can share the TXOP according to the rules defined in IEEE 802.11 before reaching the dedicated_byte of the primary frame.

Figure 43 illustrates an example embodiment 790 in which AP1 shares a TXOP after transmitting frames from the primary AC for a period of time. The figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during the TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in Figure 36 assumes the queue state when AP1 starts TXOP400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP.

As shown, there is a dedicated time 792 for primary AC VI after the start of the TXOP. AP1 can share the TXOP after the end of the dedicated time to transmit RTA frames from non-primary ACs, even if there are untransmitted frames from the primary AC.

When AP1 gets a TXOP 400 for the VI, it first transmits RTA frames 794 and 796 from the AC_VI queues, exemplified as AC_VI(1) and AC_VI(2), to STA1. AP1 then spends more than the dedicated time 792 transmitting frames from the primary AC VI during the TXOP. AP1 then shares the TXOP to transmit RTA frames from the AC_VO queue, exemplified as AC_VO(1), to STA2 (798).

In addition, AP1 can transmit a frame carrying information such as that shown in FIG. 44 to set the dedicated time for each STA.

Transmissions 794, 796, and 798 are shown with their respective preambles 632. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

AP1 can share the TXOP according to the rules defined in IEEE 802.11 before the expiration of the dedicated_time.

Figure 44 illustrates an example embodiment 830 of a frame carrying a dedicated time parameter setting. One STA, such as an AP, can send a frame containing this time parameter setting to another STA, such as an associated STA, to set the amount of dedicated time given to that STA. In some cases, an AP can also broadcast such a frame to set the dedicated time for all its associated STAs.

In at least one embodiment, the dedicated time parameter includes the following fields: The Frame Control field indicates the type of frame. The Duration field contains NAV information used for CSMA/CA channel access. The Address 1 field contains the address of the recipient of the frame. The Address 2 field contains the address of the STA that transmitted the frame. The Address 3 field contains the BSSID. The Sequence control field indicates the sequence number of the frame. The HT control field indicates further control information for the frame.

The Dedicated Time Set field is set by the STA to the amount of dedicated time for each AC of the receiving STA. The receiving STA can use the parameters in this field for TXOP sharing. The Element ID field identifies the type of element, which in this case is a dedicated time set element. The Length field indicates the length of the dedicated time set element.

The LLTS TXOP sharing field is set to indicate the sharing rules. In at least one embodiment, this field may be a 1-bit field that is set to a first state (e.g., "1") to indicate that the receiving STA may share the TXOP using rules such as those described in Section 5.4.1 for transmitting RTA frames from non-primary ACs. Otherwise, this field is set to a second state (e.g., "0") and the receiving STA follows only the TXOP sharing rules defined in IEEE 802.11.

The Enable Dedicated Time field is set to indicate whether dedicated time is present in each TXOP. When this field is set to a first state (e.g., true), dedicated time is present in each TXOP, such as marking the beginning of the TXOP. During the dedicated time, only traffic from the primary AC can be transmitted.

The Dedicated Time field is set for each AC by the transmitting STA. Upon receiving this dedicated time information, the STA will use the AC's dedicated time, starting from the TXOP start time, to transmit frames from that AC. Only then can the receiving STA decide to share the TXOP.

Note that, as explained in Figure 42, "dedicated time" can also be replaced with "dedicated byte" within the frame to set the dedicated byte parameter.

Figure 45 shows an example embodiment 850 illustrating a fourth example of EDCA queue states for AP1 or MLD1. Frames are mapped into the queues as shown (852). AC_VO queue 854 carries two RTA frames, exemplified as AC_VO(1) under LLTS1 and AC_VO(2) under LLTS6. AC_VI queue 856 holds one RTA frame under LLTS2, exemplified as AC_VI(1), and one non-RTA frame, exemplified as AC_VI(2). AC_BE queue 858 represents the EDCA queue for AC BE and holds three non-RTA frames, exemplified as AC_BE(1) through AC_BE(3). AC_BK queue 860 has no frames in it.

Below each queue are shown respective EDCA functions 862, 864, 866 and 868 for acquiring channel 870 and transmitting on channel 870.

Figure 46 illustrates an example embodiment 890 in which AP1 transmits MU OFDMA PPDUs and RTA frames from non-primary ACs are transmitted earlier than frames from the primary AC for each user. The figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in Figure 45 assumes the queue state when AP1 starts TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is for MLD1, it is assumed that MLD1 is not transmitting on other links during the illustrated TXOP.

When AP1 obtains TXOP 400 for VI, it transmits a MU OFDMA PPDU carrying RTA frames from the AC_VO queue, exemplified as AC_VO(1) and AC_VO(2), to STA1 and STA2, and a non-RTA frame from the AC_BE queue, exemplified as AC_BE(2), to STA3 (892).

AP1 then transmits another MU OFDM PPDU carrying RTA frames AC_VI(1) and AC_VI(2) and non-RTA frame AC_BE(3) to STA1, STA2, and STA3, respectively (894). For STA1 and STA2, AP1 first transmits the RTA frames from the higher priority non-primary AC, exemplified as AC VO.

The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, where each frame of the MU PPDU is transmitted on behalf of a different RU through a different spatial stream. The feedback required is also changed from the ACK or BA of the MU PPDU to feedback appropriate for the MU MIMO PPDU in the figure.

Transmissions 892 and 894 are shown with their respective preambles 632. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

In addition, AP1 can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

Figure 47 illustrates an example embodiment 930 of TXOP sharing when the AP transmits RTA frames from non-primary ACs in a MU PPDU later than the RTA frames from the primary AC, but earlier than the non-RTA frames from the primary AC for each user. The figure shows the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

The illustrated AP1 transmits (932) an MU OFDMA PPDU to first transmit RTA frames from the primary AC, then RTA frames from the high priority AC, and then non-RTA frames from the primary AC for each user.

The EDCA queue state of AP1 or MLD1 shown in Figure 45 assumes the queue state when AP1 starts TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, when the queue state is that of MLD1, it is assumed that MLD1 is not transmitting on other links during the illustrated TXOP.

When AP1 acquires TXOP 400 for VI, it transmits (932) a MU OFDMA PPDU including RTA frames exemplified as AC_VI(1) and AC_VO(1) and a non-RTA frame from the AC_BE queue exemplified as AC_BE(2).

AP1 then transmits another MU OFDM PPDU (934) including RTA frames AC_VO(2) and AC_VI(2) and non-RTA frame AC_BE(3). AP1 transmits to user STA1 first an RTA frame from a primary AC, exemplified as AC VI, and then an RTA frame from a high priority non-primary AC, exemplified as AC_VO. AP1 transmits to user STA2 first an RTA frame from a high priority non-primary AC, such as AC_VO, and then a non-RTA frame from a primary AC, such as AC_VI.

The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, where each frame of the MU PPDU is transmitted on behalf of a different RU through a different spatial stream. The required feedback, such as ACK or BA for the MU PPDU, is also changed to a type of feedback appropriate for the MU MIMO PPDU.

Transmissions 932 and 934 are shown with their respective preambles 632. Each receiving station responds to receipt of these transmissions with a block acknowledgement (BA) 640.

Note that an AP (e.g., AP1) can reserve a TXOP using RTS/CTS or MU-RTS/CTS before transmitting a frame.

6. General Scope of the Embodiments The present technology may be described herein with reference to flowcharts of methods and systems according to embodiments of the present technology, and/or procedures, algorithms, steps, operations, formulas, or other computational expressions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and/or steps) of the flowchart, and any procedures, algorithms, steps, operations, formulas, or computational expressions, may be implemented by various means, such as hardware, firmware, and/or software that includes one or more computer program instructions embodied in the form of 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 a special purpose computer, or any other programmable processing device to produce a machine, such that the computer program instructions executing on the computer processor or other programmable processing device produce means for performing the specified function(s).

Thus, the blocks of the flowcharts and the procedures, algorithms, steps, operations, formulas, or computational expressions described herein support combinations of means for performing a particular function(s), combinations of steps for performing a particular function(s), and computer program instructions for performing a particular function(s) as embodied in computer readable program code logic means. It will also be understood that each block of the flowcharts described herein and any procedures, algorithms, steps, operations, formulas, or computational expressions, and combinations thereof, can also be implemented by a dedicated hardware-based computer system performing the particular function(s) or step(s), or a combination of dedicated hardware and computer readable program code.

Furthermore, these computer program instructions, embodied in computer readable program code or the like, may be stored in one or more computer readable memories or memory devices capable of directing a computer processor or other programmable processing device to function in a particular manner, such that the instructions stored in the computer readable memories or memory devices produce an article of manufacture that includes instruction means for performing the functions specified in the block(s) of the flowchart(s). The computer program instructions may be executed by the computer processor or other programmable processing device to generate a computer-implemented process by performing a series of operational steps on the computer processor or other programmable processing device, such that the instructions executing on the computer processor or other programmable processing device provide steps for performing the functions specified in the block(s) of the flowchart(s), procedure(s), algorithm(s), step(s), operation(s), formula(s), or computational expression(s).

Further, as used herein, the term "program" or "program executable" will be understood to mean one or more instructions executable by one or more computer processors to perform one or more functions described herein. The instructions may be embodied in software, firmware, or a combination of software and firmware. The instructions may be stored locally on a non-transitory medium of the device or remotely, such as on a server, or all or a portion of the instructions may be stored locally or remotely. Remotely stored instructions may be downloaded (pushed) to the device upon user initiation or automatically based on one or more factors.

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

From the description herein, it will be understood that the present disclosure includes multiple technology implementations, including but not limited to the following:

An apparatus for wireless communication in a network, comprising: (a) an access point (AP) radio station (STA) operating as either an AP or a non-AP STA on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is applied to multiple access categories (ACs); (b) a wireless communication circuit configured to wirelessly communicate packets carrying frames over a channel with other wireless stations (STAs), which may be any of the STAs; (c) a processor coupled to the wireless communication circuit and operating as a STA on a WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, (d) the instructions, when executed by the processor, perform one or more steps including: (i) distinguishing real-time application (RTA) traffic from non-RTA traffic; (ii) acquiring a transmission opportunity (TXOP) for a primary AC; and (iii) utilizing the remaining portion of the TXOP channel resources to transmit RTA frames from non-primary ACs, even if there may be untransmitted frames from the primary AC during the TXOP.

An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit configured to wirelessly communicate packets carrying frames over a channel with other wireless stations (STAs), either APs or non-AP STAs, on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is applied to multiple access categories (ACs), as an STA operating as either an access point (AP) wireless station (STA) or a non-AP STA; (b) a processor coupled to the wireless communication circuit and operating as an STA on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, wherein the instructions, when executed by the processor, perform the following functions: (i) exchange specifications of quality of service (QoS) requirements and higher layer information of traffic flows to set up a traffic stream between a non-AP MLD and an AP ML; and (ii) exchange specifications of quality of service (QoS) requirements and higher layer information of traffic flows to set up a traffic stream between a non-AP MLD or an AP ML to distinguish between other traffic streams having the same traffic identifier (TID) as the traffic stream. An apparatus that performs one or more steps including: (d) (iii) the non-AP MLD and/or the AP MLD assigning a low latency identification (LLID) to the traffic stream; (d) (iv) the non-AP MLD and/or the AP MLD determining over which link or links the traffic stream should be transmitted; and (d) (iv) the non-AP MLD and/or the AP MLD distinguishing traffic belonging to the traffic stream from other traffic.

A wireless communication method in a network, the method including: (a) communicating from an STA operating as either an access point (AP) or a non-AP wireless station (STA) to another wireless station (STA) that is either an AP or a non-AP STA on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is applied to multiple access categories (ACs) via a channel; (b) distinguishing real-time application (RTA) traffic from non-RTA traffic; (c) acquiring a transmission opportunity (TXOP) for a primary AC; and (d) transmitting an RTA frame from a non-primary AC by utilizing the remaining portion of the channel resources even if there is an untransmitted frame from the primary AC during the TXOP.

The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including ensuring that a minimum required channel resource is available within the channel resources to transmit a frame from the primary AC during the TXOP.

A device or method of any preceding implementation in which a STA that has secured the minimum required channel resources to transmit frames from a primary AC can use the minimum required channel resources for TXOP sharing when transmission of all frames from the primary AC is completed.

The instructions, when executed by a processor, perform a step of the apparatus or method of any preceding implementation, further including the STA not setting the minimum required channel resources for transmitting frames from the primary AC during the TXOP.

The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including the STA ensuring that a given minimum number of bytes is transmitted from the primary AC during the TXOP.

The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including the STA ensuring that it is given the minimum channel time required to transmit frames from the primary AC during the TXOP.

The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including the STA transmitting an RTA frame from a non-primary AC even if no frame from the primary AC was transmitted during the TXOP.

The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including the STA transmitting an RTA frame from a non-primary AC during a TXOP only if all RTA frames from the primary AC have been transmitted.

The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including the STA transmitting an RTA frame from a higher priority non-primary AC during the TXOP before transmitting an RTA frame from the primary AC.

The instructions, when executed by a processor, perform a step further including the STA transmitting an RTA frame from a low priority non-primary AC during the TXOP.

The instructions, when executed by a processor, perform a step of the apparatus or method of any preceding implementation further including the STA transmitting an MU PPDU packet whose length is determined by the transmission and/or delay requirements of the RTA frame from the primary AC.

The instructions, when executed by a processor, perform a step of the apparatus or method of any preceding implementation, further comprising the STA limiting the time for which it shares the TXOP.

The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including allowing the STA to transmit RTA frames from non-primary ACs earlier than frames from the primary AC only if the expiration of those RTA frames is imminent.

The instructions, when executed by a processor, perform a step of the apparatus or method of any preceding implementation, further including the STA acquiring a TXOP of the primary AC and sharing the TXOP with a lower priority non-primary AC.

The instructions, when executed by a processor, perform a step of any preceding implementation of the apparatus or method, further comprising: when the non-AP MLD requests the AP MLD to set up a traffic stream, sending a frame to the AP MLD that includes a traffic flow specification, QoS requirements, upper layer information, and an LLID.

The instructions, when executed by a processor, perform a step of any preceding implementation of the apparatus or method, further comprising the AP MLD responding to the request to set up the traffic stream with a frame including a traffic flow specification, QoS requirements, higher layer information, LLID, and status to the non-AP MLD to indicate whether the request was granted or rejected.

The instructions, when executed by a processor, perform a step of the apparatus or method of any preceding implementation, further comprising the AP MLD and the non-AP MLD performing traffic flow specification and QoS requirement exchange by using a traffic specification (TSPEC) element configured to include additional QoS requirements as defined in IEEE 802.11ax.

The apparatus or method of any preceding implementation, wherein the further QoS requirements include jitter and packet loss requirements.

The instructions, when executed by a processor, perform a step of any preceding implementation of the apparatus or method, further comprising the AP MLD and the non-AP MLD exchanging traffic flow information by transmitting frames over different links.

The instructions, when executed by a processor, perform a step of distinguishing one traffic stream from another traffic stream in response to the AP MLD and the non-AP MLD communicating a tuple including a non-AP MAC address and an LLID. The apparatus or method of any preceding implementation.

The instructions, when executed by a processor, perform a step of the apparatus or method of any preceding implementation further comprising the AP MLD transmitting an unsolicited frame to terminate or modify an existing traffic stream.

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

As used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly indicates otherwise. Reference to an object in the singular does not mean "the only one" unless expressly stated otherwise, but rather means "one or more."

In this disclosure, constructs such as "A, B, and/or C" indicate that any of A, B, or C, or any combination of items A, B, and C, may be present. Constructs such as "at least one of" followed by a group of listed elements indicate that at least one of the group of elements is present, including possible combinations of any of the listed elements, where applicable.

References in this disclosure to "an embodiment," "at least one embodiment," or similar embodiment phrases indicate that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of the disclosure. Thus, these references to various embodiments do not necessarily refer to all the same embodiment, or to a particular embodiment that is different from all other embodiments described. References to embodiments should be interpreted to mean that the particular features, structures, or characteristics of a given embodiment can be combined in any suitable manner in one or more embodiments of the disclosed device, system, or method.

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

Relative terms such as first and second, top and bottom, etc., used in this document are used merely to distinguish one entity or action from another entity or action, and do not necessarily require or imply any such actual relationship or ordering between such entities or actions.

The terms "comprises, comprising, has, having, includes, including, contains, containing" or any other variation of these terms are intended to include non-exclusive inclusions, such that a process, method, article, or device that comprises, has, or includes a list of elements does not include only those elements, but may also include other elements not expressly listed or specific to such process, method, article, or device. An element following "comprises ... a, has ... a, includes ... a, contains ... a" does not exclude, without further constraints, the presence of additional identical elements in the process, method, article, or device that comprises, has, or includes that element.

As used herein, the terms "approximately," "approximate," "substantially," "essentially," and "about," or any variation thereof, are used to describe and explain slight variations. When used in relation to events or circumstances, these terms can mean that the events or circumstances will definitely occur, and that the events or circumstances are highly likely to occur. When used in relation to a numerical value, these terms can mean a variation range of ±10% or less, such as ±5% or less, ±4% or less, ±3% or less, ±2% or less, ±1% or less, ±0.5% or less, ±0.1% or less, or ±0.05% or less of the numerical value. For example, being "substantially" aligned can mean an angle variation range of ±10° or less, such as ±5° or less, ±4° or less, ±3° or less, ±2° or less, ±1° or less, ±0.5° or less, ±0.1° or less, or ±0.05° or less.

Quantities, ratios, and other numerical values may also be presented in a range format herein. Such range formats are used as a shorthand for convenience and should be understood to include numerical values explicitly specified as the limits of the range, but should be understood to include all individual numerical values or subranges contained within the range, as if each such numerical value and subrange were expressly set forth. For example, a ratio within 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, about 4, and subranges such as about 10 to about 50, about 20 to about 100, etc.

The term "coupled," as used herein, is defined as connected, but not necessarily in a direct mechanical connection. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in ways not listed.

The benefits, advantages, solutions to problems, and any element(s) that cause or make any benefit, advantage, or solution more pronounced are not to be construed as critical, necessary, or essential features or elements of the technology described herein, or of any or all of the claims.

In addition, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Inventive subject matter may be embodied in less than all features of a single disclosed embodiment.

The Abstract of the Disclosure is presented to allow the reader to quickly ascertain the nature of the technical disclosure. It is presented with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

It is understood that some jurisdictions have a practice of requiring the deletion of one or more portions of the present disclosure after filing. Thus, readers should refer to the application as of its filing date for the original content of the disclosure. The deletion of any of the disclosed content should not be construed as an abandonment, forfeiture, or dedication to the public of any subject matter of the application as originally filed.

The following claims are hereby incorporated into this disclosure, with each claim standing on its own as a separate inventive subject matter.

Although the description in this specification contains many details, these should not be construed as limiting the scope of the disclosure, but merely as illustrating some of the currently preferred embodiments. Therefore, the scope of the disclosure will be understood to fully include other embodiments that would be apparent to one skilled in the art.

Structural and functional equivalents of elements of the embodiments of the present disclosure known to those skilled in the art are also expressly incorporated herein by reference and are intended to be included in the scope of the claims. Moreover, no elements, components, or method steps of the present disclosure are intended to be publicly available, regardless of whether they are explicitly recited in the claims. No claim element herein should be construed as a "means-plus-function" element unless the element is explicitly recited using the phrase "means for". No claim element herein should be construed as a "step-plus-function" element unless the element is explicitly recited using the phrase "step for".

表２
デフォルトパラメータ設定

表３
MLME-LLTS要求

表４
MLME-LLTS.indication

表５
MLME-LLTS.response

表６
MLME-LLTS.confirm

表７
MLME-LLTS-TERM.request

表８
MLME-LLTS-TERM.indication

表9
LLTS例

330 Example embodiment 332 STA acquires TXOP of AC represented by primary AC and decides to share TXOP with non-primary AC(s) 334 Has the STA decided to share the TXOP to transmit frames from non-primary AC(s)?
336 STA follows TXOP sharing rules for non-RTA frames defined in IEEE 802.11ax. 338 STA can transmit RTA frames from non-primary ACs regardless of whether there are frames from the primary AC to transmit. 340 STA transmits frames from non-primary AC(s) during TXOP.


Table 1
User Priority - (UP) Mapping

Table 2
Default Parameter Settings

Table 3
MLME-LLTS request

Table 4
MLME-LLTS.indication

Table 5
MLME-LLTS.response

Table 6
MLME-LLTS.confirm

Table 7
MLME-LLTS-TERM.request

Table 8
MLME-LLTS-TERM.indication

Table 9
LLTS Example

Claims (14)

1. An apparatus for wireless communication in a network, comprising:
(a) a wireless communication circuit configured as an STA operating as either an access point (AP) wireless station (STA) or a non-AP STA to wirelessly communicate packets carrying frames over a channel with other wireless stations (STAs), either APs or non-AP STAs, in a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is applied to multiple access categories (ACs);
(b) a processor coupled to the wireless communication circuitry and operating as a STA on a WLAN;
(c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs;
(d) the instructions, when executed by the processor,
(i) distinguishing real-time application (RTA) traffic from non-RTA traffic;
(ii) obtaining a transmission opportunity (TXOP) for the primary AC; and
(iii) transmitting RTA frames from non-primary ACs using the remaining portion of the TXOP channel resources even if there may be untransmitted frames from the primary AC during the TXOP; and
Performing one or more steps including:
The instructions, when executed by the processor, perform the steps further including ensuring that a minimum required channel resource for transmitting a frame from a primary AC during a TXOP is available within the channel resources.
An apparatus comprising: A STA that has secured a minimum required channel resource for transmitting a frame from a primary AC can use the minimum required channel resource for TXOP sharing when transmission of all frames from the primary AC is completed.
2. The apparatus of claim 1 . The instructions, when executed by the processor, perform a step further comprising: the STA not configuring minimum required channel resources for transmitting frames from a primary AC during a TXOP.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform steps further including the STA ensuring that a given minimum number of bytes is transmitted from a primary AC during a TXOP.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform the steps further including: the STA ensuring that a minimum amount of channel time is provided for transmitting frames from a primary AC during a TXOP.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform the steps further comprising: the STA transmitting an RTA frame from a non-primary AC even if no frame from a primary AC was transmitted during a TXOP.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform the steps further comprising: the STA transmitting an RTA frame from a non-primary AC during a TXOP only if all RTA frames from a primary AC have been transmitted.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform a step further comprising: the STA transmitting an RTA frame from a higher priority non-primary AC during a TXOP before transmitting an RTA frame from a primary AC.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform steps further including the STA transmitting an RTA frame from a low priority non-primary AC during a TXOP.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform the steps further including the STA transmitting an MU PPDU packet, the length of which is determined by transmission and/or delay requirements of an RTA frame from a primary AC.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform steps further including limiting a time for the STA to share a TXOP.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform the steps further including allowing the STA to transmit RTA frames from non-primary ACs earlier than frames from a primary AC only if the RTA frames are about to expire.
2. The apparatus of claim 1. The instructions, when executed by the processor, perform steps further including the STA acquiring a TXOP of a primary AC and sharing the TXOP with a lower priority non-primary AC.
2. The apparatus of claim 1. 1. A method for wireless communication in a network, comprising:
(a) communicating via a channel from a STA operating as either an access point (AP) or a non-AP wireless station (STA) to another wireless station (STA) that is either an AP or a non-AP STA in a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is applied to multiple access categories (AC);
(b) distinguishing real-time application (RTA) traffic from non-RTA traffic; and
(c) obtaining a transmission opportunity (TXOP) for the primary AC; and
(d) transmitting an RTA frame from a non-primary AC using the remaining portion of the channel resources even if there is an untransmitted frame from the primary AC during the TXOP; and
The apparatus includes:
The method , further comprising ensuring that a minimum required channel resource is available within the channel resources for transmitting a frame from the primary AC during the TXOP .

Images