EP4292378A2 - Partage d'une txop d'edca avec un trafic rta - Google Patents

Partage d'une txop d'edca avec un trafic rta

Info

Publication number
EP4292378A2
EP4292378A2 EP22711649.8A EP22711649A EP4292378A2 EP 4292378 A2 EP4292378 A2 EP 4292378A2 EP 22711649 A EP22711649 A EP 22711649A EP 4292378 A2 EP4292378 A2 EP 4292378A2
Authority
EP
European Patent Office
Prior art keywords
rta
frames
primary
txop
sta
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22711649.8A
Other languages
German (de)
English (en)
Inventor
Liangxiao Xin
Mohamed Abouelseoud
Li-Hsiang Sun
Qing Xia
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Group Corp
Sony Corp of America
Original Assignee
Sony Group Corp
Sony Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/509,017 external-priority patent/US20220322460A1/en
Application filed by Sony Group Corp, Sony Corp of America filed Critical Sony Group Corp
Publication of EP4292378A2 publication Critical patent/EP4292378A2/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/08—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
    • H04W74/0808—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using carrier sensing, e.g. as in CSMA
    • H04W74/0816—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using carrier sensing, e.g. as in CSMA carrier sensing with collision avoidance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/04—Scheduled or contention-free access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/08—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
    • H04W74/0866—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a dedicated channel for access
    • H04W74/0875—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using a dedicated channel for access with assigned priorities based access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2475—Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/56—Queue scheduling implementing delay-aware scheduling
    • H04L47/564—Attaching a deadline to packets, e.g. earliest due date first
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the technology of this disclosure pertains generally to wireless network communications using Enhanced Distributed Channel Access (EDCA) which defines multiple Access Categories (ACs), and more particularly to allowing Real-Time Application (RTA) packet transmissions to utilize Transmit Opportunity (TXOP) sharing to reduce latency.
  • EDCA Enhanced Distributed Channel Access
  • ACs Access Categories
  • RTA Real-Time Application
  • TXOP Transmit Opportunity
  • the present disclosure is configured to increase the flexibility of RTA packet transmission in utilizing EDCA Transmit Opportunity (TXOP) sharing in order to reduce latency.
  • TXOP Transmit Opportunity
  • the disclosed protocol provides primary benefits that: (a) STAs are able to share a TXOP of the primary AC to transmit RTA frames when there are frames from the primary AC that have not been transmitted; and (b) considering of fairness (equality, perennialitarianism) between transmitting the frames of the primary AC and transmitting the RTA frames from the non-primary ACs.
  • FIG. 1 is a data field diagram of TSPEC element content defined in IEEE 802.11.
  • FIG. 3 is a data field diagram of a TCLAS element as defined in IEEE 802.11.
  • FIG. 4 is a data field diagram of a TCLAS Processing element defined in IEEE 802.11.
  • FIG. 5 is a data field diagram of an HE multi-user (MU) PPDU format used for downlink multi-user transmission as defined in IEEE 802.11.
  • MU multi-user
  • FIG. 6 is a data field diagram of an HE Trigger-based (TB) PPDU format used for uplink multi-user transmission as defined in IEEE 802.11.
  • FIG. 7 is a data field diagram of a trigger frame (TF) as defined in IEEE 802.11.
  • FIG. 8 is a data field diagram of a Common Information field of the TF as defined in IEEE 802.11.
  • FIG. 9 is a data field diagram of a User information field of the trigger frame (TF) as defined in IEEE 802.11.
  • FIG. 10 is a data field diagram of a Trigger Dependent User Info field in the trigger frame (TF) for MU-BAR as defined in IEEE 802.11.
  • FIG. 12 is a data field diagram of a buffer state request (BSR) frame as defined in IEEE 802.11.
  • BSR buffer state request
  • FIG. 15 is a transmission queue diagram of the reference model for (Enhanced DCF Channel Access) EDCA queues as defined in IEEE 802.11.
  • FIG. 17 is a hardware block diagram of wireless station hardware according to at least one embodiment of the present disclosure.
  • FIG. 20 is a communication diagram of terminating or modifying an LLTS according to at least one example of the present disclosure.
  • FIG. 21 is a data field diagram of an LLTS Request frame according to at least one example of the present disclosure.
  • FIG. 22 is a data field diagram of an LLTS Descriptor field format according to at least one example of the present disclosure.
  • FIG. 24 is a data field diagram of an optional sub-element carrying higher layer stream ID according to at least one example of the present disclosure.
  • FIG. 25 is a data field diagram of an optional sub-element carrying LLTS/TID to Link mapping according to at least one example of the present disclosure.
  • FIG. 26 is a data field diagram of an LLTS Response frame according to at least one example of the present disclosure.
  • FIG. 29 is a flow diagram of TXOP sharing to transmit RTA traffic from non-primary AC works according to at least one example of the present disclosure.
  • FIG. 30 is a transmission queue diagram for an EDCA queue of AP1 or MLD1 according to at least one example of the present disclosure.
  • FIG. 31 is a communication diagram of AP1 transmitting RTA frames from non-primary AC only during the TXOP according to at least one example of the present disclosure.
  • FIG. 32 is a transmission queue diagram of another EDCA queue status of AP1 or MLD1 according to at least one example of the present disclosure.
  • FIG. 33 is a communication diagram of AP1 transmitting RTA frames from a higher priority non-primary AC before the frame from the primary AC during the TXOP according to at least one example of the present disclosure.
  • FIG. 34 is a communication diagram of AP1 transmitting RTA frames from the primary AC first, then the RTA frames from non-primary AC, next the non-RTA frames from the primary AC during the TXOP according to at least one example of the present disclosure.
  • FIG. 35 is a communication diagram of AP1 transmitting RTA frames from a non-primary AC which has lower priority than the primary AC according to at least one example of the present disclosure.
  • FIG. 36 is a transmission queue diagram of a third example of EDCA queue status of AP1 or MLD1 according to at least one example of the present disclosure.
  • FIG. 37 is a communication diagram of AP1 transmitting MU OFDMA PPDU carrying RTA frames from a non-primary AC whereby the duration of MU PPDU is determined by the transmission requirement of RTA frames from a non-primary AC according to at least one example of the present disclosure.
  • FIG. 38 is a communication diagram of AP1 transmitting MU OFDMA PPDU carrying RTA frames from a non-primary AC whereby the duration of MU PPDU is determined by the latency requirements of RTA frames from the primary AC according to at least one example of the present disclosure.
  • FIG. 39 is a communication diagram showing another example of
  • AP1 transmitting MU OFDMA PPDU carrying RTA frames from non-primary AC whereby the duration of MU PPDU is determined by the latency requirement of RTA frames from the primary AC according to at least one example of the present disclosure.
  • FIG. 40 is a communication diagram of AP1 transmitting MU OFDMA PPDU carrying RTA frames from a non-primary AC whereby the duration of MU PPDU is determined by the transmission requirement of the RTA frame from the primary AC according to at least one example of the present disclosure.
  • FIG. 41 is a communication diagram of AP1 limiting the time of
  • TXOP sharing according to at least one example of the present disclosure.
  • FIG. 42 is a communication diagram of AP1 sharing TXOP after transmitting a certain number of frames from the primary AC according to at least one example of the present disclosure.
  • FIG. 43 is a communication diagram of AP1 sharing TXOP after transmitting frames from the primary AC for certain amount of time according to at least one example of the present disclosure.
  • FIG. 44 is a data field diagram of a frame for carrying a dedicated time parameter setting according to at least one example of the present disclosure.
  • FIG. 45 is a transmission queue diagram of a fourth example of
  • EDCA queue status of AP1 or MLD1 according to at least one example of the present disclosure.
  • FIG. 46 is a communication diagram of AP1 transmitting MU OFDMA PPDU whereby for each user, RTA frames from non-primary AC are transmitted earlier than the frames from the primary AC according to at least one example of the present disclosure.
  • FIG. 47 is a communication diagram of TXOP sharing when an AP transmits RTA frame from non-primary AC later than the RTA frame from the primary AC, but earlier than non-RTA frames from the primary AC for each user in MU PPDU according to at least one example of the present disclosure.
  • RTA Real Time Application
  • STA transmitter station
  • non-RTA traffic packetized as non-RTA frames at the transmitter STA, which transmits packets carrying frames to the receiver STA over the channel (link).
  • RTA traffic arrives at an EDCA queue, it will be encapsulated in terms of frames.
  • the frames carrying RTA traffic are denoted by RTA frames and the frames carrying non-RTA traffic are denoted by non-RTA frames.
  • One or more frames can be included in one packet and be transmitted over links or channels.
  • the AC associated with the EDCAF that gains an EDCA TXOP is referred to as the primary AC.
  • the STA can use the TXOP time obtained by a low priority AC to transmit the RTA frames.
  • the task of sharing the TXOP of the primary AC to transmit frames from the non-primary AC is challenging due to the coexistence of RTA traffic and non-RTA traffic.
  • the challenge in this process can be summarized as: (a) distinguishing between RTA traffic and non-RTA traffic, sharing the TXOP of the primary AC to transmit RTA packets from non-primary ACs when there are packets from the primary AC that have not been transmitted.
  • a Service Start Time field contains the start time of the first SP.
  • a Minimum Data Rate field indicates the lowest data rate specified by MAC SAP for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC.
  • a Mean Data Rate field is the average data rate specified by MAC SAP for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC.
  • a Peak Data Rate field is the maximum data rate specified by MAC SAP for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC.
  • a Burst Size field indicates the maximum burst of MSDUs or A-MSDUs belonging to the TS under this TSPEC at the peak data rate.
  • FIG. 2 depicts content in the TS Info field which is defined in IEEE 802.11.
  • a Traffic Type field specifies whether the traffic is periodic or not.
  • FIG. 4 depicts content of the TCLAS Processing element which is defined in IEEE 802.11.
  • An Element ID field indicates the type of the element; which in this case is a TCLAS Processing element.
  • a Length field indicates the length of the TCLAS Processing element.
  • a Processing field indicates the method of classifying the traffic from the upper layer when multiple TCLAS elements exist.
  • IEEE 802.11 ax uses the multi-user transmission packet formats, such as shown in FIG. 5 and FIG. 6, to transmit data in multi-user mode.
  • multi-user transmission packet formats such as shown in FIG. 5 and FIG. 6, to transmit data in multi-user mode.
  • all the users share the same PLCP header of the multi-user transmission packet.
  • each user transmits or receives the data carried by the multi user transmission packet using a separate resource block, including RU allocation, MCS and so forth.
  • FIG. 5 depicts the HE multi-user (MU) PPDU format used for downlink multi-user transmission in IEEE 802.11 ax.
  • the fields are depicted as L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, HE-LTF, Data and PE.
  • FIG. 7 depicts the content of the trigger frame (TF).
  • a Frame Control field indicates the type of frame.
  • a Duration field contains NAV information used for CSMA/CA channel access.
  • An RA field contains an address for the recipient of the frame.
  • a TA field contains the address of the STA that transmitted the frame.
  • a Common Info field includes information for all allocated STAs, which is shown in FIG. 8, below.
  • a User Info field includes information for each STA, which is shown in FIG. 9. The Common Info field and the User Info field provide separate resource block allocation information to each user.
  • the trigger frame as shown in FIG. 7 can be transmitted as a Multi- User Block Ack Request (MU-BAR) by setting the trigger type in the common info field to “2”.
  • MU-BAR Multi- User Block Ack Request
  • the trigger frame is MU-BAR
  • the content of the trigger dependent user info field (as shown in FIG. 9) in the trigger frame is shown in FIG. 10.
  • FIG. 10 depicts a Trigger dependent user info field in trigger frame for MU-BAR, showing subfields BAR Control and BAR Information.
  • FIG. 11 depicts the content of the Block ACK (BA) frame having the following subfields.
  • a Frame Control field indicates the type of the frame.
  • a Duration field contains NAV information used for CSMA/CA channel access.
  • An RA field contains an address for the recipient of the frame.
  • a TA field contains the address of the STA that transmitted the frame.
  • a BA Control field indicates the policy of the Block ACK.
  • a BA info field contains feedback for the transmission.
  • FIG. 12 depicts the contents of the Buffer State Request (BSR) frame having the following fields.
  • a Frame Control field indicates the type of frame.
  • a Duration field contains NAV information used for CSMA/CA channel access.
  • a RA field contains an address for the recipient of the frame.
  • a TA field contains the address of the STA that transmitted the frame.
  • An FIT Control field indicates the BSR control subfield variant.
  • a Format Indication field is used to indicate the format of FIT control field. When the BO and B1 are set to a first state (e.g., “1”), it indicates the FIT control field uses FIE format. There is an A-Control field followed by this field.
  • An A-Control field carries the buffer status report.
  • a Control ID field indicates that the BSR is carried in the control information field.
  • a Control Information field carries the BSR control subfield variant.
  • An ACI Bitmap field indicates access categories for which the buffer status is reported.
  • a Delta TID field indicates the number of TIDs for which the buffer status is reported.
  • An ACI FHigh field indicates the access category which is reported in the Queue Size FHigh field.
  • a Scaling Factor field indicates the unit of the Queue Size FHigh and Queue Size All fields.
  • a Queue Size FHigh field indicates the queue size of the AC indicated in ACI FHigh which is in units of Scaling Factor.
  • a Queue Size All field indicates the queue size of the ACs indicated in ACI Bitmap which is also in units of Scaling Factor.
  • FIG. 13 depicts an example of downlink multi-user transmission using OFDMA.
  • the transmitter AP transmits data to its receivers 1 , 2, 3, and 4 using the FIE MU PPDU format. After finishing the initial transmission, the AP sends a multi-user Block ACK request (MU-BAR) to all the receivers. The receivers then each send a block ACK (BA) back to the AP. According to the content in the BAs, the AP decides to retransmit the packets to receivers 1 , 3, and 4. It contends for the channel and waits the given backoff time. The first retransmission is shown occurring after the AP gains channel access.
  • MU-BAR multi-user Block ACK request
  • BA block ACK
  • FIG. 14A and FIG. 14B depict an example of uplink multi-user transmission using OFDMA.
  • the AP first sends a buffer status report request (BSRP) trigger frame to all the transmitters 1, 2, 3 and 4. Then the transmitters receive the BSRP trigger frame and send their buffer status reports (BSRs) back to the AP. Then, the AP sends a trigger frame to all the transmitters 1 , 2, 3 and 4.
  • the channel resources are allocated in the trigger frame based on the BSRs received from the STAs.
  • the transmitters receive the trigger frame and start the initial transmission using the resource block allocated by the trigger frame.
  • the multi-user transmission packet uses the FIE-TB PPDU format.
  • the AP receives the packet from the transmitters and sends a BA frame to report whether the transmission was correctly received.
  • FIG. 15 illustrates the reference model of the (Enhanced DCF
  • EDCA queues in IEEE 802.11.
  • the system contains six transmit queues and four access categories (ACs).
  • Each AC uses EDCA functions (EDCAFs) to contend for channel access so that it may transmit packets in its corresponding transmit queues.
  • the six transmit queues are depicted as voice (VO), alternate voice (A_VO), alternate video (A_VI), video (VI), best effort (BE), and background (BK).
  • Each transmit queue decides the transmission order of the packets in the queue.
  • Table 1 lists the UP-to-AC mapping used in EDCA queue of IEEE 802.11.
  • the second and third columns represent user priorities of the traffic and their corresponding designations in IEEE 802.1 D.
  • the traffic will be enqueued in the corresponding transmit queue and access category.
  • the priority increases from the top row to the bottom row.
  • the traffic with higher priority has higher probability to be transmitted earlier.
  • FIG. 16 illustrates performing a channel access procedure for EDCA. As shown in the figure, it also compares EDCA channel access when only the Distributed Coordination Function (DCF) is used.
  • DCF Distributed Coordination Function
  • the STA When only DCF is used, the STA is able to immediately access the channel and the medium is free for more than the DCF Interframe Space (DIFS) time. Otherwise, the STA uses CSMA/CA to contend for the channel. After sensing that the channel is idle for DIFS time, it starts to count down backoff as long as the medium is idle. The number of backoff slots is randomly chosen between zero and its contention window. The STA pauses to count down the backoff when CCA busy occurs; for instance when the STA senses channel busy. When the backoff counts down to zero, the STA can commence to transmit packets.
  • DIFS DCF Interframe Space
  • each EDCAF as shown in FIG. 15 is able to immediately access the channel when the medium is free for more than the Arbitration inter-frame spacing (AIFS) time of the AC toward gaining channel access.
  • AIFS Arbitration inter-frame spacing
  • AIFS[i] as shown in the figure represents the AIFS time for AC i, which represents a given AC. Otherwise, each EDCAF uses CSMA/CA to contend for channel access for each AC that is attempting to gain channel access. After sensing that the channel is idle for AIFS time, the STA starts to count down backoff as long as the medium is idle. The number of backoff slots is randomly chosen between zero and its contention window size. The STA pauses to count down the backoff when CCA busy occurs, for instance when the STA senses channel busy. When the backoff counts down to zero, the STA starts to transmit packets for that AC. It should be noted that multiple EDCAFs can contend for the channel in parallel. For example, EDCAFs for AC i and AC j (representing any two ACs) can contend for the channel at the same time as shown in FIG. 16.
  • TXOP contention free time
  • Table 2 lists the default parameter setting for EDCA channel access. Each AC has its own minimum contention window and maximum contention window. AIFSN represents the AIFS duration in terms of the Number of backoff slots. The TXOP limit represents the maximum duration of TXOP that each AC can reserve each time.
  • a STA can share the TXOP to transmit RTA frames from non primary ACs only when all the frames from the primary AC have been transmitted or when the STA transmits MU PPDU.
  • frames from a lower priority non-primary AC are included in MU DL MIMO PPDU (or VFIT MU PPDU) with the TXVECTOR parameter NUMJJSERS greater than one, these frames do not increase the duration of the PPDU beyond that required for the transmissions of the frames of the primary AC and any frames from a high priority AC.
  • STAs are able to share the TXOP of the primary AC to transmit RTA frames when there are frames from the primary AC not being transmitted.
  • the disclosed protocol takes “fairness” (equitable use of the channel) into account between transmitting frames of the primary AC and transmitting the RTA frames from the non-primary ACs.
  • MLD multi-link device
  • FIG. 18 illustrates an example embodiment s of a Multi-Link Device (MLD) hardware configuration.
  • MLD Multi-Link Device
  • Multiple STAs are affiliated with an MLD, with each STA operating on a link of a different frequency.
  • the MLD has external I/O 41 access to applications, this access connects to a MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to allow executing a program(s) that implement communication protocols at the MLD level.
  • the MLD can distribute tasks to, and collect information from, each affiliated station to which it is connected STA 1 42, STA 244 through to STA N 46 and share information between affiliated STAs.
  • each STA of the MLD does not necessarily require its own processor and memory, as the STAs may share resources with one another and/or with the MLD management entity, depending on the specific MLD implementation. It should be appreciated that the above MLD diagram is given by way of example and not limitation, whereas the present disclosure can operate with a wide range of MLD implementations.
  • FIG. 19 illustrates an example embodiment 70 of a topology (network scenario), given by way of example and not limitation.
  • the topology is provided solely to explain the goals of the proposed technology, not to limit it to a specific STA configuration.
  • STAs stations
  • this example topology it is assumed that there are 7 stations (STAs) in an area (e.g., exemplified as a meeting room), 6 of them associated with 3 MLDs 72, 74 and 76.
  • two BSSs are considered as the same BSS since the two APs of the two BSSs are affiliated with the same MLD.
  • all STAs use EDCA for random channel access on all the links.
  • LLTS low latency traffic stream
  • RTA connection-oriented communication between STAs which is referred to herein as an RTA session. It is possible that the STA can have multiple RTA sessions in the network. The STA is able to manage those RTA sessions properly and apply the proper transmission scheme to the RTA packets of an RTA session.
  • a low latency traffic stream can be utilized for identifying RTA traffic of an RTA session from the upper layer.
  • FIG. 20 illustrates an example embodiment 110 of terminating or modifying an LLTS; it will also be appreciated that the process can be utilized for other LLTS operations including changing or removing an LLTS.
  • the interworking model of the STAs can be the same as defined in IEEE 802.11 standard. It is also possible that the originator can be either an AP or non-AP STA, and the recipient can also be either an AP or non-AP STA. To simplify the description, the originator in this example is assumed to be a non-AP STA and the recipient is an AP during the LLTS setup procedure of this section. The figure shows the SME 112 and MLME 114 of the non- AP STA and the MLME 116 and SME 118 of the AP.
  • the non-AP STA or MLD decides to initiate a LLTS setup procedure with the AP or AP MLD.
  • the Station Management Entity (SME) of the non- AP STA or MLD sends a MLME-LLTS. request message 120 (as shown in Table 3) to its MAC Sublayer Management Entity (MLME).
  • SME Station Management Entity
  • MLME MAC Sublayer Management Entity
  • the MLME of the non-AP STA receives the MLME-LLTS. request message, it collects the information in the MLME-LLTS. request message and sends a LLTS request frame 122 to the AP.
  • the MLME of the AP receives the frame and generates a MLME-LLTS. indication message 124 (as shown in Table 4) to its SME or the SME of its affiliated MLD.
  • the SME of the AP processes 126 the LLTS request of the AP MLD and sends an MLME-LLTS.
  • response message 130 (as shown in Table 5) containing LLTS setup result to its MLME.
  • the MLME of the AP sends an LLTS response frame 132 to the non-AP STA.
  • the MLME of the non-AP STA receives the frame and sends an MLME-LLTS. confirm message 134 (as shown in Table 6) to its SME or the SME of its affiliated MLD. Then, from the information contained therein, the non-AP can ascertain (recognize or determine) whether the LLTS setup has been successful or not.
  • the AP or AP MLD can decide to modify or terminate 128 the LLTS with the non-AP STA or MLD.
  • the SME of the AP or the SME of the AP MLD sends a MLME-LLTS-TERM. request message 136 (as shown in Table 7) to the MLME of the AP or the MLME of its affiliated AP.
  • 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 a LLTS response frame 138 to the non-AP STA.
  • the MLME of the non-AP STA receives the frame and generates a MLME-LLTS-TERM. indication message 140 (as shown in Table 8) to its SME. Then, the non-AP then recognizes that the LLTS is terminated or modified.
  • the RTA traffic of an RTA session can be classified by an LLTS setup. During the LLTS setup procedure the TCLAS element and TCLAS Process element are exchanged. The traffic from the upper layer is considered to be RTA traffic of an RTA session if the upper layer information of the traffic matches the information in the RTA-TSPEC element as shown in FIG. 23.
  • the QoS requirements of the traffic for an RTA session are shared between the AP and non-AP STA by exchanging an RTA-TSPEC element during the LLTS setup procedure.
  • the LLTS setup can also be utilized to check whether the AP and non-AP STA have sufficient resources to support RTA traffic transmission.
  • the LLTS request frame and the LLTS response frame for the same LLTS setup procedure can be transmitted over different links.
  • FIG. 21 illustrates an example embodiment 150 of an LLTS Request frame format as utilized herein.
  • a Frame Control field indicates the type of frame.
  • a Duration field contains NAV information used for CSMA/CA channel access.
  • An Address 1 field contains an address for the recipient of the frame.
  • An Address 2 field contains the address of the STA that transmitted the frame.
  • An Address 3 field contains the BSSID.
  • a Sequence control field indicates the sequence number of the frame.
  • An HT control field contains extra control information for the frames.
  • An Action field indicates the action to perform when it is the LLTS Request frame, and has subfields as outlined below.
  • a Category field and QoS Action field indicate the type of action field; in this case the action field indicates this is an LLTS request frame.
  • a Dialog token field specifies the LLTS request transaction; and in at least one embodiment can be set to an integer to identify the LLTS request frame. When the receiver receives this token field, it should respond to the LLTS response frame with the same dialog token.
  • the Action field includes an LLTS Request element, having subfields for Element ID indicating the type of element (present example indicates it is an LLTS Request element); a Length subfield indicates the length of the LLTS Request element; and an LLTS Descriptor List provides a sequence of the LLTS Descriptor fields.
  • Each LLTS Descriptor field is set to indicate an LLTS setup request for the traffic under certain specification and classification information. When that information is received, the receiver STA which recognizes the specification and classification information of the traffic can decides to accept or reject the LLTS setup request.
  • FIG. 22 illustrates an example embodiment 170 of an LLTS
  • An LLID field provides identification of a low latency transmission service; within which the non-AP STA sets a number to represent the LLTS. The AP receives this number and can use it to identify the LLTS which is set by the non-AP STA. In at least one embodiment or mode, it is possible that this field is reserved by the non-AP STA and only the AP sets this field. This field can be a streamed classification service (SCS) ID as defined in IEEE 802.11.
  • SCS streamed classification service
  • An LL Length field contains the length of the LLTS Descriptor field.
  • a Request Type field is set to indicate the type of LLTS descriptor. When the non-AP STA or MLD sets the request type field to “Add”, then the non-AP STA or MLD requests to add a new LLTS. The receiver AP or AP MLD should respond whether adding a new LLTS is accepted or not.
  • the non-AP STA or MLD requests to change an existing LLTS.
  • the AP or AP MLD receives this field, it can find the LLTS using the LLID. Then, the AP or AP MLD either accepts changing the parameters of that LLTS or rejects changing the LLTS.
  • non-AP STA or MLD sets the request type to “Remove”, then the non-AP STA or MLD requests to remove an existing LLTS.
  • the AP or AP MLD receives this field, it can find the LLTS using the LLID and remove the LLTS.
  • a TCLAS field is identical to the TCLAS element defined in IEEE 802.11.
  • the STA or MLD sets this field to indicate the information of the traffic from the upper layer.
  • the STA or MLD can use this information to identify the RTA traffic under this LLTS arriving from the upper layer when the traffic is downlink and the upper layer information of the traffic matches the TCLAS information.
  • the LLTS Descriptor field can contain multiple TCLAS fields.
  • a TCLAS Processing field is identical to the TCLAS Processing element defined in IEEE 802.11.
  • the non-AP STA sets this field to indicate the rule of using multiple TCLAS fields to identify the RTA traffic when there exists multiple TCLAS fields in the LLTS Descriptor field.
  • the AP receives this field in the LLTS Descriptor field, it will recognize that it can use multiple TCLAS fields to identify the traffic from the upper layer.
  • An RTA-TSPEC field is set by the non-AP STA to indicate the specification and the QoS requirement of the RTA traffic under the LLTS.
  • the AP can use the information in this field to decide whether to accept or reject the LLTS request.
  • This field also contains the information of the traffic direction under this LLTS (e.g., uplink, downlink, peer to peer, or bidirectional).
  • the AP can also indicate the channel resource that can be allocated for transmission of the RTA traffic under that LLTS.
  • FIG. 23 illustrates an example embodiment 190 of RTA-TSPEC field contents.
  • a TSPEC field can be identical to the TSPEC element defined in IEEE 802.11.
  • a STA sets this field to indicate the TSID, the traffic characteristics, and the partial QoS requirement of the RTA traffic under the LLTS for the RTA traffic under this RTA-TSPEC.
  • Some exceptions can be that the TSID field in the TS Info field of the TSPEC element can be set to a value between 0 to 7, or 0 to 15, or 8 to 15.
  • a RTA Attributes field indicates the additional QoS requirement for RTA traffic under this RTA-TSPEC. It is possible that this field only appears with or in the TSPEC element when LLTS is implemented on both STA and AP.
  • a Jitter field is set by the STA to indicate jitter requirements of the RTA traffic under this RTA-TSPEC.
  • the AP receives this field, it estimates the resource distribution for the transmission of the RTA traffic under this RTA-TSPEC to ensure that the jitter requirement of the RTA traffic under this RTA-TSPEC can be satisfied.
  • a Deterministic Service field is set by the STA to indicate whether the MSDU of the RTA traffic under this RTA-TSPEC will be dropped when its lifetime expires. If the STA sets this field to a first state (e.g., “1”), then the MSDU of the RTA traffic under this RTA-TSPEC will be dropped when its lifetime expires. Otherwise the STA sets this field to a second state (e.g., “0”). When the STA receives this field which is set to a first state (e.g., “1”), then the MSDU of the RTA traffic under this RTA-TSPEC will be dropped when its lifetime, as indicated in the MSDU lifetime field, expires. When the STA receives this field which is set to “0”, the MSDU lifetime field is reserved.
  • a Category subfield and QoS Action subfield indicate the type of action field, which in this case is in the LLTS Response frame.
  • a Dialog token subfield specifies the LLTS response transaction, and in at least one embodiment can be set to an integer to identify the LLTS response frame.
  • An LLID field contains an identification of a low latency transmission service.
  • An LL Length field contains the length of the LLTS Status field.
  • a Response Type field is set to indicate the type of LLTS setup result. When the AP sets the response type field to “Accept”, then the AP accepts the LLTS setup request from the non-AP STA. The non-AP STA upon receiving this field can determine if the LLTS setup was successful. When the AP sets the response type field to “Modified”, then the AP modifies an existing LLTS with non-AP STA. Upon receiving this field the non-AP STA can determine the LLTS with the corresponding LLID has been modified by the AP.
  • the non-AP STA can accept the modification or launch another LLTS to negotiate that AP.
  • the AP sets the response type field to “Denied”, then the AP rejects the LLTS setup request from the non-AP STA.
  • the non-AP STA receives this field, it may be able to initiate another LLTS setup with AP.
  • the AP sets the response type to “Terminate”, then the AP terminates an existing LLTS with the non-AP STA.
  • the non-AP STA Upon receiving this field the non-AP STA will recognize that the LLTS with the corresponding LLID is terminated and that the LLTS should be removed. It should be noted that this field may be identical to the Status Code field as defined in IEEE 802.11.
  • a TCLAS field can be identical to the TCLAS element defined in
  • the AP sets this field to indicate the information of the traffic from the upper layer.
  • the non-AP STA receives this field, it can use this information to identify the traffic under this TTLS arriving from the upper layer when the traffic is uplink.
  • the LLTS Status field may contain multiple TCLAS fields.
  • a TCLAS Processing field can be identical to TCLAS Processing element defined in IEEE 802.11. The AP sets this field to indicate the rule of using multiple TCLAS fields to identify the RTA traffic when there exists multiple TCLAS fields in the LLTS Status field. When the non-AP STA receives this field in the LLTS Status field, it can determine how to use multiple TCLAS fields to identify the traffic from the upper layer.
  • a RTA-TSPEC field can be identical to RTA-TSPEC element defined in FIG. 23. The AP sets this field to indicate the specification and QoS requirement of the RTA traffic. When the non-AP STA receives this field, it recognizes the decision of the LLTS is made for the traffic under the RTA- TSPEC. This field also contains the information of the RTA traffic direction under this LLTS (e.g., uplink, downlink, peer to peer, or bidirectional). The AP can also indicate the channel resource that can be allocated for transmission of the RTA traffic of that LLTS.
  • An Optional Sub-elements field is set by the AP to indicate additional information or setting of the traffic under this LLTS. Some examples of optional sub-elements were given in FIG. 24 and FIG. 25.
  • Table 9 gives an example of LLTSs (e.g., LLTS1 through LLTS6).
  • the originator column represents the STA or MLD which launches the LLTS setup procedure, i.e., transmits the LLTS request frame.
  • the recipient column represents the STA or MLD which receives the LLTS request frame and transmits LLTS response frame.
  • the second row in the table represents a LLTS, for example LLTS1 , with LLID equal to one.
  • the originator of that LLTS is STA2 and the recipient can be AP1 or MLD1.
  • the direction column is in regard to the direction of the LLTS.
  • FIG. 29 illustrates an example embodiment 330 of TXOP sharing to transmit RTA traffic from a non-primary AC.
  • RTA traffic arrives at an EDCA queue, it will be encapsulated in terms of frames.
  • the frames carrying RTA traffic are denoted by RTA frames and the frames carrying non-RTA traffic are denoted by non-RTA frames.
  • One or more frames can be included in one packet and be transmitted over links or channels.
  • the AC associated with the EDCAF that gains a TXOP is referred to as the primary AC.
  • a decision 334 is made on whether or not to share the TXOP to transmit frames from non primary ACs during the TXOP.
  • the STA decides not to share the TXOP to transmit non-RTA frames from non-primary ACs, then at block 338 it can follow the current TXOP sharing rules as defined in IEEE 802.11 ax, before it transmits frames 340.
  • the STA decides to share its TXOP to transmit RTA frames from non-primary ACs, it can transmit 336 RTA frames from non primary ACs even if there are frames from the primary AC that have not been transmitted. Then at block 340 the STA transmits frames from non primary AC(s) during the TXOP.
  • the station decides to share its TXOP to transmit RTA frames from non-primary ACs.
  • the non-primary ACs in block 336 may only represent those ACs which have higher priority than the primary AC.
  • RTA frames from non-primary ACs in this case may only represent those frames that are expiring (for example, this frame will be expired before the end of the TXOP).
  • the STA shall/may transmit all/some RTA frames from the non primary ACs first, and then the frames from the primary ACs.
  • the STA for example may follow any one of the following rules (a) The RTA frames from the non-primary AC which has higher priority than the primary AC shall/may be transmitted first, then the frames from the primary AC immediately next (b) The RTA frames from the primary AC shall/may be transmitted first, then the RTA frames from the non-primary AC which has higher priority than the primary AC, and next the non-RTA frames from the primary AC. (c) The RTA frame(s) from the non-primary AC which are retransmission(s) and has higher priority than the primary AC shall/may be transmitted first, then the frames from the primary AC immediately next.
  • the STA may transmit RTA frames from the non-primary ACs which have lower priority than the primary AC only as per the following (a) Those RTA frames are expiring (for example, this frame will be expired before the end of the TXOP), and/or (b) all the frames from the primary AC have been transmitted, and/or (c) that low priority AC shared its TXOP with the primary AC before. For example, in case (2)(c) that low priority AC shared its TXOP with the primary AC in the current periodic time, such as the beacon interval. It is possible that the TXOP sharing time with that low priority AC shall not be longer than the TXOP time that the low priority AC shared with the primary AC during the current periodic time.
  • the STA treats the RTA frames from the non-primary ACs, which has higher priority than the primary AC, as they were from the primary AC. Furthermore, it is possible that the STA treats the RTA frames from the non-primary ACs, which has higher priority than the primary AC, as they were RTA frames from the primary AC.
  • the duration of the MU PPDU may be determined by the transmission and latency requirement of certain frames in the MU PPDU. When other frames are included in the MU PPDU, they shall not increase the duration of the MU PPDU beyond that requirement.
  • the certain frames can be as follows: (i) frames or RTA frames only from the primary AC, and/or (ii) RTA frames from all non-primary ACs, or from non primary ACs which have higher priority than the primary AC, or from a non primary AC which has the highest priority in the MU PPDU.
  • RTA frames from a non-primary AC which have higher priority than the primary AC shall/may be transmitted earlier than frames from the primary AC.
  • any RTA frames from the primary AC shall/may be transmitted first, then any RTA frames from a higher priority AC, next any non-RTA frames from the primary AC.
  • Any RTA frames from a higher priority AC shall/may be transmitted first, then any frames from the primary AC immediately next (iii) Any frames from the primary AC shall/may be transmitted first, and then any frames from a higher priority AC immediately next (iv) Any frames with shorter expiration time (e.g., expiration time of MSDU lifetime) shall/may be transmitted first.
  • the STA guarantees allocating some channel resource to transmit frames from the primary AC during the TXOP. For example, during the TXOP, as follows (a) The STA shall not transmit frames from non-primary ACs until one or more frames from the primary AC have been transmitted. (b) The STA shall limit the duration of TXOP sharing to transmit RTA frames from non-primary ACs. For example, the STA limits the time (in terms of length, e.g., 0.3ms, or ratio, e.g., 20% of TXOP duration) of TXOP sharing per TXOP or per periodic time (e.g., beacon interval). It is possible that the AP sets this time limit on its associated STAs.
  • the STA shall not transmit RTA frames from non-primary ACs until a certain amount of TXOP time, denoted by dedicated time (in terms of length, e.g., 0.3ms, or ratio, e.g., 20% of TXOP duration), has been used for transmitting frames from the primary AC or all the frames (or all the RTA frames) from the primary AC have been transmitted (d)
  • the STA shall not transmit RTA frames from non-primary ACs until a certain amount of frames from the primary AC, such as for example denoted by a dedicated byte (e.g., in terms of bytes), have been transmitted or all the frames (or all the RTA frames) from the primary AC have been transmitted
  • the STA shall follow the TXOP sharing rule as defined in IEEE 802.11 ax for a certain period of time, denoted by a dedicated time (in terms of length, e.g., 0.3 ms, or ratio, e.g., 20% of TXOP duration), since the start time
  • the STA treats the RTA frames from the non-primary ACs as if they were from the primary AC, during a special period of channel time, such as R-TWT SPs as defined in IEEE 802.11 be.
  • FIG. 30 illustrates an example embodiment 350 of status for an STA.
  • An AC_VO queue 354 represents the EDCA queue of AC VO, which is exemplified here with three RTA frames under LLTS1 , exemplified as AC_VO(1 ) through AC_VO(3).
  • An AC_VI queue 356 represents the EDCA queue of AC VI, which is shown as having two RTA frames under LLTS2, exemplified as AC_VI(1 ) and AC_VI(2), and one non-RTA frame exemplified as AC_VI(3).
  • An AC_BE queue 358 represents the EDCA queue of AC BE, which is shown with three non-RTA frames exemplified as AC_BE(1 ) through AC_BE(3).
  • the queues are shown connecting to the EDCAFs 362, 364, 366 and 368 which contend for channel 370.
  • FIG. 31 illustrates an example embodiment 390 of AP1 transmitting RTA frames from non-primary AC only during the TXOP.
  • the figure depicts interaction between AP1 392, STA1 394, STA2396 and STA3396 during TXOP 400.
  • the EDCA queue status of AP1 or MLD1 is shown in FIG. 30.
  • FIG. 32 illustrates an example embodiment 430 of another EDCA queue status of AP1 or MLD1. Frames are mapped 432 into the queues shown.
  • the AC_VO queue 434 represents the EDCA queue of AC VO, which has one RTA frame under LLTS1 exemplified as AC_VO(1), and one non-RTA frame exemplified as AC_VO(2).
  • the AC_VI queue 436 represents the EDCA queue of AC VI, which has one RTA frame under LLTS2 exemplified as AC_VI(1 ) and one non-RTA frame exemplified as AC_VI(2).
  • the AC_BE queue 438 represents the EDCA queue of AC BE, which has one RTA frame under LLTS3 exemplified as AC_BE(1) and one non-RTA frame exemplified as AC_BE(2).
  • the AC_BK queue 440 represents the EDCA queue of AC BK, which has no frames in the queue.
  • API When API obtains TXOP 400 of VI, it first transmits RTA frames, exemplified as AC_VO(1 ) 474 from the AC_VO queue to STA2. Then, it transmits the RTA frame exemplified as AC_VI(1 ) 480 from the AC_VI queue to STA1 , and then non-RTA frame exemplified as AC_VI(2) 486 from AC_VI queue to STA3. Each of these transmissions is shown with respective preambles 472, 478 and 484. The receiving stations are shown responding with a Block Acknowledgement (BA) 476, 482 and 488.
  • BA Block Acknowledgement
  • FIG. 35 illustrates an example embodiment 530 of AP1 transmitting RTA frames from a non-primary AC which has lower priority than the primary AC.
  • the figure depicts interaction between AP1 392, STA1 394, STA2 396 and STA3396 during TXOP 400.
  • the EDCA queue status of AP1 or MLD1 is shown in FIG. 32; which is assumed here to be the queue status when AP1 starts TXOP 400 and it is also assumed that there are no new frames arriving during the TXOP. If the queue status is of MLD1 , then it is further assumed that MLD1 does not transmit on any other link during the TXOP shown in the example.
  • AP1 When AP1 obtains a TXOP of VI, it first transmits RTA frame exemplified as AC_VI(1 ) 534 from the AC_VI queue to STA1. Then, it transmits RTA frames exemplified as AC_VO(1 ) 540 from the AC_VO queue to STA2. Next, it transmits the RTA frame exemplified as AC_BE(1 ) 546 from AC_BE queue to STA3 since that RTA frame will soon expire 550, which will occur before the end time the TXOP.
  • the AP1 it should be noted that it is possible for the AP1 to utilize RTS/CTS or MU-RTS/CTS to reserve the TXOP before transmitting frames.
  • the respective EDCA functions 582, 584, 586, and 588 are shown beneath each queue, and configured for obtaining and transmitting on Channel 590.
  • AP1 When AP1 obtains a TXOP 400 of VI, it transmits 614 a MU OFDMA PPDU carrying RTA frame, exemplified as AC_VI(1) from AC_VI to STA1 queue, an RTA frame exemplified as AC_VO(1 ) from AC_VO to STA2, and a non-RTA frame exemplified as AC_VI(3) from AC_VO queue to STA3.
  • RTA frame exemplified as AC_VI(1) from AC_VI to STA1 queue
  • an RTA frame exemplified as AC_VO(1 ) from AC_VO to STA2
  • a non-RTA frame exemplified as AC_VI(3) from AC_VO queue to STA3.
  • the duration of the MU OFDMA PPDU is decided by the duration of frame AC_VO(1 ) instead of the duration of frames AC_VI(1 ) and AC_VI(3).
  • AP1 transmits 620 another MU OFDM PPDU carrying RTA frames exemplified as AC_VI(2) from the AC_VI queue and non-RTA frames shown as AC_VO(2) and AC_BE(2), which could follow the TXOP sharing rule of IEEE 802.11.
  • AP1 it should be noted that it is possible for AP1 to utilize RTS/CTS or MU-RTS/CTS to reserve the TXOP before transmitting frames.
  • AP1 transmitting 644 another MU OFDM PPDU carrying RTA frames exemplified as AC_VI(2) from the AC_VI queue and non-RTA frames exemplified as AC_VO(2) and AC_BE(2), which could follow the TXOP sharing rule of IEEE 802.11.
  • the MU OFDMA PPDU as shown in the example can be replaced by MU MIMO PPDU; wherein each frame in the MU PPDU would then be transmitted through different spatial streams instead of different RUs.
  • the solicited feedback, such as ACK or BA, of the MU PPDU would also be changed to the feedback for MU MIMO PPDU.
  • the transmissions 636 and 644 are shown with respective preambles 634 and 642. Each of the receiving stations is shown responding to receipt of these transmissions with a Block Acknowledgement (BA) 640.
  • BA Block Acknowledgement
  • FIG. 39 illustrates another example embodiment 650 of AP1 transmitting MU OFDMA PPDU carrying RTA frames from a non-primary AC whereby the maximum duration of MU PPDU 632 is determined by the latency requirement of RTA frames from the primary AC.
  • the figure depicts interaction between AP1 392, STA1 394, STA2396 and STA3396 during TXOP 400.
  • the EDCA queue status of AP1 or MLD1 shown in FIG. 36 is assumed here as the queue status when AP1 starts TXOP 400 and it is also assumed that there are no new frames arriving during the TXOP. If the queue status is for MLD1 , then it is further assumed that MLD1 does not transmit on any other link during the TXOP shown in the example .
  • AP1 When AP1 obtains TXOP 400 of VI, it transmits 636 a MU OFDMA PPDU carrying RTA frame exemplified as AC_VI(1 ) from the AC_VI queue to STA1 , an RTA frame exemplified as AC_VO(1 ) from the AC_VO queue to STA2, and a non-RTA frame exemplified as AC_VI(3) from the AC_VO queue to STA3.
  • the duration of the MU OFDMA PPDU 632 is decided by the duration of frame AC_VO(1) but the duration of the MU OFDMA PPDU and the expected feedback (e.g., BA) cannot exceed the expiration time 652 of frame AC_VI(1), shown expiring 652.
  • AP1 transmits 644 another MU OFDM PPDU carrying RTA frames exemplified as AC_VI(2) from the AC_VI queue to STA1 and non-RTA frames shown as AC_VO(2) and AC_BE(2), which can follow the TXOP sharing rule of IEEE 802.11.
  • the MU OFDMA PPDU as shown in the example can be replaced by an MU MIMO PPDU; in which case each frame in the MU PPDU is transmitted through different spatial streams instead of through different RUs.
  • the solicited feedback such as ACK or BA of the MU PPDU, would also be changed to the feedback used for MU MIMO PPDU.
  • the transmissions 636 and 644 are shown with respective preambles 634 and 642. Each of the receiving stations is shown responding to receipt of these transmissions with a Block Acknowledgement (BA) 640.
  • BA Block Acknowledgement
  • FIG. 40 illustrates an example embodiment 670 of AP1 transmitting MU OFDMA PPDU carrying RTA frames from a non-primary AC whereby the duration of MU PPDU is determined by the transmission requirement of the RTA frame from the primary AC.
  • the figure depicts interaction between AP1 392, STA1 394, STA2396 and STA3396 during TXOP 400.
  • the EDCA queue status of AP1 or MLD1 as shown in FIG. 36 is assumed in this example as the queue status when AP1 starts TXOP 400 and it is also assumed there are no new frames arriving during the TXOP.
  • AP1 When AP1 obtains a TXOP 400 of VI, it transmits 672 a MU OFDMA PPDU carrying RTA frame exemplified as AC_VI(1 ) to STA1 , from AC_VI queue, non-RTA frame exemplified as AC_VO(2) to STA2, and non-RTA frame exemplified as AC_VI(3) to STA3, from AC_VO queue.
  • Frame AC_VO(1) is not included in the first MU OFDMA PPDU because its duration is longer than the that of frame AC_VI(1 ).
  • AP1 transmits 674 another MU OFDM PPDU carrying RTA frames AC_VI(2), RTA frame AC_VO(1 ), and non-RTA frame AC_BE(2).
  • the duration of frame AC_VO is shorter than that of frame AC_VI(2).
  • the MU OFDMA PPDU as shown in the example can be replaced by MU MIMO PPDU; in which case each frame in the MU PPDU will be transmitted through different spatial stream instead of different RUs.
  • the solicited feedback, such as ACK or BA, of the MU PPDU would also be changed to the requires feedback for MU MIMO PPDU.
  • the transmissions 672 and 674 are shown with respective preambles 634 and 642. Each of the receiving stations is shown responding to receipt of these transmissions with a Block Acknowledgement (BA) 640.
  • BA Block Acknowledgement
  • the AP1 can utilize RTS/CTS or MU-RTS/CTS to reserve the TXOP before transmitting frames.
  • the EDCA queue status of AP1 or MLD1 as shown in FIG. 36 is assumed to be the queue status when AP1 starts TXOP 400 and it is also assumed that there are no new frames arriving during the TXOP. If the queue status is for MLD1 , then it is further assumed that MLD1 does not transmit on any other link during the TXOP.
  • AP1 When AP1 obtains TXOP 400 of VI, it first transmits 712 an RTA frame exemplified as AC_VI(1 ) from the AC_VI queue to STA1. Then AP1 transmits RTA frames exemplified as AC_VO(1) 716 from the AC_VO queue to STA2. After AP1 finishes transmitting frame AC_VO, it has utilized the maximum TXOP sharing time 714 during the current TXOP.
  • AP1 transmits 718 the frame exemplified as AC_VI(2) from the AC_VI queue to STA1.
  • FIG. 42 illustrates an example embodiment 750 of AP1 sharing TXOP after transmitting a certain number of frames from the primary AC.
  • the figure depicts interaction between AP1 392, STA1 394, STA2396 and STA3 396 during TXOP 400.
  • the EDCA queue status of AP1 or MLD1 as shown in FIG. 36 is assumed to be the queue status when AP1 starts TXOP 400 and it is also assumed there are no new frames arriving during the TXOP. If the queue status is for MLD1 , then it is further assumed that MLD1 does not transmit on any other link during the TXOP.
  • AP1 has to transmit a certain amount, denoted 752 by dedicated_byte, of frames from the primary AC VI since the start of the TXOP before sharing its TXOP to transmit.
  • AP1 is allowed to share TXOP with RTA frames from the non-primary ACs after the total bytes of the frames from the primary AC exceed the dedicated_byte even if there are frames from the primary AC not been transmitted.
  • AP1 When AP1 obtains a TXOP 400 of VI, it first transmits 754 and 756 RTA frames exemplified as AC_VI(1 ) and AC_VI(2) from the AC_VI queue to STA1. Then, AP1 spends more than the dedicated time on transmitting frames from the primary AC VI during the TXOP. It then shares the TXOP to transmit 758 RTA frames exemplified as AC_VO(1 ), from the AC_VO queue.
  • AP1 can send a frame carrying the information as shown in FIG. 44 to set the dedicated time of each STA.
  • AP1 may share the TXOP following the rules defined in IEEE 802.11.
  • FIG. 43 illustrates an example embodiment 790 of AP1 sharing
  • TXOP after transmitting frames from the primary AC for a certain amount of time.
  • the figure depicts interaction between AP1 392, STA1 394, STA2 396 and STA3396 during TXOP 400.
  • the transmissions 794, 796 and 798 are shown with respective preambles 632.
  • Each of the receiving stations is shown responding to receipt of these transmissions with a Block Acknowledgement (BA) 640.
  • BA Block Acknowledgement
  • FIG. 44 illustrates an example embodiment 830 of a frame for carrying a dedicated time parameter setting.
  • One STA such as the AP, can send a frame containing this time parameter settings to another STA, such as an associated STA, to set the amount of dedicated time given for that STA.
  • the AP may broadcast such a frame to set a dedicated time of all of its associated STAs.
  • the dedicated time parameters contain the following fields.
  • a Frame Control field indicates the type of frame.
  • a Duration field contains NAV information used for CSMA/CA channel access.
  • An Address 1 field contains an address for the recipient of the frame.
  • An Address 2 field contains the address of the STA that transmitted the frame.
  • An Address 3 field contains the BSSID.
  • a Sequence control field indicates the sequence number of the frame.
  • An FIT control field indicates the extra control information for the frames.
  • a Dedicated Time Set field is set by the STA to the amount of dedicated time of each AC for the receiver STA.
  • the receiver STA can use the parameters in this field for TXOP sharing.
  • An Element ID field identifies the type of element; which is in this case is a Dedicate Time set element.
  • a Length field indicates the length of the Dedicate Time set element.
  • An Enable Dedicated Time field is set to indicate whether there is dedicated time during each TXOP. If this field is set to a first state (e.g., true), then there is dedicated time during each TXOP, as marked for example from the beginning of the TXOP. During the dedicated time, only the traffic from the primary AC can be transmitted.
  • a Dedicated time field is set by the transmitting STA for each AC.
  • the STA receiving this dedicated time information spends the dedicated time for an AC, commencing at the start time of the TXOP of that AC, on transmitting frames from that AC. Only after that, can the receiver STA decide to share the TXOP.
  • the AC_BE queue 858 represents the EDCA queue of AC BE, which is depicted as holding three non-RTA frames exemplified as AC_BE(1 ) through AC_BE(3).
  • the AC_BK queue 860 is depicted without any frames in its queue.
  • FIG. 46 illustrates an example embodiment 890 of AP1 transmitting MU OFDMA PPDU whereby for each user, RTA frames from a non-primary AC are transmitted earlier than the frames from the primary AC.
  • the figure depicts interaction between AP1 392, STA1 394, STA2396 and STA3396 during TXOP 400.
  • the EDCA queue status of AP1 or MLD1 as shown in FIG. 45 is assumed to be the queue status when AP1 starts this TXOP 400 and it is also assumed there are no new frames arriving during the TXOP. If the queue status is for MLD1 , then it is further assumed that MLD1 does not transmit on any other link during the TXOP shown. [00266] When AP1 obtains a TXOP 400 of VI, it transmits 892 a MU OFDMA PPDU carrying RTA frames exemplified as AC_VO(1 ) and AC_VO(2) from the AC_VO queue to STA1 and STA2 and a non-RTA frame exemplified as AC_BE(2) from AC_BE queue to STA3.
  • AP1 transmits 894 another MU OFDM PPDU carrying RTA frames AC_VI(1 ) and AC_VI(2) and non-RTA frame AC_BE(3) to STA1 , STA2 and STA3, respectively.
  • AP1 first transmits the RTA frames from the higher priority non-primary AC exemplified as AC VO.
  • the transmissions 892 and 894 are shown with respective preambles 632.
  • Each of the receiving stations is shown responding to receipt of these transmissions with a Block Acknowledgement (BA) 640.
  • BA Block Acknowledgement
  • FIG. 47 illustrates an example embodiment 930 of TXOP sharing when the AP transmits an RTA frame from non-primary AC later than an RTA frame from the primary AC, but earlier than non-RTA frames from the primary AC for each user in MU PPDU.
  • the figure depicts interaction between AP1 392, STA1 394, STA2396 and STA3396 during TXOP 400.
  • AP1 transmits 934 another MU OFDM PPDU carrying RTA frames AC_VO(2) and AC_VI(2), and a non-RTA frame AC_BE(3).
  • AP1 transmits the RTA frames from the primary AC exemplified as AC VI, first, then the RTA frames from the higher priority non-primary AC, exemplified as AC_VO.
  • AP1 transmits the RTA frames from the higher priority non-primary AC, such as AC_VO, first, then the non-RTA frames from the primary AC, such as AC_VI.
  • the transmissions 932 and 934 are shown with respective preambles 632.
  • Each of the receiving stations is shown responding to receipt of these transmissions with a Block Acknowledgement (BA) 640.
  • BA Block Acknowledgement
  • any such computer program instructions may be executed by one or more computer processors, including without limitation a general purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer processor(s) or other programmable processing apparatus create means for implementing the function(s) specified.
  • blocks of the flowcharts, and procedures, algorithms, steps, operations, formulae, or computational depictions described herein support combinations of means for performing the specified function(s), combinations of steps for performing the specified function(s), and computer program instructions, such as embodied in computer-readable program code logic means, for performing the specified function(s).
  • each block of the flowchart illustrations, as well as any procedures, algorithms, steps, operations, formulae, or computational depictions and combinations thereof described herein can be implemented by special purpose hardware-based computer systems which perform the specified function(s) or step(s), or combinations of special purpose hardware and computer-readable program code.
  • these computer program instructions may also be stored in one or more computer-readable memory or memory devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s).
  • the computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer-implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the block(s) of the flowchart(s), procedure (s) algorithm(s), step(s), operation(s), formula(e), or computational depiction(s).
  • program executable refer to one or more instructions that can be executed by one or more computer processors to perform one or more functions as described herein.
  • the instructions can be embodied in software, in firmware, or in a combination of software and firmware.
  • the instructions can be stored local to the device in non-transitory media, or can be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely. Instructions stored remotely can be downloaded (pushed) to the device by user initiation, or automatically based on one or more factors.
  • processor hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to denote a device capable of executing the instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single core and multicore devices, and variations thereof.
  • An apparatus for wireless communication in a network comprising: (a) a wireless communication circuit, as a wireless station (STA) operating as either an access point (AP) or a non-AP STA, is configured for wirelessly communicating packets which carry frames over a channel with other wireless stations (STAs), which are either APs or non- AP STAs, on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is applied to more than one Access Category (AC); (b) a processor coupled to said wireless communication circuit for operating on the WLAN as a STA; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein said instructions, when executed by the processor, perform one or more steps comprising: (d)(i) distinguishing real time application (RTA) traffic from non-RTA traffic; (d)(ii) obtaining a transmit opportunity (TXOP) of a primary AC; and (d)(iii
  • An apparatus for wireless communication in a network comprising: (a) a wireless communication circuit, as a wireless station (STA) operating as either an access point (AP) or a non-AP STA, is configured for wirelessly communicating packets which carry frames over a channel with other wireless stations (STAs), which are either APs or non- AP STAs, on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is applied to more than one access category (AC); (b) a processor coupled to said wireless communication circuit for operating on the WLAN as a STA; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein said instructions, when executed by the processor, perform one or more steps comprising: (d)(i) exchanging a specification of quality of service (QoS) requirements and upper layer information of traffic flow to set up a traffic stream between a non-AP MLD and an AP ML; (d)(i) exchanging a specification of
  • the apparatus or method of any preceding implementation, wherein the STA, which is ensuring minimum required channel resource to transmit frames from the primary AC, can utilize the minimum required channel resource for TXOP sharing if all the frames from the primary AC have been transmitted.
  • a set refers to a collection of one or more objects.
  • a set of objects can include a single object or multiple objects.
  • Relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
  • substantially aligned can refer to a range of angular variation of less than or equal to ⁇ 10°, such as less than or equal to ⁇ 5°, less than or equal to ⁇ 4°, less than or equal to ⁇ 3°, less than or equal to ⁇ 2°, less than or equal to ⁇ 1 °, less than or equal to ⁇ 0.5°, less than or equal to ⁇ 0.1 °, or less than or equal to ⁇ 0.05°.

Abstract

L'invention concerne un circuit et un protocole de communication pour un réseau local sans fil (WLAN) à l'aide d'EDCA unique et/ou d'EDCA à utilisateurs multiples (MU) dans lequel des trames pour des applications en temps réel (RTA) peuvent utiliser des opportunités de transmission partagées (TXOP) pour réduire les latences de transmission. Le protocole est configuré selon un certain nombre de manières pour assurer une équité de communication, par exemple en garantissant une ressource de canal requise minimale pour transmettre des trames à partir du AC primaire pendant la TXOP. Les MLD AP et les MLD non AP sont également pris en charge et peuvent échanger des informations sur la distinction de flux de trafic provenant d'autres flux de trafic présentant le même identifiant de trafic (TID), en déterminant quelles liaisons utiliser pour transmettre le flux de trafic.
EP22711649.8A 2021-03-31 2022-03-14 Partage d'une txop d'edca avec un trafic rta Pending EP4292378A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202163168434P 2021-03-31 2021-03-31
US17/509,017 US20220322460A1 (en) 2021-03-31 2021-10-24 Sharing an edca txop with rta traffic
PCT/IB2022/052295 WO2022208211A2 (fr) 2021-03-31 2022-03-14 Partage d'une txop d'edca avec un trafic rta

Publications (1)

Publication Number Publication Date
EP4292378A2 true EP4292378A2 (fr) 2023-12-20

Family

ID=80819820

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22711649.8A Pending EP4292378A2 (fr) 2021-03-31 2022-03-14 Partage d'une txop d'edca avec un trafic rta

Country Status (5)

Country Link
EP (1) EP4292378A2 (fr)
JP (1) JP2024511187A (fr)
KR (1) KR20230144638A (fr)
CN (1) CN116097900A (fr)
WO (1) WO2022208211A2 (fr)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7349433B2 (en) * 2001-11-01 2008-03-25 Texas Instruments Incorporated Signaling for parameterized quality of service (QoS) support
CN103155444B (zh) * 2010-08-26 2017-04-12 马维尔国际贸易有限公司 具有主接入类别和辅接入类别的无线通信
US20160262173A1 (en) * 2015-03-03 2016-09-08 Samsung Electronics Co., Ltd Methods for uplink channel access in wireless local area networks
US10492223B2 (en) * 2015-05-21 2019-11-26 Newracom, Inc. Channel access for multi-user communication
US20220312522A1 (en) * 2019-07-02 2022-09-29 Lg Electronics Inc. Mapping of tid and link in multi-link
US11178694B2 (en) * 2019-09-09 2021-11-16 Sony Group Corporation RTA queue management in wireless local area network (WLAN) stations
US20210075675A1 (en) * 2019-10-28 2021-03-11 Dave Cavalcanti Enhanced network architecture in wirless communications

Also Published As

Publication number Publication date
WO2022208211A2 (fr) 2022-10-06
KR20230144638A (ko) 2023-10-16
WO2022208211A3 (fr) 2022-11-10
CN116097900A (zh) 2023-05-09
JP2024511187A (ja) 2024-03-12

Similar Documents

Publication Publication Date Title
US11711847B2 (en) MU-MIMO pre-packet arrival channel contention
JP6006343B2 (ja) 無線通信媒体へのアクセスを制御するための方法およびシステム
JP5639470B2 (ja) 改善されたマルチユーザ伝送
US11516846B2 (en) RTA packet duplication in time and frequency
US11337222B2 (en) Coordinated stations in a single BSS with shared TXOP in the frequency domain
CN114788400A (zh) 具有时域中的共享txop的协调wifi站
US11122624B2 (en) Pre-packet arrival channel contention
EP4165945A1 (fr) Trame de déclenchement de demande et partage de txop lancé par une sta non ap
US20230058871A1 (en) Stream classification service (scs) with restricted target wait time (r-twt) setup
US11405958B2 (en) Enhanced distributed channel access (EDCA) queue for real time application (RTA) packets
EP4364513A1 (fr) Achèvement de période de service de temps de réveil cible limité
WO2022118135A1 (fr) Stations wifi coordonnées avec txop partagée entre dl et ul dans le domaine temporel
US20220322460A1 (en) Sharing an edca txop with rta traffic
EP4292378A2 (fr) Partage d'une txop d'edca avec un trafic rta

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230913

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR