Sharing EDCA TXOPs with RTA traffic

Abstract

A communication circuit and protocol for Wireless Local Area Networks (WLANs) using single-EDCA and / or multi-user (MU) EDCA where frames for real-time applications (RTA) can utilize shared transmission opportunities (TXOPs) to reduce transmission delay. The protocol is configured in many ways to ensure communication fairness, such as by guaranteeing the minimum channel resources required to transmit frames from the primary AC during a TXOP. AP MLD and non-AP MLD are also supported, which can exchange information to distinguish a traffic stream from other traffic streams with the same traffic identifier (TID) when determining which link a traffic stream should be transmitted using.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority and the benefit thereof to U.S. Provisional Patent Application Serial No. 63 / 168,434, filed on March 31, 2021, the entire disclosure of which is incorporated herein by reference.

[0002] [Description of Research or Development Sponsored by the Federal Government] Not applicable

[0003] [Notice of Materials Subject to Copyright Protection] Portions of the material in this patent document may be subject to copyright protection under the copyright laws of the United States and other countries. The copyright owner does not object to the reproduction by a third party of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office's general - public file or records, but reserves all other copyrights. The copyright owner does not hereby waive any rights to maintain the patent document in secrecy, including, but not limited to, the rights provided for in 37 C.F.R. § 1.14.

[0004] The technology of the present disclosure generally relates to wireless network communication using Enhanced Distributed Channel Access (EDCA) that defines multiple Access Categories (ACs), and specifically to enabling Real - Time Application (RTA) packet transmissions to reduce latency by utilizing Transmission Opportunity (TXOP) sharing.

Background Art

[0005] Current wireless 802.11 technology that uses CSMA / CA focuses on high throughput performance of the network, but does not sufficiently support low-latency traffic required by real-time applications (RTA) that transmit RTA frames. Each RTA frame requires low latency due to the high timeliness requirement that it is only valid if delivered within a certain time. Also, problems occur when using Extended Distributed Channel Access (EDCA) that defines multiple access categories (AC) for RTA traffic. Summary of the Invention Problems to be Solved by the Invention

[0006] Therefore, there is a need to enhance the TXOP RTA traffic sharing process when using EDCA. This disclosure meets this need and provides further advantages. Means for Solving the Problems

[0007] Current wireless communication systems that use Extended Distributed Channel Access (EDCA) do not distinguish RTA packets from non-RTA packets, so all packets use the same TXOP sharing rule under EDCA. This disclosure is configured to enhance the flexibility of RTA packet transmission when utilizing EDCA transmission opportunity (TXOP) sharing to reduce latency. The disclosed protocol provides main advantages such as (a) when there are unsent frames from the primary AC, the STA can share the TXOP of the primary AC to transmit RTA frames, and (b) considering fairness (uniformity, equality) between the transmission of frames of the primary AC and the transmission of RTA frames from non-primary ACs.

[0008] In the following parts of this specification, further aspects of the technology described in this specification will become apparent, and this detailed description is for fully disclosing the technology without limiting the preferred embodiments of the technology.

[0009] The technology described in this specification will be fully understood by referring to the following drawings, which are for illustrative purposes only.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14A

Figure 14B

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Figure 39

Figure 40

Figure 41

Figure 42

Figure 43

Figure 44

Figure 45

Figure 46

Figure 47

Mode for Carrying Out the Invention

[0011] 1. Introduction Real-time applications (RTA) require low latency and use best-effort communication. Data generated from RTA is called RTA traffic and is packetized as RTA frames at the transmitting station (STA). Also, in this specification, data generated from non-time-dependent applications is called non-RTA traffic, and these are packetized as non-RTA frames at the transmitting STA that transfers packets carrying frames to the receiving STA via a channel (link).

[0012] RTA traffic is encapsulated in frame units when it arrives at the EDCA queue. Frames carrying RTA traffic are represented by RTA frames, and frames carrying non-RTA traffic are represented by non-RTA frames. One packet can include one or more frames and be transmitted via a link or channel. The AC associated with the EDCAF that has acquired the EDCA TXOP is called the primary AC.

[0013] Since the RTA frame is only valid when delivered within a certain time, it requires low latency due to the high timeliness requirement for delivery. One solution in CSMA / CA wireless technology is, for example, to use a high-priority AC such as for transmitting the RTA frame to increase the opportunity for the STA to transmit the RTA frame.

[0014] Due to the random channel access scenario, the STA needs to sense the channel before transmitting each frame and compete for channel access rights. In EDCA, the STA can accelerate channel access by using the short channel contention time of the high-priority AC. However, the low-priority AC may also access the channel earlier than the high-priority AC. The cause of the transmission delay of the RTA frame from the high-priority AC lies in the TXOP time obtained by the low-priority AC.

[0015] To avoid the delay caused by the TXOP time obtained by the low-priority AC, the STA can transmit the RTA frame using the TXOP time obtained by the low-priority AC. The task of sharing the TXOP of the primary AC to transmit frames from the non-primary AC is difficult due to the coexistence of RTA traffic and non-RTA traffic. The challenge of this process can be summarized as (a) distinguishing between RTA traffic and non-RTA traffic and sharing the TXOP of the primary AC to transmit RTA packets from the non-primary AC when there are undelivered packets from the primary AC.

[0016] 2. Current 802.11 Operations 2.1. TSPEC Elements Figure 1 shows the content of the TSPEC elements defined by IEEE802.11, which have the following fields. The Element ID indicates the type of the element, indicating that it is a TSPEC element in this case. The Length field indicates the length of the TSPEC element. The TS Info field indicates traffic stream information and has sub-fields shown in Figure 2. The Nominal MSDU Size field indicates the nominal size of the MSDU or A-MSDU belonging to the TS under this TSPEC. The Maximum MSDU Size field indicates the maximum size of the MSDU or A-MSDU belonging to the TS under this TSPEC. The Minimum Service Interval field indicates the minimum time between the start times of two consecutive service periods (SPs). The Maximum Service Interval field indicates the maximum time between the start times of two consecutive SPs. The Inactivity Interval field indicates the time interval during which there is no arrival or transmission of MSDUs belonging to the TS before the deletion of the TS. The Suspension Interval field indicates the period during which there is no arrival or transmission of MSDUs belonging to the TS before the suspension of the generation of QoS(+)CF-Poll for the TS.

[0017] The Service Start Time field includes the start time of the first SP. The Minimum Data Rate field indicates the minimum data rate for transmitting MSDUs or A-MSDUs belonging to this TS under this TSPEC as specified by the MAC SAP. The Mean Data Rate field indicates the average data rate for transmitting MSDUs or A-MSDUs belonging to this TS under this TSPEC as specified by the MAC SAP. The Peak Data Rate field indicates the maximum data rate for transmitting MSDUs or A-MSDUs belonging to this TS under this TSPEC as specified by the MAC SAP. The Burst Size field indicates the maximum burst at the peak data rate of MSDUs or A-MSDUs belonging to this TS under this TSPEC. The Delay Bound field indicates the maximum time allowed for transmitting MSDUs or A-MSDUs belonging to this TS under this TSPEC. The Minimum PHY Rate field indicates the minimum PHY rate for transmitting MSDUs or A-MSDUs belonging to this TS under this TSPEC. The Surplus Bandwidth Allowance field indicates the ratio of the bandwidth used for transmitting and retransmitting MSDUs or A-MSDUs belonging to this TS under this TSPEC to the bandwidth used for transmitting this MSDU or A-MSDU once at the minimum PHY rate. The Medium Time field indicates the time allowed to access the medium. The DMG Attributes field is presented when the TSPEC is applied to a directional multi-gigabit (DMG) BSS.

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

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

[0020] 2.3. TCLAS Process Element Figure 4 shows the content of the TCLAS processing element defined in IEEE802.11. The Element ID field indicates the type of the element, which is the TCLAS processing element in this case. The Length field indicates the length of the TCLAS processing element. The Processing field indicates the method for classifying the traffic from the upper layer when there are multiple TCLAS elements.

[0021] 2.4. Multi-user Transmission In wireless networks such as IEEE802.11, multi-user transmission is available. Since IEEE802.11ax, the network can support multi-user transmission in both the uplink and downlink. The multi-user transmission of IEEE802.11ax includes the MIMO mode and the OFDMA mode, which can be used alone or in combination.

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

[0023] IEEE802.11ax defines a plurality of PLCP Protocol Data Unit (PPDU) formats for transmitting packets in different multi-user transmissions, which will be described later. Note that PLCP is the initials of the PHY Layer Convergence Protocol.

[0024] FIG. 5 shows the HE multi-user (MU) PPDU format used for downlink multi-user transmission in IEEE802.11ax. These fields are shown as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, Data, and PE.

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

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

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

[0028] FIG. 9 shows the user information field of the trigger frame shown in FIG. 7, and this field has the following sub-fields. These are AID12, RU Allocation, Coding Type, MCS, DCM, SS Allocation, Target RSSI, Reserved, and Trigger Dependent Common Info.

[0029] The trigger frame shown in FIG. 7 can be transmitted as a multi-user block ACK request (MU-BAR) by setting the trigger type of the common information field to "2". When the trigger frame is a MU-BAR, the content of the trigger-dependent user information field (shown in FIG. 9) within the trigger frame is as shown in FIG. 10.

[0030] Figure 10 shows the trigger-dependent user information field within the trigger frame for the case of MU-BAR, showing the subfields BAR control and BAR information.

[0031] Figure 11 shows the content of the Block ACK (BA) frame having the following subfields. The Frame Control field indicates the type of the frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA that transmitted the frame. The BA Control field indicates the policy of the block ACK. The BA info field contains the feedback for transmission.

[0032] Figure 12 shows the content of a Buffer Status Request (BSR) frame having the following fields. The Frame Control field indicates the type of the frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the recipient of the frame. The TA field contains the address of the STA that transmitted the frame. The HT Control field indicates a variant of the BSR control subfield. The Format Indication field is used to indicate the format of the HT Control field. When B0 and B1 are set to the first state (e.g., "1"), it indicates that the HT Control field uses the HE format. After this field, there is an A-Control field. The A-Control field carries the buffer status report. The Control ID field indicates that the BSR is carried within the control information field. The Control Information field carries a variant of the BSR control subfield. The ACI Bitmap field indicates the access categories for which the buffer status is reported. The Delta TID field indicates the number of TIDs for which the buffer status is reported. The ACI High field indicates the access categories reported in the queue size high field. The Scaling Factor field indicates the unit of the queue size high field and the queue size all field. The Queue Size High field indicates the queue size of the AC indicated by ACI High in the unit of the scaling factor. The Queue Size All field indicates the queue size of the AC indicated by the ACI Bitmap, also in the unit of the scaling factor.

[0033] FIG. 13 shows an example of downlink multi-user transmission using OFDMA. The transmitting AP transmits data packets to its receiving sides 1, 2, 3, and 4 using the HE MU PPDU format. After finishing the first transmission, the AP transmits a multi-user block ACK request (MU-BAR) to all the receiving sides. Then, each receiving side returns a block ACK (BA) to the AP. The AP decides to retransmit the packets to receiving sides 1, 3, and 4 according to the content of the BA. The AP competes for the channel and waits for a given backoff time. The first retransmission is performed after the AP obtains the channel access right.

[0034] FIGS. 14A and 14B show an example of uplink multi-user transmission using OFDMA. The AP first transmits a buffer status report request (BSRP) trigger frame to all the transmitting sides 1, 2, 3, and 4. Next, the transmitting sides receive the BSRP trigger frame and return a buffer status report (BSR) to the AP. Then, the AP transmits a trigger frame to all the transmitting sides 1, 2, 3, and 4. In the trigger frame, channel resources are allocated based on the BSR received from the STA. The transmitting sides receive the trigger frame and start the first transmission using the resource blocks allocated by the trigger frame. The multi-user transmission packet uses the HE-TB PPDU format. The AP receives the packet from the transmitting side and transmits a BA frame to report whether the transmission is correctly received.

[0035] 2.5. EDCA System Figure 15 shows a reference model of an (Extended DCF Channel Access) EDCA queue in IEEE 802.11. This system includes six transmit queues and four access categories (ACs). Each AC competes for channel access rights using an EDCA function (EDCAF) so that it can transmit the packets in its corresponding transmit queue. Six transmit queues are shown 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 the packets in the queue.

[0036] The four ACs shown in the figure are Voice (VO), Video (VI), Best Effort (BE), and Background (BK). Each AC has an EDCA function (EDCAF) that provides the function of channel contention. When multiple EDCAs attempt to access the channel simultaneously, an internal collision avoidance mechanism is used. If an internal collision occurs, the EDCAF with a higher priority acquires the channel access right.

[0037] 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 designation in IEEE 802.1D. In each row, according to the user priority, the traffic is added to the corresponding transmit queue and access category. The priority increases from the top row to the bottom row. The higher the priority of the traffic, the higher the probability of being transmitted earlier.

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

[0039] When using only DCF, the STA can immediately access the channel, and the medium is idle for a longer time than the DCF Inter - Frame Space (DIFS). Otherwise, the STA uses CSMA / CA to compete for access to the channel. After the STA senses that the channel has been idle for the DIFS time, it starts counting down the back - off as long as the medium is idle. The number of back - off slots is randomly selected between zero and the contention window. When the STA senses that CCA busy occurs, e.g., the channel is busy, it pauses the back - off countdown. When the back - off counts down to zero, the STA can start transmitting the packet.

[0040] In EDCA, when the medium is idle for a longer time than the Arbitration Inter - Frame Spacing (AIFS) time of the AC, each EDCAF as shown in FIG. 15 can immediately access the channel to obtain the channel access right. Note that the illustrated AIFS[i] represents the AIFS time of AC i representing a given AC. Otherwise, each EDCAF uses CSMA / CA to compete for the channel access right for each AC that is trying to obtain the channel access right. After the STA senses that the channel has been idle for the AIFS time, it starts counting down the back - off as long as the medium is idle. The number of back - off slots is randomly selected between zero and the contention window size. When the STA senses that CCA busy occurs, e.g., senses channel busy, it pauses the back - off countdown. When the back - off counts down to zero, the STA starts transmitting the packet of that AC. Note that multiple EDCAFs can also compete for the channel simultaneously. For example, as shown in FIG. 16, the EDCAFs of AC i and AC j (representing any two ACs) can compete for the channel simultaneously.

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

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

[0043] 2.6. Sharing of TXOP in IEEE802.11ax. The STA can share the TXOP to transmit RTA frames from non - primary ACs only when all frames from the primary AC have been transmitted or when the STA transmits a MU PPDU. When the TXVECTOR parameter NUM_USERS is greater than 1 and frames from a non - primary AC with a lower priority are included in a MU DL MIMO PPDU (VHT MU PPDU), these frames do not increase the PPDU period beyond the period required for the transmission of frames from the primary AC and any frames from ACs with a higher priority. When frames from non - primary ACs with a higher or lower priority are included in the HE MU PPDU by the AP, these frames do not increase the HE MU PPDU period beyond the period required for the transmission of frames from the primary AC and any frames from ACs with a higher priority. For a given user within a VHT / HE MU PPDU, any frame from the primary AC must be transmitted first, and then any frame from the next higher - priority AC must be transmitted.

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

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

[0046] 5. Embodiments 5.1 STA and MLD hardware configuration FIG. 17 shows an example embodiment 10 of STA hardware configured to execute the protocol of this disclosure. The external I / O connection 14 is coupled to the internal bus 16, and preferably, a CPU 18 and a memory (e.g., RAM) 20 are connected on the internal bus 16 to execute a (single or multiple) program implementing the communication protocol. The host machine houses at least one modem 22 that supports communication, which is coupled to at least one RF module 24, 28, each of which is connected to one or more antennas 29, 26a, 26b, 26c~26n. An RF module having a plurality of antennas (e.g., an antenna array) enables beamforming to be performed during transmission and reception. In this way, the STA can transmit signals using multiple sets of beam patterns.

[0047] Bus 14 can connect various devices such as sensors and actuators to the CPU. On processor 18, instructions from memory 20 are executed to run a program that implements a communication protocol to enable the STA to perform the functions of an access point (AP) station or a normal station (non-AP STA). Also, this programming is configured to operate in different modes (TXOP owner, TXOP shared participant, source, intermediate, destination, first AP, other AP, station related to the first AP, station related to other APs, coordinator, coordinatee, etc.) according to what role it plays in the current communication situation. Therefore, the illustrated STA HW is configured using at least one modem and related RF circuits for providing communication on at least one band such as the sub-6 GHz band and / or the mmW band.

[0048] Also, multiple instances of the illustrated station hardware can be combined into a multi-link device (MLD). Usually, this MLD has a processor and memory to coordinate activities, but it is not necessarily the case that each STA within the MLD requires a separate CPU and memory.

[0049] FIG. 18 shows an example embodiment 40 of the hardware configuration of a multi-link device (MLD). The MLD has multiple STAs belonging to it, and each STA operates on a link with a different frequency. The MLD has external I / O 41 access to an application, and this access connects to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to enable the execution of a (single or multiple) program that implements a communication protocol at the MLD level. The MLD can distribute tasks to and collect information from each of the belonging stations STA1 42, STA2 44 to STA N 46, and share information among the belonging STAs.

[0050] In at least one embodiment, each STA of the MLD has its own CPU 50 and memory (RAM) 52, which are coupled via a bus 58 to at least one modem 54 connected to at least one RF circuit 56 having one or more antennas 60a, 60b, 60c to 60n. The present disclosure is mainly interested in the sub-6 GHz band with omnidirectional antennas. The modem combined with the RF circuit and the associated (single or multiple) antennas transmits / receives data frames with neighboring STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuits for interacting with the antennas.

[0051] It should be understood that each STA of the MLD does not necessarily require its own processor and memory, as they can share resources with each other and / or with the MLD management entity depending on the specific MLD implementation. Note that the above MLD diagram is shown as an example and not a limitation, and it should be understood that the present disclosure can operate with a wide range of MLD implementations.

[0052] 5.2. STA Topology to Consider To better illustrate the objectives of the disclosed technology, a certain network scenario is utilized in the examples.

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

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

[0055] 5.3. Distinction between RTA Traffic and Non-RTA Traffic 5.3.1. Low Latency Traffic Stream (LLTS) Operation In this section, a mechanism called Low Latency Traffic Stream (LLTS) is introduced to distinguish between RTA traffic and non-RTA traffic. Generally, LLTS can be used to distinguish traffic streams having special QoS requirements such as latency, jitter, and / or reliability from other traffic.

[0056] Often, the RTA generates traffic periodically as connection-oriented communication between STAs, which is referred to as an RTA session in this specification. An STA can have multiple RTA sessions within a network. The STA can correctly manage these RTA sessions and apply the correct transmission scheme to the RTA packets of the RTA sessions. By way of example and not limitation, a low-latency traffic stream (LLTS) can be utilized to identify the RTA traffic of an RTA session from an upper layer.

[0057] FIG. 20 shows an exemplary embodiment 110 for terminating or modifying an LLTS, and it will be understood that this process can also be utilized for other LLTS operations including changes or deletions of the LLTS. The interaction model of the STA can be the same as that defined in the IEEE802.11 standard. The transmitter can be either an AP or a non-AP STA, and the receiver can also be either an AP or a non-AP STA. For simplicity of explanation, in the LLTS setup procedure of this section, it is assumed that the transmitter in this example is a non-AP STA and the receiver is an AP. This figure shows the SME112 and MLME114 of the non-AP STA, and the MLME116 and SME118 of the AP.

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

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

[0060] The AP or the AP MLD can decide to change or terminate the LLTS with the non-AP STA or MLD. The SME of the AP or the SME of the AP MLD sends an MLME-LLTS-TERM.request message 136 (as shown in Table 7) to the MLME of the AP or the MLME of the belonging AP. When the MLME of the AP receives the MLME-LLTS-TERM.request message, it collects the information in the MLME-LLTS-TERM.request message and sends an LLTS response frame 138 to the non-AP STA. The MLME of the non-AP STA receives the frame and generates an MLME-LLTS-TERM.indication message 140 (as shown in Table 8) for the SME. Then, the non-AP recognizes that the LLTS has ended or been modified.

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

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

[0063] Also, the LLTS request frame and the LLTS response frame for the same LLTS setup procedure can be transmitted via different links.

[0064] FIG. 21 shows an example embodiment 150 of the LLTS request frame format used in this specification. The Frame Control field indicates the type of the frame. The Duration field contains the NAV information used for CSMA / CA channel access. The Address 1 field contains the address of the recipient of the frame. The Address 2 field contains the address of the STA that transmitted the frame. The Address 3 field contains the BSSID. The Sequence control field indicates the sequence number of the frame. The HT control field indicates further control information for the frame. The Action field indicates the operation to be performed if the frame is an LLTS request frame and has sub-fields outlined below.

[0065] The Category field and the QoS Action field indicate the type of the action field, indicating that the action field is an LLTS request frame in this case. The Dialog token field specifies the LLTS request transaction and can be set to an integer that identifies the LLTS request frame in at least one embodiment. When the receiving side receives this token field, it should respond to the LLTS response frame using the same dialog token. The action field includes an LLTS request element having a subfield of Element ID indicating the type of the element (indicating that it is an LLTS request element in this example), a Length subfield indicating the length of the LLTS request element, and an LLTS Descriptor List subfield indicating a sequence of LLTS descriptor fields. Each LLTS descriptor field is set to indicate an LLTS setting request for traffic according to specific specifications and classification information. When this information is received, the receiving STA that recognizes the traffic specifications and classification information can decide whether to accept or reject the LLTS setting request.

[0066] Figure 22 shows an example embodiment 170 of the LLTS descriptor field format. The LLID field provides identification of the low-latency transmission service, and the non-AP STA sets a number representing the LLTS therein. The AP can receive this number and use it to identify the LLTS set by the non-AP STA. In at least one embodiment or mode, this field is reserved by the non-AP STA and only the AP can set this field. This field can be the Streamed Classification Service (SCS) ID defined in IEEE802.11. The LL Length field includes the length of the LLTS descriptor field. The Request Type field is set to indicate the type of the LLTS descriptor. When the non-AP STA or MLD sets the Request Type field to "Add", it requests to add a new LLTS. The receiving AP or AP MLD should respond whether to approve the addition of the new LLTS.

[0067] When the non-AP STA or MLD sets the Request Type field to "Change", it requests to change an existing LLTS. When receiving this field, the AP or AP MLD can discover the LLTS using the LLID. Then, the AP or AP MLD approves or rejects the change of the parameters of this LLTS.

[0068] When the non-AP STA or MLD sets the Request Type to "Remove", it requests to delete an existing LLTS. When receiving this field, the AP or AP MLD can discover and delete the LLTS using the LLID.

[0069] The TCLAS field is the same as the TCLAS element defined in IEEE802.11. The STA or MLD sets this field to indicate the information of the traffic 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 under this LLTS arriving from this upper layer. The LLTS Descriptor field can contain multiple TCLAS fields.

[0070] The TCLAS Processing field is identical to the TCLAS processing element defined in IEEE802.11. When there are multiple TCLAS fields in the LLTS Descriptor field, the non-AP STA sets this field to indicate the rules for identifying RTA traffic using the multiple TCLAS fields. When the AP receives this field within the LLTS Descriptor field, it recognizes that it can use the multiple TCLAS fields to identify the traffic from the upper layer.

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

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

[0073] FIG. 23 shows an example embodiment 190 of the RTA-TSPEC field content. The TSPEC field can be the same as the TSPEC element defined in IEEE802.11. The STA sets this field to indicate the TSID, traffic characteristics, and partial QoS requirements of the RTA traffic under this RTA-TSPEC for the RTA traffic under this LLTS. As some exceptions, the TSID field in the TS information field of the TSPEC element can be set to values from 0 to 7, or from 0 to 15, or from 8 to 15.

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

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

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

[0077] Alternatively, the reliability field can also be set to the value of the packet delivery rate of the RTA traffic under this RTA-TSPEC. After the AP approves the LLTS of the RTA traffic, it should ensure that the packet delivery rate of the RTA traffic does not become lower than the value set in the field. For example, if the AP sets this field to 95%, at least 95 out of 100 RTA frames need to be transmitted successfully. If the AP cannot guarantee this level of packet delivery rate, it can reject the LLTS setting request.

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

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

[0080] The MSDU Lifetime field represents the time that 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 for RTA traffic under this RTA-TSPEC. If the STA receives this field and the Deterministic Service field is set to the first state (e.g., "1"), the MSDU or A-MSDU is discarded if it is not successfully transmitted within this MSDU lifetime. When the Deterministic Service field is set to the second state (e.g., "0"), this field is reserved. Note that this field can be replaced by the delay limit field within the TSPEC element.

[0081] The Deterministic Service field is set by the STA to indicate whether an MSDU of RTA traffic under this RTA-TSPEC is discarded when its expiration time has passed. When the STA sets this field to the first state (e.g., "1"), the MSDU of RTA traffic under this RTA-TSPEC is discarded when its expiration time has passed. Otherwise, the STA sets this field to the second state (e.g., "0"). When the STA receives this field set to the first state (e.g., "1"), the MSDU of RTA traffic under this RTA-TSPEC is discarded when the expiration time indicated in the MSDU Expiration field has passed. When the STA receives this field set to "0", the MSDU Expiration field is tentative.

[0082] Figure 24 shows an example embodiment 210 of any sub-element that carries a higher layer stream ID. The Sub-element ID field includes the type of the sub-element and indicates that it is any sub-element under the LLTS request element in this case. The Length field indicates the length of any sub-element field. The Higher Layer Stream ID field indicates the higher layer stream ID from the higher layer. The STA sets this field in the frame so that the recipient of this field can map the current LLTS to the higher layer traffic flow.

[0083] Figure 25 shows an example embodiment 230 of any sub - element that conveys an LLTS / TID pair link mapping. The Sub - element ID field indicates the type of the sub - element, and in this case, it indicates that it is any sub - element under the LLTS request element. The Length field indicates the length of any sub - element field. The LLTS level link mapping field provides a mechanism for determining the type of link mapping to be used. In at least one embodiment, this field can contain a 1 - bit indication. When this field is set to the first state (e.g., "1"), the LLTS / TID pair link mapping field is for using the 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 the second state (e.g., "0"), the LLTS / TID pair link mapping field is for using the TID - to - link mapping where the TID is the TID of the LLTS indicated in the LLTS descriptor field.

[0084] The LLTS / TID to Link mapping field indicates an LLTS / TID pair link mapping. The STA sets this field to indicate the link through which it can transmit traffic under the LLTS. This field contains the following sub - fields.

[0085] The LLID field includes the identification of the low-latency transmission service. The non-AP STA sets a number representing the LLTS. The AP can receive this number and use it to identify the LLTS set in the non-AP STA. This field can identify the stream classification service (SCS) defined in IEEE 802.11. The Number of Links field is set to indicate the number of Link ID fields within the LLTS / TID pair link mapping field. The Link ID field is set to indicate the link through which the traffic of the LLTS can be transmitted. One or more Link ID fields can be used, and in this example, a plurality (from 1 to n) of Link ID fields are shown. The STA can set this field to suggest which link the traffic under this LLTS should be transmitted through when sending the LLTS / TID pair link mapping in the LLTS request frame.

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

[0087] The Category subfield and the QoS Action subfield indicate the type of the action field and are present within the LLTS response frame in this example. The Dialog token subfield specifies the LLTS response transaction and, in at least one embodiment, can be set to an integer that identifies the LLTS response frame. If the LLTS response frame is a response to an LLTS request frame, this field should be set the same as the LLTS request frame. When the receiving side receives this field, it recognizes that the LLTS response frame is a response to an LLTS request frame having the same dialog token.

[0088] The action field also includes LLTS response elements. The format of the LLTS request elements is as follows. The Element ID field indicates the type of the element and indicates that it is an LLTS response element in this example. The Length field indicates the length of the LLTS response element. The LLTS Status List field includes a series of LLTS status fields. Each LLTS status field is set to indicate the LLTS configuration response of traffic under specific specifications and classification information. When the receiving STA receives this information, it can determine the result of the LLTS configuration of the RTA traffic or a change to an existing LLTS.

[0089] Figure 27 shows an example embodiment 270 of the LLTS state field. The LLID field includes the identification of the low-latency transmission service. The LL Length field includes the length of the LLTS state field. The Response Type field is set to indicate the type of the LLTS setting result. When the AP sets the Response Type field to "Accept", it accepts the LLTS setting request from the non-AP STA. When receiving this field, the non-AP STA can determine whether the LLTS setting was successful. When the AP sets the Response Type field to "Modified", it modifies the existing LLTS with the non-AP STA. When receiving this field, the non-AP STA can determine that the LLTS with the corresponding LLID has been modified by the AP. The non-AP STA can either accept the modification or start another LLTS to negotiate with this AP. When the AP sets the Response Type field to "Denied", it rejects the LLTS setting request from the non-AP STA. When receiving this field, the non-AP STA can start another LLTS setting with the AP. When the AP sets the Response Type to "Terminate", it terminates the existing LLTS with the non-AP STA. When receiving this field, the non-AP STA recognizes that the LLTS of the corresponding LLID has ended and should delete the LLTS. Note that this field can be the same as the Status Code field defined in IEEE802.11.

[0090] The TCLAS field can be the same as the TCLAS element defined in IEEE802.11. The AP sets this field to indicate the information of the traffic from the upper layer. When receiving this field, the non-AP STA can use this information to identify the traffic if the traffic arriving from this upper layer under the TTLS is the uplink traffic. The LLTS state field can include a plurality of TCLAS fields.

[0091] The TCLAS processing field can be the same as the TCLAS processing element defined in IEEE802.11. When there are multiple TCLAS fields in the LLTS state field, the AP sets this field to indicate the rule for identifying RTA traffic using the multiple TCLAS fields. When a non-AP STA receives this field within the LLTS state field, it can determine how to identify traffic from the upper layer using the multiple TCLAS fields.

[0092] The RTA-TSPEC field can be the same as the RTA-TSPEC element defined in Figure 23. The AP sets this field to indicate the specification and QoS requirements of the RTA traffic. When a non-AP STA receives this field, it recognizes that the determination of the LLTS is made for the traffic under the RTA-TSPEC. This field also includes information on 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 the RTA traffic of this LLTS.

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

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

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

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

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

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

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

[0100] If the STA decides not to share the TXOP to transmit a non-RTA frame from a non-primary AC, at block 338, it can transmit frame 340 according to the current TXOP sharing rules defined in IEEE 802.11ax.

[0101] On the other hand, if the STA decides to share its TXOP to transmit an RTA frame from a non-primary AC, it can transmit the RTA frame from the non-primary AC even if there are untransmitted frames from the primary AC (336). Then, at block 340, the STA transmits frames from the non-primary AC (singular or plural) during the TXOP.

[0102] If the station decides to share the TXOP to transmit an RTA frame from a non-primary AC, the following points should be noted. The non-primary AC in block 336 can only represent an AC that has a higher priority than the primary AC. The RTA frame from the non-primary AC in this case can only represent a frame whose expiration date is approaching (for example, this frame will expire before the end of the TXOP).

[0103] The following sequence is possible during the TXOP.

[0104] (1) The STA shall first transmit all / part of the RTA frames from the non-primary AC and then transmit the frames from the primary AC. The STA can follow, for example, any one of the following rules. (a) It is assumed that the RTA frames from the non-primary AC with a higher priority than the primary AC are transmitted first, and then the frames from the primary AC are transmitted immediately thereafter. (b) It is assumed that the RTA frames from the primary AC are transmitted first, then the RTA frames from the non-primary AC with a higher priority than the primary AC are transmitted, and then the non-RTA frames from the primary AC are transmitted. (c) It is assumed that the (re)transmission (single or multiple) of the RTA frames from the non-primary AC with a higher priority than the primary AC is transmitted first, and then the frames from the primary AC are transmitted.

[0105] (2) The STA can transmit the RTA frames from the non-primary AC with a lower priority than the primary AC only in the following cases. (a) When the expiration date of these RTA frames is approaching (for example, this frame will expire before the end of the TXOP), and / or (b) when all the frames from the primary AC have been transmitted, and / or (c) when this low-priority AC has previously shared the TXOP with the primary AC. For example, in the case of (2)(c), it is assumed that this low-priority AC has shared the TXOP with the primary AC during the current periodic time such as the beacon interval. The TXOP sharing time with this low-priority AC shall not be longer than the TXOP time that the low-priority AC has shared with the primary AC during the current periodic time.

[0106] (3) The STA shall handle the RTA frames from the non-primary AC with a higher priority than the primary AC in the same manner as the RTA frames from the primary AC. Furthermore, the STA can also handle the RTA frames from the non-primary AC with a higher priority than the primary AC as the RTA frames from the primary AC.

[0107] (4) When the STA transmits a MU PPDU (e.g., a MU PPDU of MU-MIMO or MU-OFDMA), it can include RTA frames and non-RTA frames from non-primary ACs with high or low priority in the MU PPDU.

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

[0109] (b) For a given user (i.e., the receiving STA of the MU PPDU), RTA frames from non-primary ACs with higher priority than the primary AC shall be / can be transmitted earlier than frames from the primary AC. For example, (i) any RTA frame from the primary AC is transmitted first, then any RTA frame from the high-priority AC is transmitted, and then any non-RTA frame from the primary AC is transmitted. (ii) Any RTA frame from the high-priority AC is transmitted first, and then any frame from the primary AC is transmitted immediately after. (iii) Any frame from the primary AC is transmitted first, and then any frame from the high-priority AC is transmitted immediately after. (iv) Frames with a short expiration period (e.g., MSDU expiration period) can be transmitted first.

[0110] (5) The STA ensures to allocate some channel resources for transmitting frames from the primary AC during the TXOP. For example, the rules during the TXOP are as follows. (a) The STA shall not transmit frames from non-primary ACs until one or more frames from the primary AC are transmitted. (b) The STA shall limit the period of 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 periodic time (e.g., beacon interval) (in units of the length of the TXOP period such as 0.3 ms or the ratio of the TXOP period such as 20%). The AP can set this time limit for the relevant STAs. (c) The STA shall not transmit RTA frames from non-primary ACs until a certain amount of TXOP time (in units of the length of the TXOP period such as 0.3 ms or the ratio of the TXOP period such as 20%) indicated by dedicated time is used for transmitting frames from the primary AC, or until all frames (or all RTA frames) from the primary AC are transmitted. (d) The STA shall not transmit RTA frames from non-primary ACs until a certain amount of frames from the primary AC (e.g., in units of bytes) are transmitted as indicated by dedicated bytes, or until all frames (or all RTA frames) from the primary AC are transmitted. (e) After the start time of the TXOP, the STA shall follow the TXOP sharing rules defined in IEEE 802.11ax for a certain period indicated by dedicated time (in units of the length of the TXOP period such as 0.3 ms or the ratio of the TXOP period such as 20%).

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

[0112] 5.4.2. Example In this section, a plurality of embodiments are shown that explain how a STA shares the TXOP of the primary AC in order to transmit RTA frames from a non-primary AC. The network topologies of these embodiments are shown in FIG. 19. The traffic classification process between RTA and non-RTA can be the same as or similar to the LLTS operation or any other traffic classification procedure described in Section 5.3. As an example, here it is assumed that each STA or MLD in the network topology has a traffic flow of RTA as shown in Table 9. Traffic under LLTS can enter the EDCA queue according to the UP-to-AC mapping shown in Table 1. Note that the UP of traffic under LLTS is shown as UP as shown in Table 9 in the LLTS setting.

[0113] FIG. 30 shows an embodiment example 350 of the state of the EDCA queue of AP1 or MLD1. Frames (MSDU, UP, RTA) are mapped (352) and placed in the queue.

[0114] The AC_VO queue 354 represents the EDCA queue of AC VO exemplified as having three RTA frames under LLTS1, exemplified here as AC_VO(1) to AC_VO(3).

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

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

[0117] The AC_BK queue 360 represents the EDCA queue of AC BK exemplified as being empty with no frames in the queue.

[0118] These queues are connected to competing EDCAFs 362, 364, 366, and 368 seeking channel 370.

[0119] FIG. 31 shows an example embodiment 390 in which AP1 transmits RTA frames from non-primary ACs only during the TXOP. This figure shows the interaction among AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400. The EDCA queue states of AP1 or MLD1 are shown in FIG. 30.

[0120] In this example, it is assumed that AP1 starts an EDCA TXOP and no new frames arrive during the EDCA TXOP. Also, when the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP shown in this example.

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

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

[0123] Figure 32 shows another embodiment example 430 of the EDCA queue state of AP1 or MLD1. The frame is mapped into the illustrated queue (432). As shown, the AC_VO queue 434 represents the EDCA queue of AC VO having one RTA frame under LLTS1 exemplified as AC_VO(1) and one non-RTA frame exemplified as AC_VO(2). The AC_VI queue 436 represents the EDCA queue of AC VI having one RTA frame under LLTS2 exemplified as AC_VI(1) and one non-RTA frame exemplified as AC_VI(2). The AC_BE queue 438 represents the EDCA queue of AC BE having one RTA frame below LLTS3 exemplified as AC_BE(1) and a non-RTA frame exemplified as AC_BE(2). The AC_BK queue 440 represents the EDCA queue of AC BK where no frame exists in the queue. Below each queue, respective EDCA functions 442, 444, 446, and 448 for acquiring channel 450 and transmitting on channel 450 are shown.

[0124] Figure 33 shows an embodiment example 470 in which AP1 transmits an RTA frame from a non-primary AC with higher priority than a frame from the primary AC during a TXOP. This figure shows the interaction among 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. In this example, it is assumed that the queue state is when AP1 starts TXOP 400 and no new frame arrives during the EDCA TXOP. Also, when the queue state belongs to MLD1, it is assumed that MLD1 does not perform transmission on other links during the TXOP shown in this example.

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

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

[0127] FIG. 34 shows Embodiment Example 510 in which during the TXOP, AP1 first transmits an RTA frame from the primary AC, then transmits an RTA frame from a non-primary AC, and then transmits a non-RTA frame from the primary AC. The EDCA queue states of AP1 or MLD1 are as shown in FIG. 32. Assume the queue state when AP1 starts the TXOP400 and assume that no new frames arrive during the EDCA TXOP. Also, when the queue state is that of MLD1, assume that MLD1 does not transmit on other links during the exemplified TXOP.

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

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

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

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

[0132] When AP1 acquires a TXOP of VI, it first transmits an RTA frame from the AC_VI queue exemplified as AC_VI(1)534 to STA1. Next, it transmits an RTA frame from the AC_VO queue exemplified as AC_VO(1)540 to STA2. Next, it transmits an RTA frame from the AC_BE queue exemplified as AC_BE(1)546 to STA3 because an expiration 550 that will occur soon before the end time of the TXOP is about to occur.

[0133] Each of these transmissions is shown together with its respective preambles 532, 538, and 544. The receiving stations respond with block acknowledgment responses (BA) 536, 542, and 548.

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

[0135] FIG. 36 shows Embodiment Example 570 which shows a third example of the EDCA queue state of AP1 or MLD1. The frames are mapped into the illustrated queue (432). The AC_VO queue 574 has one RTA frame AC_VO(1) under LLTS1 and one non-RTA frame AC_VO(2). The AC_VI queue 576 has two RTA frames under LLTS2 and one non-RTA frame AC_VI(3). The AC_BE queue 578 has three non-RTA frames. The AC_BK queue 580 has no frame in the queue.

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

[0137] FIG. 37 shows Embodiment Example 610 in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the period of the MU PPDU is determined by a transmission request of an RTA frame from the non-primary AC. This figure shows the interaction among AP1 392, STA1 394, STA2 396 and STA3 396 during TXOP400.

[0138] The EDCA queue state of AP1 or MLD1 is shown in FIG. 36. In this figure, it is assumed that the queue state is when AP1 starts TXOP400, and it is also assumed that no new frame arrives during the EDCA TXOP. Further, when the queue state belongs to MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP shown in this example.

[0139] When AP1 acquires TXOP400 of VI, it transmits a MU OFDMA PPDU (614) that conveys an RTA frame from the AC_VI exemplified as AC_VI(1) to the queue of STA1, an RTA frame from the AC_VO exemplified as AC_VO(1) to STA2, and a non-RTA frame from the AC_VO queue exemplified as AC_VI(3) to STA3. Note that the period of the MU OFDMA PPDU is determined by the period of the frame AC_VO(1), rather than the periods of the frames AC_VI(1) and AC_VI(3).

[0140] Thereafter, AP1 transmits another MU OFDM PPDU 620 that includes an RTA frame from the AC_VI queue exemplified as AC_VI(2) and non-RTA frames shown as AC_VO(2) and AC_BE(2) in accordance with the TXOP sharing rules of IEEE802.11.

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

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

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

[0144] Note that AP1 can reserve the TXOP by using RTS / CTS or MU-RTS / CTS before transmitting the frame.

[0145] FIG. 38 shows Embodiment Example 630 in which AP1 transmits a MU OFDMA PPDU that conveys an RTA frame from a non-primary AC, and the period of the MU PPDU is determined by the delay requirement of the RTA frame from the primary AC. This figure shows the interaction among AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP400.

[0146] The EDCA queue states of AP1 or MLD1 are shown in FIG. 36. Here, it is assumed that the queue state is when AP1 starts TXOP400, and it is also assumed that no new frames arrive during the EDCA TXOP. Further, when the queue state is that of MLD1, it is assumed that MLD1 does not perform transmission on other links during the illustrated TXOP.

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

[0148] Thereafter, it can be seen that AP1 transmits another MU OFDM PPDU that includes an RTA frame from the AC_VI queue exemplified as AC_VI(2) and non-RTA frames exemplified as AC_VO(2) and AC_BE(2) in accordance with the TXOP sharing rules of IEEE802.11 (644).

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

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

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

[0152] FIG. 39 shows another exemplary embodiment 650 in which AP1 transmits a MU OFDMA PPDU carrying an RTA frame from a non-primary AC, and the period of the MU PPDU is determined by the delay requirement of the RTA frame from the primary AC. This figure shows the interaction among AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0153] The EDCA queue state of AP1 or MLD1 shown in FIG. 36 assumes the queue state when AP1 starts TXOP 400 here, and also assumes that no new frames arrive during the EDCA TXOP. Further, when the queue state belongs to MLD1, it is assumed that MLD1 does not perform transmission on other links during the TXOP shown in this example.

[0154] When AP1 acquires TXOP400 of VI, it transmits a MU OFDMA PPDU (636) that conveys an RTA frame from the AC_VI queue exemplified as AC_VI(1) to STA1, an RTA frame from the AC_VO queue exemplified as AC_VO(1) to STA2, and a non-RTA frame from the AC_VO queue exemplified as AC_VI(3) to STA3. Note that the period 632 of the MU OFDMA PPDU is determined by the period of frame AC_VO(1), but the period of the MU OFDMA PPDU and the expected feedback (e.g., BA) cannot exceed the validity period 652 of frame AC_VI(1) indicated as expiration 652.

[0155] AP1 transmits another MU OFDM PPDU (644) to STA1 that conveys an RTA frame from the AC_VI queue exemplified as AC_VI(2) and non-RTA frames indicated as AC_VO(2) and AC_BE(2) in accordance with the TXOP sharing rules of IEEE802.11.

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

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

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

[0159] FIG. 40 shows an example embodiment 670 in which AP1 transmits a MU OFDMA PPDU that carries an RTA frame from a non-primary AC, and the period of the MU PPDU is determined by the transmission requirement of the RTA frame from the primary AC. This figure shows the interaction among AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP400.

[0160] The EDCA queue state of AP1 or MLD1 shown in FIG. 36 assumes, in this example, the queue state when AP1 starts TXOP400 and also assumes that no new frames arrive during the EDCA TXOP. Further, when the queue state is that of MLD1, it is assumed that MLD1 does not perform transmission on other links during the TXOP.

[0161] When AP1 acquires TXOP400 of VI, it transmits a MU OFDMA PPDU that carries an RTA frame from the AC_VI queue exemplified as AC_VI(1) to STA1, a non-RTA frame to STA2 exemplified as AC_VO(2), and a non-RTA frame from the AC_VO queue exemplified as AC_VI(3) to STA3 (672). Since frame AC_VO(1) is longer than the period of frame AC_VI(1), it is not included in the first MU OFDMA PPDU.

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

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

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

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

[0166] FIG. 41 shows an embodiment example 710 in which AP1 limits the time of TXOP sharing. This figure shows the interaction among AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0167] The EDCA queue state of AP1 or MLD1 shown in FIG. 36 assumes the queue state when AP1 starts TXOP 400 and also assumes that no new frames arrive during the EDCA TXOP. Further, when the queue state is that of MLD1, it is assumed that MLD1 does not perform transmission on other links during TXOP.

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

[0169] Next, AP1 transmits a frame from the AC_VI queue, exemplified as AC_VI(2), to STA1 (718).

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

[0171] FIG. 42 shows an embodiment example 750 in which AP1 shares a TXOP after transmitting a certain number of frames from the primary AC. This figure shows the interaction among AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP 400.

[0172] The EDCA queue state of AP1 or MLD1 shown in FIG. 36 assumes the queue state when AP1 starts TXOP 400 and assumes that no new frames arrive during the EDCA TXOP. Further, when the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP.

[0173] As shown in the figure, before sharing its TXOP for transmission, AP1 needs to transmit a certain amount of frames from the primary AC VI indicated by dedicated_byte after the start of the TXOP. Even if there are untransmitted frames from the primary AC, AP1 can share the TXOP with the RTA frames from non-primary ACs after the total bytes of the frames from the primary AC exceed dedicated_byte.

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

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

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

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

[0178] Before reaching the dedicated_byte of the primary frame, AP1 can share the TXOP according to the rules defined in IEEE802.11.

[0179] FIG. 43 shows an embodiment example 790 in which AP1 shares the TXOP after transmitting frames from the primary AC for a certain period of time. This figure shows the interaction between AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP400.

[0180] The EDCA queue state of AP1 or MLD1 shown in FIG. 36 assumes the queue state when AP1 starts TXOP400 and assumes that no new frames arrive during the EDCA TXOP. Further, when the queue state belongs to MLD1, it is assumed that MLD1 does not transmit on other links during the TXOP.

[0181] As shown in the figure, after the start of the TXOP, there is a dedicated time 792 for the primary AC VI. Even if there are unsent frames from the primary AC, AP1 can share the TXOP after the end of the dedicated time and transmit RTA frames from non-primary ACs.

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

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

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

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

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

[0187] FIG. 44 shows an example embodiment 830 of a frame that carries dedicated time parameter settings. One STA, such as an AP, can transmit a frame including this time parameter setting to another STA, such as a related STA, in order to set the amount of dedicated time given to the other STA. In some cases, the AP can also broadcast such a frame in order to set the dedicated time for all of its related STAs.

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

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

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

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

[0192] The Dedicated Time field is set by the transmitting STA for each AC. The STA that receives this dedicated time information spends the dedicated time for the AC starting from the TXOP start time on transmitting frames from that AC. The receiving STA can then later decide to finally share the TXOP.

[0193] Note that, as described with reference to FIG. 42, the "dedicated time" can also be replaced with "dedicated bytes" within a frame for setting dedicated byte parameters.

[0194] FIG. 45 shows Embodiment Example 850 illustrating a fourth embodiment of the EDCA queue state of AP1 or MLD1. The frame is mapped into the queue as shown (852). The AC_VO queue 854 carries two RTA frames exemplified as AC_VO(1) under LLTS1 and AC_VO(2) under LLTS6. The AC_VI queue 856 holds one RTA frame under LLTS2 exemplified as AC_VI(1) and one non-RTA frame exemplified as AC_VI(2). The AC_BE queue 858 represents the EDCA queue for AC BE and holds three non-RTA frames exemplified as AC_BE(1) to AC_BE(3). The AC_BK queue 860 has no frame in the queue.

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

[0196] FIG. 46 shows Embodiment Example 890 in which AP1 transmits a MU OFDMA PPDU and RTA frames from non-primary ACs for each user are transmitted earlier than frames from the primary AC. This figure shows the interaction among AP1 392, STA1 394, STA2 396, and STA3 396 during TXOP400.

[0197] The EDCA queue state of AP1 or MLD1 shown in FIG. 45 assumes the queue state when AP1 starts TXOP400 and also assumes that no new frame arrives during the EDCA TXOP. Further, when the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the illustrated TXOP.

[0198] When AP1 obtains TXOP400 of VI, it transmits a MU OFDMA PPDU that conveys RTA frames from the AC_VO queues exemplified as AC_VO(1) and AC_VO(2) to STA1 and STA2, and non-RTA frames from the AC_BE queue exemplified as AC_BE(2) to STA3 (892).

[0199] Next, AP1 transmits another MU OFDM PPDU that conveys RTA frames AC_VI(1) and AC_VI(2) and non-RTA frame AC_BE(3) to STA1, STA2, and STA3 respectively (894). For STA1 and STA2, AP1 first transmits RTA frames from a high-priority non-primary AC exemplified as AC VO.

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

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

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

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

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

[0205] The EDCA queue state of AP1 or MLD1 shown in FIG. 45 assumes the queue state when AP1 starts TXOP400 and assumes that no new frames arrive during the EDCA TXOP. Further, when the queue state is that of MLD1, it is assumed that MLD1 does not transmit on other links during the illustrated TXOP.

[0206] When AP1 acquires TXOP400 of VI, it transmits (932) a MU OFDMA PPDU including RTA frames exemplified as AC_VI(1) and AC_VO(1) and non-RTA frames from the AC_BE queue exemplified as AC_BE(2).

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

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

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

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

[0211] 6. General scope of the embodiments In this specification, embodiments of the present technology can be described with reference to methods and systems, and / or procedures, algorithms, steps, operations, mathematical formulas, or other computational representations in the form of flowcharts that can also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and / or steps) of the flowchart, as well as any procedure, algorithm, step, operation, mathematical formula, or computational representation can be implemented by various means such as software including one or more computer program instructions embodied in the form of hardware, firmware, and / or computer-readable program code. As will be understood, such any computer program instructions can be executed by one or more computer processors including, but not limited to, general-purpose computers or special-purpose computers, or any other programmable processing device for producing machines, so that the computer program instructions executed on the computer processor or other programmable processing device can create means for implementing the specified functions (singular or plural).

[0212] Accordingly, the blocks of the flowcharts, as well as the procedures, algorithms, steps, operations, mathematical formulas, or computational expressions described herein, support computer program instructions for performing (single or plural) specific functions, in the form of combinations of means for performing (single or plural) specific functions, combinations of steps for performing (single or plural) specific functions, and computer-readable program code logic means. Also, it will be understood that each block of the flowcharts described herein, as well as any procedure, algorithm, step, operation, mathematical formula, or computational expression, and combinations thereof, can be implemented by a dedicated hardware-based computer system for performing (single or plural) specific functions or steps, or by a combination of dedicated hardware and computer-readable program code.

[0213] Furthermore, these computer program instructions, embodied in the form of computer-readable program code or the like, can be stored in one or more computer-readable memories or memory devices that direct a computer processor or other programmable processing device to function in a specific manner, such that the instructions stored in these computer-readable memories or memory devices produce an article of manufacture that includes instruction means for performing the functions specified within (single or plural) blocks of (single or plural) flowcharts. The computer program instructions can be executed by a computer processor or other programmable processing device to generate a computer-implemented process in which a series of operational steps are executed on the computer processor or other programmable processing device, and the instructions executed on the computer processor or other programmable processing device provide steps for performing the functions specified in (single or plural) blocks, (single or plural) procedures, (single or plural) algorithms, (single or plural) steps, (single or plural) operations, (single or plural) mathematical formulas, or (single or plural) computational expressions of (single or plural) flowcharts.

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

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

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

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

[0218] An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit configured to wirelessly communicate packets that carry frames via a channel with another wireless station (STA) that is either an access point (AP) or a non-AP STA on a wireless local area network (WLAN) where extended distributed channel access (EDCA) is applied to a plurality of access categories (AC), and the STA operates as either an AP wireless station (STA) or a non-AP STA; (b) a processor coupled to the wireless communication circuit and operating as an STA on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; (d) the instructions, when executed by the processor, perform one or more steps including: (d)(i) exchanging a specification of quality of service (QoS) requirements and upper layer information of a traffic flow to set up a traffic stream between a non-AP MLD and an AP ML; (d)(ii) assigning a low latency identifier (LLID) to the traffic stream by the non-AP MLD or the AP MLD to distinguish the traffic stream from another traffic stream having the same traffic identifier (TID); (d)(iii) determining by the non-AP MLD and / or the AP MLD which one or more links the traffic stream should be transmitted through; (d)(iv) distinguishing the traffic belonging to the traffic stream by the non-AP MLD and / or the AP MLD from other traffic.

[0219] A wireless communication method in a network, wherein a device: (a) communicates via a channel with another wireless station (STA) that is either an access point (AP) or a non-AP STA, operating as either an AP or a non-AP wireless station (STA) on a wireless local area network (WLAN) where extended distributed channel access (EDCA) is applied to a plurality of access categories (ACs); (b) differentiates real-time application (RTA) traffic from non-RTA traffic; (c) acquires a transmission opportunity (TXOP) for a primary AC; and (d) transmits RTA frames from non-primary ACs using the remaining portion of the channel resources even if there are untransmitted frames from the primary AC during the TXOP.

[0220] The apparatus or method of any preceding implementation, wherein the instructions further include steps of ensuring, when executed by a processor, that the minimum channel resources necessary to transmit frames from the primary AC during the TXOP are available within the channel resources.

[0221] A STA that secures the minimum channel resources necessary to transmit frames from the primary AC can utilize the minimum channel resources for TXOP sharing when all transmissions of frames from the primary AC are completed, for the apparatus or method of any preceding implementation.

[0222] The apparatus or method of any preceding implementation, wherein the instructions further include steps of ensuring, when executed by a processor, that the STA does not set the minimum channel resources necessary to transmit frames from the primary AC during the TXOP.

[0223] The apparatus or method of any preceding implementation, wherein the instructions further include steps of ensuring, when executed by a processor, that the STA guarantees that a given minimum number of bytes are transmitted from the primary AC during the TXOP.

[0224] The command further includes steps that, when executed by a processor, cause the STA to ensure that the minimum channel time required to transmit frames from the primary AC during a TXOP is provided, for any prior implementation's apparatus or method.

[0225] The command further includes steps that, when executed by a processor, cause the STA to transmit RTA frames from a non-primary AC even if frames from the primary AC are not transmitted during the TXOP, for any prior implementation's apparatus or method.

[0226] The command further includes steps that, when executed by a processor, cause the STA to transmit RTA frames from a non-primary AC during a TXOP only when all RTA frames from the primary AC have been transmitted, for any prior implementation's apparatus or method.

[0227] The command further includes steps that, when executed by a processor, cause the STA to transmit higher-priority RTA frames from a non-primary AC during a TXOP before transmitting RTA frames from the primary AC, for any prior implementation's apparatus or method.

[0228] The command further includes steps that, when executed by a processor, cause the STA to transmit lower-priority RTA frames from a non-primary AC during a TXOP, for any prior implementation's apparatus or method.

[0229] The command further includes steps that, when executed by a processor, cause the STA to transmit MU PPDU packets whose length is determined by the transmission requirements and / or delay requirements of RTA frames from the primary AC, for any prior implementation's apparatus or method.

[0230] The apparatus or method of any preceding implementation, wherein the command, when executed by a processor, further includes steps of causing the STA to limit the time of TXOP sharing.

[0231] The apparatus or method of any preceding implementation, wherein the command, when executed by a processor, further includes steps of causing the STA to be permitted to transmit these RTA frames earlier than frames from the primary AC only when the expiration of RTA frames from a non-primary AC is approaching.

[0232] The apparatus or method of any preceding implementation, wherein the command, when executed by a processor, further includes steps of causing the STA to obtain the TXOP of the primary AC and share the TXOP with a non-primary AC having a lower priority.

[0233] The apparatus or method of any preceding implementation, wherein the command, when executed by a processor, further includes steps of causing the non-AP MLD to transmit a frame including traffic flow specifications, QoS requirements, upper layer information, and LLID to the AP MLD when requesting the AP MLD to configure a traffic stream.

[0234] The apparatus or method of any preceding implementation, wherein the command, when executed by a processor, further includes steps of causing the AP MLD to respond to the non-AP MLD with a frame including traffic flow specifications, QoS requirements, upper layer information, LLID, and status to indicate whether the request for configuring a traffic stream is approved or rejected.

[0235] When executed by a processor, the command further includes steps of performing specification of traffic flow and exchange of QoS requirements by using a traffic specification (TSPEC) element configured such that AP MLD and non-AP MLD include further QoS requirements defined in IEEE802.11ax, for any prior implementation device or method.

[0236] The further QoS requirements include jitter and packet loss requirements, for any prior implementation device or method.

[0237] When executed by a processor, the command further includes steps of performing traffic flow information exchange by having AP MLD and non-AP MLD transmit frames via different links, for any prior implementation device or method.

[0238] When executed by a processor, the command further includes steps of distinguishing one traffic stream from another in response to AP MLD and non-AP MLD communicating a tuple including a non-AP MAC address and LLID, for any prior implementation device or method.

[0239] When executed by a processor, the command further includes steps of having AP MLD transmit uncommitted frames to terminate or modify an existing traffic stream, for any prior implementation device or method.

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

[0241] As used herein, the singular forms "a," "an," and "the" include the plural referents unless the context clearly dictates otherwise. A reference to an item in the singular is not meant to mean "only one" unless explicitly stated to that effect, but rather "one or more than one."

[0242] Expressions such as "A, B, and / or C" in this disclosure represent that any of A, B, or C, or any combination of items A, B, and C, may exist. Expressions indicating that a group of elements listed after "at least one of" follow, when applicable, indicate that at least one of these listed elements exists, including any possible combination of these listed elements.

[0243] References to "an embodiment," "at least one embodiment," or similar phrases in this disclosure indicate that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of this disclosure. Accordingly, these various references to embodiments do not necessarily mean all the same embodiments, or a particular embodiment that is different from all the other embodiments described. The phrase "an embodiment" should be construed to mean that a particular feature, structure, or characteristic of a given embodiment can be combined in any suitable form in one or more embodiments of the disclosed apparatus, system, or method.

[0244] As used herein, the term "set" means a collection of one or more items. Thus, for example, a set of items can include a single item or multiple items.

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

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

[0247] The terms "approximately", "approximate", "substantially", "essentially" and "about" or any variations thereof as used herein are for the description and explanation of minor variations. When used in relation to an event or situation, these terms can mean that the event or situation will definitely occur and when the likelihood of these events or situations occurring is very high. When used in relation to a numerical value, these terms can mean a variation range of ±10% or less, such as ±5% or less, ±4% or less, ±3% or less, ±2% or less, ±1% or less, ±0.5% or less, ±0.1% or less, or ±0.05% or less of that numerical value. For example, "substantially" aligned can mean an angular variation range of ±10° or less, such as ±5° or less, ±4° or less, ±3° or less, ±2° or less, ±1° or less, ±0.5° or less, ±0.1° or less, or ±0.05° or less.

[0248] In addition, in this specification, quantities, ratios, and other numerical values may be presented in a range format. Such a range format is used for convenience and simplicity, and includes the numerical values clearly specified as the limits of the range. However, it should be understood flexibly that all individual numerical values or partial ranges included in this range are also included as if each of these numerical values and partial ranges were clearly indicated. For example, a ratio within the range of about 1 to about 200 includes the clearly listed limit values of about 1 and about 200, but it should also be understood to include individual ratios such as about 2, about 3, about 4, etc., and partial ranges such as about 10 to about 50, about 20 to about 100, etc.

[0249] As used herein, the term "coupled" is defined as "connected", but it is not necessarily a direct mechanical connection. A device or structure "configured" in a particular form is configured at least in that form, but can also be configured in forms not listed.

[0250] Advantages, benefits, problem-solving means, and any (singular or plural) elements that give rise to or make more prominent any advantage, benefit, or solution should not be construed as important, necessary, or essential features or elements of the technology described herein or of some or all of the claims.

[0251] Also, in the above disclosure, for the purpose of rationalizing the disclosure, various features can be grouped together in various embodiments. The method of this disclosure should not be construed as reflecting the intention that the embodiments described in the claims require more features than those explicitly described in each claim. The subject matter of the present invention can be achieved by less than all the features of a single disclosed embodiment.

[0252] The abstract of this disclosure is presented with the understanding that it is not used to interpret or limit the scope or meaning of the claims. Its purpose is to enable the reader to quickly confirm the essence of the technical disclosure.

[0253] Depending on the jurisdiction, it should be understood that there is also a practice of seeking deletion of one or more portions of the present disclosure after filing. Therefore, the reader should refer to the application as filed at the filing date for the original content of the present disclosure. Any deletion of the disclosed content should not be construed as a waiver, forfeiture, or dedication to the public of any subject matter of the application as originally filed.

[0254] The following claims are incorporated into the present disclosure in a stand-alone manner with each claim as a separate inventive subject matter.

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

[0256] Structural and functional equivalents of elements of embodiments of the present disclosure well known to those skilled in the art are also expressly incorporated herein by reference and are intended to be included within the scope of the present claims. Further, elements, components, or method steps of the present disclosure are not intended to be dedicated to the public generally, whether or not they are explicitly recited in the claims. With respect to the elements of the claims herein, they should not be construed as "means-plus-function" elements unless such element is expressly recited using the phrase "means for". Also, with respect to the elements of the claims herein, they should not be construed as "step-plus-function" elements unless such element is expressly recited using the phrase "step for".

Description of Reference Numerals

[0257] 330 Example of Embodiment 332 The STA obtains the TXOP of the AC represented by the primary AC and determines to share the TXOP with the (single or multiple) non-primary ACs. 334 Has the STA determined to share the TXOP to transmit frames from the (single or multiple) non-primary ACs? The 336 STA follows the TXOP sharing rules for non-RTA frames defined by IEEE802.11ax The 338 STA can transmit RTA frames from non-primary ACs regardless of whether there are frames from the primary AC to be transmitted The 340 STA transmits frames from non-primary ACs (single or multiple) during the TXOP Table 1 User Priority-(UP) Mapping TIFF0007679488000001.tif57136 Table 2 Default Parameter Settings TIFF0007679488000002.tif31139 Table 3 MLME-LLTS Request TIFF0007679488000003.tif109165 Table 4 MLME-LLTS.indication TIFF0007679488000004.tif125150 Table 5 MLME-LLTS.response TIFF0007679488000005.tif114150 Table 6 MLME-LLTS.confirm TIFF0007679488000006.tif104159 Table 7 MLME-LLTS-TERM.request TIFF0007679488000007.tif109158 Table 8 MLME-LLTS-TERM.indication TIFF0007679488000008.tif119165 Table 9 LLTS Example TIFF0007679488000009.tif47151

Claims

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

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

2. The apparatus of claim 1.

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

Images