Sharing EDCA TXOP with RTA traffic

Abstract

To provide a method and apparatus for wireless communication in a network.SOLUTION: A communication circuit and protocol are provided for a wireless local area network (WLAN) using single EDCA and / or Multiple-User (MU) EDCA in which frames for Real Time Applications (RTA) can utilize shared Transmit Opportunities (TXOPs) to reduce transmission latencies. The protocol is configured in a number of ways to ensure communication fairness, such as by ensuring a minimum required channel resource for transmitting frames from the primary AC during the TXOP. AP MLDs and non-AP MLDs are also supported and can exchange information on distinguishing traffic streams from other traffic streams having the same Traffic Identifier (TID), in determining which links to use for transmitting the traffic stream.SELECTED DRAWING: Figure 29

Description

[Technical field]

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

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT N / A

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

[0004] The techniques of this disclosure relate generally to wireless network communications using Enhanced Distributed Channel Access (EDCA) that defines multiple Access Categories (ACs), and more specifically to enabling Real Time Application (RTA) packet transmissions to utilize Transmission Opportunity (TXOP) sharing to reduce latency. [Background technology]

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

[0006] Thus, there exists a need for enhancing RTA traffic sharing handling of TXOPs when using EDCA.The present disclosure fulfills this need and provides further advantages. [Means for solving the problem]

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

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

[0009] The techniques described herein will be better understood with reference to the following drawings, which are for illustrative purposes only. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a data field diagram of the TSPEC element contents defined in IEEE 802.11. [Diagram 2] FIG. 1 is a data field diagram of a TS information element defined in IEEE 802.11. [Diagram 3] FIG. 1 is a data field diagram of the TCLAS element defined in IEEE 802.11. [Figure 4] FIG. 1 is a data field diagram of a TCLAS processing element defined in IEEE 802.11. [Diagram 5] FIG. 1 is a data field diagram of an HE multi-user (MU) PPDU format used for downlink multi-user transmission, as defined in IEEE 802.11. [Figure 6] FIG. 1 is a data field diagram of an HE trigger-based (TB) PPDU format used for uplink multi-user transmission, as defined in IEEE 802.11. [Figure 7] FIG. 1 is a data field diagram of a trigger frame (TF) defined in IEEE 802.11. [Figure 8] FIG. 1 is a data field diagram of a common information field of a TF defined in IEEE 802.11. [Figure 9] FIG. 1 is a data field diagram of a user information field of a trigger frame (TF) defined in IEEE 802.11. [Figure 10] FIG. 11 is a data field diagram of the trigger-dependent user information field of the trigger frame (TF) of the MU-BAR defined in IEEE 802.11. [Figure 11] FIG. 1 is a data field diagram of a Block Ack (BA) frame defined in IEEE 802.11. [Figure 12]1 is a data field diagram of a buffer status request (BSR) frame defined in IEEE 802.11. [Figure 13] 1 is a communication diagram of downlink multi-user transmission using OFDMA as utilized in IEEE 802.11. [Figure 14A] 1 is a communication diagram of uplink multi-user transmission utilizing Orthogonal Frequency Division Multiple Access (OFDMA) as defined in IEEE 802.11. [Figure 14B] 1 is a communication diagram of uplink multi-user transmission utilizing Orthogonal Frequency Division Multiple Access (OFDMA) as defined in IEEE 802.11. [Figure 15] FIG. 1 is a transmission queue diagram of a reference model of EDCA (Extended DCF Channel Access) defined in IEEE 802.11. [Figure 16] FIG. 1 is a communication diagram for executing a channel access procedure of EDCA defined in IEEE 802.11. [Figure 17] FIG. 2 is a hardware block diagram of radio station hardware in accordance with at least one embodiment of the present disclosure. [Figure 18] FIG. 2 is a hardware block diagram of a station configuration, such as that included in multilink device hardware, in accordance with at least one embodiment of the present disclosure. [Figure 19] A topology of a WLAN having seven STAs, six of which are in three MLDs, in accordance with at least one embodiment of the present disclosure. [Figure 20] FIG. 1 is a communication diagram for terminating or modifying an LLTS in accordance with at least one embodiment of the present disclosure. [Figure 21] FIG. 2 is a data field diagram of an LLTS request frame in accordance with at least one embodiment of the present disclosure. [Figure 22] FIG. 1 is a data field diagram of an LLTS descriptor field format in accordance with at least one embodiment of the present disclosure. [Diagram 23] FIG. 2 is a data field diagram of RTA-TSPEC field contents in accordance with at least one embodiment of the present disclosure. [Figure 24] FIG. 13 is a data field diagram of an optional sub-element carrying an upper layer stream ID in accordance with at least one embodiment of the present disclosure. [Diagram 25] FIG. 13 is a data field diagram of an optional sub-element that carries LLTS / TID to link mapping in accordance with at least one embodiment of the present disclosure. [Figure 26] FIG. 2 is a data field diagram of an LLTS response frame in accordance with at least one embodiment of the present disclosure. [Figure 27] FIG. 2 is a data field diagram of an LLTS status field in accordance with at least one embodiment of the present disclosure. [Figure 28] FIG. 1 is a flow diagram for distinguishing between RTA and non-RTA traffic in accordance with at least one embodiment of the present disclosure. [Figure 29] FIG. 13 is a flow diagram of TXOP sharing for transmitting RTA traffic from a non-primary AC work in accordance with at least one embodiment of the present disclosure. [Diagram 30] FIG. 2 is a transmit queue diagram of an EDCA queue of AP1 or MLD1 in accordance with at least one embodiment of the present disclosure. [Diagram 31] FIG. 1 is a communication diagram in which AP1 transmits RTA frames from non-primary ACs only during TXOP, in accordance with at least one embodiment of the present disclosure. [Diagram 32] FIG. 11 is a transmission queue diagram of another EDCA queue state of AP1 or MLD1 in accordance with at least one embodiment of the present disclosure. [Diagram 33] FIG. 1 is a communication diagram in which AP1 transmits an RTA frame from a higher priority non-primary AC before a frame from a primary AC during a TXOP, in accordance with at least one embodiment of the present disclosure. [Diagram 34] FIG. 1 illustrates a communication diagram in which AP1 first transmits an RTA frame from a primary AC, then transmits an RTA frame from a non-primary AC, and then transmits a non-RTA frame from the primary AC during a TXOP, in accordance with at least one embodiment of the present disclosure. [Diagram 35]FIG. 1 is a communication diagram in which AP1 transmits an RTA frame from a non-primary AC with a lower priority than the primary AC, according to at least one embodiment of the present disclosure. [Diagram 36] FIG. 11 is a transmission queue diagram of a third example embodiment of EDCA queue states for AP1 or MLD1 in accordance with at least one embodiment of the present disclosure. [Figure 37] 1 is a communication diagram in which AP1 transmits an MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by a transmission request of the RTA frame from the non-primary AC, in accordance with at least one embodiment of the present disclosure. [Figure 38] 1 is a communication diagram in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by the delay requirement of the RTA frame from the primary AC, in accordance with at least one embodiment of the present disclosure. [Figure 39] FIG. 11 is a communication diagram illustrating another example in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by the delay requirement of the RTA frame from the primary AC, in accordance with at least one embodiment of the present disclosure. [Diagram 40] 1 is a communication diagram in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the duration of the MU PPDU is determined by the transmission requirements of the RTA frame from the primary AC, in accordance with at least one embodiment of the present disclosure. [Diagram 41] FIG. 1 is a communication diagram in which AP1 limits the time of TXOP sharing, in accordance with at least one embodiment of the present disclosure. [Diagram 42] FIG. 1 is a communication diagram in which AP1 shares a TXOP after transmitting a certain number of frames from a primary AC, in accordance with at least one embodiment of the present disclosure. [Diagram 43] FIG. 1 is a communication diagram in which AP1 shares a TXOP after transmitting frames from a primary AC for a period of time, in accordance with at least one embodiment of the present disclosure. [Diagram 44]FIG. 2 is a data field diagram of a frame conveying a dedicated time parameter setting in accordance with at least one embodiment of the present disclosure. [Diagram 45] FIG. 11 is a transmission queue diagram of a fourth example embodiment of EDCA queue states for AP1 or MLD1, in accordance with at least one embodiment of the present disclosure. [Figure 46] FIG. 1 is a communication diagram in which AP1 transmits MU OFDMA PPDUs and, for each user, RTA frames from non-primary ACs are transmitted earlier than frames from the primary AC, in accordance with at least one embodiment of the present disclosure. [Figure 47] FIG. 13 is a communication diagram of TXOP sharing when an AP transmits RTA frames from non-primary ACs later than RTA frames from the primary AC, but earlier than non-RTA frames from the primary AC for each user, in a MU PPDU, in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0013] Since an RTA frame is only valid if it is delivered within a certain time, it requires low latency due to the high timeliness requirement for delivery. One solution in CSMA / CA wireless technology is to increase the chances for a STA to transmit an RTA frame, for example by using a high priority AC for the transmission of the RTA frame.

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

[0015] STAs can transmit RTA frames using the TXOP time acquired by the low-priority AC to avoid delays caused by the TXOP time acquired by the low-priority AC. The task of sharing the TXOP of the primary AC to transmit frames from non-primary ACs is difficult due to the coexistence of RTA and non-RTA traffic. The challenges of this process can be summarized as (a) distinguishing between RTA and non-RTA traffic and sharing the TXOP of the primary AC to transmit RTA packets from non-primary ACs when there are unsent packets from the primary AC;

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

[0017] 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 MSDUs or A-MSDUs belonging to a TS under this TSPEC. The Mean Data Rate field indicates the average data rate, specified by the MAC SAP, for transmitting MSDUs or A-MSDUs belonging to a TS under this TSPEC. The Peak Data Rate field indicates the maximum data rate, specified by the MAC SAP, for transmitting MSDUs or A-MSDUs belonging to a TS under this TSPEC. The Burst Size field indicates the maximum burst at the peak data rate of MSDUs or A-MSDUs belonging to a TS under this TSPEC. The Delay Bound field indicates the maximum time allowed for transmitting MSDUs or A-MSDUs belonging to a TS under this TSPEC. The Minimum PHY Rate field indicates the minimum PHY rate for transmitting MSDUs or A-MSDUs belonging to a TS under this TSPEC. The Surplus Bandwidth Allowance field indicates the ratio of the bandwidth used for transmission and retransmission of an MSDU or A-MSDU belonging to a TS under this TSPEC to the bandwidth used for one transmission of this MSDU or A-MSDU at the minimum PHY rate. The Medium Time field indicates the time allowed to access the medium. The DMG Attributes field is present when the TSPEC applies to a Directional Multi-Gigabit (DMG) BSS.

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

[0019] 2.2.TCLAS Elements Figure 3 shows the contents of the TCLAS element defined in IEEE802.11. The Element ID field indicates the type of element, which in this case is a TCLAS element. The Length field indicates the length of the TSPEC element. The User Priority field indicates the user priority from the upper layer. The Frame Classifier field indicates how to classify frames from the upper layer.

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

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

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

[0023] IEEE 802.11ax specifies multiple PLCP protocol data unit (PPDU) formats for transmitting packets in different multi-user transmissions, which will be described later. PLCP is an acronym for PHY Layer Convergence Protocol.

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

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

[0026] The contents of the Trigger Frame (TF) are shown in Figure 7. The Frame Control field indicates the type of frame. The duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA that sent the frame. The Common Info field contains information for all assigned STAs as shown in Figure 8 below. The User Info field contains information for each STA as shown in Figure 9. The Common Info and User Info fields provide individual resource block allocation information for each user.

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

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

[0029] The trigger frame shown in Figure 7 can be sent as a Multi-User Block Ack Request (MU-BAR) by setting the trigger type in the common information field to "2". When the trigger frame is a MU-BAR, the contents of the Trigger-Dependent User Information field (shown in Figure 9) in the trigger frame are as shown in Figure 10.

[0030] FIG. 10 shows the trigger dependent user information field in a trigger frame for MU-BAR, showing the subfields BAR Control and BAR Information.

[0031] Figure 11 shows the contents of a Block Ack (BA) frame with the following subfields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA that sent the frame. The BA Control field indicates the Block Ack policy. The BA info field contains the transmission feedback.

[0032] FIG. 12 shows the contents of a Buffer Status Request (BSR) frame with the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA that sent the frame. The HT Control field indicates the variant of the BSR control subfield. The Format Indication field is used to indicate the format of the HT control field. If B0 and B1 are set to the first state (e.g., "1"), it indicates that the HT control field uses the HE format. This field is followed by the A-Control field. The A-Control field carries the buffer status report. The Control ID field indicates that the BSR is carried in the control information field. The Control Information field carries the variant of the BSR control subfield. The ACI Bitmap field indicates the access category for which the buffer status is reported. The Delta TID field indicates the number of TIDs for which the buffer status is being reported. The ACI High field indicates the Access Category reported in the Queue Size High field. The Scaling Factor field indicates the units of the Queue Size High and Queue Size All fields. The Queue Size High field indicates the queue size of the AC indicated in the ACI High in units of Scaling Factor. The Queue Size All field indicates the queue size of the AC indicated in the ACI Bitmap, also in units of Scaling Factor.

[0033] Figure 13 shows an example of downlink multi-user transmission using OFDMA. The transmitting AP transmits data packets to its receivers 1, 2, 3 and 4 using the HE MU PPDU format. After the AP finishes the first transmission, it sends a Multi-User Block Ack Request (MU-BAR) to all receivers. Then, each receiver sends a Block Ack (BA) back to the AP. The AP decides to retransmit packets to receivers 1, 3 and 4 according to the content of the BA. The AP contends for the channel and waits for a given backoff time. The first retransmission occurs after the AP gains channel access right.

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

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

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

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

[0038] The implementation of the EDCA channel access procedure is shown in Figure 16. As shown, the EDCA channel access when using only the Distributed Coordination Function (DCF) is also compared.

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

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

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

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

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

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

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

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

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

[0048] Additionally, multiple instances of station hardware as shown may be combined into a Multi-Link Device (MLD), which typically has a processor and memory to coordinate activity, although each STA within the MLD does not necessarily require a separate CPU and memory.

[0049] FIG. 18 shows an example embodiment 40 of a Multi-Link Device (MLD) hardware configuration. The MLD has multiple STAs, each operating on a different frequency link. The MLD has external I / O 41 access to applications, which connects to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to enable execution of program(s) that implement the communication protocol at the MLD level. The MLD distributes tasks to each of its associated stations, STA1 42, STA2 44 to STA N 46, collects information from them, and can share the information among its associated STAs.

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

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

[0052] 5.2. STA Topologies Considered To better illustrate the objectives of the disclosed technology, a network scenario is used in the embodiment.

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

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

[0055] 5.3. Differentiating RTA and non-RTA traffic 5.3.1. Low Latency Traffic Stream (LLTS) Operation In this section, we introduce a mechanism called Low Latency Traffic Streams (LLTS) to distinguish between RTA and non-RTA traffic. In general, LLTS can be used to distinguish traffic streams with special QoS requirements, such as delay, jitter and / or reliability, from other traffic.

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

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

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

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

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

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

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

[0063] Also, the LLTS request frame and the LLTS response frame for the same LLTS configuration procedure may be transmitted over different links.

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

[0065] The Category and QoS Action fields indicate the type of action field, which in this case indicates that it 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 this token field, it should respond with an LLTS response frame using the same dialog token. The Action field contains an LLTS request element with an Element ID indicating the type of element (in this example, an LLTS request element), a Length subfield indicating the length of the LLTS request element, and an LLTS Descriptor List subfield indicating the sequence of LLTS descriptor fields. Each LLTS descriptor field is set to indicate an LLTS configuration request for traffic according to a particular specification and classification information. Once this information is received, the receiving STA, knowing the traffic specification and classification information, can decide whether to accept or reject the LLTS configuration request.

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

[0067] If a non-AP STA or MLD sets the Request Type field to "Change", it requests to modify an existing LLTS. When an AP or AP MLD receives this field, it can use the LLID to discover the LLTS. The AP or AP MLD then accepts or rejects the change of the parameters of this LLTS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0092] The RTA-TSPEC field may be identical to the RTA-TSPEC element defined in Figure 23. The AP sets this field to indicate the specification and QoS requirements of the RTA traffic. When a non-AP STA receives this field, it knows that the LLTS decision is made for traffic under RTA-TSPEC. This field also contains information of the direction (e.g., uplink, downlink, peer-to-peer, or bidirectional) of the RTA traffic under this LLTS. The AP may also indicate the channel resources that can be allocated for the transmission of the RTA traffic of this LLTS.

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

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

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

[0096] The STA can identify an LLTS by a tuple of LLTS information such as <LLID, transmitter>, <LLID, receiver>, or <LLID, transmitter, receiver>. The AP or AP MLD can use the unique LLID of each LLTS within its BSS to enable each STA to identify the LLTS within the BSS by the LLID only, or to identify the LLTS within the BSS and OBSS using a tuple of <LLID, BSSID>.

[0097] 5.4 TXOP Sharing for Sending RTA Packets 5.4.1 Flowchart The procedure for TXOP sharing for transmitting RTA frames from a non-primary AC is described. The disclosed technique enables a STA to share the TXOP of the primary AC and transmit RTA frames from the non-primary AC even if there are unsent frames from the primary AC, compared to the current TXOP sharing rules in IEEE 802.11ax.

[0098] FIG. 29 shows an example embodiment 330 of TXOP sharing for transmitting RTA traffic from a non-primary AC. RTA traffic is encapsulated in frame units when it arrives at the EDCA queue. Frames carrying RTA traffic are represented as RTA frames, and frames carrying non-RTA traffic are represented as non-RTA frames. One or more frames can be included in one packet and transmitted via a link or channel. The AC associated with the EDCAF that has acquired the TXOP is called the primary AC.

[0099] When the STA acquires the TXOP of the primary AC (332), a decision is made as to whether to share the TXOP to transmit frames from the non-primary AC during this TXOP (334).

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

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

[0102] If a station decides to share a TXOP to transmit an RTA frame from a non-primary AC, it should be noted that: the non-primary AC in block 336 can only represent an AC with a higher priority than the primary AC; the RTA frame from the non-primary AC in this case can only represent an expiring frame (e.g., the frame will expire before the end of the TXOP).

[0103] The following sequences are possible during a TXOP:

[0104] (1) A STA shall / may transmit all / some RTA frames from non-primary ACs first, followed by frames from the primary AC. A STA may, for example, follow any one of the following rules: (a) A STA shall / may transmit RTA frames from non-primary ACs with higher priority than the primary AC first, followed immediately by frames from the primary AC; (b) A STA shall / may transmit RTA frames from the primary AC first, followed by RTA frames from non-primary ACs with higher priority than the primary AC, followed by non-RTA frames from the primary AC; (c) A STA shall / may transmit RTA frame(s) from non-primary ACs with higher priority than the primary AC first, followed by frames from the primary AC that are retransmissions.

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

[0106] (3) The STA handles an RTA frame from a non-primary AC with a higher priority than the primary AC in the same way as an RTA frame from the primary AC. In addition, the STA can also handle an RTA frame from a non-primary AC with a higher priority than the primary AC as an RTA frame from the primary AC.

[0107] (4) When a STA transmits an MU PPDU (eg, an MU PPDU for MU-MIMO or MU-OFDMA), it may include RTA frames and non-RTA frames from non-primary ACs with higher or lower priority in the MU PPDU.

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

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

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

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

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

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

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

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

[0116] AC_BE queue 358 represents an EDCA queue for an AC BE, shown having three non-RTA frames, illustrated as AC_BE(1) through AC_BE(3).

[0117] AC_BK queue 360 ​​represents the EDCA queue for AC BK, which is illustrated as being empty with no frames present in the queue.

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

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

[0120] In this example, we consider the queue state when AP1 initiates an EDCA TXOP and no new frames arrive during the EDCA TXOP, and we also assume that if the queue state is that of MLD1, MLD1 does not transmit on other links during the TXOP shown in this example.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0139] Once AP1 has acquired VI TXOP 400, it transmits 614 an MU OFDMA PPDU carrying an RTA frame from AC_VI to STA1's queue, exemplified as AC_VI(1), an RTA frame from AC_VO to STA2, exemplified as AC_VO(1), and a non-RTA frame from the AC_VO queue to STA3, exemplified as AC_VI(3). Note that the duration of the MU OFDMA PPDU is determined by the duration of frame AC_VO(1), not the durations of frames AC_VI(1) and AC_VI(3).

[0140] AP1 then transmits 620 another MU OFDM PPDU including an RTA frame from the AC_VI queue, illustrated as AC_VI(2), and non-RTA frames, illustrated as AC_VO(2) and AC_BE(2), according to the IEEE 802.11 TXOP sharing rules.

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

[0142] The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, so that each frame of the MU PPDU is transmitted through a different spatial stream instead of a different RU. In this figure, the required feedback such as ACK or BA of the MU PPDU is also changed to feedback of the MU MIMO PPDU.

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

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

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

[0146] The EDCA queue state of AP1 or MLD1 is shown in Figure 36, assuming the queue state when AP1 initiates TXOP 400, and assuming that no new frames arrive during the EDCA TXOP. Furthermore, assuming that the queue state is that of MLD1, MLD1 does not transmit on other links during the illustrated TXOP.

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

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

[0149] The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, in which each frame of the MU PPDU is transmitted through a different spatial stream instead of a different RU, and the required feedback such as ACK or BA of the MU PPDU is also changed to feedback of the MU MIMO PPDU.

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

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

[0152] 39 illustrates another example embodiment 650 in which AP1 transmits MU OFDMA PPDUs carrying RTA frames from non-primary ACs, with the duration of the MU PPDUs determined by the delay requirements of the RTA frames from the primary AC. This figure illustrates the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 in the TXOP 400.

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

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

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

[0156] The MU OFDMA PPDU shown in this example can be replaced with a MU MIMO PPDU, in which case each frame in the MU PPDU is transmitted through a different spatial stream instead of a different RU, in which case the required feedback such as ACK or BA for the MU PPDU is also changed to the feedback used for the MU MIMO PPDU.

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

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

[0159] 40 illustrates an example embodiment 670 in which AP1 transmits MU OFDMA PPDUs carrying RTA frames from non-primary ACs, with the duration of the MU PPDUs determined by the transmission requirements of the RTA frames from the primary AC. This figure illustrates the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 during the TXOP 400.

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

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

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

[0163] The MU OFDMA PPDU in this example can be replaced with an MU MIMO PPDU, and each frame in the MU PPDU is transmitted through a different spatial stream instead of a different RU. The required feedback, such as ACK or BA, of the MU PPDU is also changed to the feedback required for the MU MIMO PPDU.

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

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

[0166] 41 illustrates an example embodiment 710 in which AP1 limits the time of TXOP sharing. The figure shows the interactions between AP1 392, STA1 394, STA2 396, and STA3 396 in a TXOP 400.

[0167] The EDCA queue state of AP1 or MLD1 shown in Figure 36 assumes the queue state when AP1 initiates the TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, assume that if the queue state is that of MLD1, then MLD1 does not transmit on other links during the TXOP.

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

[0169] AP1 then transmits the frame from the AC_VI queue, illustrated as AC_VI(2), to STA1 (718).

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

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

[0172] The EDCA queue state of AP1 or MLD1 shown in Figure 36 assumes the queue state when AP1 initiates the TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, assume that if the queue state is that of MLD1, then MLD1 does not transmit on other links during the TXOP.

[0173] As shown, AP1 must transmit a certain amount of frames from primary AC VI, indicated by dedicated_byte, after the start of the TXOP before it can share the TXOP for transmission. AP1 can share the TXOP with an RTA frame from a non-primary AC after the total bytes of frames from the primary AC exceed dedicated_byte, even if there are unsent frames from the primary AC.

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

[0175] In order to set the dedicated time for each STA, AP1 can transmit a frame carrying information as shown in FIG.

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

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

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

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

[0180] The EDCA queue state of AP1 or MLD1 shown in Figure 36 assumes the queue state when AP1 initiates the TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, assume that if the queue state is that of MLD1, then MLD1 does not transmit on other links during the TXOP.

[0181] As shown, there is a dedicated time 792 for primary AC VI after the start of the TXOP. AP1 can share the TXOP after the end of the dedicated time to transmit an RTA frame from a non-primary AC, even if there is an unsent frame from the primary AC.

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

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

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

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

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

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

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

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

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

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

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

[0193] As explained in FIG. 42, the "dedicated time" can also be replaced with a "dedicated byte" within the frame to set the dedicated byte parameter.

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

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

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

[0197] The EDCA queue state of AP1 or MLD1 shown in Figure 45 assumes the queue state when AP1 initiates the TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is that of MLD1, assume that MLD1 is not transmitting on other links during the TXOP shown.

[0198] Once AP1 acquires the VI TXOP 400, it transmits (892) an MU OFDMA PPDU carrying RTA frames from the AC_VO queue, exemplified as AC_VO(1) and AC_VO(2), to STA1 and STA2, and a non-RTA frame from the AC_BE queue, exemplified as AC_BE(2), to STA3.

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

[0200] The MU OFDMA PPDU shown in this example can be replaced with an MU MIMO PPDU, in which case each frame of the MU PPDU is transmitted through a different spatial stream instead of a different RU, and the required feedback is also changed from the ACK or BA of the MU PPDU to feedback suitable for the MU MIMO PPDU in the figure.

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

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

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

[0204] The illustrated AP1 transmits an MU OFDMA PPDU (932) by first transmitting an RTA frame from the primary AC, then an RTA frame from a high priority AC, and then a non-RTA frame from the primary AC for each user.

[0205] The EDCA queue state of AP1 or MLD1 shown in Figure 45 assumes the queue state when AP1 initiates the TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Furthermore, if the queue state is that of MLD1, assume that MLD1 is not transmitting on other links during the illustrated TXOP.

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

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

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

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

[0210] Note that an AP (eg, AP1) can reserve a TXOP using RTS / CTS or MU-RTS / CTS before transmitting a frame.

[0211] 6. General Scope of the Embodiments Embodiments of the present technology may be described herein with reference to flowcharts of methods and systems according to embodiments of the present technology, and / or procedures, algorithms, steps, operations, formulas, or other computational expressions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and / or steps) of the flowchart, and any procedures, algorithms, steps, operations, formulas, or computational expressions, may be implemented by various means, such as hardware, firmware, and / or software that includes one or more computer program instructions embodied in a computer readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including, but not limited to, a general purpose computer or a special purpose computer, or any other programmable processing device to produce a machine, such that the computer program instructions executing on the computer processor or other programmable processing device produce means for performing the specified function(s).

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

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

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

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

[0216] From the description herein, it will be understood that the present disclosure encompasses multiple technology implementations, including but not limited to the following.

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

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

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

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

[0221] An apparatus or method of any preceding implementation, in which a STA that has reserved the minimum required channel resources to transmit frames from a primary AC can use the minimum required channel resources for TXOP sharing when transmission of all frames from the primary AC is completed.

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

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

[0224] The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including the STA ensuring that a minimum amount of channel time is provided for transmitting frames from the primary AC during a TXOP.

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

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

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

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

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

[0230] The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform steps further including the STA limiting the time of TXOP sharing.

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

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

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

[0234] The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including the AP MLD responding to the request to set up a traffic stream with a frame including a traffic flow specification, QoS requirements, upper layer information, LLID, and status to indicate whether the request has been granted or rejected.

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

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

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

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

[0239] The apparatus or method of any preceding implementation, wherein the instructions, when executed by a processor, perform a step further including AP MLD transmitting unsolicited frames to terminate or modify an existing traffic stream.

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

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

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

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

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

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

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

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

[0248] In addition, amounts, ratios, and other numerical values ​​may be expressed in range format in this specification. Such range formats are used for convenience and simplification, and include numerical values ​​explicitly specified as the limits of the range, but should be understood to include all individual numerical values ​​or subranges within the range as if each of these numerical values ​​and subranges were explicitly stated. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also include individual ratios such as about 2, about 3, about 4, and subranges such as about 10 to about 50, about 20 to about 100, etc.

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

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

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

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

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

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

[0255] Although the description herein contains many details, these should not be construed as limiting the scope of the disclosure, but merely as exemplifying some of the presently preferred embodiments, and therefore the scope of the disclosure will be understood to fully embrace other embodiments that may become apparent to those skilled in the art.

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

[0257] 330 Example of embodiment 332 STA acquires a TXOP for an AC represented by a primary AC and decides to share the TXOP with a non-primary AC(s). 334 Has the STA decided to share a TXOP to transmit frames from a non-primary AC(s)? 336 STA follows the TXOP sharing rules for non-RTA frames defined in IEEE 802.11ax. 338 A STA can transmit an RTA frame from a non-primary AC regardless of whether there is a frame from the primary AC to transmit. 340 STA transmits frame from non-primary AC(s) during TXOP TIFF2025074257000002.tif75156 TIFF2025074257000003.tif44153 TIFF2025074257000004.tif103169 TIFF2025074257000005.tif119156 TIFF2025074257000006.tif120156 TIFF2025074257000007.tif103169 TIFF2025074257000008.tif115156 TIFF2025074257000009.tif115156 TIFF2025074257000010.tif55169

Claims

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

2. The instructions, when executed by the processor, perform the steps further including ensuring that a minimum required channel resource for transmitting a frame from a primary AC during a TXOP is available within the channel resources.

2. The apparatus of claim 1.

3. A STA that has secured a minimum required channel resource for transmitting a frame from a primary AC can use the minimum required channel resource for TXOP sharing when transmission of all frames from the primary AC is completed.

3. The apparatus of claim 2.

4. The instructions, when executed by the processor, perform a step further comprising: the STA not configuring minimum required channel resources for transmitting frames from a primary AC during a TXOP.

2. The apparatus of claim 1.

5. The instructions, when executed by the processor, perform steps further including the STA ensuring that a given minimum number of bytes is transmitted from a primary AC during a TXOP.

2. The apparatus of claim 1.

6. The instructions, when executed by the processor, perform the steps further including: the STA ensuring that a minimum amount of channel time is provided for transmitting frames from a primary AC during a TXOP.

2. The apparatus of claim 1.

7. The instructions, when executed by the processor, perform the steps further comprising: the STA transmitting an RTA frame from a non-primary AC even if no frame from a primary AC was transmitted during a TXOP.

2. The apparatus of claim 1.

8. The instructions, when executed by the processor, perform the steps further comprising: the STA transmitting an RTA frame from a non-primary AC during a TXOP only if all RTA frames from a primary AC have been transmitted.

2. The apparatus of claim 1.

9. The instructions, when executed by the processor, perform a step further comprising: the STA transmitting an RTA frame from a higher priority non-primary AC during a TXOP before transmitting an RTA frame from a primary AC.

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

11. The instructions, when executed by the processor, perform the steps further including the STA transmitting an MU PPDU packet, the length of which is determined by transmission and / or delay requirements of an RTA frame from a primary AC.

2. The apparatus of claim 1.

12. The instructions, when executed by the processor, perform steps further including limiting a time for the STA to share a TXOP.

2. The apparatus of claim 1.

13. The instructions, when executed by the processor, perform the steps further including allowing the STA to transmit RTA frames from non-primary ACs earlier than frames from a primary AC only if the RTA frames are about to expire.

2. The apparatus of claim 1.

14. The instructions, when executed by the processor, perform steps further including the STA acquiring a TXOP of a primary AC and sharing the TXOP with a lower priority non-primary AC.

2. The apparatus of claim 1.

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

16. The instructions, when executed by the processor, perform the steps of: when the non-AP MLD requests the AP MLD to set up a traffic stream, sending a frame to the AP MLD including a traffic flow specification, a QoS requirement, upper layer information, and an LLID.

16. The apparatus of claim 15.

17. The instructions, when executed by the processor, perform the steps of: the AP MLD responding to the request to set up the traffic stream with a frame including a traffic flow specification, QoS requirements, higher layer information, an LLID, and a state to indicate whether the request was granted or rejected by the non-AP MLD.

17. The apparatus of claim 16.

18. The instructions, when executed by the processor, perform the steps of: the AP MLD and the non-AP MLD performing the traffic flow specification, QoS requirement exchange by using a traffic specification (TSPEC) element configured to include additional QoS requirements as defined in IEEE 802.11ax.

20. The apparatus of claim 17.

19. The further QoS requirements include jitter and packet loss requirements.

20. The apparatus of claim 18.

20. The instructions, when executed by the processor, perform steps further including the AP MLD and the non-AP MLD exchanging traffic flow information by transmitting frames over different links.

16. The apparatus of claim 15.

21. The instructions, when executed by the processor, perform the steps of: in response to the AP MLD and the non-AP MLD communicating a tuple including a non-AP MAC address and an LLID, distinguishing one traffic stream from another traffic stream.

16. The apparatus of claim 15.

22. The instructions, when executed by the processor, perform steps further including the AP MLD transmitting an unsolicited frame to terminate or modify an existing traffic stream.

16. The apparatus of claim 15.

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

Images