CN116097900A - Sharing EDCA TXOP with RTA traffic - Google Patents

Abstract

A communication circuit and protocol for a Wireless Local Area Network (WLAN) using single EDCA and/or multi-user (MU) EDCA in which frames for real-time applications (RTAs) may utilize a shared transmit opportunity (TXOP) to reduce transmission latency. The protocol is configured in several ways to ensure communication fairness, such as by ensuring that the minimum required channel resources are provided for transmitting frames from the primary AC during a TXOP. AP MLD and non-AP MLD are also supported and may exchange information about distinguishing traffic flows from other traffic flows having the same Traffic Identifier (TID) in determining which links to use to transmit the traffic flows.

Description

Sharing EDCA TXOP with RTA traffic

Cross Reference to Related Applications

The present application claims priority and benefit from U.S. patent application Ser. No. 17/509,017 filed on 10/24 of 2021, which is incorporated herein by reference in its entirety. The present application also claims priority and benefit from U.S. provisional patent application Ser. No. 63/168,434, filed 3/31/2021, which is incorporated herein by reference in its entirety.

Statement regarding federally sponsored research or development in the united states

Is not suitable for

Reminder for copyrighted material

Some 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 facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner does not disclaim any rights to keep this patent document secret, including but not limited to rights in accordance with 37c.f.r. ≡1.14.

Technical Field

The technology of the present disclosure relates generally to wireless network communications using Enhanced Distributed Channel Access (EDCA) defining multiple Access Categories (ACs), and more particularly to allowing real-time application (RTA) packet transmissions to utilize transmit opportunity (TXOP) sharing to reduce latency.

Background

Current wireless 802.11 technology using CSMA/CA focuses on high throughput performance of the network but lacks sufficient support for low latency traffic such as that required for real-time applications (RTA) sending RTA frames. Each RTA frame requires low latency due to its high timeliness requirement, since the RTA frames are only valid to be delivered within a certain period of time. In addition to RTA traffic, problems may occur when defining multiple Access Categories (ACs) for RTA traffic using Enhanced Distributed Channel Access (EDCA).

Thus, enhanced handling of RTA traffic sharing of TXOPs is required when EDCA is used. The present disclosure meets this need and provides additional benefits.

Disclosure of Invention

Current wireless communication systems using Enhanced Distributed Channel Access (EDCA) do not distinguish between RTA packets and non-RTA packets, and thus all packets use the same TXOP sharing rules under EDCA. The present disclosure is configured to increase the flexibility of RTA packet transmission in order to reduce latency when EDCA transmit opportunity (TXOP) sharing is utilized. The main benefits provided by the disclosed protocol are as follows: (a) When there is a frame from the primary AC that is not transmitted, the STAs can share the TXOP of the primary AC to transmit RTA frames; and (b) taking into account fairness (equality, average) between transmitting frames of the primary AC and transmitting RTA frames from non-primary AC.

Other aspects of the technology described herein will be brought out in the later part of the specification, the detailed description of which is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon.

Drawings

The techniques described herein will be more fully understood by reference to the accompanying drawings, in which:

Fig. 1 is a data field diagram of the contents of a TSPEC element defined in IEEE 802.11.

Fig. 2 is a data field diagram of a TS information unit as defined in IEEE 802.11.

Fig. 3 is a data field diagram of a TCLAS element as defined in IEEE 802.11.

Fig. 4 is a data field diagram of a TCLAS processing unit defined in IEEE 802.11.

Fig. 5 is a data field diagram of an HE multi-user (MU) PPDU format for downlink multi-user transmission as defined in IEEE 802.11.

Fig. 6 is a data field diagram of a HE Trigger (TB) PPDU format for uplink multi-user transmission as defined in IEEE 802.11.

Fig. 7 is a data field diagram of a Trigger Frame (TF) as defined in IEEE 802.11.

Fig. 8 is a data field diagram of the common information field of TF as defined in IEEE 802.11.

Fig. 9 is a data field diagram of a user information field of a Trigger Frame (TF) as defined in IEEE 802.11.

Fig. 10 is a data field diagram of a trigger related user information field in a Trigger Frame (TF) for MU-BAR as defined in IEEE 802.11.

Fig. 11 is a data field diagram of a Block ACK (BA) frame as defined in IEEE 802.11.

Fig. 12 is a data field diagram of a Buffer Status Request (BSR) as defined in IEEE 802.11.

Fig. 13 is a communication diagram of downlink multi-user transmission using OFDMA as utilized in IEEE 802.11.

Fig. 14A and 14B are communication diagrams of uplink multi-user transmission using Orthogonal Frequency Division Multiple Access (OFDMA) as defined in IEEE 802.11.

Fig. 15 is a transmit queue diagram of a reference model for (enhanced DCF channel access) EDCA queues as defined in IEEE 802.11.

Fig. 16 is a communication diagram implementing a channel access procedure for EDCA as defined in IEEE 802.11.

Fig. 17 is a hardware block diagram of wireless station hardware in accordance with at least one embodiment of the present disclosure.

Fig. 18 is a hardware block diagram of a station configuration, such as contained in multi-link device hardware, in accordance with at least one embodiment of the present disclosure.

Fig. 19 is a topology of a WLAN with seven STAs, six of which are within three MLDs, according to at least one example of the present disclosure.

Fig. 20 is a communication diagram of terminating or modifying LLTS in accordance with at least one example of the present disclosure.

Fig. 21 is a data field diagram of an LLTS request frame in accordance with at least one example of the present disclosure.

Fig. 22 is a data field diagram of an LLTS descriptor field format in accordance with at least one example of the present disclosure.

Fig. 23 is a data field diagram of RTA-TSPEC field content in accordance with at least one example of the present disclosure.

Fig. 24 is a data field diagram of an optional subunit carrying a higher layer stream ID in accordance with at least one example of the present disclosure.

Fig. 25 is a data field diagram of an alternative subunit carrying LLTS/TID to link mapping in accordance with at least one example of the present disclosure.

Fig. 26 is a data field diagram of an LLTS response frame in accordance with at least one example of the present disclosure.

Fig. 27 is a data field diagram of an LLTS status field in accordance with at least one example of the present disclosure.

FIG. 28 is a flow chart distinguishing RTA traffic from non-RTA traffic in accordance with at least one example of the present disclosure.

Fig. 29 is a workflow diagram of TXOP sharing of sending RTA traffic from non-primary ACs in accordance with at least one example of the present disclosure.

Fig. 30 is a transmit queue diagram of an EDCA queue for AP1 or MLD1 in accordance with at least one example of the disclosure.

Fig. 31 is a communication diagram of AP1 transmitting RTA frames from a non-primary AC only during a TXOP in accordance with at least one example of the present disclosure.

Fig. 32 is a transmit queue diagram of another EDCA queue for AP1 or MLD1 in accordance with at least one example of the disclosure.

Fig. 33 is a communication diagram of an AP1 transmitting an RTA frame from a higher priority non-primary AC prior to a frame from a primary AC during a TXOP in accordance with at least one example of the present disclosure.

Fig. 34 is a communication diagram of an AP1 first transmitting an RTA frame from a primary AC during a TXOP, followed by an RTA frame from a non-primary AC, followed by a non-RTA frame from the primary AC, in accordance with at least one example of the present disclosure.

Fig. 35 is a communication diagram of an AP1 transmitting RTA frames from a non-primary AC having a lower priority than a primary AC in accordance with at least one example of the present disclosure.

Fig. 36 is a transmit queue diagram of a third example of EDCA queue status for AP1 or MLD1 in accordance with at least one example of the present disclosure.

Fig. 37 is a communication diagram of an AP1 transmitting MU OFDMA PPDUs carrying RTA frames from a non-primary AC, wherein the duration of the MU PPDUs is determined by the transmission requirements of the RTA frames from the non-primary AC, in accordance with at least one example of the present disclosure.

Fig. 38 is a communication diagram of an AP1 transmitting a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, wherein the duration of the MU PPDU is determined by the latency requirement of the RTA frame from the primary AC, in accordance with at least one example of the present disclosure.

Fig. 39 is a communication diagram of another example of an AP1 transmitting an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, wherein the duration of the MU PPDU is determined by the latency requirement of the RTA frame from the primary AC, in accordance with at least one example of the present disclosure.

Fig. 40 is a communication diagram of an AP1 transmitting MU OFDMA PPDUs carrying RTA frames from a non-primary AC, wherein the duration of the MU PPDUs is determined by the transmission requirements of the RTA frames from the primary AC, in accordance with at least one example of the present disclosure.

Fig. 41 is a communication diagram of an AP1 restricting time of TXOP sharing in accordance with at least one example of the present disclosure.

Fig. 42 is a communication diagram of an AP1 sharing a TXOP after transmitting a certain number of frames from a primary AC in accordance with at least one example of the present disclosure.

Fig. 43 is a communication diagram of an AP1 sharing a TXOP after transmitting frames from a primary AC for a certain amount of time in accordance with at least one example of the present disclosure.

Fig. 44 is a data field diagram of a frame for carrying dedicated time parameter settings in accordance with at least one example of the present disclosure.

Fig. 45 is a transmit queue diagram of a fourth example of EDCA queue status for AP1 or MLD1 in accordance with at least one example of the present disclosure.

Fig. 46 is a communication diagram of an AP1 transmitting a MU OFDMA PPDU according to at least one example of the present disclosure, wherein for each user, an RTA frame from a non-primary AC is transmitted earlier than a frame from a primary AC.

Fig. 47 is a communication diagram of TXOP sharing in a MU PPDU according to at least one example of the present disclosure, wherein an AP transmits RTA frames from a non-primary AC later than RTA frames from a primary AC but earlier than non-RTA frames from a primary AC for each user.

Detailed Description

1. Introduction to the invention

Real-time applications (RTAs) require low latency and use best effort communication. Data generated from RTAs is referred to as RTA traffic and is packetized into RTA frames at a transmitter Station (STA). Further, data generated from non-time sensitive applications is referred to herein as non-RTA traffic and is packetized into non-RTA frames at the transmitter STA, which transmits packets carrying the frames over a channel (link) to the receiver STA.

When RTA traffic reaches the EDCA queue, it will be encapsulated in frames. Frames carrying RTA traffic are indicated by RTA frames and frames carrying non-RTA traffic are indicated by non-RTA frames. One or more frames may be included in one packet and transmitted over a link or channel. The AC associated with EDCAF that obtains EDCA TXOP is referred to as the primary AC.

RTA frames require low latency due to their high timeliness requirements for delivery, since RTA frames are only valid for a certain period of time. One solution in CSMA/CA wireless technology is to have STAs with more opportunities to transmit RTA frames, e.g., using a high priority AC for transmitting RTA frames.

Due to the random channel access scenario, STAs need to sense and contend for channel access before transmitting each frame. For EDCA, STAs may use short channel contention times of a high priority AC to speed up channel access. But there is a possibility that the low priority AC accesses the channel earlier than the high priority AC. The TXOP time obtained by the low priority AC causes a delay in the transmission of RTA frames from the high priority AC.

To avoid delay due to the TXOP time obtained by the low priority AC, the STA may transmit the RTA frame using the TXOP time obtained by the low priority AC. The task of sharing the TXOPs of the primary AC to send frames from the non-primary AC is challenging due to the coexistence of RTA traffic and non-RTA traffic. The challenges in this process can be summarized as: (a) A distinction is made between RTA traffic and non-RTA traffic, and when there is a packet from a primary AC that is not being transmitted, the TXOPs of the primary AC are shared to transmit RTA packets from non-primary ACs.

2. Current 802.11 operation

2.1 TSPCs units

Fig. 1 depicts the content in a TSPEC element defined in IEEE 802.11, with the following fields. The element ID indicates the type of element, which in this example is indicated as a TSPCelement. The length field indicates the length of the TSPEC element. The TS information field indicates traffic flow information, having subfields shown in fig. 2. The nominal MSDU size field indicates the nominal size of the MSDU or A-MSDU belonging to the TS under this TSPCs. The maximum MSDU size field indicates the maximum size of the MSDU or A-MSDU belonging to the TS under this TSPCs. 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 an MSDU belonging to a TS is not arrived or transmitted before the TS is deleted. The pause interval field indicates a time interval during which there is no arrival or transmission of an MSDU belonging to a TS before the generation of successive QoS (+) CF polls for that 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 specified by the MAC SAP for transmitting the MSDU or a-MSDU belonging to the TS under this TSPEC. The average data rate field is the average data rate specified by the MAC SAP for transmitting MSDUs or a-MSDUs belonging to the TS under this TSPEC. The peak data rate field is the maximum data rate specified by the MAC SAP for transmitting MSDUs or a-MSDUs belonging to the TS under this TSPEC. The burst size field indicates the maximum burst of MSDUs or a-MSDUs that belong to the TS under this TSPEC at the peak data rate. 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 lowest PHY rate for transmitting an MSDU or a-MSDU belonging to a TS under this TSPEC. The allowed spare bandwidth field indicates the ratio of the bandwidth used to transmit an MSDU or a-MSDU belonging to a TS under this TSPEC and its retransmission to the bandwidth used to transmit the MSDU or a-MSDU once at the minimum PHY rate. The media time field indicates the time allowed for accessing the media. The DMG attribute field is given when the TSPEC is applied to a directional multi-gigabit (DMG) BSS.

Fig. 2 depicts contents in a TS information field defined in IEEE 802.11. The traffic type field specifies whether the traffic is periodic. The TSID field indicates an ID number to identify the TS. The direction field specifies the direction of data transmission. The access policy field specifies the method used to obtain channel access. The aggregation field specifies whether or not aggregation scheduling is required. The APSD field indicates whether automatic PS delivery is used. The user priority field indicates the user priority of the MSDU or a-MSDU belonging to the TS. The TS information Ack (acknowledgement) policy field indicates whether an Ack is required and what form of Ack is used. The schedule field indicates the type of schedule.

2.2 TCLAS Unit

Fig. 3 depicts the content in a TCLAS element defined in IEEE 802.11. The element ID field indicates the type of element; in this case a TCLAS cell. The length field indicates the length of the TCLAS element. The user priority field indicates the user priority from an upper layer. The frame classifier field indicates a method to classify frames from an upper layer.

2.3 TCLAS processing Unit

Fig. 4 depicts the contents of a TCLAS processing unit defined in IEEE 802.11. The element ID field indicates the type of element; in this case a TCLAS processing unit. The length field indicates the length of the TCLAS processing unit. The processing field indicates the method used to classify traffic from the upper layers when there are multiple TCLAS elements.

2.4 Multi-user Transmission

Multi-user transmissions are available in wireless networks, such as IEEE 802.11. Since ieee802.11ax, networks have been able to support multi-user transmissions in both the uplink and downlink. Multi-user transmission in IEEE802.11ax includes a MIMO mode and an OFDMA mode, which may be utilized separately or together.

IEEE802.11ax transmits data in a multi-user mode using a multi-user transmission packet format such as that shown in fig. 5 and 6. When a plurality of users transmit or receive a multi-user transmission packet, all users share the same PLCP header of the multi-user transmission packet. Each user then uses separate resource blocks to transmit or receive data carried by the multi-user transmission packet, including RU allocation, MCS, and the like.

IEEE802.11ax defines a variety of PLCP Protocol Data Unit (PPDU) formats to transmit packets in different multi-user transmissions, as will be described below. It should be noted that PLCP is an acronym for physical layer convergence protocol.

Fig. 5 depicts an HE multi-user (MU) PPDU format used for downlink multi-user transmission in IEEE802.11 ax. The fields are depicted as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, data, and PE.

Fig. 6 depicts a HE Trigger (TB) PPDU format used for uplink multi-user transmission in IEEE 802.11 ax. The fields in the HE TB PPDU format are identical to the fields in the HE single user PPDU format except that the HE-STF field is 8 mus. The fields are depicted as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, HE-LTFs, data, and PE.

Fig. 7 depicts the content of the Trigger Frame (TF). The frame control field indicates the type of frame. The duration field contains NAV information that is used for CSMA/CA channel access. The RA field contains the address of the recipient for the frame. The TA field contains the address of the STA that sent the frame. The common information field contains information for all assigned STAs, as shown below in fig. 8. The user information field includes information for each STA, shown in fig. 9. The common information field and the user information field provide separate resource block allocation information for each user.

Fig. 8 depicts common information fields of the trigger frame shown in fig. 7. Ext> theext> subfieldsext> ofext> theext> commonext> informationext> fieldext> areext> depictedext> asext> triggerext> typeext>,ext> lengthext>,ext> concatenationext> indicationext>,ext> requiredext> CSext>,ext> BWext>,ext> GIext> andext> LTFext> typesext>,ext> MUext> MIMOext> LTFext> modeext>,ext> HEext> -ext> LTFext> symbolext> numberext>,ext> STBCext>,ext> LDPCext> extraext> symbolext> segmentext>,ext> APext> TXext> powerext>,ext> packetext> extensionext>,ext> spaceext> reuseext>,ext> dopplerext>,ext> GIext> andext> LTFext> typesext>,ext> HEext> -ext> SIGext> -ext> aext> reservationext>,ext> reservationext> andext> triggerext> relatedext> commonext> informationext>.ext>

Fig. 9 depicts the user information field of the trigger frame shown in fig. 7, with the following subfields: AID12 subfield, RU allocation, coding type, MCS, DCM, SS allocation, target RSSI, reservation and trigger related user information.

By setting the trigger type in the common information field to "2", the trigger frame as shown in fig. 7 may be transmitted as a multi-user block Ack request (MU-BAR). When the trigger frame is a MU-BAR, the contents of the trigger-related user information field (as shown in fig. 9) in the trigger frame are shown in fig. 10.

Fig. 10 depicts the trigger related user information fields in a trigger frame for a MU-BAR, wherein BAR control and BAR information subfields are shown.

Fig. 11 depicts the contents of a Block ACK (BA) frame having the following subfields. The frame control field indicates the type of frame. The duration field contains NAV information that is used for CSMA/CA channel access. The RA field contains the address of the recipient for the frame. The TA field contains the address of the STA that sent the frame. The BA control field indicates the policy of the block ACK. The BA information field contains feedback for the transmission.

Fig. 12 depicts 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 NAV information that is used for CSMA/CA channel access. The RA field contains the address of the recipient for the frame. The TA field contains the address of the STA that sent the frame. The HT control field indicates a BSR control subfield variant. The format indication field is used to indicate the format of the HT control field. When B0 and B1 are set to a first state (e.g., "1"), it indicates that the HT control field uses the HE format. This field follows the a control field. The a-control field carries a buffer status report. The control ID field indicates that the BSR is carried in the control information field. The control information field carries a BSR control subfield variant. The ACI bitmap field indicates the access class 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 scale factor field indicates the units of the queue size high and the entire field of the queue size. The queue size high field indicates the queue size of the AC indicated in ACI high in units of scale factors. The queue size all field indicates the queue size of the AC indicated in the ACI bitmap summary, also in units of scale factors.

Fig. 13 depicts an example of downlink multi-user transmission using OFDMA. The transmitter AP transmits data to its receivers 1, 2, 3 and 4 using the HE MU PPDU format. After ending the initial transmission, the AP transmits a multi-user block ACK request (MU-BAR) to all receivers. The receiver then sends Block ACKs (BAs) back to the APs, respectively. Based on the content in the BA, the AP decides to send packets to receivers 1, 3 and 4. The AP contends for the channel and waits for a given backoff time. The first retransmission is shown to occur after the AP gains channel access.

Fig. 14A and 14B depict examples of uplink multi-user transmission using OFDMA. The AP first transmits a buffer status report request (BSRP) trigger frame to all the transmitters 1, 2, 3 and 4. The sender then receives the BSRP trigger frame and sends its Buffer Status Report (BSR) back to the AP. Subsequently, the AP transmits a trigger frame to all the transmitters 1, 2, 3 and 4. Channel resources are allocated in a trigger frame based on BSR received from the STA. The transmitter receives the trigger frame and starts initial transmission using the resource blocks allocated by the trigger frame. The multi-user transmission packet uses the HE-TB PPDU format. The AP receives the packet from the transmitter and transmits a BA frame to report whether the transmission was received correctly.

2.5, EDCA System

Fig. 15 shows a reference model of the EDCA queue (enhanced DCF channel access) in IEEE 802.11. The system includes six transmit queues and four Access Categories (ACs). Each AC uses EDCA functions (EDCAF) to contend for channel access so that packets may be transmitted in their respective transmit queues. The six transmit queues are depicted as speech (VO), replacement speech (a_vo), replacement video (a_vi), video (VI), best Effort (BE), and Background (BK). Each transmit queue determines the order of transmission of packets in the queue.

The four ACs depicted are Voice (VO), video (VI), best Effort (BE), and Background (BK). Each AC has an EDCA function (EDCAF) to provide a function of channel contention. The internal collision avoidance mechanism is used when multiple EDCAF attempts to access the channel simultaneously. When an internal collision occurs, the EDCAF with higher priority gains channel access.

Table 1 lists the UP-to-AC mapping used in the EDCA queue of IEEE 802.11. The second and third columns represent the user priority of the traffic and their corresponding names in IEEE 802.1D. In each row, traffic will be queued in a corresponding transmit queue and access class according to user priority. The priority rises from top row to bottom row. Traffic with higher priority has a higher probability of being sent earlier.

Fig. 16 shows the implementation of a channel access procedure for EDCA. EDCA channel access is also compared to when only Distributed Coordination Function (DCF) is used, as shown in the figure.

When only DCF is used, the STA can immediately access the channel and the medium is idle more than DCF inter-frame space (DIFS) time. Otherwise, the STAs contend for the channel using CSMA/CA. After sensing that the channel is idle for DIFS time, the STA starts a countdown backoff as long as the medium is idle. The number of backoff slots is randomly selected between zero and its contention window. The STA pauses the countdown backoff when the CCA is busy, e.g., when the STA senses that the channel is busy. When the backoff countdown reaches zero, the STA may begin transmitting packets.

In EDCA, each EDCAF as shown in fig. 15 can access a channel immediately when the medium is idle more than any inter-frame space (AIFS) time of the AC in order to obtain channel access. It should be noted that AIFS [ i ] as shown in the figure represents AIFS time corresponding to AC i, which represents a given AC. Otherwise, each EDCAF contends for channel access using CSMA/CA for each AC attempting to obtain channel access. After sensing that the channel is idle for the AIFS time, the STA starts a countdown backoff as long as the medium is idle. The number of backoff slots is randomly selected between zero and its contention window size. The STA pauses the countdown backoff when the CCA is busy, e.g., when the STA senses that the channel is busy. When the backoff countdown reaches zero, the STA starts transmitting packets for the AC. It should be noted that multiple EDCAFs may contend for the channel in parallel. For example, as shown in fig. 16, EDCAF for AC i and AC j (representing any two ACs) may contend for the channel at the same time.

When an internal collision occurs, the EDCAF with higher priority gains channel access, and the EDCAF with lower priority doubles its contention window. When the ACs are VO or VI, they can reserve a contention-free period (such as TXOP) for transmitting packets. The maximum duration of a TXOP is referred to as the TXOP limit.

Table 2 lists default parameter settings for EDCA channel access. Each AC has its own minimum contention window and maximum contention window. The AIFSN indicates the AIFS duration by the number of backoff slots. The TXOP represents the maximum duration of the TXOP that each AC can reserve at a time.

TXOP sharing in 2.6, IEEE 802.11ax

The STAs can share the TXOP to transmit RTA frames from non-primary ACs only when all frames from primary ACs have been transmitted or when the STAs transmit MU PPDUs. When frames from low priority non-primary ACs are included in a MU DL MIMO PPDU (or VHT MU PPDU) and the TXVECTOR parameter num_users is greater than 1, the frames do not increase the duration of the PPDU beyond that required for transmission of the primary AC's frames and any frames from high priority ACs. When frames from higher or lower priority non-primary ACs are included in the HE MU PPDU by the AP, the frames do not increase the duration of the HE MU PPDU beyond that required for transmission of the primary AC's frames and any frames from the high priority AC. For a given user in the VHT/HE MU PPDU, any frame from the primary AC should be sent first, followed by any frame from the immediately next higher priority AC.

3. Statement of problem

Current wireless communication systems using EDCA do not recognize RTA frames and non-RTA frames, and all packets use the same TXOP sharing rules. To reduce latency, the present disclosure describes mechanisms that provide STAs with flexibility to use a particular TXOP sharing mechanism for RTA packets.

4. Contribution of the invention

By utilizing the present disclosure, STAs can share the TXOP of the primary AC to transmit RTA frames when frames from the primary AC are not transmitted. In at least one preferred embodiment, the disclosed protocol takes into account "fairness" (for equal use of the channel) between transmitting frames of primary ACs and transmitting RTA frames from non-primary ACs.

5. Examples

5.1, STA and MLD hardware configuration

Fig. 17 illustrates an exemplary embodiment 10 of STA hardware configured to execute the protocols of the present disclosure. External I/O connection 14 is preferably coupled to internal bus 16, and cpu 18 and memory (e.g., RAM) 20 are connected to internal bus 16 for executing program(s) embodying a communications protocol. The host machine houses at least one modem 22 to support communication coupled to at least one RF module 24, 28 connected to one or more antennas 29, 26a, 26b, 26c through 26n, respectively. An RF module with multiple antennas (e.g., an antenna array) allows beamforming to be implemented during transmission and reception. In this way, the STA may transmit signals using a set of multiple beam patterns.

Bus 14 allows various devices to be connected to the CPU, such as sensors, actuators, and the like. The instructions from the memory 20 are executed on the processor 18 to perform a program that implements a communication protocol that is executed to allow a STA to implement the functions of an Access Point (AP) station or a regular station (non-AP STA). It should also be appreciated that the program is configured to operate in different modes (TXOP holder, TXOP sharing participant, source, intermediary, destination, first AP, other AP, station associated with the first AP, station associated with other AP, coordinator, coordinated, etc.) depending on the role played in the current communication context. Thus, the STA HW is shown configured with at least one modem and associated RF circuitry for providing communication over at least one frequency band, such as the sub-6GHz band and/or mmW band.

It should also be noted that multiple instances of station hardware as shown in the figures may be combined into a multi-link device (MLD) that will typically have a processor and memory for coordination activities, not always requiring separate CPUs and memory for each STA within the MLD.

Fig. 18 shows an exemplary embodiment 40 of a multi-link device (MLD) hardware configuration. A plurality of STAs are attached to the MLD, each STA operating on a different frequency link. The MLD has external I/O41 access to the application, which is connected to an MLD management entity 48 having a CPU 62 and a memory (e.g. RAM) 64 to allow execution of program(s) implementing the communication protocol of the MLD hierarchy. The MLD may assign tasks and collect information to/from each of the dependent stations STA 1, STA2, 44 to STA N46 to which it is connected, and share information among the various dependent stations.

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

It should be appreciated that each STA of an MLD does not necessarily need its own processor and memory, as STAs may share resources with each other and/or with the MLD management entity, depending on the particular MLD implementation. It should be appreciated that the MLD illustrations given above are by way of example and not limitation, and that the present disclosure may operate with a variety of MLD implementations.

5.2 STA topology for consideration

To better explain the goals of the disclosed technology, a network scenario is utilized in the examples.

Fig. 19 shows an exemplary embodiment 70 of a topology (network scenario) given by way of example and not limitation. The topology is provided merely to explain the goals of the proposed technology and not to limit it to a particular STA configuration. In this exemplary topology, it is assumed that there are 7 Stations (STAs) within an area (e.g., illustrated as a conference room), 6 of which are associated with 3 MLDs 72, 74 and 76. AP1 80 and AP2 82 are attached to multi-link device (MLD) #1 72, STA1 84 and STA4 86 are attached to MLD #2 74, STA3 88 and STA5 90 are attached to MLD #376.STA2 78 may be, for example, a non-AP STA operating on Link1 92 or a single Link MLD (i.e., a special MLD having only one STA and operating on one Link). STA1, STA2, and STA3 are associated with AP1 through links 1 a and 96a, and STA4 and STA5 are associated with AP2 through links 2 94b and 96 b.

Each STA and its associated AP may communicate with each other. It should be noted that it is also possible to treat two BSSs as the same BSS, since both APs of the two BSSs are attached to the same MLD. In this example, all STAs are considered to use EDCA for random channel access on all links.

5.3 differentiation of RTA traffic from non-RTA traffic

5.3.1 Low Latency Traffic Stream (LLTS) operations

In this section, a mechanism called low latency traffic flow (LLTS) is introduced to distinguish RTA traffic from non-RTA traffic. Generally speaking, LLTS can be utilized to distinguish between traffic flows having particular QoS requirements (such as latency, jitter, and/or reliability) and other traffic.

RTA often periodically generates traffic as connection-oriented communications between STAs, referred to herein as RTA sessions. It is possible that a STA may have multiple RTA sessions in the network. The STA can properly manage these RTA sessions and apply an appropriate transmission scheme to RTA packets of the RTA sessions. By way of example and not limitation, low latency traffic flows (LLTS) may be used to identify RTA traffic from an RTA session of an upper layer.

FIG. 20 illustrates an exemplary embodiment 110 of terminating or modifying LLTS; it should also be appreciated that the process may be used for other LLTS operations, including changing or removing LLTS. The interworking model of the STA may be the same as defined in the IEEE 802.11 standard. It is also possible that the initiator may be an AP or non-AP STA and the receiver may be an AP or non-AP STA. To simplify the description, during the LLTS setup procedure of this section, it is assumed that the initiator in this example is a non-AP STA and the receiver is an AP. The figure shows the SME 112 and MLME 114 of a non-AP STA, and the MLME 116 and SME 118 of an AP.

The non-AP STA or MLD decides to initiate an LLTS setup procedure with the AP or AP MLD. A Station Management Entity (SME) of a non-AP STA or MLD sends a MLME-llts. Requests message 120 (as shown in table 3) to its MAC sublayer management entity (MLME). When the MLME of the non-AP STA receives the MLME-LLTS. Request t message, it gathers the information in the MLME-LLTS. Request t message and sends an LLTS request frame 122 to the AP. The MLME of the AP receives the frame and generates an MLME-llts. Indication message 124 (as shown in table 4) to its SME or the SME of its affiliated MLD.

Subsequently, the AP's SME processes 126 the LLTS request of the AP MLD and sends to its MLME an MLME-LLTS. Response message 130 containing the LLTS setup result (as shown in Table 5). Subsequently, the MLME of the AP 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 its SME or the SME of its affiliated MLD. The non-AP may then determine (recognize or decide) from the information contained therein whether the LLTS setting was successful.

The AP or AP MLD may decide to modify or terminate 128 the LLTS of the 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 to the MLME of the AP or the MLME of its affiliated AP (as shown in Table 7). When the MLME of the AP receives the MLME-LLTS-TERM.request message, it gathers 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 its SME. Subsequently, the non-AP recognizes that the LLTS is terminated or modified.

RTA traffic for RTA sessions can be classified by LLTS setup. During the LLTS setup procedure, the TCLAS element and the TCLAS processing element are swapped. If the upper layer information of the traffic matches the information in the RTA-TSPCs unit as shown in FIG. 23, the traffic from the upper layer is treated as RTA traffic for the RTA session.

In at least one embodiment, the QoS requirements for traffic for an RTA session are shared between an AP and a non-AP STA by exchanging RTA-TSPEC elements during an LLTS setup procedure. LLTS settings may also be utilized to check if AP and non-AP STAs have sufficient resources to support RTA traffic transmissions.

It should also be noted that the LLTS request frame and the LLTS response frame for the same LLTS setup procedure may be sent over different links.

Fig. 21 illustrates an exemplary 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 that is used for CSMA/CA channel access. The address 1 field contains the address of the recipient for the frame. The address 2 field contains the address of the STA transmitting 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 additional control information for the frame. The action field indicates the action to be performed when it is an LLTS request frame and has subfields as outlined below.

The category field and QoS action field indicate the type of action field; the action field in this example indicates that this is an LLTS request frame. The dialog token field specifies the LLTS request transaction; and in at least one embodiment may be set to an integer that identifies the LLTS request frame. When the receiver receives the token field, it should respond to LLTS response frames with the same dialog token. The action field indicates the LLTS request unit, with a subfield (in this example, LLTS request unit) indicating the unit ID of the unit type; the length subfield indicates the length of the LLTS request unit; the list of LLTS descriptors provides a sequence of LLTS descriptor fields. Each LLTS descriptor field is set to an LLTS set request that indicates traffic under specific specification and classification information. Upon receiving this information, the receiver STA recognizing the traffic specification and classification information may decide to accept or reject the LLTS setting request.

Fig. 22 illustrates an exemplary embodiment 170 of an LLTS descriptor field format. The LLID field provides an identification of the low latency transmission service; the non-AP STA sets a number to represent LLTS in this field. The AP receives the number and may use the number to identify LLTS set by the non-AP STA. In at least one embodiment or mode, this field may be reserved by non-AP STAs and only the AP sets this field. This field may be a Stream Class 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. When the non-AP STA or MLD sets the request type to "Add", the non-AP STA or MLD requests to Add a new LLTS. The receiver AP or AP MLD should respond with an acceptance to add a new LLTS.

When the non-AP STA or MLD sets the request type field to "Change", the non-AP STA or MLD requests to Change the existing LLTS. When the AP or AP MLD receives this field, LLTS can be found using LLID. The AP or AP MLD then accepts the change of parameters of the LLTS or refuses to change LLTS.

When the non-AP STA or MLD sets the request type to "Remove", the non-AP STA or MLD requests to Remove the existing LLTS. When the AP or AP MLD receives this field, the LLID can be used to find the LLTS and remove the LLTS.

The TCLAS field is identical to the TCLAS element defined in IEEE 802.11. The STA or MLD sets this field as information indicating traffic from the upper layer. When traffic is downlink and upper layer information of the traffic matches TCLAS information, the STA or MLD may use the information to identify RTA traffic under the LLTS arriving from the upper layer. The LLTS descriptor field may contain a plurality of TCLAS fields.

The TCLAS processing field is identical to the TCLAS processing unit defined in IEEE 802.11. When there are multiple TCLAS fields in the LLTS descriptor field, the non-AP STA sets this field to indicate a rule to identify RTA traffic using the multiple TCLAS fields. When the AP receives this field in the LLTS descriptor field, it will recognize that multiple TCLAS fields may be used to identify traffic from the upper layers.

The RTA-TSPEC field is set by the non-AP STA to indicate the QoS requirements and specifications of the RTA traffic under LLTS. When the AP receives this field, the AP may use the information in this field to decide whether to accept or reject the LLTS request. This field also contains information (e.g., uplink, downlink, peer-to-peer, or bi-directional) of the traffic direction under the LLTS. The AP may also indicate channel resources that may be allocated for transmission of RTA traffic under the LLTS.

The optional subunit field is set by the STA to an additional request or information indicating traffic under the LLTS. When the AP receives this field, a decision may be made to accept or reject LLTS taking into account the information in the optional sub-unit. Some examples of alternative subunits are given in fig. 24 and 25.

Fig. 23 illustrates an exemplary embodiment 190 of RTA-TSPEC field content. The TSPEC field may be identical to the TSPEC element defined in IEEE 802.11. For RTA traffic under the RTA-TSPCs, the STA sets this field to the TSID, traffic characteristics, and partial QoS requirements that indicate RTA traffic under LLTS. Some exceptions may be that the TSID field in the TS information field of the TSPEC element may be set to a value between 0 and 7 or 0 and 15 or 8 and 15.

The RTA attribute field indicates additional QoS requirements for RTA traffic under the RTA-TSPEC. It is possible that this field will only appear with or in the TSPEC element when LLTS is implemented on both STA and AP.

The reliability field is set by the STA to indicate the packet loss requirement of RTA traffic under the RTA-TSPEC. When the AP receives this field, the resource allocation for the transmission of RTA traffic under the RTA-TSPEC should then be estimated to ensure that the packet loss of the RTA traffic under the RTA-TSPEC is lower than that indicated in the reliability field.

The reliability field may be set to a value of a packet error rate of RTA traffic under the RTA-TSPEC. The AP should then ensure that the packet error rate of the RTA traffic is not higher than the value set in this field after accepting the LLTS of the RTA traffic. For example, if the field is set to 5%, the AP may have 5 RTA frames failed to transmit out of 100 RTA frames at most. If the AP is unable to guarantee the packet error rate level, the LLTS setup request may be denied.

Alternatively, the reliability field may also be set to a value of the packet delivery rate of RTA traffic under the RTA-TSPEC. The AP should then ensure that the packet delivery rate of the RTA traffic is not below the value set in this field after accepting the LLTS of the RTA traffic. For example, if the field is set to 95%, the AP must successfully transmit at least 95 RTA frames among 100 RTA frames. If the AP cannot guarantee the packet delivery rate level, the LLTS setup request may be denied.

The jitter field is set by the STA to indicate the jitter requirement of the RTA traffic under the RTA-TSPEC. When the AP receives this field, it evaluates the resource allocation for the transmission of RTA traffic under the RTA-TSPEC to ensure that the jitter requirements of the RTA traffic under the RTA-TSPEC can be met.

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

The MSDU lifetime field indicates the time at which the MSDU may be stored at the queue. When the deterministic service field is set to a first state (e.g., "1"), the STA sets the field to an MSDU or a-MSDU lifetime that indicates RTA traffic under the RTA-TSPEC. When the STA receives this field and the deterministic service field is set to a first state (e.g., "1"), then the MSDU or a-MSDU will be discarded when it is not successfully transmitted within its lifetime. When the deterministic service field is set to a second state (e.g., "0"), the field is reserved. It should be noted that this field may be replaced by a delay boundary field in the TSPEC element.

The deterministic service field is set by the STA to indicate whether the MSDU of RTA traffic under the RTA-TSPEC will be discarded when its lifetime expires. If the STA sets this field to a first state (e.g., "1"), then the MSDU for RTA traffic under this RTA-TSPEC will be discarded when its lifetime expires. Otherwise, the STA sets this field to a second state (e.g., "0"). When the STA receives this field set to a first state (e.g. "1"), then the MSDU of RTA traffic under this RTA-TSPEC will be discarded when its lifetime expires as indicated in the MSDU lifetime field. When the STA receives this field set to "0", the MSDU lifetime field is reserved.

Fig. 24 shows an exemplary embodiment 210 of an alternative subunit carrying a higher layer flow ID. The subunit ID field contains the type of subunit, which in this example is shown as an optional subunit under the LLTS request unit. The length field indicates the length of the optional subunit field. The higher layer stream ID field indicates a higher layer stream ID from a higher layer. The STA sets this field in the frame so that the receiver of this field can map the current LLTS to higher layer traffic streams.

Fig. 25 illustrates an exemplary embodiment 230 of an optional subunit carrying LLTS/TID to link mapping. The subunit ID field indicates the type of subunit, which in this example is shown as an optional subunit under the LLTS request unit. The length field indicates the length of the optional subunit field. The LLTS-level link map field provides a mechanism for determining the type of link map to be used. In at least one embodiment, the field may include a 1-bit indication. When this field is set to a first state (e.g., "1"), the LLTS/TID-to-link mapping field is for using 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 will use TID-to-link mapping, where 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 link over which traffic under LLTS can be transmitted. This field contains the following subfields.

The LLID field contains an identification of the low latency transmission service. The non-AP STA sets a number representing LLTS. The AP receives the number that may be utilized to identify LLTS set by the non-AP STA. This field may identify a Stream Class Service (SCS) as 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 link over which traffic under LLTS can be sent. One or more link ID fields may be utilized, the illustration showing multiple (1-n) link ID fields. When transmitting an LLTS/TID to link map in an LLTS request frame, the STA may set this field to suggest the link used to transmit traffic under the LLTS.

Fig. 26 illustrates an exemplary embodiment 250 of an LLTS response frame. The frame control field indicates the type of frame. The duration field contains NAV information that is used for CSMA/CA channel access. The address 1 field contains the address of the recipient for the frame. The address 2 field contains the address of the STA transmitting 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 additional control information for the frame. The action field indicates the action to be performed when it is an LLTS response frame. The action field contains the following subfields.

The category subfield and QoS action subfield indicate the type of action field, in this example an LLTS response frame. The session token field specifies the LLTS response transaction and may be set to an integer used to identify the LLTS response frame in at least one embodiment. If the LLTS response frame is a response to an LLTS request frame, then the field should be set to be the same as in the LLTS request frame. When the receiver receives this field, it recognizes that the LLTS response frame is a response to an LLTS request frame with the same dialog token.

The action field also includes an LLTS response unit. The format of the LLTS response unit is as follows. The element ID field indicates the type of element; in this example, an LLTS response unit is shown. The length field indicates the length of the LLTS response unit. The LLTS status list field contains a sequence of LLTS status fields. Each LLTS status field is set to indicate an LLTS set response for traffic under specific specifications and classification information. Receiving this information allows the receiver STA to determine the result of the LLTS setup for RTA traffic or a change in existing LLTS.

Fig. 27 illustrates an exemplary embodiment 270 of an LLTS status field. The LLID field contains an identification of the low latency transmission service. The LL length field contains the length of the LLTS status field. The response type field is set to indicate the type of LLTS set result. When the AP sets the response type field to "Accept", the AP accepts an LLTS setting request from a non-AP STA. The non-AP STA, upon receiving this field, may determine whether the LLTS setup was successful. When the AP sets the response type field to "Modified", the AP modifies the existing LLTS of the non-AP STA. The non-AP STA, upon receiving this field, may determine that LLTS with the corresponding LLID has been modified by the AP. The non-AP STA may accept the modification or initiate another LLTS to negotiate with the AP. When the AP sets the response type field to "reject", the AP rejects the LLTS setting request from the non-AP STA. When the non-AP STA receives this field, it may be able to initiate another LLTS setting with the AP. When the AP sets the response type to Terminate, the AP terminates the existing LLTS of the non-AP STA. The non-AP STA will recognize that LLTS with the corresponding LLID is terminated upon receiving this field and that the LLTS should be removed. It should be noted that this field may be identical to the status code field as defined in IEEE 802.11.

The TCLAS field may be identical to the TCLAS element defined in IEEE 802.11. The AP sets this field to information indicating traffic from the upper layer. When the traffic is uplink, the non-AP STA, upon receiving this field, may use this information to identify traffic under this TTLS that arrives from the upper layer. The LLTS status field may contain a plurality of TCLAS fields.

The TCLAS process field may be identical to the TCLAS process elements defined in IEEE 802.11. When there are multiple TCLAS fields in the LLTS state field, the AP sets the field to indicate a rule that identifies RTA traffic using the multiple TCLAS fields. When a non-AP STA receives this field in the LLTS status field, it may be determined how to use multiple TCLAS fields to identify traffic from the upper layers.

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

The optional subunit field is set by the AP to additional information or settings indicating traffic under the LLTS. Some examples of alternative subunits are given in fig. 24 and 25.

5.3.2 differentiation of RTA traffic

Fig. 28 illustrates an exemplary embodiment 310 of distinguishing RTA traffic from non-RTA traffic. When the MAC layer of the STA or MLD receives 312 traffic from the upper layer, a check is made to determine 314 whether the traffic from the upper layer belongs to an existing LLTS. If the traffic is from an upper layer belonging to an existing LLTS, then the traffic is registered as RTA traffic belonging to the LLTS at block 316. Otherwise, if the traffic from the upper layer does not belong to an existing LLTS, the traffic is registered as non-RTA traffic at block 318.

5.3.3 examples of LLTS

Table 9 gives examples of LLTS (e.g., LLTS1 through LLTS 6). In this table, the initiator column indicates the STA or MLD that initiated the LLTS setup procedure (i.e., sent the LLTS request frame). The receiver column indicates the STA or MLD that receives the LLTS request frame and transmits the LLTS response frame. For example, the second row in the table represents LLTS with LLID equal to 1, such as LLTS1. The initiator of the LLTS is STA2 and the receiver may be AP1 or MLD1. The direction column is the direction with respect to LLTS. If the direction is downlink, RTA traffic under the LLTS will be sent from AP1 (or MLD 1) to STA2; otherwise, if the direction is uplink, then in the opposite direction, this is illustrated as TID for the LLTS being 8 and User Priority (UP) being 6. The link column indicates over which link (e.g., link 1 and/or link 2) traffic under the LLTS is to be sent.

The STA may identify LLTS by a tuple of LLTS information, such as < LLID, initiator >, < LLID, receiver > or < LLID, initiator, receiver >. It is also possible that an AP or AP MLD uses a unique LLID for each LLID in its BSS, so that each STA can identify the LLIDs in the BSS with LLID only by LLID, or can identify the LLIDs in the BSS and OBSS using a tuple of < LLID, BSSID >.

5.4 TXOP sharing to send RTA packets

5.4.1 flow chart

This section explains the procedure of TXOP sharing to send RTA frames from non-primary ACs. In contrast to the current TXOP sharing rules in IEEE 802.11ax, the disclosed techniques allow STAs to share their primary AC's TXOPs to send RTA frames from non-primary ACs even though frames from the primary AC are not sent.

Fig. 29 illustrates an exemplary embodiment 330 of TXOP sharing to transmit RTA traffic from non-primary ACs. When RTA traffic reaches the EDCA queue, it will be encapsulated in frames. Frames carrying RTA traffic are referred to as RTA frames and frames carrying non-RTA traffic are referred to as non-RTA frames. One or more frames may be included in one packet and transmitted over a link or channel. The AC associated with EDCAF that obtains the TXOP is referred to as the primary AC.

When the STA obtains 332 the TXOP of the primary AC, a decision 334 is made as to whether to share the TXOP to transmit frames from non-primary ACs during the TXOP.

If the STA decides not to share the TXOP to transmit a non-RTA frame from a non-primary AC, then the current TXOP sharing rules as defined in IEEE 802.11ax may be followed at block 338 before transmitting frame 340.

Otherwise, if the STA decides to share its TXOP to transmit RTA frames from non-primary AC, the RTA frames from non-primary AC may be transmitted 336 even if frames from primary AC are not transmitted. The STA then transmits frames from the non-primary AC(s) during the TXOP, block 340.

If a station decides to share its TXOP to send an RTA frame from a non-primary AC, the following should be noted. The non-primary ACs in block 336 may represent only those ACs that have a higher priority than the primary AC. In this case, RTA frames from non-primary ACs may represent only those frames that are about to expire (e.g., that will expire before the TXOP ends).

During a TXOP, the following sequence is possible.

(1) The STA should/may transmit all/some RTA frames from the non-primary AC first, followed by frames from the primary AC. The STA may follow any one of the following rules, for example. (a) RTA frames from non-primary AC with higher priority than primary AC should/can be sent first, followed by frames from primary AC. (b) It should/could be possible to send an RTA frame from the primary AC first, followed by an RTA frame from a non-primary AC with higher priority than the primary AC, followed by a non-RTA frame from the primary AC. (c) The RTA frame(s) from the non-primary AC that is (multiple) retransmission and has higher priority than the primary AC should/can be sent first, followed by the frame from the primary AC.

(2) The STA may transmit RTA frames from non-primary ACs having lower priority than primary ACs only as follows. (a) these RTA frames will expire soon (e.g., the frame will expire before the TXOP ends), and/or (b) all frames from the primary AC have been sent, and/or (c) the low priority AC shares its TXOP with the primary AC before. For example, in the case of (2) (c), the low priority AC shares its TXOP with the primary AC during the current cycle time (such as the beacon interval). It is possible that the TXOP sharing time with the low priority AC should not be longer than the TXOP time that the low priority AC shares with the primary AC during the current cycle time.

(3) The STA treats RTA frames from non-primary AC with higher priority than primary AC as coming from primary AC. It is also possible that the STA treats RTA frames from non-primary AC with higher priority than primary AC as RTA frames from primary AC.

(4) When a STA transmits a MU PPDU (e.g., a MU PPDU for MU-MIMO or MU-OFDMA), RTA and non-RTA frames from higher or lower priority non-primary ACs may be included in the MU PPDU.

(a) The duration of the MU PPDU may be determined by the transmission and latency requirements of the particular frames in the MU PPDU. When other frames are included in the MU PPDU, they should not increase the duration of the MU PPDU beyond this requirement. For example, the specific frame may be as follows: (i) Frames from only the primary AC or RTA frames, and/or (i i) RTA frames from all non-primary AC or from non-primary AC with higher priority than the primary AC or from non-primary AC with highest priority in the MU PPDU.

(b) For a given user (i.e., the receiver STA of the MU PPDU), RTA frames from non-primary ACs having higher priority than primary ACs should/can be transmitted earlier than frames from primary ACs. For example, (i) any RTA frame from the primary AC should/can be sent first, followed by any RTA frame from the higher priority AC, followed by any non-RTA frame from the primary AC. (i i) any RTA frame from a higher AC should/can be sent first, followed by any frame from the primary AC. (ii) any frame from the primary AC should/can be sent first, followed by any frame from the higher priority AC. (iv) Any frame with a shorter expiration time (e.g., the expiration time of the MSDU lifetime) should/may be sent first.

(5) The STA ensures that some channel resources are allocated to transmit frames from the primary AC during the TXOP. For example, there are the following points during a TXOP. (a) The STA should not transmit frames from non-primary ACs until one or more frames from the primary AC are transmitted. (b) The STA should limit the duration of TXOP sharing to transmit RTA frames from non-primary ACs. For example, the STA limits the time of TXOP sharing (in length, e.g., 0.3ms, or in proportion, e.g., 20% of the TXOP duration) for each TXOP or for each cycle time (e.g., beacon interval). It is possible that the AP sets the time limit on its associated STA. (c) The STA should not transmit RTA frames from non-primary ACs until a certain amount of TXOP time indicated by a dedicated time (in length, e.g., 0.3ms, or in proportion, e.g., 20% of the TXOP duration) is 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 should not transmit RTA frames from non-primary ACs until a certain number of frames from the primary AC, such as indicated by a dedicated byte (e.g., in terms of number of bytes), are transmitted, or until all frames (or all RTA frames) from the primary AC have been transmitted. (e) The STA should follow the TXOP sharing rules as defined in IEEE 802.11ax for a specific period of time indicated by a dedicated time (in length, e.g., 0.3ms, or in proportion, e.g., 20% of the TXOP duration) since the start time of the TXOP.

(6) During a special channel period, such as the R-TWT SP defined in IEEE 802.11be, the STA treats RTA frames from non-primary ACs as coming from primary ACs.

5.4.2, example

This section provides a number of examples to explain how STAs share the TXOP of the primary AC to send RTA frames from non-primary ACs. The network topology of these examples is shown in fig. 19. Traffic classification processing between RTA and non-RTA may be the same as or similar to LLTS operation as described in section 5.3 or any other traffic classification procedure. By way of example, it is assumed herein that each STA or MLD in the network topology has an RTA traffic flow as shown in table 9. It is possible that traffic under LLTS is queued in EDCA queues according to the UP-to-AC mapping shown in table 1. It should be noted that the UP of traffic under LLTS is indicated in the LLTS settings, such as the UP shown in table 9.

Fig. 30 shows an exemplary embodiment 350 of the state of the EDCA queue for AP1 or MLD 1. Frames (MSDUs, UPs, RTAs) are shown mapped 352 and placed into a queue.

Ac_vo queue 354 represents the EDCA queue of AC VOs, illustrated here by three RTA frames under LLTS1, illustrated as ac_vo (1) through ac_vo (3).

Ac_vi queue 356 represents the EDCA queue of AC VI, shown with two RTA frames under LLTS2 illustrated as ac_vi (1) and ac_vi (2) and a non-RTA frame illustrated as ac_vi (3).

Ac_be queue 358 represents the EDCA queue of AC BE, which is shown with three non-RTA frames illustrated as ac_be (1) through ac_be (3).

AC BK queue 360 represents the EDCA queue of AC BK, which is illustrated as empty, i.e., no frames are in the queue.

The various queues are shown as EDCAF 362, 364, 366, and 368 connected to a contention channel 370.

Fig. 31 shows an exemplary embodiment 390 in which AP1 transmits RTA frames from non-primary ACs only during a TXOP. Interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400 are depicted. The EDCA queue status for AP1 or MLD1 is shown in fig. 30.

This example assumes that this is the queue state when AP1 starts EDCA TXOP and no new frames arrive during EDCA TXOP. If the queue state is that of MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP shown in this example.

When AP1 obtains TXOP 400 for VI, it sends RTA frames illustrated as ac_vo (1) 404, ac_vo (2) 410, and ac_vo (3) 416 with corresponding preambles 402, 408, and 414 from the ac_vo queue to STA 2. As shown in this example, AP1 only transmits RTA frames from the ac_vo queue during the TXOP. STA2 generates block acknowledgements 406, 412, and 418 upon receiving each of these transmissions.

It should be noted that it is possible for AP1 to reserve a TXOP using RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 32 shows an exemplary embodiment 430 of another EDCA queue state for AP1 or MLD 1. The frames are mapped 432 into queues shown in the figure. As shown, ac_vo queue 434 represents the EDCA queue of AC VOs, with one RTA frame under LLTS1 illustrated as ac_vo (1) and one non-RTA frame illustrated as ac_vo (2). Ac_vi queue 436 represents the EDCA queue of AC VI with one RTA frame under LLTS2 illustrated as ac_vi (1) and one non-RTA frame illustrated as ac_vi (2). Ac_be queue 438 represents the EDCA queue of AC BE with one RTA frame under LLTS3 illustrated as ac_be (1) and one non-RTA frame illustrated as ac_be (2). The AC BK queue 440 represents the EDCA queue of AC BK, which has no frames in the queue. Below each queue is shown a corresponding EDCA function 442, 444, 446 and 448 for obtaining and transmitting on channel 450.

Fig. 33 illustrates an exemplary embodiment 470 in which AP1 transmits RTA frames from higher priority non-primary ACs prior to frames from primary ACs during a TXOP. The figure depicts interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400. The EDCA queue state of AP1 or MLD1 is shown in fig. 32, which example assumes this is the queue state when AP1 starts TXOP 400, and also assumes that no new frames arrive during the TXOP. If the queue state is that of MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP shown in this example.

When AP1 obtains TXOP 400 for VI, it first sends an RTA frame, illustrated as AC VO (1) 474, from the AC VO queue to STA 2. AP1 then transmits RTA frames, illustrated as AC VI (1) 480, from the AC VI queue to STA1, and then transmits non-RTA frames, illustrated as AC VI (2) 486, from the AC VI queue to STA 3. Each of these transmissions is shown with a corresponding preamble 472, 478, and 484. The receiving station is shown as responding with Block Acknowledgements (BAs) 476, 482, and 488.

It should be noted that it is possible that AP1 may reserve a TXOP with an RTS/CTS or MU-RTS/CTS before sending a frame.

Fig. 34 illustrates an exemplary embodiment 510 in which AP1 transmits an RTA frame from a primary AC first, followed by an RTA frame from a non-primary AC, followed by a non-RTA frame from a primary AC during a TXOP. The EDCA queue status for AP1 or MLD1 is shown in fig. 32; it is assumed that the queue state is that when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If the queue state is that of MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the illustrated TXOP.

When AP1 obtains TXOP 400 for a VI, it first sends an RTA frame, illustrated as ac_vi (1) 514, from the ac_vi queue to STA 1. AP1 then sends an RTA frame, illustrated as AC VO (1) 520, from the AC VO queue to STA 2. Next, AP1 transmits a non-RTA frame illustrated as ac_vi (2) 526 from the ac_vi queue to STA 3.

Each of these transmissions is shown with a corresponding preamble 512, 518, and 524. The receiving station is shown as responding with Block Acknowledgements (BAs) 516, 522, and 528.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 35 illustrates an exemplary embodiment 530 of AP1 transmitting an RTA frame from a non-primary AC having a lower priority than a primary AC. The figure depicts interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400. The EDCA queue status for AP1 or MLD1 is shown in fig. 32; it is assumed here that the queue state is that when AP1 starts TXOP400, and that no new frames arrive during the TXOP. If the queue state is that of MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP shown in this example.

When AP1 obtains the TXOP for VI, it first sends an RTA frame, illustrated as ac_vi (1) 534, from the ac_vi queue to STA 1. AP1 then sends an RTA frame, illustrated as AC VO (1) 540, from the AC VO queue to STA 2. Next, AP1 sends an RTA frame, illustrated as ac_be (1) 546, from the ac_be queue to STA3, because the RTA frame will expire 550 soon and will occur before the end time of the TXOP.

Each of these transmissions is shown with a corresponding preamble 532, 538 and 544. The receiving station is shown as responding with Block Acknowledgements (BAs) 536, 542, and 548.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 36 shows an exemplary embodiment 570 in which a third example of EDCA queue status for AP1 or MLD1 is depicted. The frames are mapped 572 into queues shown in the figure. AC VO queue 574 is shown with one RTA frame AC VO (1) and one non-RTA frame AC VO (2) under LLTS 1. Ac_vi queue 576 is shown with two RTA frames and one non-RTA frame ac_vi (3) under LLTS 2. Ac_be queue 578 is shown with three non-RTA frames. The AC BK queue 580 is shown without any frames in the queue.

Below each queue is shown a corresponding EDCA function 582, 584, 586, and 588 configured to acquire and transmit on channel 590.

Fig. 37 illustrates an exemplary embodiment 610 of AP1 transmitting MU OFDMA PPDUs carrying RTA frames from non-primary ACs, wherein the duration of the MU PPDUs is determined by the transmission requirements of the RTA frames from the non-primary ACs. The figure depicts interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400.

The EDCA queue status for AP1 or MLD1 is shown in fig. 36; this figure assumes that this is the same queue state as when AP1 starts TXOP 400, and also assumes that no new frames arrive during the illustrated TXOP. If the queue state is that of MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP shown in this example.

When AP1 obtains TXOP 400 for VI, it sends 614 a MU OFDMA PPDU carrying an RTA frame exemplified as ac_vi (1) from ac_vi to STA1 queue, an RTA frame exemplified as ac_vo (1) from ac_vo to STA2, and a non-RTA frame exemplified as ac_vi (3) from ac_vo queue to STA 3. It should be noted that the duration of the MU OFDMA PPDU is determined by the duration of the frame ac_vo (1) instead of the durations of the frames ac_vi (1) and ac_vi (3).

AP1 then transmits 620 another MU OFDM PPDU carrying the RTA frame illustrated as AC VI (2) from the AC VI queue and the non-RTA frames illustrated as AC VO (2) and AC BE (2), which may follow the TXOP sharing rules of IEEE 802.11.

It should be noted that in this and subsequent examples, the short frames are shown as being padded.

The MU OFDMA PPDU shown in this example may be replaced by a MU MIMO PPDU. Each frame in the MU PPDU will then be transmitted over a different spatial stream instead of a different RU. The feedback of the MU PPDU sought (e.g., ACK or BA) will also be changed to the feedback in the figure for MU MIMO PPDUs.

Transmissions 614 and 620 are shown with corresponding preambles 612 and 618. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 616.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 38 illustrates an exemplary embodiment 630 of AP1 transmitting MU OFDMA PPDUs carrying RTA frames from non-primary ACs, wherein the duration of the MU PPDUs is determined by the latency requirement of the RTA frames from the primary ACs. The figure depicts interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400.

The EDCA queue status for AP1 or MLD1 is shown in fig. 36; it is assumed here that the queue state is that when AP1 starts TXOP 400, and that no new frame arrives during the TXOP of this example. If the queue state is that of MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the illustrated TXOP.

When AP1 obtains TXOP 400 for VI, it sends 636 a MU OFDMA PPDU carrying an RTA frame exemplified as ac_vi (1) from ac_vi queue to STA1, an RTA frame exemplified as ac_vo (1) from ac_vo queue to STA2, and a non-RTA frame exemplified as ac_vi (3) from ac_vo queue to STA 3. It should be noted that the duration of the MU OFDMA PPDU is determined by the duration of the frame ac_vo (1) shown as about to expire 638, and the duration of the MU OFDMA PPDU cannot exceed the maximum duration (expiration time) 632 of the frame ac_vi (1).

It is then seen that AP1 transmits 644 another MU OFDM PPDU carrying the RTA frame illustrated as AC VI (2) from the AC VI queue and the non-RTA frames illustrated as AC VO (2) and AC BE (2), which may follow the TXOP sharing rules of IEEE 802.11.

The MU OFDMA PPDU shown in this example may be replaced by a MU MIMO PPDU; wherein each frame in the MU PPDU will then be transmitted over a different spatial stream instead of a different RU. The feedback of the sought MU PPDU (such as ACK or BA) will also be changed to the feedback for MU MIMO PPDUs.

Transmissions 636 and 644 are shown with corresponding preambles 634 and 642. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 39 illustrates another exemplary embodiment 650 of AP1 transmitting MU OFDMA PPDUs carrying RTA frames from non-primary ACs, wherein the maximum duration of MU PPDUs 632 is determined by the latency requirement of the RTA frames from the primary ACs. The figure depicts interactions between AP1392, STA1 394, STA2 396, and STA3 396 during a TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in fig. 36 is assumed here to be the queue state when AP1 starts TXOP 400, and also assumes that no new frame arrives during the TXOP. If the queue status is for MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP shown in this example.

When AP1 obtains TXOP 400 for VI, it sends 636 a MU OFDMA PPDU carrying an RTA frame exemplified as ac_vi (1) from ac_vi queue to STA1, an RTA frame exemplified as ac_vo (1) from ac_vo queue to STA2, and a non-RTA frame exemplified as ac_vi (3) from ac_vo queue to STA 3. It should be noted that the duration of MU OFDMA PPDU 632 is determined by the duration of frame ac_vo (1), but the duration of MU OFDMA PPDU and the expected feedback (e.g., BA) cannot exceed expiration time 652 of frame ac_vi (1) shown as about to expire 652.

AP1 transmits 644 another MU OFDM PPDU carrying the RTA frame illustrated as AC VI (2) from the AC VI queue to STA1 and the non-RTA frames illustrated as AC VO (2) and AC BE (2), which may follow the TXOP sharing rules of IEEE 802.11.

The MU OFDMA PPDU shown in this example may be replaced by a MU MIMO PPDU; in this case each frame in the MU PPDU will be transmitted over a different spatial stream rather than over a different RU. In this case, the feedback of the sought MU PPDU (such as ACK or BA) will also be changed to the feedback for MU MIMO PPDUs.

Transmissions 636 and 644 are shown with corresponding preambles 634 and 642. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 40 illustrates an exemplary embodiment 670 of AP1 transmitting MU OFDMA PPDUs carrying RTA frames from non-primary ACs, wherein the duration of the MU PPDUs is determined by the transmission requirements of the RTA frames from the primary ACs. The figure depicts 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 is assumed in this example to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frame arrives during the TXOP. If the queue status is for MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP.

When AP1 obtains TXOP 400 for VI, it sends 672 MU OFDMA PPDUs carrying an RTA frame from the ac_vi queue exemplified as ac_vi (1) to STA1, a non-RTA frame from the ac_vo queue exemplified as ac_vo (2) to STA2, and a non-RTA frame exemplified as ac_vi (3) to STA 3. The frame ac_vo (1) is not included in the first MU OFDMA PPDU because its duration is longer than the duration of the frame ac_vi (1).

Subsequently, AP1 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 the frame ac_vo is shorter than the duration of the frame ac_vi (2).

The MU OFDMA PPDU shown in this example may be replaced by a MU MIMO PPDU; in this case each frame in the MU PPDU will be transmitted over a different spatial stream instead of a different RU. The feedback of the MU PPDU sought, such as an ACK or BA, will also be changed to the feedback required for the MU MIMO PPDU.

Transmissions 672 and 674 are shown with corresponding preambles 634 and 642. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 41 illustrates an exemplary embodiment 710 of AP1 limiting the time of TXOP sharing. The figure depicts 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 is assumed to be a queue state when AP1 starts TXOP 400, and it is also assumed that no new frame arrives during the TXOP. If the queue status is for MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP.

When AP1 obtains TXOP 400 for VI, it first sends 712 an RTA frame illustrated as ac_vi (1) from the ac_vi queue to STA 1. AP1 then transmits an RTA frame illustrated as AC VO (1) 716 from the AC VO queue to STA 2. After AP1 completes transmitting the frame ac_vo, it has utilized the maximum TXOP sharing time 714 during the current TXOP.

Next, AP1 transmits 718 is illustrated as a frame from the ac_vi queue to ac_vi (2) of STA 1.

Transmissions 712, 714, and 718 are shown with corresponding preambles 632. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

Fig. 42 illustrates an exemplary embodiment 750 of AP1 sharing a TXOP after transmitting a certain number of frames from a primary AC. The figure depicts interactions between AP1 392, STA1394, STA2 396, and STA3 396 during a TXOP 400.

The EDCA queue state of AP1 or MLD1 shown in fig. 36 is assumed to be a queue state when AP1 starts TXOP 400, and it is also assumed that no new frame arrives during the TXOP. If the queue status is for MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP.

As shown in the figure, AP1 must transmit a certain number of frames from the primary AC VI, indicated by the dedicated byte 752, before sharing its TXOP for transmission since the start of the TXOP. After the total number of bytes of frames from the primary AC exceeds the decoded_byte, AP1 is allowed to share TXOPs with RTA frames from non-primary ACs even if there are frames from the primary AC that are not being transmitted.

When AP1 obtains TXOP 400 for VI, it first sends 754 and 756 RTA frames illustrated as ac_vi (1) and ac_vi (2) from the ac_vi queue to STA 1. Then, AP1 spends more than the dedicated time sending frames from the primary AC VI during the TXOP. AP1 then shares the TXOP to send 758 an RTA frame from the AC VO queue, illustrated as AC VO (1).

The AP1 may transmit a frame carrying information as shown in fig. 44 to set a dedicated time for each STA.

Transmissions 754, 756, and 758 are shown with corresponding preambles 632; each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

It is possible that AP1 may share the TXOP following the rules defined in IEEE 802.11 before reaching the dedicated_byte of the primary frame.

Fig. 43 illustrates an exemplary embodiment 790 of AP1 sharing a TXOP after transmitting frames from a primary AC for a particular amount of time. The figure depicts 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 is assumed to be a queue state when AP1 starts TXOP 400, and it is also assumed that no new frame arrives during the TXOP. If the queue status is for MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the TXOP.

As shown, there is a dedicated time 792 for the primary AC VI since the beginning of the TXOP. After the dedicated time has ended, AP1 is allowed to share a TXOP to transmit RTA frames from non-primary ACs even when no frames from primary ACs are being transmitted at this time.

When AP1 obtains TXOP 400 for VI, it first sends 794 RTA frames 794 and 796, illustrated as ac_vi (1) and ac_vi (2) from the ac_vi queue to STA 1. AP1 then spends more than the dedicated time 792 sending frames from the primary AC VI during the TXOP. AP1 then shares the TXOP to send 798 an RTA frame illustrated as AC VO (1) from the AC VO queue to STA 2.

It should be noted that the AP1 may transmit a frame carrying information as shown in fig. 44 to set a dedicated time for each STA.

Transmissions 794, 796 and 798 are shown with corresponding preambles 632. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

It is possible that AP1 shares the TXOP in response to following the rules defined in IEEE 802.11 before the expiration of the scheduled _ t time.

Fig. 44 shows an exemplary embodiment 830 of a frame for carrying dedicated time parameter settings. One STA (e.g., AP) may send a frame containing the time parameter setting to another STA (e.g., an associated STA) to set the amount of dedicated time given for the STA. In some cases, the AP may broadcast such frames to set the dedicated times of 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 that is used for CSMA/CA channel access. The address 1 field contains the address of the recipient for the frame. The address 2 field contains the address of the STA transmitting 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 additional control information for the frame.

The dedicated time setting field is set by the STA to the number of dedicated times for each AC of the receiver STA. The receiver STA may use the parameters in this field for TXOP sharing. The unit ID field identifies the type of unit; which in this example is a dedicated time setting unit. The length field indicates the length of the dedicated time setting unit.

The LLTS TXOP share field is set to indicate a sharing rule. In at least one embodiment, this field may be a 1-bit field set to a first state (e.g., "1") indicating that the receiver STA may share the TXOP to send RTA frames from non-primary ACs using the rules described in section 5.4.1. Alternatively, the field is set to a second state (e.g., "0") and the receiver STA only follows the TXOP sharing rules defined in IEEE 802.11.

The enable dedicated time field is set to indicate whether there is dedicated time during each TXOP. If the field is set to a first state (e.g., true), there is a dedicated time during each TXOP, e.g., marked from the beginning of the TXOP. During the dedicated time, only traffic from the primary AC may be sent.

The dedicated time field is set by the transmitting STA for each AC. From the start time of the TXOP of an AC, the STA that receives the dedicated time information spends the dedicated time for the AC transmitting frames from the AC. Only after this can the receiver STA decide to share the TXOP.

It should be noted that it is possible to replace "dedicated time" with "dedicated byte" in a frame to set the dedicated byte parameter as depicted in fig. 42.

Fig. 45 shows an exemplary embodiment 850 providing a fourth example of EDCA queue status for AP1 or MLD 1. The frames are mapped 852 into a queue as shown in the figure. AC VO queue 854 is depicted as carrying two RTA frames illustrated as AC VO (1) under LLTS1 and AC VO (2) under LLTS 6. Ac_vi queue 856 is depicted as holding one RTA frame under LLTS2, illustrated as ac_vi (1), and one non-RTA frame, illustrated as ac_vi (2). Ac_be queue 858 represents the EDCA queue of AC BE, depicted as holding three non-RTA frames illustrated as ac_be (1) through ac_be (3). The AC BK queue 860 is depicted as having no frames in its queue.

Below each queue is shown a corresponding EDCA function 862, 864, 866, and 868 for obtaining and transmitting on channel 870.

Fig. 46 shows an exemplary embodiment 890 of AP1 transmitting MU OFDMA PPDUs, wherein for each user, RTA frames from non-primary ACs are transmitted earlier than frames from primary ACs. The figure depicts 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. 45 is assumed to be a queue state when AP1 starts TXOP 400, and it is also assumed that no new frame arrives during the TXOP. If the queue status is for MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the illustrated TXOP.

When AP1 obtains TXOP 400 for VI, its transmission 892 carries MU OFDMA PPDUs that are illustrated as RTA frames of AC VO (1) and AC VO (2) from the ac_vo queue to STA1 and STA2 and as non-RTA frames of ac_be (2) from the ac_be queue to STA 3.

Subsequently, AP1 transmits 894 another MU OFDM PPDU carrying RTA frames ac_vi (1) and ac_vi (2) and non-RTA frames ac_be (3) to STA1, STA2 and STA3, respectively. For STA1 and STA2, AP1 first transmits an RTA frame from a higher priority non-primary AC, illustrated as AC VO.

The MU OFDMA PPDU shown in this example may be replaced by a MU MIMO PPDU; in this case each frame in the MU PPDU is transmitted over a different spatial stream instead of a different RU. The feedback sought will also be 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 corresponding preambles 632. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

It should be noted that it is possible for AP1 to reserve a TXOP with RTS/CTS or MU-RTS/CTS before sending the frame.

Fig. 47 illustrates an exemplary embodiment 930 of TXOP sharing when an AP transmits an RTA frame from a non-primary AC later than an RTA frame from a primary AC but earlier than a non-RTA frame from a primary AC for each user in a MU PPDU. The figure depicts interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during a TXOP 400.

AP1 is shown transmitting 932MU OFDMA PPDUs, wherein for each user, AP1 first transmits an RTA frame from the primary AC, followed by an RTA frame from the higher priority AC, followed by a non-RTA frame from the primary AC.

The EDCA queue state of AP1 or MLD1 shown in fig. 45 is assumed to be a queue state when AP1 starts TXOP 400, and it is also assumed that no new frame arrives during the TXOP. If the queue status is for MLD1, then it is also assumed that MLD1 is not transmitting on any other link during the illustrated TXOP.

When AP1 obtains TXOP 400 for VI, its transmission 932 carries MU OFDMA PPDUs of RTA frames, illustrated as ac_vi (1) and ac_vo (1), and non-RTA frames, illustrated as ac_be (2), from the ac_be queue.

AP1 then transmits 934 another MU OFDM PPDU carrying RTA frames ac_vo (2) and ac_vi (2) and non-RTA frames ac_be (3). For user STA1, AP1 first transmits an RTA frame from the primary AC, illustrated as AC VI, followed by an RTA frame from the higher priority non-primary AC, illustrated as AC VO. For the user STA2, AP1 first transmits an RTA frame from a higher priority non-primary AC (e.g., ac_vo), followed by a non-RTA frame from a primary AC (e.g., ac_vi).

The MU OFDMA PPDU shown in this example may be replaced by a MU MIMO PPDU; in which case each frame in the MU PPDU is transmitted over a different spatial stream rather than over a different RU. The feedback of the sought MU PPDU (such as ACK or BA) will also be changed to the appropriate type of feedback for the MU MIMO PPDU.

The transmissions 932 and 934 are shown with corresponding preambles 632. Each receiving station is shown as responding to the receipt of these transmissions with a Block Acknowledgement (BA) 640.

It should be noted that it is possible for an AP (e.g., AP 1) to reserve a TXOP using an RTS/CTS or MU-RTS/CTS prior to transmitting a frame.

6. General scope of the examples

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

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

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

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

It should also be appreciated that the terms processor, hardware processor, computer processor, central Processing Unit (CPU), and computer as used herein are synonymously used to denote a device capable of executing instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single or multi-core devices, and variations thereof.

As will be appreciated from the description herein, the present disclosure encompasses a variety of implementations of the technology, including but not limited to the following implementations:

an apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit as a wireless Station (STA) operating as an Access Point (AP) or a non-AP STA, the wireless communication circuit configured to wirelessly transmit packets carrying frames over a channel with other wireless Stations (STAs) as APs or non-AP STAs on a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is applied to more than one Access Category (AC); (b) A processor coupled to the wireless communication circuit for operating as a STA over a WLAN; (c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein the instructions, when executed by the processor, perform steps comprising one or more of: (d) (i) distinguishing real-time application (RTA) traffic from non-RTA traffic; (d) (i i) obtaining a transmit opportunity (TXOP) of the primary AC; and (d) (ii) transmitting RTA frames from non-primary ACs using the remaining TXOP channel resources, although frames from primary ACs may not be transmitted during the TXOP.

An apparatus for wireless communication in a network, the apparatus comprising: (a) A wireless communication circuit as a wireless Station (STA) operating as an Access Point (AP) or a non-AP STA, the wireless communication circuit configured to wirelessly transmit packets carrying frames over a channel with other wireless Stations (STAs) as APs or non-AP STAs on a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is applied to more than one Access Category (AC); (b) A processor coupled to the wireless communication circuit for operating as a STA over a WLAN; (c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein the instructions, when executed by the processor, perform steps comprising one or more of: (d) (i) exchanging specifications of quality of service (QoS) requirements and upper layer information of traffic flows between the non-AP MLD and the AP MLD to set the traffic flows; (d) (i i) assigning, by the non-AP MLD or AP MLD, a Low Latency Identification (LLID) to the traffic flow to distinguish the traffic flow from other traffic flows having the same Traffic Identifier (TID); (d) (ii) determining by the non-AP MLD and/or the AP MLD over which link or links the traffic flow is to be transmitted; and (d) (iv) distinguishing between traffic belonging to the traffic flow and other traffic by the non-AP MLD and/or the AP MLD.

A method of wireless communication in a network, the method comprising: (a) Communicating over a channel from a wireless Station (STA) operating as an Access Point (AP) or a non-AP STA with other wireless Stations (STAs) on a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is applied to more than one Access Class (AC) as an AP or a non-AP STA; (b) Distinguishing real-time application (RTA) traffic from non-RTA traffic; (c) obtaining a transmit opportunity (TXOP) of the primary AC; and (d) transmitting the RTA frames from the non-primary AC using the remaining channel resources even when there are frames from the primary AC that are not transmitted during the TXOP.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: ensuring that there are minimum required channel resources within the channel resources available for transmitting frames from the primary AC during the TXOP.

Any of the apparatus or methods of the previous implementations, wherein if all frames from the primary AC have been transmitted, the STA that ensures the least required channel resources to transmit the frames from the primary AC may use the least required channel resources for TXOP sharing.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA does not set the minimum required channel resources to transmit frames from the primary AC during the TXOP.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA ensures that a given minimum number of bytes from the primary AC are transmitted during the TXOP.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA ensures that the minimum required channel time is provided for transmitting frames from the primary AC during the TXOP.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA transmits RTA frames from non-primary ACs even though no frames from primary ACs are transmitted during the TXOP.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA transmits RTA frames from non-primary ACs during the TXOP only if all RTA frames from primary ACs have been transmitted.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA transmits RTA frames from higher priority non-primary ACs during the TXOP before transmitting RTA frames from primary ACs.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA transmits RTA frames from lower priority non-primary ACs during the TXOP.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA transmits MU PPDU packets whose length is determined by the transmission and/or latency requirements of the RTA frames from the primary AC.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA restricts the time for TXOP sharing.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: only if RTA frames from non-primary ACs are about to expire, the STA is allowed to transmit these RTA frames earlier than frames from primary ACs.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the STA obtains the TXOP of the primary AC and shares the TXOP with the low priority non-primary AC.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the non-AP MLD transmits a frame including a specification of the traffic flow, qoS requirements, upper layer information, and LLID to the AP MLD to request it to set the traffic flow.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the AP MLD responds to the request for setting up the traffic flow for the non-AP MLD with a frame including the traffic flow specification, qoS requirements, upper layer information, LLID and status to indicate whether it accepts or rejects the request.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the AP MLD and the non-AP MLD implement the exchange of traffic flow specifications, qoS requirements, by using a Traffic Specification (TSPEC) element as defined in IEEE 802.11ax configured to contain additional QoS requirements.

An apparatus or method of any of the previous implementations, wherein the additional QoS requirements include jitter and packet loss requirements.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: the AP MLD and the non-AP MLD exchange traffic flow information by transmitting frames on different links.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: in response to the AP MLD and the non-AP MLD transmitting a tuple comprising the non-AP MAC address and the LLID, one traffic stream is distinguished from the other traffic stream.

An apparatus or method of any preceding implementation, wherein the instructions, when executed by the processor, further implement steps comprising: unsolicited frames are sent by the AP MLD to terminate or modify existing traffic flows.

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

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

Phrase structure descriptions in this disclosure such as "A, B and/or C" may exist for the case of A, B or C or any combination of items A, B and C. For example, a phrase structure in which a group of elements is listed followed by "at least one of" indicates the presence of at least one of those group elements, including any applicable possible combinations of the listed elements.

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

The term "collection" as used herein refers to a collection of one or more objects. Thus, a set of objects may comprise, for example, a single object or multiple objects.

Relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, or comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further constraints, the terms "comprising," "having," "including," and "containing" preceding an element do not exclude the presence of additional identical elements in a process, method, article, or apparatus that comprises, has, contains the element.

The terms "approximately," "substantially," and "approximately" or any other version thereof as used herein are used to describe and explain within a context of a minor variation. When used in connection with an event or circumstance, the term can refer to instances where the event or circumstance occurs precisely and instances where it occurs approximately. When used in conjunction with a numerical value, the term may refer to a range of variation of less than or equal to ±10% of the numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, "substantially" aligned may refer to a range of angular variation of less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

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

The term coupled, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure that is "configured" in a particular manner is configured in at least that manner, but may also be configured in ways that are not listed.

The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of the techniques described herein or any or all the claims.

Furthermore, 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 lie in less than all features of a single disclosed embodiment.

The Abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. Applicant's understanding at the time of filing this abstract, it will not be used to interpret or limit the scope or meaning of the claims.

It should be appreciated that the practice of some jurisdictions may require that one or more portions of the disclosure be deleted after the application is filed. Accordingly, the reader should consult the filed application for the original content of the present disclosure. Any deletion of content from the disclosure should not be construed as disclaimer, or donation to the public of any subject matter of the originally filed application.

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

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

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

TABLE 1 user priority to (UP) mapping

Table 2 default parameter set

AC	CWmin	CWmax	AIFSN	TXOP limit
					BK	15	1023	7	0
BE	15	1023	3	0
					VI	7	15	2 or 1 (AP)	3ms
VO
		3	7	2 or 1 (AP)	1.5ms

TABLE 3MLME-LLTS. Requests t

TABLE 4MLME-LLTS. Indication

TABLE 5MLME-LLTS. Response

TABLE 6MLME-LLTS. Condi rm

TABLE 7MLME-LLTS-TERM. Requests t

TABLE 8MLME-LLTS-TERM. Indication

Table 9 exemplary LLTS

	LLID	Initiator	Receiver(s)	Direction	TID	UP	Link
								LLTS1
	1	STA2	AP1/MLD1	Downlink link	8	6	1
								LLTS2	2	MLD2	MLD1	Downlink link	9	5	1
LLTS3	3	MLD3	MLD1	Downlink link	10	3	1
								LLTS4	4	STA2	AP1/MLD1	Uplink channel	8	6	1
LLTS5	5	MLD2	MLD1	Uplink channel	8	6	1&2
								LLTS6	6	STA2	AP1/MLD1	Downlink link	8	6	1

Claims (23)

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

(a) A wireless communication circuit as a wireless Station (STA) operating as an Access Point (AP) or a non-AP STA, the wireless communication circuit configured to wirelessly transmit packets carrying frames over a channel with other wireless Stations (STAs) as APs or non-AP STAs on a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is applied to more than one Access Category (AC);

(b) A processor coupled to the wireless communication circuit for operating as a STA over a WLAN;

(c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and

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

(i) Distinguishing real-time application (RTA) traffic from non-RTA traffic;

(ii) Obtaining a transmit opportunity (TXOP) of the primary AC; and

(iii) Although there may be frames from the primary AC that are not transmitted during the TXOP, RTA frames from non-primary ACs are transmitted using the remaining TXOP channel resources.

2. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: ensuring that there are minimum required channel resources within the channel resources available for transmitting frames from the primary AC during the TXOP.

3. The apparatus of claim 2, wherein if all frames from the primary AC have been transmitted, STAs that ensure minimum required channel resources to transmit frames from the primary AC can use the minimum required channel resources for TXOP sharing.

4. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA does not set the minimum required channel resources to transmit frames from the primary AC during the TXOP.

5. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA ensures that a given minimum number of bytes from the primary AC are transmitted during the TXOP.

6. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA ensures that the minimum required channel time is provided for transmitting frames from the primary AC during the TXOP.

7. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA transmits RTA frames from non-primary ACs even though no frames from primary ACs are transmitted during the TXOP.

8. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA transmits RTA frames from non-primary ACs during the TXOP only if all RTA frames from primary ACs have been transmitted.

9. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA transmits RTA frames from higher priority non-primary ACs during the TXOP before transmitting RTA frames from primary ACs.

10. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA transmits RTA frames from lower priority non-primary ACs during the TXOP.

11. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA transmits MU PPDU packets whose length is determined by the transmission and/or latency requirements of the RTA frames from the primary AC.

12. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA restricts the time for TXOP sharing.

13. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: only if RTA frames from non-primary ACs are about to expire, the STA is allowed to transmit these RTA frames earlier than frames from primary ACs.

14. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform steps comprising: the STA obtains the TXOP of the primary AC and shares the TXOP with the low priority non-primary AC.

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

(a) A wireless communication circuit as a wireless Station (STA) operating as an Access Point (AP) or a non-AP STA, the wireless communication circuit configured to wirelessly transmit packets carrying frames over a channel with other wireless Stations (STAs) as APs or non-AP STAs on a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is applied to more than one Access Category (AC);

(b) A processor coupled to the wireless communication circuit for operating as a STA over a WLAN;

(c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and

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

(i) Exchanging specifications of quality of service (QoS) requirements and upper layer information of traffic flows between non-AP MLD and AP MLD to set the traffic flows;

(ii) Assigning, by the non-AP MLD or AP MLD, a Low Latency Identification (LLID) to the traffic flow to distinguish the traffic flow from other traffic flows having the same Traffic Identifier (TID);

(iii) Determining by the non-AP MLD and/or the AP MLD over which link or links the traffic flow is to be sent; and

(iv) A distinction is made by the non-AP MLD and/or the AP MLD between traffic belonging to the traffic flow and other traffic.

16. The apparatus of claim 15, wherein the instructions, when executed by a processor, further perform steps comprising: the non-AP MLD transmits a frame including a specification of the traffic flow, qoS requirements, upper layer information, and LLID to the AP MLD to request it to set the traffic flow.

17. The apparatus of claim 16, wherein the instructions, when executed by a processor, further perform steps comprising: the AP MLD responds to the request for setting up the traffic flow for the non-AP MLD with a frame including the traffic flow specification, qoS requirements, upper layer information, LLID and status to indicate whether it accepts or rejects the request.

18. The apparatus of claim 17, wherein the instructions, when executed by a processor, further perform steps comprising: the AP MLD and the non-AP MLD implement the exchange of traffic flow specifications, qoS requirements, by using Traffic Specification (TSPEC) elements defined in IEEE 802.11ax configured to contain additional QoS requirements.

19. The apparatus of claim 18, wherein the additional QoS requirements comprise jitter and packet loss requirements.

20. The apparatus of claim 15, wherein the instructions, when executed by a processor, further perform steps comprising: the AP MLD and the non-AP MLD exchange traffic flow information by transmitting frames on different links.

21. The apparatus of claim 15, wherein the instructions, when executed by a processor, further perform steps comprising: in response to the AP MLD and the non-AP MLD transmitting a tuple comprising the non-AP MAC address and the LLID, one traffic stream is distinguished from the other traffic stream.

22. The apparatus of claim 15, wherein the instructions, when executed by a processor, further perform steps comprising: unsolicited frames are sent by the AP MLD to terminate or modify existing traffic flows.

23. A method of wireless communication in a network, the apparatus comprising:

(a) Communicating over a channel from a wireless Station (STA) operating as an Access Point (AP) or a non-AP STA with other wireless Stations (STAs) on a Wireless Local Area Network (WLAN) in which Enhanced Distributed Channel Access (EDCA) is applied to more than one Access Class (AC) as an AP or a non-AP STA;

(b) Distinguishing real-time application (RTA) traffic from non-RTA traffic;

(c) Obtaining a transmit opportunity (TXOP) of the primary AC; and

(d) Even when frames from the primary AC are not transmitted during the TXOP, RTA frames from non-primary ACs are transmitted using the remaining channel resources.

Images