Shared EDCA TXOP with RTA traffic

Abstract

A communication circuit and protocol for a wireless local area network (WLAN) using a single EDCA and / or a multi-user (MU) EDCA, wherein frames for real-time applications (RTA) can utilize shared transmission opportunities (TXOP) to reduce transmission latency. The protocol is configured in several ways to ensure communication fairness, such as by ensuring that minimum required channel resources are provided for transmitting frames from the primary AC during the TXOP. AP MLD and non-AP MLD are also supported, and information regarding distinguishing a traffic stream from other traffic streams with the same traffic identifier (TID) can be exchanged when determining which links to use for transmitting traffic streams.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority and benefit to U.S. Patent Application Serial No. 17 / 509,017, filed October 24, 2021, which is incorporated herein by reference in its entirety. This application also claims priority and benefit to U.S. Provisional Patent Application Serial No. 63 / 168,434, filed March 31, 2021, which is incorporated herein by reference in its entirety.

[0003] Statement regarding research or development sponsored by the U.S. federal government

[0004] not applicable

[0005] Reminder about copyrighted materials

[0006] Some material in this patent document may be protected under copyright laws in the United States and other countries. The copyright holder does not object to any reproduction or reproduction of this patent document or patent disclosure as it appears in publicly available documents or records in the United States Patent and Trademark Office, but otherwise reserves all copyright rights involved. The copyright holder hereby does not waive any right to keep this patent document confidential, including but not limited to the rights under 37C.FR §1.14. Technical Field

[0007] The technology disclosed herein generally relates to wireless network communication using Enhanced Distributed Channel Access (EDCA) that defines multiple Access Classes (ACs), and more specifically to allowing Real-Time Application (RTA) packet transmission to utilize Transmission Opportunity (TXOP) sharing to reduce latency. Background Technology

[0008] Current 802.11 wireless technology using CSMA / CA focuses on high network throughput performance, but lacks sufficient support for the low-latency traffic required by real-time applications (RTA) such as transmitting RTA frames. Each RTA frame requires low latency due to its high timeliness requirements, as it is only valid if delivered within a specific time period. In addition to RTA traffic, problems arise when defining multiple access classes (ACs) for RTA traffic using Enhanced Distributed Channel Access (EDCA).

[0009] Therefore, enhanced processing for RTA traffic sharing of TXOP is required when using EDCA. This disclosure meets this requirement and provides additional benefits. Summary of the Invention

[0010] Current wireless communication systems using Enhanced Distributed Channel Access (EDCA) do not differentiate between RTA packets and non-RTA packets; therefore, all packets use the same TXOP sharing rules under EDCA. This disclosure is configured to improve the flexibility of RTA packet transmission to reduce latency when utilizing EDCA transmission opportunity (TXOP) sharing. The main benefits provided by the disclosed protocol are as follows: (a) STAs can share the TXOP of the primary AC to transmit RTA frames when frames from the primary AC are not being transmitted; and (b) fairness (equality, averaging) is taken into account between transmitting frames from the primary AC and transmitting RTA frames from non-primary ACs.

[0011] Other aspects of the technology described herein will be presented later in the specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology and not for limiting it. Attached Figure Description

[0012] A more comprehensive understanding of the techniques described herein will be achieved by referring to the accompanying drawings, which are for illustrative purposes only:

[0013] Figure 1 is a diagram of the data fields of the TSPEC cell content as defined in IEEE 802.11.

[0014] Figure 2 is a diagram of the data fields of a TS information unit as defined in IEEE 802.11.

[0015] Figure 3 is a diagram of the data fields of a TCLAS cell as defined in IEEE 802.11.

[0016] Figure 4 is a diagram of the data fields of the TCLAS processing unit as defined in IEEE 802.11.

[0017] Figure 5 is a diagram of the data fields in the HE multi-user (MU) PPDU format for downlink multi-user transmission as defined in IEEE 802.11.

[0018] Figure 6 is a diagram of the data fields for HE-based trigger (TB) PPDU format for uplink multi-user transmission as defined in IEEE 802.11.

[0019] Figure 7 is a diagram of the data fields of a trigger frame (TF) as defined in IEEE 802.11.

[0020] Figure 8 is a data field diagram of the common information field of a TF as defined in IEEE 802.11.

[0021] Figure 9 is a data field diagram of the user information field of a trigger frame (TF) as defined in IEEE 802.11.

[0022] Figure 10 is a data field diagram of the trigger-related user information field in a trigger frame (TF) for MU-BAR as defined in IEEE 802.11.

[0023] Figure 11 is a diagram of the data fields of a block ACK (BA) frame as defined in IEEE 802.11.

[0024] Figure 12 is a diagram of the data fields for a Buffered State Request (BSR) as defined in IEEE 802.11.

[0025] Figure 13 is a communication diagram of downlink multi-user transmission using OFDMA as utilized in IEEE 802.11.

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

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

[0028] Figure 16 is a communication diagram illustrating the implementation of a channel access procedure for EDCA as defined in IEEE 802.11.

[0029] Figure 17 This is a hardware block diagram of wireless station hardware according to at least one embodiment of the present disclosure.

[0030] Figure 18 This is a hardware block diagram of a station configuration, such as that included in multi-link device hardware, according to at least one embodiment of the present disclosure.

[0031] Figure 19 This is a topology of a WLAN with seven STAs, according to at least one example of this disclosure, where six are located within three MLDs.

[0032] Figure 20 This is a communication diagram of the termination or modification of LLTS based on at least one example of the content of this disclosure.

[0033] Figure 21 This is a data field diagram of an LLTS request frame based on at least one example of this disclosure.

[0034] Figure 22 It is a data field diagram in LLTS descriptor field format according to at least one example of this disclosure.

[0035] Figure 23This is a data field diagram of the RTA-TSPEC field content based on at least one example of this disclosure.

[0036] Figure 24 It is a data field diagram of an optional sub-unit carrying a higher-layer flow ID, based on at least one example of this disclosure.

[0037] Figure 25 This is a data field diagram of an optional sub-unit that carries an LLTS / TID to a link mapping, according to at least one example of this disclosure.

[0038] Figure 26 This is a diagram of the data fields of an LLTS response frame, based on at least one example of this disclosure.

[0039] Figure 27 This is a data field diagram of an LLTS status field based on at least one example of the present disclosure.

[0040] Figure 28 It is a flowchart illustrating the distinction between RTA traffic and non-RTA traffic based on at least one example of the present disclosure.

[0041] Figure 29 This is a flowchart illustrating the TXOP sharing of RTA traffic from a non-primary AC, based on at least one example of this disclosure.

[0042] Figure 30 This is a sending queue diagram of an EDCA queue for AP1 or MLD1, based on at least one example of the present disclosure.

[0043] Figure 31 This is a communication diagram of AP1 sending RTA frames from a non-primary AC only during TXOP, according to at least one example of this disclosure.

[0044] Figure 32 It is a sending queue diagram of another EDCA queue of AP1 or MLD1 according to at least one example of this disclosure.

[0045] Figure 33 This is a communication diagram of at least one example of the present disclosure in which AP1 transmits RTA frames from a higher-priority non-primary AC before frames from the primary AC during TXOP.

[0046] Figure 34 This is a communication diagram based on at least one example of the present disclosure, in which AP1 first sends RTA frames from the primary AC, followed by RTA frames from the non-primary AC, and then non-RTA frames from the primary AC during TXOP.

[0047] Figure 35This is a communication diagram of AP1 sending RTA frames from a non-primary AC that has a lower priority than the primary AC, according to at least one example of this disclosure.

[0048] Figure 36 This is a third example of a transmission queue diagram of the EDCA queue status of AP1 or MLD1, based on at least one example of this disclosure.

[0049] Figure 37 This is a communication diagram of AP1 transmitting a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, according to at least one example of the present disclosure, wherein the duration of the MU PPDU is determined by the transmission request of the RTA frame from the non-primary AC.

[0050] Figure 38 This is a communication diagram of AP1 transmitting a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, according to at least one example of the present disclosure, wherein the duration of the MU PPDU is determined by the latency requirement of the RTA frame from the primary AC.

[0051] Figure 39 This is a communication diagram of another example of AP1 transmitting a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, according to at least one example of this disclosure, wherein the duration of the MU PPDU is determined by the latency requirement of the RTA frame from the primary AC.

[0052] Figure 40 This is a communication diagram of AP1 transmitting a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, according to at least one example of the present disclosure, wherein the duration of the MU PPDU is determined by the transmission request of the RTA frame from the primary AC.

[0053] Figure 41 This is a communication diagram of AP1 limiting the time of TXOP sharing, based on at least one example of this disclosure.

[0054] Figure 42 This is a communication graph of AP1 sharing TXOP after sending a specific number of frames from the main AC, according to at least one example of the present disclosure.

[0055] Figure 43 This is a communication diagram of AP1 sharing TXOP after sending frames from the main AC for a certain amount of time, according to at least one example of this disclosure.

[0056] Figure 44 It is a data field diagram of a frame for carrying dedicated time parameter settings, according to at least one example of the present disclosure.

[0057] Figure 45 This is a fourth example of a transmission queue diagram of the EDCA queue status of AP1 or MLD1, based on at least one example of this disclosure.

[0058] Figure 46 This is a communication diagram of AP1 transmitting MU OFDMA PPDU according to at least one example of the present disclosure, wherein for each user, RTA frames from the non-primary AC are transmitted earlier than frames from the primary AC.

[0059] Figure 47 It is a communication graph shared by TXOP in a MU PPDU according to at least one example of the present disclosure, wherein the AP sends RTA frames from the non-primary AC later than RTA frames from the primary AC but earlier than non-RTA frames from the primary AC for each user. Detailed Implementation

[0060] 1. Introduction

[0061] Real-time applications (RTA) require low latency and best-effort communication. Data generated from RTA is called RTA traffic and is packetized into RTA frames at the transmitter station (STA). Conversely, data generated from non-time-sensitive applications is referred to herein as non-RTA traffic and is packetized into non-RTA frames at the transmitter station (STA). The transmitter station (STA) then transmits packets carrying frames to the receiver station (STA) via a channel (link).

[0062] When RTA traffic arrives at the EDCA queue, it is encapsulated as frames. Frames carrying RTA traffic are identified by RTA frames, and frames carrying non-RTA traffic are identified by non-RTA frames. One or more frames can be included in a packet and transmitted over a link or channel. The AC associated with the EDCAF that obtains the EDCA TXOP is called the primary AC.

[0063] RTA frames require low latency due to their high timeliness requirements for delivery, as they are only valid if delivered within a specific time period. One solution in CSMA / CA wireless technology is to give STAs more opportunities to transmit RTA frames, for example, by using a high-priority AC for transmitting RTA frames.

[0064] Due to random channel access, the STA needs to sense and contend for channel access before transmitting each frame. For EDCA, the STA can use the short channel contention time of the high-priority AC to accelerate channel access. However, there is a possibility that a low-priority AC will access the channel earlier than the high-priority AC. The TXOP time obtained by the low-priority AC causes a delay in the transmission of RTA frames from the high-priority AC.

[0065] To avoid delays caused by the TXOP time acquired by the low-priority AC, the STA can use the TXOP time acquired by the low-priority AC to send RTA frames. Due to the coexistence of RTA and non-RTA traffic, sharing the TXOP of the primary AC to send frames from non-primary ACs is challenging. This challenge can be summarized as: (a) distinguishing between RTA and non-RTA traffic, and sharing the TXOP of the primary AC to send RTA packets from non-primary ACs when packets from the primary AC have not been sent.

[0066] 2. Current 802.11 operation

[0067] 2.1 TSPEC Unit

[0068] Figure 1 depicts the contents of a TSPEC cell as defined in IEEE 802.11, with the following fields: Cell ID indicates the cell type, in this example a TSPEC cell. Length field indicates the length of the TSPEC cell. TS Information field indicates traffic flow information, with the subfields shown in Figure 2. Nominal MSDU Size field indicates the nominal size of the MSDU or A-MSDU belonging to this TSPEC. Maximum MSDU Size field indicates the maximum size of the MSDU or A-MSDU belonging to this TSPEC. Minimum Service Interval field indicates the minimum time between the start times of two successive Service Periods (SPs). Maximum Service Interval field indicates the maximum time between the start times of two successive SPs. Inactive Interval field indicates the time interval during which no MSDUs belonging to this TS arrive or are transmitted before the TS is deleted. Pause Interval field indicates the time interval during which no MSDUs belonging to this TS arrive or are transmitted before the generation of successive QoS(+)CF polling for the TS is stopped.

[0069] 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 MAC SAP for sending MSDUs or A-MSDUs belonging to this TSPEC. The Average Data Rate field is the average data rate specified by MAC SAP for sending MSDUs or A-MSDUs belonging to this TSPEC. The Peak Data Rate field is the maximum data rate specified by MAC SAP for sending MSDUs or A-MSDUs belonging to this TSPEC. The Burst Size field indicates the maximum burst size of MSDUs or A-MSDUs belonging to this TSPEC at the peak data rate. The Delay Boundary field indicates the maximum allowed time for sending MSDUs or A-MSDUs belonging to this TSPEC. The Minimum PHY Rate field indicates the minimum PHY rate used for sending MSDUs or A-MSDUs belonging to this TSPEC. The Allowed Safer Bandwidth field indicates the ratio of the bandwidth used for sending MSDUs or A-MSDUs belonging to this TSPEC and their retransmissions to the bandwidth used for sending the MSDU or A-MSDU once at the minimum PHY rate. The Media Time field indicates the allowed time for accessing the media. The DMG Attribute field is given when TSPEC is applied to a Directed Multi-Gigabit (DMG) BSS.

[0070] Figure 2 illustrates the contents of the TS information fields as defined in IEEE 802.11. The Traffic Type field specifies whether the traffic is periodic. The TSID field indicates the ID number used to identify the TS. The Direction field specifies the direction of data transmission. The Access Policy field specifies the method used to obtain channel access. The Aggregation field specifies whether aggregation scheduling is required. The APSD field indicates whether automatic PS delivery is used. The User Priority field indicates the user priority belonging to the TS's MSDU or A-MSDU. The TS Information Ack (Acknowledgment) Policy field indicates whether an acknowledgment (Ack) is required and what form of Ack is used. The Scheduling field indicates the type of scheduling.

[0071] 2.2, TCLAS Unit

[0072] Figure 3 depicts the contents of a TCLAS cell as defined in IEEE 802.11. The cell ID field indicates the type of cell; in this example, it is a TCLAS cell. The length field indicates the length of the TCLAS cell. The user priority field indicates the user priority from the upper layer. The frame classifier field indicates the method used to classify frames from the upper layer.

[0073] 2.3 TCLAS Processing Unit

[0074] Figure 4 illustrates the contents of a TCLAS processing unit as defined in IEEE 802.11. The Unit ID field indicates the type of unit; in this example, it is a TCLAS processing unit. The Length field indicates the length of the TCLAS processing unit. The Processing field indicates the method used to classify traffic from the upper layer when multiple TCLAS units exist.

[0075] 2.4 Multi-user sending

[0076] Multi-user transmission is available in wireless networks such as IEEE 802.11. Since IEEE 802.11ax, networks have supported multi-user transmission in both uplink and downlink. Multi-user transmission in IEEE 802.11ax includes MIMO mode and OFDMA mode, which can be used separately or together.

[0077] IEEE 802.11ax uses multi-user transmit packet formats, such as those shown in Figures 5 and 6, to transmit data in multi-user mode. When multiple users send or receive multi-user transmit packets, all users share the same PLCP header of the multi-user transmit packets. Subsequently, each user uses separate resource blocks to send or receive the data carried by the multi-user transmit packets, including RU allocations, MCS, etc.

[0078] IEEE 802.11ax defines various PLCP protocol data unit (PPDU) formats for transmitting packets in different multi-user transmissions, which will be described below. It should be noted that PLCP is an abbreviation for Physical Layer Convergence Protocol.

[0079] Figure 5 illustrates the HE multi-user (MU) PPDU format used for downlink multi-user transmission in IEEE 802.11ax. The fields are depicted as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, Data, and PE.

[0080] Figure 6 depicts the HE-based trigger (TB) PPDU format used for uplink multi-user transmission in IEEE 802.11ax. Except for the HE-STF field being 8μs, the fields in the HE TB PPDU format are identical to those in the HE single-user PPDU format. The fields are depicted as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, HE-LTFs, Data, and PE.

[0081] Figure 7 depicts the contents of a Trigger Frame (TF). The Frame Control field indicates the frame type. The Duration field contains NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver for this frame. The TA field contains the address of the STA that sent the frame. The Common Information field contains information for all allocated STAs, shown below in Figure 8. The User Information field includes information for each STA, shown in Figure 9. The Common Information and User Information fields provide individual resource block allocation information for each user.

[0082] Figure 8 depicts the common information field of the trigger frame shown in Figure 7. The subfields of the common information field are depicted as trigger type, length, cascade indication, required CS, BW, GI and LTF types, MU MIMO LTF mode, number of HE-LTF symbols, STBC, LDPC extra symbol segment, AP TX power, packet spread, space reuse, Doppler, GI and LTF types, HE-SIG-A reservation, reservation and trigger-related common information.

[0083] Figure 9 depicts the user information field of the trigger frame shown in Figure 7, which has the following subfields: AID12 subfield, RU allocation, encoding type, MCS, DCM, SS allocation, target RSSI, and reserved and trigger-related user information.

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

[0085] Figure 10 depicts the trigger-related user information fields in the trigger frame used for MU-BAR, showing the BAR control and BAR information subfields.

[0086] Figure 11 depicts the contents of a block ACK (BA) frame with the following subfields: The frame control field indicates the frame type. The duration field contains NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver for this 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 information field contains feedback for transmission.

[0087] Figure 12 depicts the contents of a Buffer Status Request (BSR) frame with the following fields: The Frame Control field indicates the frame type. The Duration field contains NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver for this frame. The TA field contains the address of the STA that sent the frame. The HT Control field indicates a variant of the BSR control subfield. The Format Indicator field is used to indicate the format of the HT Control field. When B0 and B1 are set to the first state (e.g., "1"), it indicates that the HT Control field uses the HE format. This field follows 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 class for which the buffer status is reported. The Incremental TID field indicates the number of TIDs for which the buffer status is reported. The ACI High field indicates the access class reported in the Queue Size High field. The Scaling Factor field indicates the units for the Queue Size High and Queue Size fields. The Queue Size High field indicates the queue size of the AC as shown in the ACI High field, in units of scaling. The Queue Size All field indicates the queue size of the AC as shown in the ACI Bitmap Summary, also in units of scaling.

[0088] Figure 13 illustrates an example of downlink multi-user transmission using OFDMA. The transmitter (AP) sends data to its receivers 1, 2, 3, and 4 using the HE MU PPDU format. After the initial transmission, the AP sends a multi-user block ACK request (MU-BAR) to all receivers. The receivers then send block ACKs (BAs) back to the AP, respectively. Based on the contents of the BA, the AP decides to send packets to receivers 1, 3, and 4. The AP contends for the channel and waits for a given backoff time. The first retransmission is shown as occurring after the AP has gained channel access.

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

[0090] 2.5 EDCA System

[0091] Figure 15 shows a reference model of the EDCA queue (Enhanced DCF Channel Access) in IEEE 802.11. The system comprises six transmit queues and four access classes (ACs). Each AC uses the EDCA function (EDCAF) to contend for channel access, allowing packets to be transmitted in its corresponding transmit queue. The six transmit queues are depicted as Voice (VO), Alternate Voice (A_VO), Alternate Video (A_VI), Video (VI), Best Effort (BE), and Background (BK). Each transmit queue determines the transmission order of packets within it.

[0092] The four Access Centers (ACs) depicted are Voice (VO), Video (VI), Best Effort (BE), and Background (BK). Each AC has an EDCA (Electronic Contention Controller) function (EDCAF) to provide channel contention capabilities. An internal collision avoidance mechanism is used when multiple EDCAFs attempt to access the channel simultaneously. When an internal collision occurs, the EDCAF with the higher priority gains channel access.

[0093] Table 1 lists the UP-AC mapping used in the EDCA queue of IEEE 802.11. The second and third columns represent the user priority of the traffic and its corresponding name in IEEE 802.1D. In each row, traffic is queued in the appropriate transmit queue and access class according to user priority. Priority increases from top to bottom. Traffic with higher priority has a higher probability of being transmitted earlier.

[0094] Figure 16 illustrates the channel access procedure for EDCA. As shown in the figure, EDCA channel access is also compared to using only the Distributed Coordination Function (DCF).

[0095] When using DCF alone, the STA can immediately access the channel, and the medium is idle for more than the DCF inter-frame interval (DIFS) time. Otherwise, the STA uses CSMA / CA to contend for the channel. After sensing that the channel is idle for the DIFS time, the STA begins countdown backoff as long as the medium is idle. The number of backoff slots is randomly selected between zero and its contention window. When CCA busy occurs, for example when the STA senses that the channel is busy, the STA pauses countdown backoff. When the backoff countdown reaches zero, the STA can begin transmitting packets.

[0096] In EDCA, each EDCAF, as shown in Figure 15, can immediately access the channel when the medium is idle for more than the arbitrary inter-frame interval (AIFS) time required for the AC to gain channel access. It should be noted that AIFS[i] in the figure represents the AIFS time corresponding to AC i, where AC i represents a given AC. Otherwise, for each AC attempting to gain channel access, each EDCAF uses CSMA / CA to contend for channel access. After sensing that the channel is idle for the AIFS time, the STA begins countdown backoff as long as the medium is idle. The number of backoff slots is randomly selected between zero and its contention window size. When CCA busy occurs, for example when the STA senses the channel is busy, the STA pauses countdown backoff. When the backoff countdown reaches zero, the STA begins transmitting packets for that AC. It should be noted that multiple EDCAFs can contend for the channel in parallel. For example, as shown in Figure 16, EDCAFs for AC i and AC j (representing any two ACs) can contend for the channel simultaneously.

[0097] When internal conflicts occur, the higher-priority EDCAF gains channel access, while the lower-priority EDCAF doubles its contention window. When the AC is VO or VI, it can reserve contention-free periods (such as TXOP) for packet transmission. The maximum duration of TXOP is called the TXOP limit.

[0098] Table 2 lists the default parameter settings for EDCA channel access. Each AC has its own minimum contention window and maximum contention window. The AIFSN represents the AIFS duration by the number of backoff slots. TXOP represents the maximum duration for which each AC can retain TXOPs at any given time.

[0099] 2.6 TXOP Sharing in IEEE 802.11ax

[0100] A STA can share a TXOP to send RTA frames from a non-primary AC only when all frames from the primary AC have been sent or when the STA sends a MU PPDU. When frames from a low-priority non-primary AC are included in a MU DL MIMO PPDU (or VHT MU PPDU) and the TXVECTOR parameter NUM_USERS is greater than 1, these frames do not increase the PPDU duration beyond the duration required for sending frames from the primary AC and any frames from a high-priority AC. When frames from higher or lower priority non-primary ACs are included in a HE MU PPDU by the AP, these frames do not increase the HE MU PPDU duration beyond the duration required for sending frames from the primary AC and any frames from a high-priority AC. For a given user in a VHT / HE MU PPDU, any frames from the primary AC should be sent first, followed by any frames from the next higher-priority AC.

[0101] 3. Problem Statement

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

[0103] 4. Contributions of this invention

[0104] By utilizing this disclosure, a STA can share the TXOP of the primary AC to transmit RTA frames when frames from the primary AC are not being transmitted. In at least one preferred embodiment, the disclosed protocol incorporates "fairness" (equal use of the channel) between transmitting frames from the primary AC and transmitting RTA frames from non-primary ACs.

[0105] 5. Examples

[0106] 5.1 STA and MLD Hardware Configuration

[0107] Figure 17An exemplary embodiment 10 of STA hardware configured to execute the protocols of this disclosure is shown. An external I / O connection 14 is preferably coupled to an internal bus 16, and a CPU 18 and a memory (e.g., RAM) 20 are connected to the internal bus 16 for executing multiple programs implementing the communication protocol. The host machine houses at least one modem 22 to support communication coupled to at least one RF module 24, 28, respectively connected to one or more antennas 29, 26a, 26b, 26c to 26n. The RF module having multiple antennas (e.g., an antenna array) allows beamforming to be implemented during transmission and reception. In this way, the STA can transmit signals using a set of multiple beam patterns.

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

[0109] It should also be noted that multiple instances of the station hardware shown in the figure can be combined into a multi-link device (MLD), which will typically have a processor and memory for coordinating activities, and each STA within the MLD does not always require a separate CPU and memory.

[0110] Figure 18 An exemplary embodiment 40 of a multi-link device (MLD) hardware configuration is illustrated. Multiple STAs are attached to the MLD, each operating on a link at a different frequency. The MLD has external I / O 41 access for applications, which connects to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to allow execution of multiple programs implementing communication protocols at the MLD level. The MLD can assign tasks and collect information to / from each of its connected affiliate stations STA 1 42, STA 2 44 through STA N 46, and share information among the affiliate stations.

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

[0112] It should be recognized that each STA in an MLD does not necessarily need its own processor and memory, because depending on the specific MLD implementation, STAs can share resources with each other and / or with the MLD management entity. It should also be understood that the MLD diagrams given above are illustrative and not limiting, and this disclosure can be implemented in various MLD implementations.

[0113] 5.2 STA Topology for Consideration

[0114] To better explain the goals of the disclosed technology, a network scenario is used in the example.

[0115] Figure 19 An exemplary embodiment 70 of a topology (network scenario) is shown by way of example and not limitation. This topology is provided merely to illustrate the objectives of the proposed technology and not to limit it to a specific STA configuration. In this exemplary topology, it is assumed that there are 7 stations (STAs) in an area (e.g., a conference room), 6 of which are associated with 3 MLDs 72, 74, and 76. AP1 80 and AP2 82 are attached to Multi-Link Device (MLD) #1 72, STA1 84 and STA4 86 are attached to MLD #2 74, and STA3 88 and STA5 90 are attached to MLD #3 76. STA2 78 may be, for example, a non-AP STA operating on Link1 92 or a single-link MLD (i.e., a special MLD with only one STA and operating on one link). STA1, STA2, and STA3 are associated with AP1 via Link1 94a and 96a, and STA4 and STA5 are associated with AP2 via Link2 94b and 96b.

[0116] Each STA and its associated AP can communicate with each other. It should be noted that it is also possible to consider two BSSs as the same BSS, because the two APs of the two BSSs are attached to the same MLD. In this example, it is assumed that all STAs use EDCA for random channel access on all links.

[0117] 5.3 Distinguish between RTA traffic and non-RTA traffic

[0118] 5.3.1 Low Latency Streaming (LLTS) Operation

[0119] This section introduces a mechanism called Low-Latency Traffic Streaming (LLTS) to distinguish between Real-Time Transaction (RTA) and non-RTA traffic. Generally, LLTS can be used to differentiate traffic streams with specific QoS requirements (such as latency, jitter, and / or reliability) from other traffic.

[0120] RTAs often periodically generate traffic for connection-oriented communication between STAs, referred to as RTA sessions in this paper. An STA may have multiple RTA sessions in the network. STAs are able to appropriately manage these RTA sessions and apply appropriate transmission schemes to the RTA packets of the RTA sessions. By way of example, and not limitation, Low-Latency Traffic Streams (LLTS) can be used to identify RTA traffic from RTA sessions originating from upper-layer RTA sessions.

[0121] Figure 20 An exemplary embodiment 110 for terminating or modifying an LLTS is shown; it should also be recognized that the process can be used for other LLTS operations, including changing or removing an LLTS. The interoperability model of the STA can be the same as that defined in the IEEE 802.11 standard. It is also possible that the initiator can be an AP or a non-AP STA, and the receiver can also be an AP or a non-AP STA. For simplicity, during the LLTS setup procedure in this section, it is assumed that the initiator in this example is a non-AP STA and the receiver is an AP. SME 112 and MLME 114 for non-AP STAs, and MLME 116 and SME 118 for APs are shown in the figure.

[0122] A non-AP STA or MLD decides to initiate an LLTS setup procedure with the AP or AP MLD. The non-AP STA or MLD station management entity (SME) sends an MLME-LLTS.request message 120 to its MAC sub-layer management entity (MLME) (as shown in Table 3). When the non-AP STA's MLME 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 to its SME or the SME of its affiliated MLD (as shown in Table 4).

[0123] Subsequently, the AP's SME processes the AP MLD's LLTS request 126 and sends an MLME-LLTS.response message 130 containing the LLTS setting result to its MLME (as shown in Table 5). The AP's MLME then sends an LLTS response frame 132 to the non-AP STA. The non-AP STA's MLME receives this frame and sends an MLME-LLTS.confirm message 134 to its SME or the SME of its affiliated MLD (as shown in Table 6). The non-AP can then determine (identify or judge) whether the LLTS setting was successful from the information contained therein.

[0124] An AP or AP MLD can decide to modify or terminate 128 with a non-AP STA or MLD's LLTS. The AP's SME or the AP MLD's SME sends an MLME-LLTS-TERM.request message 136 to the AP's MLME or the MLME of its affiliated AP (as shown in Table 7). When the AP's MLME receives the MLME-LLTS-TERM.request message, it collects the information from the MLME-LLTS-TERM.request message and sends an LLTS response frame 138 to the non-AP STA. The non-AP STA's MLME receives this frame and generates an MLME-LLTS-TERM.indication message 140 to its SME (as shown in Table 8). Subsequently, the non-AP recognizes that the LLTS has been terminated or modified.

[0125] RTA traffic in an RTA session can be classified through LLTS settings. During the LLTS configuration procedure, TCLAS units and TCLAS processing units are exchanged. If the upper-layer information of the traffic is related to... Figure 23 If the information in the RTA-TSPEC unit shown matches, then the traffic from the upper layer is regarded as the RTA traffic of the RTA session.

[0126] In at least one embodiment, QoS requirements for traffic used in RTA sessions are shared between the AP and non-APSTAs by exchanging RTA-TSPEC units during the LLTS setup procedure. The LLTS setup can also be used to check whether the AP and non-APSTAs have sufficient resources to support RTA traffic transmission.

[0127] It should also be noted that LLTS request frames and LLTS response frames for the same LLTS setup procedure can be sent through different links.

[0128] Figure 21 An exemplary embodiment 150 of the LLTS request frame format used herein is shown. 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 receiver for this 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 additional control information for the frame. The action field indicates the action to be performed when it is an LLTS request frame and has subfields summarized below.

[0129] The category field and QoS action field indicate the type of action field; in this example, the action field indicates that this is an LLTS request frame. The session token field specifies the LLTS request transaction; and in at least one embodiment, it can be set to an integer used to identify the LLTS request frame. When the receiver receives this token field, it should respond to an LLTS response frame with the same session token. The action field indicates the LLTS request unit, has a subfield for unit ID indicating the unit type (in this example, an LLTS request unit); a length subfield indicating the length of the LLTS request unit; and an LLTS descriptor list providing a sequence of LLTS descriptor fields. Each LLTS descriptor field is set to indicate an LLTS setup request for traffic under specific specification and classification information. When this information is received, the receiver STA, which identifies the specification and classification information of the traffic, can decide to accept or reject the LLTS setup request.

[0130] Figure 22An exemplary embodiment 170 of the LLTS descriptor field format is illustrated. The LLID field provides an identifier for the low-latency transmission service; a non-AP STA sets a number within this field to represent the LLTS. The AP receives this number and can use it to identify the LLTS set by the non-AP STA. In at least one embodiment or mode, this field may be reserved by the non-AP STA, and only the AP sets this field. This field may be a Streaming Classified Service (SCS) ID as defined in IEEE 802.11. The LL length field contains the length of the LLTS descriptor field. The request type field is set to indicate the type of LLTS descriptor. When a non-AP STA or MLD sets the request type to "Add," the non-AP STA or MLD requests the addition of a new LLTS. The receiver AP or AP MLD should respond with whether or not the addition of the new LLTS is accepted.

[0131] When a non-AP STA or MLD sets the request type field to "Change", the non-AP STA or MLD requests to change an existing LLTS. When the AP or AP MLD receives this field, it can use the LLID to locate the LLTS. Subsequently, the AP or AP MLD either accepts the parameters for changing the LLTS or refuses to change the LLTS.

[0132] When a non-AP STA or MLD sets the request type to "Remove", the non-AP STA or MLD requests the removal of the existing LLTS. When the AP or AP MLD receives this field, it can use the LLID to locate and remove the LLTS.

[0133] The TCLAS field is identical to the TCLAS unit defined in IEEE 802.11. The STA or MLD sets this field to indicate information about traffic originating from the upper layer. When 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 arriving from the upper layer under this LLTS. An LLTS descriptor field can contain multiple TCLAS fields.

[0134] The TCLAS processing field is identical to the TCLAS processing unit defined in IEEE 802.11. When multiple TCLAS fields exist in the LLTS descriptor field, non-AP STAs set this field to indicate the rule of using multiple TCLAS fields to identify RTA traffic. When the AP receives this field in the LLTS descriptor field, it will recognize that multiple TCLAS fields can be used to identify traffic from the upper layer.

[0135] The RTA-TSPEC field is set by non-AP STAs to indicate the specifications and QoS requirements for RTA traffic under LLTS. When an 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 contains information about the traffic direction under this LLTS (e.g., uplink, downlink, peer-to-peer, or bidirectional). The AP can also indicate the channel resources that can be allocated for transmitting RTA traffic under this LLTS.

[0136] The Optional Sub-Unit field is set by the STA to indicate additional requests or information regarding traffic under this LLTS. When the AP receives this field, it can decide whether to accept or reject the LLTS, taking into account the information in the Optional Sub-Unit. Figure 24 and Figure 25 Some examples of optional subunits are given in the document.

[0137] Figure 23 An exemplary embodiment 190 of the RTA-TSPEC field content is shown. The TSPEC field can be exactly the same as the TSPEC element defined in IEEE 802.11. For RTA traffic under this RTA-TSPEC, the STA sets this field to indicate the TSID, traffic characteristics, and some QoS requirements of the RTA traffic under LLTS. Some exceptions are that the TSID field in the TS information field of the TSPEC element can be set to a value between 0 and 7, 0 and 15, or 8 and 15.

[0138] The RTA attribute field indicates additional QoS requirements for RTA traffic under this RTA-TSPEC. It is possible that this field will only appear with the TSPEC unit or within the TSPEC unit if LLTS is implemented on both the STA and AP.

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

[0140] The reliability field can be set to the packet error rate of the RTA traffic under this RTA-TSPEC. Subsequently, after accepting the LLTS of the RTA traffic, the AP should ensure that the packet error rate of the RTA traffic does not exceed the value set in this field. For example, if this field is set to 5%, the AP can have a maximum of 5 failed RTA frames out of 100. If the AP cannot guarantee this packet error rate level, it can reject the LLTS setting request.

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

[0142] The jitter field is set by the STA to indicate the jitter requirements for RTA traffic under this RTA-TSPEC. When the AP receives this field, it estimates the resource allocation for transmitting RTA traffic under this RTA-TSPEC to ensure that the jitter requirements for RTA traffic under this RTA-TSPEC can be met.

[0143] The jitter field can be combined with the delay boundary field in the original TSPEC unit to indicate the average latency requirement for RTA traffic under the RTA-TSPEC unit. For example, if the delay boundary field is set to 15ms and the jitter field is set to 5ms, then the average latency requirement for RTA traffic under the RTA-TSPEC unit is (delay boundary - jitter) = 15ms - 5ms = 10ms. In an alternative method, the average latency requirement for RTA traffic under the RTA-TSPEC unit is (delay boundary - jitter / 2) = 15ms - 5ms / 2 = 12.5ms. To meet the jitter requirement, the AP should ensure that the average latency of RTA traffic under the RTA-TSPEC is lower than the average latency requirement.

[0144] The MSDU lifetime field indicates the time an MSDU can be stored in the queue. When 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. When the STA receives this field and the Deterministic Service field is set to the first state (e.g., "1"), the MSDU or A-MSDU will be discarded if it is not successfully transmitted within its lifetime. When the Deterministic Service field is set to the second state (e.g., "0"), the field is retained. It should be noted that this field can be replaced by the Delay Boundary field in the TSPEC unit.

[0145] The Deterministic Service field is set by the STA to indicate whether the MSDU of RTA traffic under the RTA-TSPEC will be discarded when its lifetime expires. If the STA sets this field to a first state (e.g., "1"), the MSDU of RTA traffic under the RTA-TSPEC will be discarded when its lifetime expires. Otherwise, the STA sets this field to a second state (e.g., "0"). When the STA receives this field set to a first state (e.g., "1"), the MSDU of RTA traffic under the RTA-TSPEC will be discarded when its lifetime expires as indicated in the MSDU Lifetime field. When the STA receives this field set to "0", the MSDU Lifetime field is retained.

[0146] Figure 24 An exemplary embodiment 210 is shown, which carries an optional sub-unit carrying a higher-layer flow ID. The sub-unit ID field contains the type of the sub-unit, which in this example indicates an optional sub-unit under an LLTS request unit. The length field indicates the length of the optional sub-unit field. The higher-layer flow ID field indicates the higher-layer flow ID from a higher layer. The STA sets this field in the frame so that the receiver of this field can map the current LLTS to a higher-layer traffic flow.

[0147] Figure 25 An exemplary embodiment 230 of an optional subunit carrying an LLTS / TID to link mapping is shown. The subunit ID field indicates the type of subunit, in this example indicating an optional subunit under an LLTS request unit. The length field indicates the length of the optional subunit field. The LLTS hierarchical 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 1-bit indication. When this field is set to a first state (e.g., "1"), the LLTS / TID to link mapping field is used to use an LLTS to link mapping, where the LLTS in the mapping is the LLTS indicated in the LLTS descriptor field. When this field is set to a second state (e.g., "0"), the LLTS / TID to link mapping field will use a TID to link mapping, where the TID is the TID of the LLTS indicated in the LLTS descriptor field.

[0148] The LLTS / TID to Link Mapping field indicates the LLTS / TID to link mapping. The STA sets this field to indicate the link on which LLTS-based traffic can be sent. This field contains the following subfields.

[0149] The LLID field contains an identifier for the Low Latency Transmission Service (LLTS). Non-AP STAs set a number representing the LLTS. AP reception can use this number to identify the LLTS set by a non-AP STA. This field can identify a Flow Classification Service (SCS) as defined in IEEE 802.11. The Link Quantity field is set to indicate the number of Link ID fields in the LLTS / TID to Link Map field. The Link ID field is set to indicate the links on which traffic under the LLTS can be transmitted. One or more Link ID fields can be used; this example illustrates multiple (1-n) Link ID fields. When sending the LLTS / TID to Link Map in an LLTS request frame, the STA can set this field to suggest links to use for transmitting traffic under that LLTS.

[0150] Figure 26 An exemplary embodiment 250 of an LLTS response frame is shown. 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 receiver for this 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 additional control information for the frame. The action field indicates the action to be performed when it is an LLTS response frame. The action field contains the following subfields.

[0151] The Category subfield and QoS Action subfield indicate the type of action field, which in this case is in the LLTS response frame. The Session Token subfield specifies the LLTS response transaction and, in at least one embodiment, can be set to an integer used to identify the LLTS response frame. If the LLTS response frame is a response to an LLTS request frame, this field should be set to the same value as in the LLTS request frame. When the receiver receives this field, it recognizes that the LLTS response frame is a response to an LLTS request frame with the same session token.

[0152] The Action field also includes LLTS Response Units. The format of an LLTS Response Unit is as follows: The Unit ID field indicates the type of unit; in this example, it indicates an LLTS Response Unit. The Length field indicates the length of the LLTS Response Unit. The LLTS Status List field contains a sequence of LLTS Status Fields. Each LLTS Status Field is set to indicate an LLTS setting response for traffic under a specific specification and classification information. Receiving this information allows the STA receiver to determine the result of an LLTS setting for RTA traffic or a change to an existing LLTS.

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

[0154] The TCLAS field can be identical to the TCLAS unit defined in IEEE 802.11. The AP sets this field to indicate information about traffic from the upper layer. When the traffic is uplink, non-AP STAs can use this information to identify the traffic arriving from the upper layer under this TTLS when they receive this field. The LLTS status field can contain multiple TCLAS fields.

[0155] The TCLAS processing field can be identical to the TCLAS processing unit defined in IEEE 802.11. When multiple TCLAS fields exist in the LLTS status field, the AP sets this field to indicate the rule for using multiple TCLAS fields to identify RTA traffic. When a non-AP STA receives this field in the LLTS status field, it can determine how to use multiple TCLAS fields to identify traffic from the upper layer.

[0156] The RTA-TSPEC field can be used with Figure 23The RTA-TSPEC unit defined in the documentation is identical. The AP sets this field to indicate the specifications and QoS requirements for RTA traffic. When a non-AP STA receives this field, it identifies that an LLTS decision has been made for traffic under RTA-TSPEC. This field also contains information about the direction of the RTA traffic under this LLTS (e.g., uplink, downlink, peer-to-peer, or bidirectional). The AP can also indicate the channel resources that can be allocated for the transmission of RTA traffic under this LLTS.

[0157] The optional sub-cell field is set by the AP to indicate additional information or settings related to the traffic under this LLTS. Figure 24 and Figure 25 Some examples of optional subunits are given in the document.

[0158] 5.3.2 Distinguishing RTA traffic

[0159] Figure 28 An exemplary embodiment 310 distinguishing between RTA and non-RTA traffic is shown. When the MAC layer of the STA or MLD receives traffic 312 from an upper layer, it checks 314 to determine whether the traffic from the upper layer belongs to an existing LLTS. If the traffic comes from an upper layer belonging to an existing LLTS, the traffic is registered as an RTA traffic belonging to that LLTS at block 316. Otherwise, if the traffic from the upper layer does not belong to an existing LLTS, the traffic is registered as a non-RTA traffic at block 318.

[0160] 5.3.3, Examples of LLTS

[0161] Table 9 provides examples of LLTSs (e.g., LLTS1 to LLTS6). In this table, the Initiator column indicates the STA or MLD that initiates the LLTS setup procedure (i.e., sends an LLTS request frame). The Receiver column indicates the STA or MLD that receives the LLTS request frame and sends an LLTS response frame. For example, the second row in the table represents an LLTS with an LLID equal to 1, such as LLTS1. The initiator of this LLTS is STA2, and the receiver can be AP1 or MLD1. The Direction column indicates the direction of the LLTS. If the direction is downlink, the RTA traffic under this LLTS will be sent from AP1 (or MLD1) to STA2; otherwise, if the direction is uplink, it will be in the opposite direction, exemplified as this LLTS having a TID of 8 and a User Priority (UP) of 6. The Link list indicates which link (e.g., Link 1 and / or Link 2) will be used to send the traffic under this LLTS.

[0162] The STA can identify an LLTS through a tuple of LLTS information, such as <LLID, initiator>, <LLID, receiver>, or <LLID, initiator, receiver>. It is also possible that the AP or AP MLD uses a unique LLID for each LLTS in its BSS, enabling each STA to identify the LLTS in the BSS solely by the LLID or to use the tuple <LLID, BSSID> to identify the LLTS in both the BSS and OBSS.

[0163] 5.4 TXOP Sharing for Sending RTA Packets

[0164] 5.4.1 Flowchart

[0165] This section explains the procedure for TXOP sharing for sending RTA frames from a non-primary AC. Compared with the current TXOP sharing rules in IEEE 802.11ax, the disclosed technology allows the STA to share its TXOP of the primary AC to send RTA frames from a non-primary AC even if there are frames from the primary AC not sent.

[0166] Figure 29 An exemplary embodiment 330 of TXOP sharing for sending RTA traffic from a non-primary AC is shown. When RTA traffic arrives at the EDCA queue, it is encapsulated in the form of frames. The frame carrying RTA traffic is called an RTA frame, and the frame carrying non-RTA traffic is called a non-RTA frame. One or more frames can be included in a packet and sent through a link or channel. The AC associated with the EDCAF that obtains the TXOP is called the primary AC.

[0167] When the STA obtains the TXOP of the 332 primary AC, a decision 334 is made on whether to share the TXOP to send frames from a non-primary AC during the TXOP.

[0168] If the STA decides not to share the TXOP to send non-RTA frames from a non-primary AC, before sending the frame 340, the current TXOP sharing rules defined in IEEE 802.11ax can be followed at block 338.

[0169] Otherwise, if the STA decides to share its TXOP to send RTA frames from a non-primary AC, even if there are frames from the primary AC not sent, RTA frames from the non-primary AC can still be sent 336. Subsequently, at block 340, the STA sends frames from the non-primary AC(s) during the TXOP.

[0170] If a station decides to share its TXOP to send RTA frames from a non-primary AC, the following should be noted: The non-primary AC in box 336 may simply refer to those ACs with a higher priority than the primary AC. In this case, RTA frames from a non-primary AC may simply refer to those frames that are about to expire (e.g., the frame will expire before the TXOP ends).

[0171] During TXOP, the following sequences are possible.

[0172] (1) The STA shall / may first transmit all / some RTA frames from the non-primary AC, followed by frames from the primary AC. The STA may, for example, follow any of the following rules: (a) It shall / may first transmit RTA frames from the non-primary AC that has a higher priority than the primary AC, followed immediately by frames from the primary AC. (b) It shall / may first transmit RTA frames from the primary AC, followed by RTA frames from the non-primary AC that has a higher priority than the primary AC, and then non-RTA frames from the primary AC. (c) It shall / may first transmit (multiple) RTA frames from the non-primary AC that are (multiple) retransmissions and have a higher priority than the primary AC, followed immediately by frames from the primary AC.

[0173] (2) A STA may send RTA frames from a non-primary AC with a lower priority than the primary AC only if: (a) these RTA frames are about to expire (e.g., the frame will expire before the end of the TXOP); and / or (b) all frames from the primary AC have been sent; and / or (c) the low-priority AC previously shared its TXOP with the primary AC. For example, in cases (2)(c), the low-priority AC shares its TXOP with the primary AC during the current cycle time (e.g., the beacon interval). It is possible that the TXOP sharing time with this low-priority AC should not be longer than the TXOP time that the low-priority AC shared with the primary AC during the current cycle time.

[0174] (3) The STA treats RTA frames from a non-primary AC that has a higher priority than the primary AC as if they came from the primary AC. Alternatively, the STA may treat RTA frames from a non-primary AC that has a higher priority than the primary AC as if they came from the primary AC.

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

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

[0177] (b) For a given user (i.e., the receiver STA of the MU PPDU), RTA frames from non-primary ACs that have a higher priority than the primary AC should be transmitted earlier than frames from the primary AC. For example, (i) any RTA frame from the primary AC should be transmitted first, followed by any RTA frame from a higher priority AC, and then any non-RTA frame from the primary AC. (ii) any RTA frame from a higher priority AC should be transmitted first, followed immediately by any frame from the primary AC. (iii) any frame from the primary AC should be transmitted first, followed immediately by any frame from a higher priority AC. (iv) any frame with a shorter expiration time (e.g., the expiration time of the MSDU lifetime) should be transmitted first.

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

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

[0180] 5.4.2, Example

[0181] This section provides several examples to illustrate how STAs can share the TXOP of the primary AC to send RTA frames from a non-primary AC. The network topologies used in these examples are... Figure 19 The traffic classification process between RTA and non-RTA can be the same as or similar to the LLTS operation described in Section 5.3 or any other traffic classification procedure. For example, it is assumed here that each STA or MLD in the network topology has an RTA traffic flow as shown in Table 9. It is possible that traffic under LLTS is queued in the EDCA queue according to the UP-AC mapping shown in Table 1. It should be noted that the UP of traffic under LLTS is indicated in the LLTS settings, such as the UP shown in Table 9.

[0182] Figure 30 An exemplary embodiment 350 shows the state of the EDCA queue for AP1 or MLD1. Frames (MSDU, UP, RTA) are shown as being mapped 352 and placed into the queue.

[0183] AC_VO queue 354 represents the EDCA queue of AC VO, which is here exemplified by three RTA frames under LLTS1, exemplified as AC_VO(1) to AC_VO(3).

[0184] AC_VI queue 356 represents the EDCA queue of AC VI, which is shown as having two RTA frames under LLTS2, which are exemplified as AC_VI(1) and AC_VI(2), and a non-RTA frame, which is exemplified as AC_VI(3).

[0185] AC_BE queue 358 represents the EDCA queue of AC BE, which is shown as having three non-RTA frames, exemplified as AC_BE(1) to AC_BE(3).

[0186] AC_BK queue 360 ​​represents the EDCA queue of AC BK, which is instantiated as empty, meaning there are no frames in the queue.

[0187] The queues are shown as EDCAF 362, 364, 366 and 368 connected to contention channel 370.

[0188] Figure 31 An exemplary embodiment 390 is shown where AP1 transmits RTA frames from a non-primary AC only during TXOP. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400. Figure 30 The status of the EDCA queue for AP1 or MLD1 is shown in the image.

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

[0190] When AP1 receives TXOP 400 of VI, it sends RTA frames from the AC_VO queue to STA2, exemplified as AC_VO(1)404, AC_VO(2)410, and AC_VO(3)416, with corresponding preambles 402, 408, and 414. As shown in this example, AP1 sends RTA frames from the AC_VO queue only during TXOP. STA2 generates block acknowledgments 406, 412, and 418 upon receiving each of these transmissions.

[0191] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0192] Figure 32 An exemplary embodiment 430 of another EDCA queue state of AP1 or MLD1 is shown. Frames are mapped 432 into the queues shown in the figure. As shown, AC_VO queue 434 represents the EDCA queue of AC VO, which has 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 the EDCA queue of AC VI, which has 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 the EDCA queue of AC BE, which has 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 the EDCA queue of AC BK, which has no frames in the queue. Below each queue are shown the corresponding EDCA functions 442, 444, 446, and 448 used to obtain and transmit on channel 450.

[0193] Figure 33 Exemplary embodiment 470 is shown where AP1 transmits RTA frames from a higher-priority non-primary AC before frames from the primary AC during TXOP. The figure depicts the interactions 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 As shown in the example, this case assumes that this is the queue state when AP1 starts TXOP 400, and also assumes that no new frames arrive during the TXOP. If this queue state is the queue state of MLD1, it is also assumed that MLD1 does not transmit on any other link during the TXOP shown in this example.

[0194] When AP1 receives TXOP 400 of VI, it first sends an RTA frame, identified as AC_VO(1)474, from the AC_VO queue to STA2. Then, AP1 sends an RTA frame, identified as AC_VI(1)480, from the AC_VI queue to STA1, followed by a non-RTA frame, identified as AC_VI(2)486, from the AC_VI queue to STA3. Each of these transmissions is shown with corresponding preambles 472, 478, and 484. The receiving station is shown responding using block acknowledgments (BAs) 476, 482, and 488.

[0195] It should be noted that, in some cases, AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0196] Figure 34 Exemplary embodiment 510 is illustrated, wherein AP1 first transmits an RTA frame from the primary AC during TXOP, followed by an RTA frame from the non-primary AC, and then a non-RTA frame from the primary AC. The EDCA queue state of AP1 or MLD1 is... Figure 32 The diagram illustrates this; it is assumed that the queue state is the same as when AP1 begins TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If the queue state is the queue state of MLD1, it is further assumed that MLD1 does not transmit on any other link during the illustrated TXOP.

[0197] When AP1 receives TXOP 400 of VI, it first sends an RTA frame, instanced AC_VI(1)514, to STA1 from the AC_VI queue. Then, AP1 sends an RTA frame, instanced AC_VO(1)520, to STA2 from the AC_VO queue. Next, AP1 sends a non-RTA frame, instanced AC_VI(2)526, to STA3 from the AC_VI queue.

[0198] Each of these transmissions is shown with corresponding preambles 512, 518, and 524. The receiving station is shown responding using block acknowledgments (BAs) 516, 522, and 528.

[0199] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0200] Figure 35 An exemplary embodiment 530 is shown where AP1 transmits RTA frames from a non-primary AC with a lower priority than the primary AC. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400. The EDCA queue status of AP1 or MLD1 is shown in... Figure 32 The following is an example; it is assumed here that the queue state is the same as when AP1 starts TXOP400, and it is also assumed that no new frames arrive during the TXOP. If the queue state is the queue state of MLD1, it is further assumed that MLD1 does not transmit on any other link during the TXOP shown in this example.

[0201] When AP1 acquires the TXOP of VI, it first sends an RTA frame, instantiated as AC_VI(1)534, from the AC_VI queue to STA1. Then, AP1 sends an RTA frame, instantiated as AC_VO(1)540, from the AC_VO queue to STA2. Next, AP1 sends an RTA frame, instantiated as AC_BE(1)546, from the AC_BE queue to STA3 because this RTA frame will soon expire (550) and will occur before the end of the TXOP.

[0202] Each of these transmissions is shown with corresponding preambles 532, 538, and 544. The receiving station is shown responding using block acknowledgments (BAs) 536, 542, and 548.

[0203] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0204] Figure 36 Exemplary embodiment 570 is shown, depicting a third example of the EDCA queue state for AP1 or MLD1. Frames are mapped 572 into the queues shown in the figure. The AC_VO queue 574 is shown with one RTA frame AC_VO (1) and one non-RTA frame AC_VO (2) under LLTS1. The AC_VI queue 576 is shown with two RTA frames and one non-RTA frame AC_VI (3) under LLTS2. The AC_BE queue 578 is shown with three non-RTA frames. The AC_BK queue 580 is shown with no frames in the queue.

[0205] Below each queue are shown the corresponding EDCA functions 582, 584, 586, and 588 configured to acquire and transmit on channel 590.

[0206] Figure 37 An exemplary embodiment 610 is shown in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, wherein the duration of the MU PPDU is determined by the transmission request of the RTA frame from the non-primary AC. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP400.

[0207] The EDCA queue status of AP1 or MLD1 is in Figure 36The diagram illustrates this; it assumes that this is the same queue state when AP1 begins TXOP 400, and also assumes that no new frames arrive during the illustrated TXOP. If this queue state is the queue state of MLD1, it is further assumed that MLD1 does not transmit on any other link during the TXOP illustrated in this example.

[0208] When AP1 acquires TXOP 400 of VI, it sends 614 MU OFDMA PPDUs carrying RTA frames instantiated as AC_VI(1) from AC_VI to STA1 queue, RTA frames instantiated as AC_VO(1) from AC_VO to STA2, and non-RTA frames instantiated as AC_VI(3) from AC_VO queue to STA3. It should be noted that the duration of the MU OFDMA PPDU is determined by the duration of frame AC_VO(1) rather than the durations of frames AC_VI(1) and AC_VI(3).

[0209] AP1 then sends 620 carrying another MU OFDM PPDU, which carries an RTA frame represented as AC_VI(2) from the AC_VI queue and a non-RTA frame represented as AC_VO(2) and AC_BE(2), and may follow the TXOP sharing rules of IEEE 802.11.

[0210] It should be noted that in this example and subsequent examples, the short frame is shown as being filled.

[0211] The MU OFDMA PPDU shown in this example can be replaced by a MU MIMO PPDU. Subsequently, each frame in the MU PPDU will be transmitted via a different spatial stream instead of a different RU. The feedback for the sought MU PPDU (e.g., ACK or BA) will also be changed to the feedback for the MU MIMO PPDU shown in the figure.

[0212] Transmissions 614 and 620 are shown with corresponding preambles 612 and 618. Each receiving station is shown responding to the reception of these transmissions with a block acknowledgment (BA) 616.

[0213] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0214] Figure 38An exemplary embodiment 630 is shown in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, wherein the duration of the MU PPDU is determined by the latency requirement of the RTA frame from the primary AC. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0215] The EDCA queue status of AP1 or MLD1 is in Figure 36 The following is an illustration; it is assumed here that the queue state is the same as when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP in this example. If the queue state is the queue state of MLD1, it is further assumed that MLD1 does not transmit on any other link during the illustrated TXOP.

[0216] When AP1 acquires TXOP 400 of VI, it transmits 636 MU OFDMA PPDUs carrying RTA frames exemplified as AC_VI(1) from AC_VI queue to STA1, RTA frames exemplified as AC_VO(1) from AC_VO queue to STA2, and non-RTA frames exemplified as AC_VI(3) from AC_VO queue to STA3. It should be noted that the duration of the MU OFDMA PPDU is determined by the duration of frame AC_VO(1) shown as expiring 638, and the duration of the MU OFDMA PPDU cannot exceed the maximum duration (expiration time) 632 of frame AC_VI(1).

[0217] Then we see AP1 sending 644 RTA frames, represented as AC_VI(2) from the AC_VI queue, and another MU OFDM PPDU, represented as AC_VO(2) and AC_BE(2), which can follow the TXOP sharing rules of IEEE 802.11.

[0218] The MU OFDMA PPDU shown in this example can be replaced by a MU MIMO PPDU; where each frame in the MU PPDU will subsequently be transmitted via a different spatial stream instead of a different RU. The feedback for the sought MU PPDU (such as ACK or BA) will also be changed to the feedback used for the MU MIMO PPDU.

[0219] Transmissions 636 and 644 are shown with corresponding preambles 634 and 642. Each receiving station is shown responding to these transmissions with a block acknowledgment (BA) 640.

[0220] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0221] Figure 39 Another exemplary embodiment 650 is shown, in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, wherein the maximum duration of the MU PPDU 632 is determined by the latency requirement of the RTA frame from the primary AC. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0222] Figure 36 The EDCA queue state of AP1 or MLD1 shown here is assumed to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If this queue state is for MLD1, it is also assumed that MLD1 does not transmit on any other link during the TXOP shown in this example.

[0223] When AP1 receives TXOP 400 of VI, it sends 636 MU OFDMA PPDUs carrying RTA frames exemplified as AC_VI(1) from AC_VI queue to STA1, RTA frames exemplified as AC_VO(1) from AC_VO queue to STA2, and non-RTA frames exemplified as AC_VI(3) from AC_VO queue to STA3. It should be noted that the duration of MU OFDMA PPDU 632 is determined by the duration of frame AC_VO(1), but the duration of MU OFDMA PPDU and expected feedback (e.g., BA) cannot exceed the expiration time 652 of frame AC_VI(1) shown as expiring soon 652.

[0224] AP1 sends 644 RTA frames, represented as AC_VI(2) from the AC_VI queue to STA1, and another MU OFDM PPDU, represented as AC_VO(2) and AC_BE(2), which may follow the TXOP sharing rules of IEEE 802.11.

[0225] The MU OFDMA PPDU shown in this example can be replaced by a MU MIMO PPDU; in this case, each frame in the MU PPDU will be transmitted via a different spatial stream instead of a different RU. In this case, the feedback (e.g., ACK or BA) of the sought MU PPDU will also be changed to the feedback used for the MU MIMO PPDU.

[0226] Transmissions 636 and 644 are shown with corresponding preambles 634 and 642. Each receiving station is shown responding to these transmissions with a block acknowledgment (BA) 640.

[0227] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0228] Figure 40 An exemplary embodiment 670 is shown in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, wherein the duration of the MU PPDU is determined by the transmission request of the RTA frame from the primary AC. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0229] Figure 36 The EDCA queue state of AP1 or MLD1 shown in this example is assumed to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If this queue state is for MLD1, it is also assumed that MLD1 does not transmit on any other link during the TXOP.

[0230] When AP1 receives TXOP 400 of VI, it sends 672 MU OFDMA PPDUs carrying the RTA frame AC_VI(1) from the AC_VI queue, which is specified as going to STA1, the non-RTA frame AC_VO(2) from the AC_VO queue, which is specified as going to STA2, and the non-RTA frame AC_VI(3) from the AC_VO queue, which is specified as going to STA3. Frame AC_VO(1) is not included in the first MU OFDMA PPDU because its duration is longer than that of frame AC_VI(1).

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

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

[0233] Transmissions 672 and 674 are shown with corresponding preambles 634 and 642. Each receiving station is shown responding to these transmissions with a block acknowledgment (BA) 640.

[0234] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0235] Figure 41 An exemplary embodiment 710 is shown where AP1 restricts the time of TXOP sharing. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0236] Figure 36 The EDCA queue state of AP1 or MLD1 shown is assumed to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If this queue state is for MLD1, it is also assumed that MLD1 does not transmit on any other link during the TXOP.

[0237] When AP1 acquires TXOP 400 of VI, it first sends an RTA frame 712, represented as AC_VI(1) from the AC_VI queue to STA1. Subsequently, AP1 sends an RTA frame 716, represented as AC_VO(1) from the AC_VO queue to STA2. After AP1 finishes sending frame AC_VO, it has utilized the maximum TXOP sharing time 714 during the current TXOP.

[0238] Next, AP1 sends frame 718, which is exemplified as AC_VI(2) from the AC_VI queue to STA1.

[0239] Transmissions 712, 714, and 718 are shown with corresponding preambles 632. Each receiving station is shown responding to the reception of these transmissions with a block acknowledgment (BA) 640.

[0240] Figure 42 An exemplary embodiment 750 is shown where AP1 shares a TXOP after sending a specific number of frames from the primary AC. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0241] Figure 36The EDCA queue state of AP1 or MLD1 shown is assumed to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If this queue state is for MLD1, it is also assumed that MLD1 does not transmit on any other link during the TXOP.

[0242] As shown in the figure, since the TXOP begins, AP1 must send a specific number of frames from the primary AC VI before sharing its TXOP for transmission. This specific number is indicated by the dedicated_byte (752 bytes). After the total number of bytes of frames from the primary AC exceeds the dedicated_byte, AP1 is still allowed to share the TXOP with RTA frames from non-primary ACs, even if some frames from the primary AC have not been sent.

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

[0244] AP1 can send payloads such as Figure 44 The information frames shown are used to set the dedicated time for each STA.

[0245] Transmitters 754, 756, and 758 are shown with corresponding preambles 632; each receiving station is shown responding to the reception of these transmits with a block acknowledgment (BA) 640.

[0246] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0247] It is possible that AP1 can share TXOP according to the rules defined in IEEE 802.11 before reaching the dedicated_byte of the main frame.

[0248] Figure 43 An exemplary embodiment 790 is shown where AP1 shares a TXOP after sending frames from the primary AC for a specific amount of time. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0249] Figure 36The EDCA queue state of AP1 or MLD1 shown is assumed to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If this queue state is for MLD1, it is also assumed that MLD1 does not transmit on any other link during the TXOP.

[0250] As shown in the figure, after the TXOP begins, there is a dedicated time 792 for the primary AC VI. After the dedicated time ends, AP1 is still allowed to share the TXOP to send RTA frames from non-primary ACs, even if frames from the primary AC have not been sent at this time.

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

[0252] It should be noted that AP1 can send payloads such as Figure 44 The information frames shown are used to set the dedicated time for each STA.

[0253] Transmissions 794, 796, and 798 are shown with corresponding preambles 632. Each receiving station is shown responding to these transmissions with a block acknowledgment (BA) 640.

[0254] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0255] It is possible that AP1 will share TXOP in accordance with the rules defined in IEEE 802.11 before the dedicated_time expires.

[0256] Figure 44 An exemplary embodiment 830 for carrying a frame containing a dedicated time parameter setting is shown. A STA (such as an AP) can send a frame containing the time parameter setting to another STA (such as an associated STA) to set the number of dedicated times assigned to that STA. In some cases, an AP can broadcast such a frame to set the dedicated times for all its associated STAs.

[0257] In at least one embodiment, the dedicated timing parameter includes the following fields: A frame control field indicates the type of frame. A duration field contains NAV information used for CSMA / CA channel access. An address 1 field contains the address of the receiver for this frame. An address 2 field contains the address of the STA that sent the frame. An address 3 field contains the BSSID. A sequence control field indicates the sequence number of this frame. An HT control field indicates additional control information for the frame.

[0258] The Dedicated Time Setting field is set by the STA to the amount of dedicated time for each AC used by the receiver STA. The receiver STA can use the parameters in this field for TXOP sharing. The Unit ID field identifies the type of unit; in this example, it is a dedicated time setting unit. The Length field indicates the length of the dedicated time setting unit.

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

[0260] The Enable Dedicated Time field is set to indicate whether there is dedicated time during each TXOP. If this field is set to the first state (e.g., true), there is dedicated time during each TXOP, for example, marked from the beginning of that TXOP. During the dedicated time, only traffic from the primary AC can be sent.

[0261] The dedicated time field is set by the transmitting STA for each AC. Starting from the start time of the AC's TXOP, the STA that receives this dedicated time information spends the dedicated time transmitting frames from that AC. Only after this can the receiving STA decide to share the TXOP.

[0262] It should be noted that it is possible to replace "dedicated time" with "dedicated bytes" in the frame to set, for example... Figure 42 The special byte parameters described in [the document].

[0263] Figure 45An exemplary embodiment 850 showing a fourth example of EDCA queue states providing AP1 or MLD1 is illustrated. Frames are mapped 852 into the queues shown in the figure. The AC_VO queue 854 is depicted as carrying two RTA frames, AC_VO(1) under LLTS1 and AC_VO(2) under LLTS6. The AC_VI queue 856 is depicted as holding one RTA frame under LLTS2, AC_VI(1), and one non-RTA frame, AC_VI(2). The AC_BE queue 858 represents the EDCA queue for AC BE, which is depicted as holding three non-RTA frames, AC_BE(1) to AC_BE(3). The AC_BK queue 860 is depicted as having no frames in its queue.

[0264] Below each queue are shown the corresponding EDCA functions 862, 864, 866, and 868 used to obtain and transmit on channel 870.

[0265] Figure 46 An exemplary embodiment 890 of AP1 transmitting a MU OFDMA PPDU is shown, wherein for each user, an RTA frame from a non-primary AC is transmitted earlier than a frame from the primary AC. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0266] Figure 45 The EDCA queue state of AP1 or MLD1 shown is assumed to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If this queue state is for MLD1, it is also assumed that MLD1 does not transmit on any other link during the shown TXOP.

[0267] When AP1 obtains TXOP 400 of VI, it sends 892 MUOFDMA PPDUs carrying RTA frames, represented as AC_VO(1) and AC_VO(2) from the AC_VO queue to STA1 and STA2, and non-RTA frames, represented as AC_BE(2) from the AC_BE queue to STA3.

[0268] Subsequently, AP1 sends another MU OFDM PPDU carrying RTA frames AC_VI(1) and AC_VI(2) destined for STA1, STA2, and STA3, and a non-RTA frame AC_BE(3). For STA1 and STA2, AP1 first sends an RTA frame from the higher-priority non-primary AC, which is exemplified as ACVO.

[0269] The MU OFDMA PPDU shown in this example can be replaced by a MU MIMO PPDU; in this case, each frame in the MU PPDU is transmitted via a different spatial stream instead of a different RU. The sought feedback will also be changed from the ACK or BA of the MU PPDU to a feedback suitable for the MU MIMO PPDU in the figure.

[0270] Transmissions 892 and 894 are shown with corresponding preambles 632. Each receiving station is shown responding to these transmissions with a block acknowledgment (BA) 640.

[0271] It should be noted that AP1 may use RTS / CTS or MU-RTS / CTS to reserve TXOPs before sending frames.

[0272] Figure 47 An exemplary embodiment 930 of TXOP sharing is illustrated when the AP sends an RTA frame from a non-primary AC later than the RTA frame from the primary AC but earlier than the non-RTA frame from the primary AC for each user in the MU PPDU. The figure depicts the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0273] AP1 is shown as sending 932MU OFDMA PPDUs, where for each user, AP1 first sends an RTA frame from the primary AC, followed by an RTA frame from a higher priority AC, and then a non-RTA frame from the primary AC.

[0274] Figure 45 The EDCA queue state of AP1 or MLD1 shown is assumed to be the queue state when AP1 starts TXOP 400, and it is also assumed that no new frames arrive during the TXOP. If this queue state is for MLD1, it is also assumed that MLD1 does not transmit on any other link during the illustrated TXOP.

[0275] When AP1 acquires TXOP 400 of VI, it sends 932 MU OFDMA PPDUs carrying RTA frames instantiated as AC_VI(1) and AC_VO(1) and non-RTA frames instantiated as AC_BE(2) from the AC_BE queue.

[0276] AP1 then sends another MUOFDM PPDU carrying RTA frames AC_VO(2) and AC_VI(2) and a non-RTA frame AC_BE(3). For user STA1, AP1 first sends the RTA frame from the primary AC, which is instanced as AC VI, followed by the RTA frame from the higher-priority non-primary AC, which is instanced as AC_VO. For user STA2, AP1 first sends the RTA frame from the higher-priority non-primary AC (e.g., AC_VO), followed by the non-RTA frame from the primary AC (e.g., AC_VI).

[0277] The MU OFDMA PPDU shown in this example can be replaced by a MU MIMO PPDU; in this case, each frame in the MU PPDU is transmitted via a different spatial stream instead of a different RU. The feedback sought for the MU PPDU (such as ACK or BA) will also be changed to the appropriate type of feedback used for the MU MIMO PPDU.

[0278] Transmissions 932 and 934 are shown with corresponding preamble 632. Each receiving station is shown responding to these transmissions with a block acknowledgment (BA) 640.

[0279] It should be noted that an AP (e.g., AP1) may reserve TXOPs using RTS / CTS or MU-RTS / CTS before sending frames.

[0280] 6. General Scope of the Embodiments

[0281] Embodiments of the present invention may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the present invention and / or may also be depicted as procedures, algorithms, steps, operations, formulas or other computational descriptions implemented as computer program products. In this regard, each block or step of the flowchart and combinations of blocks (and / or steps) in the flowchart, as well as any procedure, algorithm, step, operation, formula or computational description, may be implemented by various means, such as hardware, firmware and / or software including one or more computer program instructions specifically implemented in computer-readable program code. It should be understood that any such computer program instructions may be executed by one or more computer processors, including, but not limited to, general-purpose or special-purpose computers, or other programmable processing means for producing a machine, such that the computer program instructions executed on the computer processor(s) or other programmable processing means produce means for performing the specified functions(s).

[0282] Therefore, the flowchart blocks and the procedures, algorithms, steps, operations, formulas, or computational depictions described herein support combinations of means for implementing the specified functions(s), combinations of steps for implementing the specified functions(s), and computer program instructions, such as those specifically implemented in computer-readable program code logic devices, for implementing the specified functions(s). It should also be understood that each block in the flowchart and any procedure, algorithm, step, operation, formula, or computational depiction and combination thereof described herein can be implemented by a dedicated hardware-based computer system or a combination of dedicated hardware and computer-readable program code that implements the specified functions(s) or steps(s).

[0283] Furthermore, these computer program instructions, specifically implemented in computer-readable program code, may also be stored in one or more computer-readable storage media or memory devices, which may direct a computer processor or other programmable processing apparatus to operate in a particular manner, thereby causing the instructions stored in the computer-readable storage media or memory devices to produce an article of manufacture including an instruction means comprising the functions specified in the blocks of the flowchart. The computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus, thereby producing computer-implemented processing, such that the instructions executing on the computer processor or other programmable processing apparatus provide steps for implementing the functions, procedures, algorithms, steps, operations, formulas, or calculations specified in the blocks of the flowchart.

[0284] It should also be understood that, as used herein, the term "program" or "executable program" refers to one or more instructions that can be executed by one or more computer processors to perform one or more of the functions described herein. Instructions may be implemented in software, firmware, or a combination of software and firmware. Instructions may be stored on a non-transitory medium local to the device, or remotely stored, such as on a server, or all or part of the instructions may be stored both locally and remotely. Remotely stored instructions may be downloaded (pushed) to the device by user initiation, or may be automatically downloaded (pushed) to the device based on one or more factors.

[0285] It should also be recognized that the terms processor, hardware processor, computer processor, central processing unit (CPU) and computer, as used herein, are used synonymously to refer to a device capable of executing instructions and communicating with input / output interfaces and / or peripheral devices, and the terms processor, hardware processor, computer processor, CPU and computer are intended to cover single or multiple devices, single-core or multi-core devices, and various variations thereof.

[0286] As will be appreciated from the description herein, this disclosure covers a variety of implementations of the technology, including, but not limited to, the following:

[0287] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuitry acting as a wireless station (STA), the wireless station operating as an access point (AP) or a non-AP STA, the wireless communication circuitry being configured to wirelessly transmit packets carrying frames via a channel to other wireless stations (STAs) acting as APs or non-AP STAs on a wireless local area network (WLAN), wherein enhanced distributed channel access (EDCA) is applied to more than one access class (AC) in the WLAN; (b) a processor coupled to the wireless communication circuitry for operation as an STA on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein the instructions, when executed by the processor, perform one or more of the following steps: (d)(i) distinguishing between real-time application (RTA) traffic and non-RTA traffic; (d)(ii) obtaining a transmission opportunity (TXOP) from the primary AC; and (d)(iii) transmitting RTA frames from non-primary ACs using the remaining TXOP channel resources, even though frames from the primary AC may not be transmitted during the TXOP.

[0288] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuitry acting as a wireless station (STA), the wireless station operating as an access point (AP) or a non-AP STA, the wireless communication circuitry being configured to wirelessly transmit packets carrying frames via a channel to other wireless stations (STAs) acting as APs or non-AP STAs on a wireless local area network (WLAN), wherein enhanced distributed channel access (EDCA) is applied to more than one access class (AC) in the WLAN; (b) a processor coupled to the wireless communication circuitry for operation as an STA on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein the instructions, when executed by the processor, implement one or more of the following steps: (d)(i) exchanging specifications and upper-layer information of the Quality of Service (QoS) requirements of a traffic flow between a non-AP MLD and an AP MLD to set up the traffic flow; (d)(ii) by the non-AP MLD or AP The MLD assigns a Low Latency Identifier (LLID) to the traffic flow to distinguish it from other traffic flows with the same Traffic Identifier (TID); (d)(iii) the non-AP MLD and / or AP MLD determine which link(s) the traffic flow will be sent through; and (d)(iv) the non-AP MLD and / or AP MLD distinguish traffic belonging to the traffic flow from other traffic.

[0289] A wireless communication method in a network, the method comprising: (a) communicating via a channel from a wireless station (STA) operating as an access point (AP) or a non-AP STA with other wireless stations (STAs) operating as APs or non-AP STAs on a wireless local area network (WLAN), wherein enhanced distributed channel access (EDCA) is applied to more than one access class (AC) in the WLAN; (b) distinguishing between real-time application (RTA) traffic and non-RTA traffic; (c) obtaining a transmission opportunity (TXOP) from the primary AC; and (d) transmitting RTA frames from non-primary ACs using the remaining channel resources even when frames from the primary AC are not transmitted during the TXOP.

[0290] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: ensuring that there are minimum required channel resources available for transmitting frames from the primary AC during TXOP.

[0291] Any apparatus or method in a priori implementation wherein, if all frames from the primary AC have been transmitted, the STA that has the minimum required channel resources for transmitting frames from the primary AC can use those minimum required channel resources for TXOP sharing.

[0292] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the step of: the STA not setting the minimum required channel resources for transmitting frames from the primary AC during TXOP.

[0293] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further implement the following steps: STA ensures that a given minimum number of bytes are sent from the primary AC during TXOP.

[0294] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the STA ensures that a minimum required channel time is provided for transmitting frames from the primary AC during TXOP.

[0295] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the STA still transmits RTA frames from a non-primary AC even if no frames are transmitted during TXOP.

[0296] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the STA transmits RTA frames from a non-primary AC only during the TXOP if all RTA frames from the primary AC have been transmitted.

[0297] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the step of: the STA transmitting an RTA frame from a higher-priority non-primary AC during TXOP before transmitting an RTA frame from the primary AC.

[0298] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the STA transmits an RTA frame from a lower-priority non-primary AC during TXOP.

[0299] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the step of: the STA sending MU PPDU packets whose length is determined by the transmission and / or delay requirements of the RTA frames from the primary AC.

[0300] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further implement the following steps: STA limits the time of TXOP sharing.

[0301] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the STA allows the transmission of RTA frames earlier than frames from the primary AC only if the RTA frames from the non-primary AC are about to expire.

[0302] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the STA acquires the TXOP of the primary AC and shares the TXOP with a low-priority non-primary AC.

[0303] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the non-AP MLD sends a frame to the AP MLD including the specifications of the traffic stream, QoS requirements, upper-layer information, and LLID to request it to set up the traffic stream.

[0304] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further implement the following steps: the AP MLD responds to a non-APMLD request to set a traffic flow using a frame including the specifications of the traffic flow, QoS requirements, upper-layer information, LLID, and status, to indicate whether it accepts or rejects the request.

[0305] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further implement the following steps: the AP MLD and non-AP MLD implement the exchange of specifications and QoS requirements for traffic flows by using a Traffic Specification (TSPEC) unit configured to include additional QoS requirements as defined in IEEE 802.11ax.

[0306] Any apparatus or method implemented prior to this, wherein the additional QoS requirements include jitter and packet loss requirements.

[0307] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the following steps: the AP MLD and non-AP MLD exchange traffic stream information by sending frames on different links.

[0308] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further perform the following steps: distinguishing one traffic stream from other traffic streams in response to AP MLD and non-AP MLD transmissions of tuples including a non-AP MAC address and LLID.

[0309] Any apparatus or method with a prior implementation, wherein the instructions, when executed by a processor, further include the step of sending an unsolicited frame by the AP MLD to terminate or modify an existing traffic stream.

[0310] The term “implementation” as used herein is intended to include, but is not limited to, embodiments, examples or other forms of practicing the techniques described herein.

[0311] Unless the context explicitly indicates otherwise, the singular terms “a,” “an,” and “the” used herein may also include plural items. Unless explicitly stated otherwise, reference to a singular object is not intended to mean “one and only one,” but rather “one or more.”

[0312] Phrases such as "A, B, and / or C" in this disclosure can describe situations where A, B, or C, or any combination of items A, B, and C, exist. For example, a phrase phrase "at least one of" following a list of unit groups indicates the presence of at least one of these group units, including any applicable possible combinations of the listed units.

[0313] When the terms "embodiment," "at least one embodiment," or similar expressions are used in this disclosure, it indicates that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of this disclosure. Therefore, these different embodiment phrases do not necessarily all refer to the same embodiment or to a specific embodiment different from all other embodiments described. Embodiment phrases should be interpreted as meaning that a particular feature, structure, or characteristic of a given embodiment can be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method.

[0314] The term "set" as used in this article refers to a collection of one or more objects. Therefore, a set of objects may include, for example, a single object or multiple objects.

[0315] For example, relational terms such as first and second, top and bottom can simply be used to distinguish one entity or action from another, without necessarily requiring or implying any actual such relationship or order between such entities or actions.

[0316] The terms “comprising,” “having,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, and therefore a process, method, article, or apparatus that includes, has, or comprises a list of units not only includes those units but may include other units not expressly listed or inherent to such a process, method, article, or apparatus. Without further constraints, the use of “comprising,” “having,” or “including” preceding a unit does not exclude the presence of additional identical units in the process, method, article, or apparatus that includes, has, or comprises that unit.

[0317] The terms “approximately,” “approximately,” “substantially,” “essentially,” and “about,” or any other version thereof, as used herein, are used to describe and explain small variations. When used in conjunction with an event or situation, the terms may refer to instances where the event or situation occurred precisely or approximately. When used in conjunction with a numerical value, the terms may refer to a range of variation less than or equal to ±10% of that value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, “substantially” alignment may refer to a range of angular variation less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

[0318] Furthermore, quantities, ratios, and other numerical values ​​may sometimes be given in range format herein. It should be understood that such range format is for convenience and brevity and should be flexibly interpreted to include not only the numerical values ​​explicitly defined as range boundaries, but also all individual numerical values ​​or subranges covered within that range, as if each numerical value and subrange were explicitly defined. For example, ratios in the range of approximately 1 to approximately 200 should be understood to include the explicitly listed boundaries of approximately 1 and approximately 200, as well as individual ratios such as approximately 2, approximately 3, and approximately 4, and subranges such as approximately 10 to approximately 50, approximately 20 to approximately 100, etc.

[0319] The term "coupling" as used in this document is defined as a connection, but not necessarily a direct connection and not necessarily a mechanical connection. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in ways not listed.

[0320] Various benefits, advantages, solutions to problems, and any elements(s) that may cause any benefit, advantage, or solution to occur or become more significant shall not be construed as key, required, or essential features or elements of the technology described herein or of any or all claims.

[0321] Furthermore, in the foregoing disclosure, various features may have been grouped together in different embodiments for the purpose of streamlining the disclosure. This approach to disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than expressly listed in each claim. The inventive subject matter may be contained in fewer than all features of a single disclosed embodiment.

[0322] An abstract of this disclosure is provided to allow readers to quickly determine the nature of the technical disclosure. The applicant understands at the time of filing the abstract that it will not be used to interpret or limit the scope or meaning of the claims.

[0323] It should be recognized that practice in some jurisdictions may require the removal of one or more portions of the published content after the application has been filed. Therefore, readers should consult the applicant regarding the original content of this publication. Any removal of content from the publication should not be construed as a disclaimer, waiver, or donation to the public of any subject matter of the original application.

[0324] The appended claims are incorporated herein by reference, and each claim exists independently as a separate subject matter for protection.

[0325] While the description herein contains numerous details, these details should not be construed as limiting the scope of this disclosure, but rather as providing illustrations of some of the presently preferred embodiments. Therefore, it should be understood that the scope of this disclosure fully covers other embodiments that may become apparent to those skilled in the art.

[0326] All structural and functional equivalents of the elements of the disclosed embodiments known to those skilled in the art are expressly incorporated herein by reference and are intended to be covered by these claims. Furthermore, the elements, components, or method steps in this disclosure are not intended to be donated to the public, regardless of whether they are expressly listed in the claims. Unless the phrase "means for…" is expressly used to list an element of a claim herein, that element should not be construed as a "means plus function" element. Unless the phrase "steps for…" is expressly used to list an element of a claim herein, that element should not be construed as a "step plus function" element.

[0327] Table 1 User Priority to (UP) Mapping

[0328]

[0329] Table 2 Default Parameter Set

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

[0331] Table 3 MLME-LLTS.reques t

[0332]

[0333] Table 4 MLME-LLTS.indicat ion

[0334]

[0335] Table 5 MLME-LLTS.response

[0336]

[0337] Table 6 MLME-LLTS.conf

[0338]

[0339] Table 7 MLME-LLTS-TERM.reques t

[0340]

[0341] Table 8MLME-LLTS-TERM.indication

[0342]

[0343] Table 9 Exemplary LLTS

[0344] LLID Initiator Receiver direction TID UP link LLTS1 1 STA2 AP1 / MLD1 downlink 8 6 1 LLTS2 2 MLD2 MLD1 downlink 9 5 1 LLTS3 3 MLD3 MLD1 downlink 10 3 1 LLTS4 4 STA2 AP1 / MLD1 uplink 8 6 1 LLTS5 5 MLD2 MLD1 uplink 8 6 1&2 LLTS6 6 STA2 AP1 / MLD1 downlink 8 6 1

Claims

1. An apparatus for wireless communication in a network, the apparatus being a wireless station STA, the wireless station STA operating as an access point (AP) or a non-AP STA, the apparatus comprising: (a) A wireless communication circuit configured to wirelessly transmit packets carrying frames to other STAs acting as APs or non-AP STAs on a wireless local area network (WLAN) via a channel, wherein enhanced distributed channel access (EDCA) is applied to more than one access class AC in the WLAN. (b) A processor coupled to the wireless communication circuit; (c) Non-transitory memory storing instructions executable by the processor for communication with other STAs; and (d) The instructions described herein perform the following steps when executed by the processor: (i) Use Low Latency Traffic Streaming (LLTS) to distinguish between Real-Time Application (RTA) traffic and non-RTA traffic; (ii) Obtain the primary AC's transmission opportunity (TXOP); as well as (iii) Even though frames from the primary AC may not be transmitted during the TXOP, the remaining TXOP channel resources are used to transmit RTA frames from non-primary ACs, including transmitting RTA frames from non-primary ACs with higher priority than the primary AC or from non-primary ACs with lower priority than the primary AC. The cases in which RTA frames from non-primary ACs with lower priority than the primary AC are transmitted include when these RTA frames are about to expire or when the lower-priority non-primary AC previously shared its TXOP with the primary AC.

2. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: ensuring that there are minimum required channel resources available for transmitting frames from the primary AC during TXOP.

3. The apparatus according to claim 2, wherein, If all frames from the primary AC have been transmitted, ensure that the STA with the minimum required channel resources for transmitting frames from the primary AC can use those minimum required channel resources for TXOP sharing.

4. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: the STA does not set the minimum required channel resources for transmitting frames from the primary AC during TXOP.

5. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: STA ensures that a given minimum number of bytes are sent from the primary AC during TXOP.

6. The apparatus according to claim 1, wherein, When executed by the processor, the instructions also implement steps including: the STA ensures that the minimum required channel time is provided for transmitting frames from the primary AC during TXOP.

7. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: even if no frames are sent from the primary AC during TXOP, the STA still sends RTA frames from the non-primary AC.

8. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: the STA only transmits RTA frames from non-primary ACs during TXOP if all RTA frames from the primary AC have been transmitted.

9. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: before sending an RTA frame from the primary AC, the STA sends an RTA frame from a higher-priority non-primary AC during the TXOP period.

10. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: the STA sends an RTA frame from a lower-priority non-primary AC during TXOP.

11. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: the STA sends MU PPDU packets whose length is determined by the transmission and / or delay requirements of the RTA frames from the primary AC.

12. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: STA limits the time for TXOP sharing.

13. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: the STA allows RTA frames to be sent earlier than frames from the primary AC only if the RTA frames from non-primary ACs are about to expire.

14. The apparatus according to claim 1, wherein, When executed by the processor, the instruction also performs the following steps: the STA acquires the TXOP of the primary AC and shares the TXOP with the low-priority non-primary AC.

15. A method of operating an apparatus for wireless communication in a network, the apparatus being a wireless station STA, the wireless station STA operating as an access point AP or a non-AP STA, the method comprising: (a) Communicating with other STAs as APs or non-APs on a wireless local area network (WLAN) via a channel, and applying Enhanced Distributed Channel Access (EDCA) to more than one access class AC in the WLAN. (b) Use Low Latency Traffic Streaming (LLTS) to distinguish between Real-Time Application (RTA) traffic and non-RTA traffic; (c) Obtain the primary AC transmission opportunity (TXOP); as well as (d) Even when frames from the primary AC are not transmitted during the TXOP, the remaining channel resources are used to transmit RTA frames from non-primary ACs, including transmitting RTA frames from non-primary ACs with higher priority than the primary AC or from non-primary ACs with lower priority than the primary AC. The cases in which RTA frames from non-primary ACs with lower priority than the primary AC are transmitted include when these RTA frames are about to expire or when the lower-priority non-primary AC previously shared its TXOP with the primary AC.

Images