Duplication of RTA packets in time and frequency

Abstract

A wireless station and protocol for a wireless local area network (WLAN) that supports real-time application (RTA) packets by setting an active retry policy for RTA packets within a TXOP, wherein the station retransmits RTA packets in the time and frequency domains without waiting for feedback. A block acknowledgment (BA) protocol is set up to receive feedback to adapt future packet transmissions. If the retry count for an RTA packet exceeds the active retry limit or the lifetime of that packet has expired, the RTA packet is discarded. Multi-link devices (MLDs) are supported, including access point multi-link devices (AP-MLDs) that perform simultaneous transmission / reception (STR) and non-access point multi-link devices (non-AP MLDs) that are not configured for simultaneous transmission / reception (non-STRs).

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Patent Application Serial No. 17 / 116,072, filed December 9, 2020, which is hereby incorporated by reference in its entirety. This application further claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 022,692, filed May 11, 2020, which is hereby incorporated by reference in its entirety.

[0003] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0004] not applicable

[0005] Incorporation by Reference into the Computer Program Appendix

[0006] not applicable

[0007] Notice of Copyrighted Material

[0008] Portions of the material in this patent document are copyrighted under the copyright laws of the United States and other countries. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the U.S. Patent and Trademark Office publicly available file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner hereby does not waive any of its rights to have this patent document maintained in confidence, including but not limited to its rights under 37 CFR §1.14. Technical Field

[0009] The technology of this disclosure relates generally to wireless communication stations, and more particularly to wireless local area network (WLAN) stations that utilize a queue management system to transmit real-time traffic. Background Art 1. Technical Field

[0011] The technology of the present disclosure generally relates to wireless communication networks (WLANs) using CSMA / CA, and more particularly to WLANs using CSMA / CA that replicates real-time application (RTA) packets in the time and / or frequency domains and transmits these packets during the same TXOP period.

[0012] 2. Background Technology Discussion

[0013] Current wireless technologies using CSMA / CA mainly focus on improving network throughput performance, but they lack low latency capabilities.

[0014] However, an increasing number of applications, such as real-time applications (RTA), require low latency, creating a technology gap. RTA requires low-latency communication and uses best-effort communication in current wireless networks. RTA packets require low latency due to their high timeliness requirements for packet delivery. RTA packets are only valid if they are delivered within a certain timeframe.

[0015] Existing techniques for retransmission schemes do not meet the timeliness requirements of RTA packets and are not configured to minimize RTA packet transmission delays.

[0016] Therefore, there is a need for enhanced handling of RTA transmissions and retransmissions. The present disclosure satisfies this need and provides additional benefits over prior art techniques. Summary of the Invention

[0017] The present disclosure operates in a CSMA / CA WLAN and distinguishes real-time application (RTA) traffic from non-RTA traffic. It handles RTA traffic in a manner that takes into account the timeliness of packets, because RTA packets must be transmitted within a limited lifetime or they will be invalid. In this protocol, stations schedule retransmissions of RTA packets based on their lifetime.

[0018] In particular, the present disclosure separates the retransmission scheme for RTA packets from non-RTA packets, while non-RTA packets can still use the conventional retransmission scheme defined in CSMA / CA. The proposed technology defines an active retry scheme for RTA services to transmit and retransmit RTA packets within the same transmission opportunity (TXOP) period. The present disclosure allows a station to obtain a TXOP on a multi-link device (MLD) to transmit the initial transmission of RTA packets on one link and retransmit their retransmissions on (one or more) other links. The present disclosure is compatible with orthogonal frequency division multiple access (OFDMA) systems. The present disclosure allows a station to use one resource unit (RU) to transmit the initial transmission of an RTA packet and use another RU to transmit its retransmission in the same multi-user (MU) PPDU packet. It should be noted that the PPDU is a physical layer consistency procedure (PLCP) protocol data unit (PPDU). The present disclosure allows a station to set a block acknowledgment (BA) protocol for RTA packets to obtain packet loss information on multiple links to adapt to future packet transmissions. It should be appreciated that packet transmission may also be adapted, for example, by using a modulation and coding scheme (MCS), active retry limiting, or other adaptations without departing from the teachings of the present disclosure.

[0019] Other aspects of the technology described herein will be set forth in the following portions of this specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The technology described herein will be more fully understood by reference to the following drawings, which are included for illustrative purposes only:

[0021] Figure 1 It is a data field diagram of the service specification (TSPEC) defined in IEEE 802.11.

[0022] Figure 2 This is a diagram of the data fields of the Service Stream (TS) information field defined in IEEE 802.11.

[0023] Figure 3 This is a data field diagram of the Traffic Classification (TCLAS) information field defined in IEEE 802.11.

[0024] Figure 4 This is a data field diagram of the Traffic Classification (TCLAS) process element field defined in IEEE 802.11.

[0025] Figure 5 is a hardware block diagram of wireless station hardware in accordance with at least one embodiment of the present disclosure.

[0026] Figure 6 is a network topology diagram shown by way of example according to at least one embodiment of the present disclosure and is not limited to a basic service set (BSS) scenario, one of which is configured for a multi-link device (MLD).

[0027] Figure 7 is a communication sequence diagram for establishing a low latency transport service (LLTS) according to at least one embodiment of the present disclosure.

[0028] Figure 8 is a diagram of data fields of a low latency transport service (LLTS) request frame according to at least one embodiment of the present disclosure.

[0029] Figure 9 is a diagram of data fields of a low latency transport service (LLTS) descriptor frame according to at least one embodiment of the present disclosure.

[0030] Figure 10 is a data field diagram of an RTA-TSPEC field in accordance with at least one embodiment of the present disclosure.

[0031] Figure 11 is a data field diagram of an optional sub-element field according to at least one embodiment of the present disclosure.

[0032] Figure 12 is a diagram of data fields of a low latency transport service (LLTS) response frame according to at least one embodiment of the present disclosure.

[0033] Figure 13is a diagram of data fields of a Low Latency Transport Service (LLTS) status frame according to at least one embodiment of the present disclosure.

[0034] Figure 14 is a flow chart of a station deciding whether to apply an active retry policy to an RTA packet in accordance with at least one embodiment of the present disclosure.

[0035] Figure 15 is a flow diagram of a station transmitting an RTA packet, wherein proactive retries are performed, with packet duplication with respect to time, in accordance with at least one embodiment of the present disclosure.

[0036] Figure 16 The present invention is a flowchart of a multi-link device (MLD) obtaining a transmission opportunity (TXOP) for an RTA packet using active retry in a multi-link scenario according to at least one embodiment of the present disclosure.

[0037] Figure 17A and Figure 17B is a flowchart of a STR AP MLD obtaining a TXOP for transmission to a non-STR non-AP MLD in a multi-link scenario according to at least one embodiment of the present disclosure.

[0038] Figure 18 is a flow chart for transmitting an RTA packet when active retries are allowed on multiple resource units (RUs), in accordance with at least one embodiment of the present disclosure.

[0039] Figure 19 is a flow chart of a station discarding an RTA packet when active retries are allowed, in accordance with at least one embodiment of the present disclosure.

[0040] Figure 20 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 1 according to at least one embodiment of the present disclosure.

[0041] Figure 21 FIG. 2 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 2 according to at least one embodiment of the present disclosure.

[0042] Figure 22 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 2-1 according to at least one embodiment of the present disclosure.

[0043] Figure 23 FIG. 3 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 3 according to at least one embodiment of the present disclosure.

[0044] Figure 244 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 4 according to at least one embodiment of the present disclosure.

[0045] Figure 25 FIG. 5 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 5 according to at least one embodiment of the present disclosure.

[0046] Figure 26 4 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 6 according to at least one embodiment of the present disclosure.

[0047] Figure 27 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 6-1 according to at least one embodiment of the present disclosure.

[0048] Figure 28 is a communication sequence diagram of a station as Example 6-1-1 utilizing active retry transmission of an RTA packet on a single link according to at least one embodiment of the present disclosure.

[0049] Figure 29 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 6-2 according to at least one embodiment of the present disclosure.

[0050] Figure 30 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 6-3 according to at least one embodiment of the present disclosure.

[0051] Figure 31 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 7 according to at least one embodiment of the present disclosure.

[0052] Figure 32 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 8 according to at least one embodiment of the present disclosure.

[0053] Figure 33 is a diagram of data fields of the format of a Block Acknowledgement Request (BAR) frame according to at least one embodiment of the present disclosure.

[0054] Figure 34 is a diagram of a data field of a block acknowledgement (BA) response frame according to at least one embodiment of the present disclosure.

[0055] Figure 35 is a communication sequence diagram of a station using active retry transmission of RTA packets on multiple links as Example 9 according to at least one embodiment of the present disclosure.

[0056] Figure 36 is a communication sequence diagram of a station using active retry transmission of an RTA packet on a single link as Example 10 according to at least one embodiment of the present disclosure.

[0057] Figure 37 is a communication sequence diagram illustrating how a station, as Example 11, utilizes active retry transmission of an RTA packet on a single link according to at least one embodiment of the present disclosure.

[0058] Figure 38 is a hardware block diagram of a wireless communication station in a multi-link device (MLD) configuration according to at least one embodiment of the present disclosure. DETAILED DESCRIPTION

[0059] 1. Introduction to relevant 802.11 elements

[0060] 1.1.TSPEC elements

[0061] Figure 1 The diagram shows the contents of a Traffic Specification (TSPEC) element defined in IEEE 802.11 as having the following fields. The "Element ID" field indicates the type of element. In this case, it would indicate that this is a TSPEC element. The "Length" field indicates the length of the TSPEC element. The "TS Information" field contains the following information about the Figure 2The service flow information described above. The "Nominal MAC Service Data Unit (MSDU) Size" field indicates the nominal size of the MSDU or A-MSDU belonging to the service flow (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 maximum amount of time that no MSDU belonging to the TS is allowed to arrive or be transmitted before that TS is deleted. The "Suspend Interval" field contains the maximum amount of time that no MSDU belonging to the TS is allowed to arrive or be transmitted before generating a subsequent Quality of Service (QoS): QoS (+) CF - Stop polling for this TS. The "Service Start Time" field indicates the start time of the first SP. The "Minimum Data Rate" field indicates the minimum data rate specified by the MAC SAP for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC. The "Average Data Rate" field indicates the average data rate specified by the Medium Access Control (MAC) Service Access Point (SAP) for transmission of MSDUs or A-MSDUs belonging to a TS under this TSPEC. The "Peak Data Rate" field indicates the maximum data rate specified by the MAC SAP for transmission of MSDUs or A-MSDUs belonging to a TS under this TSPEC. The "Burst Size" field indicates the maximum burst of MSDUs or A-MSDUs belonging to a TS under this TSPEC at the peak data rate. The "Delay Bound" field indicates the maximum time allowed for transmission of MSDUs or A-MSDUs belonging to a TS under this TSPEC. The "Minimum PHY Rate" field indicates the minimum PHY rate for transmission of MSDUs or A-MSDUs belonging to a TS over the physical layer under this TSPEC. The "Excess Bandwidth Allowed" field indicates the ratio of the bandwidth used for transmission of MSDUs or A-MSDUs belonging to a TS under this TSPEC and their retransmissions to the bandwidth for a single transmission of the MSDU or A-MSDU at the minimum PHY rate. The "Medium Time" field indicates the time specified for access to the medium. When TSPEC applies to a Directional Multi-Gigabit (DMG) BSS, the "DMG Attributes" field is present.

[0062] 1.2.TS Information Elements

[0063] Figure 2 Shows the contents of the TS information field, as defined in IEEE 802.11. Figure 1One of the fields in the TSPEC element described in , and has the following subfields. The "Service Type" subfield specifies whether the service is periodic. The TSID subfield indicates the ID number that identifies the service stream (TS). The "Direction" subfield specifies the direction of data transmission. The "Access Policy" subfield specifies the method used to obtain channel access. The "Aggregation" subfield specifies whether an aggregation schedule is required. The APSD subfield indicates whether automatic power save (PS) delivery is used. The "User Priority" subfield indicates the user priority of the MSDU or A-MSDU belonging to this TS. The "TS Information Acknowledgement Policy" subfield indicates whether ACK (acknowledgement) is required and which form of ACK to use. The "Schedule" subfield indicates the type of schedule.

[0064] 1.3.TCLAS Elements

[0065] Figure 3 The contents of the TCLAS element defined in IEEE 802.11 are shown, and have the following fields. The "Element ID" field indicates the type of element, and in this case, indicates a TCLAS element. The "Length" field indicates the length of the TCLAS element. The "User Priority" field indicates the user priority from the upper layer. The "Frame Classifier" field indicates the method used to classify frames from the upper layer.

[0066] 1.4.TCLAS Process Elements

[0067] Figure 4 The contents of the TCLAS Processing element defined in IEEE 802.11 are shown, with the following fields. The "Element ID" field indicates the type of element; in this case, a TCLAS Processing element. The "Length" field indicates the length of the TCLAS Processing element. The "Processing" field indicates the method for classifying traffic from upper layers when multiple TCLAS elements are present.

[0068] 2. Problem Statement

[0069] At the time of this disclosure, wireless communication systems using CSMA / CA do not distinguish between RTA packets and non-RTA packets, and all packets use the same retransmission scheme in CSMA / CA. The retransmission scheme in CSMA / CA is designed to reduce the probability of packet collisions, while packet latency is not a major concern. In these CSMA / CA systems, each retransmission requires stations to contend for the channel with an increasingly longer contention window, which adds significant delay to packet transmission and, therefore, increases packet latency.

[0070] The retransmission scheme in CSMA / CA does not consider packet timeliness. The sending station retransmits a packet until either it is received by the receiving station or the retry limit is exceeded. However, RTA packets have a lifespan and must be transmitted within this lifespan or they are considered invalid. In other words, RTA packets must be transmitted or retransmitted within a certain period of time.

[0071] 3. Contributions of the Present Disclosure

[0072] One solution in CSMA / CA wireless technology is to allow stations to gain channel access faster with less channel contention time. Due to random channel access, stations need to sense and contend for channel access before transmitting each packet. While shorter channel contention time speeds up channel access, it increases the probability of packet collisions. Due to the channel contention time for each retransmission, the delay caused by packet collisions is still significant.

[0073] To avoid packet collisions and improve packet delivery success rates, current WLAN systems handle packet collisions by having stations retransmit packets with longer channel contention periods after receiving feedback indicating transmission failures, such as ACK timeouts or BAs. However, this approach increases packet latency.

[0074] To eliminate the delays caused by current retransmission processes, this document describes a beneficial proactive retry scheme in which RTA packets can be retransmitted without waiting for any feedback. In this proactive retry scheme for RTA packets, a station node replicates the RTA packet in the time and / or frequency domain. The RTA packet replication is considered both the initial transmission and a retransmission of the RTA packet. They are transmitted during the same TXOP period to achieve the desired packet loss rate required for the RTA service.

[0075] Due to the coexistence of RTA and non-RTA traffic, the task of applying an active retry scheme for RTA packets in a CSMA / CA system is more challenging. The challenges in this process can be summarized as follows: (a) identifying RTA and non-RTA packets; (b) duplicating RTA packets in the time and / or frequency domains; and (c) transmitting duplicate RTA packets during the same TXOP period.

[0076] The proactive retry scheme designed for RTA packets according to the present disclosure aims to consider the time validity of RTA traffic and minimize its delay in wireless networks where RTA and non-RTA traffic coexist.

[0077] By utilizing the present disclosure, the importance of RTA packet latency is addressed, such as by the following contributions. A station can distinguish between RTA packets and non-RTA packets. The timeliness of RTA services is taken into account because the station schedules the retransmission of RTA packets based on the life cycle of the RTA packets. The station separates the retransmission scheme for RTA packets from the retransmission scheme for non-RTA packets, while non-RTA packets can still use the conventional retransmission scheme defined in CSMA / CA. An active retry scheme is provided for RTA services to transmit and retransmit RTA packets within the same TXOP period. A station is allowed to obtain TXOPs on multiple links to transmit the initial transmission of an RTA packet on one link and retransmit its retransmissions on other links. The present disclosure is compatible with OFDMA systems. A station is allowed to use one resource unit (RU) to transmit the initial transmission of an RTA packet and use another RU to transmit its retransmission in the same MU-PPDU packet. A station is allowed to set a block acknowledgment (BA) protocol for RTA packets to obtain packet loss information on multiple links to adapt to packet transmission, such as modulation and coding scheme (MCS), active retry limit, etc., without restrictions.

[0078] 4. Examples

[0079] 4.1. Station Hardware and Example Network Topology

[0080] Figure 5 An example embodiment 10 of wireless communication circuitry is illustrated, one or more of which may be used in a station (STA). The station is shown having external I / O, a CPU, and memory for executing programs implementing such a communication protocol, as well as at least one modem and radio frequency (RF) circuitry for transmitting / receiving data frames with neighboring stations.

[0081] Specifically, a WLAN station according to the present disclosure is shown having an I / O path 14 into a station circuit block 12 having a bus 16 connected to at least one computer processor (CPU) 18, memory (RAM) 20, and at least one modem 22. Bus 14 allows various devices, such as sensors, actuators, etc., to be connected to the CPU. Instructions from memory 20 are executed on processor 18 to execute a program that implements a communication protocol. The program is executed to allow the station to function as an access point (AP) station or a non-AP (regular) station (STA), or a multi-link device (MLD), whether for an AP or non-AP station. It should also be appreciated that the programming is configured to operate in different modes (source, intermediate, destination, first AP, other APs, non-AP stations associated with the first AP, stations associated with other APs, coordinator, coordinator, etc.), depending on the role it plays in the current communication context.

[0082] The host machine is shown as being configured with at least one modem and RF circuitry to generate and receive physical signals. By way of example and not limitation, mmW modem 22 is coupled to at least one radio frequency (RF) circuitry 24, which is connected to at least one antenna 26a, 26b, 26c to 26n (e.g., an antenna array) to transmit and receive frames with neighboring stations. The present disclosure can be used with stations that transmit directional signals, omnidirectional signals, or a combination of directional and omnidirectional signals.

[0083] By way of example and not limitation, an antenna array (such as shown at 26a, 26b, 26c to 26n) can allow a station to transmit signals using multiple sets of beam patterns. The RF circuitry generally includes a frequency converter, an array antenna controller, and other control and radio frequency circuitry. The combination of the processor, modem, and RF circuitry allows for support of beamformed (directional) communications, as well as support for quasi-omnidirectional (herein referred to as omnidirectional) pattern transmissions from the antenna array. Furthermore, in at least one preferred embodiment, nulls can be generated in the pattern created by the antenna array to shield selected directions (sectors), thereby reducing interference between stations.

[0084] Thus, the station HW is shown configured with at least one modem and associated RF circuitry for providing communications in at least one frequency band. By way of example and not limitation, the intended directional communications band is implemented using a mmW band modem and its associated RF circuitry for transmitting and receiving data in the mmW band. In at least one other embodiment, at least a second frequency band is supported in hardware, generally referred to as a discovery band, which, by way of example and not limitation, may include a sub-6 GHz modem and its associated RF circuitry for transmitting and receiving data in the sub-6 GHz band.

[0085] It should be appreciated that the present disclosure can be configured with multiple modems 22, each coupled to any number of RF circuits. Generally speaking, using a greater number of RF circuits will result in wider coverage of the antenna beam direction. It should be appreciated that the number of RF circuits and antennas used is determined by the hardware constraints of a particular device. When a station determines that it does not need to communicate with a neighboring station, some of the RF circuitry and antennas can be disabled.

[0086] Figure 38 Pictured Figure 5 A variation of embodiment 930 is provided in which the wireless communication stations are attached to a multi-link device (MLD) hardware configuration. Each station operates on a link of a different frequency. Each station 10' may be configured as follows: Figure 5As described in , each station has a CPU, RAM, modem, RF circuit and one or more antennas. As can be seen from the figure, each of the n stations shown provides a different link (for example, link 1, link 2 to link n are shown).

[0087] The MLD is also shown along with circuitry 932 of an MLD management entity having at least one processor (CPU) 934, memory 936 that provides external I / O to access the MLD's applications and implements communication protocols at the MLD level. The MLD is configured to distribute tasks to each satellite station and collect information from them and share information between satellite stations.

[0088] It should also be appreciated that each station of an MLD need not have its own processor and memory. In at least one embodiment, one or more stations may share a processor and memory, or a processor and memory of an MLD circuit. Thus, the present disclosure contemplates many possible arrangements for communicating over multiple links within an MLD.

[0089] Figure 6 An example embodiment of a topology 30 is illustrated, which is used herein for illustrative purposes and not as a limitation, as the present disclosure can support network scenarios with various numbers of stations and station arrangements without limitation. To simplify the description, this example describes seven stations consisting of two BSSs in an ambient enclosure (e.g., a conference room) 32, with any desired configuration and openings / holes 34, furniture, etc. Each station can communicate with other stations in the same BSS. All stations use CSMA / CA for random channel access.

[0090] By way of example and not limitation, all stations are assumed to be running both applications requiring low-latency communication and applications using best-effort communication. Data generated from applications requiring low-latency communication is referred to as RTA traffic and is packaged into RTA packets at the sending station. Furthermore, data generated from non-time-sensitive applications is referred to as non-RTA traffic and is packaged into non-RTA packets at the sending station. Thus, the sending station generates both RTA and non-RTA traffic for communication. The locations of the stations and their transmission links are shown in the figure.

[0091] The first BSS includes Station 0 (AP) 36, Station 1 38, and Station 2 40 and is capable of transmitting packets only on a single channel / frequency band. The second BSS includes Station 3 (AP) 46 and Station 4 (AP) 48 (which are attached to AP Multilink Device (MLD) #1 42) through Station 5 50 and Station 6 52 (which are attached to non-AP MLD #2 44). MLD includes a MAC data service shared by attached stations. Station 5 is associated with Station 3 via Link 1 52, and Station 6 is associated with Station 4 via Link 2 54. MLD #1 and MLD #2 can transmit and receive data via either Link 1 or Link 2.

[0092] If an MLD has a link pair such that the MLD cannot simultaneously transmit on one link of the link pair and receive on the other link of the link pair due to intra-device operational limitations, then the MLD is called a non-simultaneous transmit / receive (non-STR) MLD. Otherwise, the MLD is called a simultaneous transmit / receive (STR) MLD.

[0093] 4.2. Low Latency Transport Service (LLTS) Settings

[0094] RTA often generates traffic periodically, just like in connection-oriented communication. The RTA connection-oriented communication established by the application between stations is called an RTA session. A station can have multiple RTA sessions in the network. The station is able to properly manage those RTA sessions and apply active retry policies to the RTA packets of the RTA session. LLTS settings can be used to: (a) identify RTA traffic of an RTA session from upper layers; (b) set active retry configuration for the RTA traffic of the RTA session; and (c) schedule active retries for the RTA traffic of the RTA session to meet its Quality of Service (QoS) requirements.

[0095] Figure 7 An example embodiment 70 of LLTS setup communications is illustrated between a MAC sublayer management entity (SME) 76 and a MAC sublayer management entity (MLME) 78 of a station (e.g., a non-AP station) 72, and an MLME 80 and SME 82 of another station (e.g., an AP) 74. It will be appreciated that the interworking model of the stations may use the same model as defined in the IEEE 802.11 standard.

[0096] A non-AP station decides to initiate the LLTS setup procedure with the AP. The non-AP station's Station Management Entity (SME) sends an MLME-LLTS.request message 84 to its MAC Sublayer Management Entity (MLME). When the non-AP station's MLME receives the MLME-LLTS.request message, it gathers the information in the MLME-LLTS.request message and sends an LLTS request frame 86 to the AP. The AP's MLME receives this frame and generates an MLME-LLTS.indication message 88 to its SME.

[0097] The AP's SME then processes the message 90 and sends an MLME-LLTS.response message 92 containing the LLTS setup result to its MLME. The AP's MLME then sends an LLTS response frame 94 to the non-AP station. The non-AP station's MLME receives the frame and sends an MLME-LLTS.confirm message 96 to its SME. Through this exchange, the non-AP station knows (can determine) whether the LLTS setup was successful.

[0098] The above process can also be used to change or remove LLTS. The lower portion of the figure shows an example of terminating LLTS. An AP station decides to terminate 98 LLTS with a non-AP station. The AP's SME sends an MLME-LLTS-TERM.request message 100 to its MLME. When the AP's MLME receives the MLME-LLTS-TERM.request message, it collects the information in the MLME-LLTS-TERM.request message and sends an LLTS response frame 102 to the non-AP station. The non-AP station's MLME receives the frame and generates an MLME-LLTS-TERM.indication message 104 to its SME. Thus, through this communication, the non-AP station knows (determines) that LLTS has been terminated.

[0099] RTA traffic of an RTA session can be classified by LLTS setup. If the upper layer information of the traffic matches the information of the TCLAS element and TCLAS handle element exchanged during the LLTS setup procedure, then the traffic from the upper layer is RTA traffic of the RTA session.

[0100] By exchanging RTA-TSPEC elements during the LLTS setup process, the Quality of Service (QoS) requirements of the RTA traffic of the RTA session can be shared between AP and non-AP stations. LLTS setup can also be used to check whether the AP and non-AP stations have sufficient resources to support RTA traffic transmission.

[0101] 4.2.1.LLTS Request Frame

[0102] Figure 8An example embodiment 110 of the format for an LLTS request frame having the following fields is illustrated. The "Frame Control" field indicates the type of frame. The "Duration" field contains the NAV information used for CSMA / CA channel access. The "Address 1" field contains the address of the receiver of the frame. The "Address 2" field contains the address of the station transmitting the frame. The "Address 3" field contains the BSSID. The "Sequence Control" field indicates the sequence number of the frame. The "HT Control" field indicates additional control information for high throughput (HT) or very high throughput (VHT) frames. The "Action" field indicates the action to be performed when it is an LLTS request frame. The "Frame Check Sequence (FCS)" is seen here, and in other data formats described in this disclosure, because it provides an error detection code for the frame added to the communication protocol.

[0103] The "Action" field includes an LLTS request element, which, in at least one embodiment, has the following subfields. The "Element ID" subfield indicates the element type, in this case, an LLTS request element. The "Length" subfield indicates the length of the LLTS request element. The "LLTS Descriptor List" subfield indicates a sequence of "LLTS Descriptor" fields, each of which is configured to indicate an LLTS setup request for a service under a specific profile and classification information. Upon receiving this information, the receiving station can understand (identify) the service profile and classification information and decide whether to accept or reject the LLTS setup request.

[0104] 4.2.2. "LLTS Descriptor" Field

[0105] Figure 9 An example embodiment 130 of an "LLTS Descriptor" is illustrated, having the following fields. The LLID field contains the identifier of the low-latency transport service. For example, a non-AP station sets a number to represent the LLTS. An AP that receives this number can use it to identify the LLTS set up with the non-AP station. The LL Length field indicates the length of the LLTS Descriptor field. The Request Type field is set to indicate the type of LLTS descriptor. When a non-AP station sets the Request Type field to "Add," the non-AP station requests the addition of a new LLTS. The receiving AP should respond to this request regardless of whether the AP accepts the addition of the new LLTS. When a non-AP station sets the Request Type field to "Change," the non-AP station requests a parameter change for an existing LLTS. When an AP receives this field, it can use the LLID to locate the LLTS and either accept or reject the parameter change for that LLTS. When a non-AP station sets the Request Type field to "Remove," the non-AP station requests the removal of an existing LLTS. When an AP receives this field, it can use the LLID to locate and remove the LLTS.

[0106] The TCLAS field can be identical to the TCLAS element defined in IEEE 802.11. Non-AP stations set this field to indicate service information from upper layers. When the service is downlink and the upper layer information for that service matches the TCLAS information, the AP uses this information to identify the upper layer RTA service under this LLTS. The "LLTS Descriptor" field can contain multiple TCLAS fields.

[0107] The "TCLAS Handle" field can be the same as the TCLAS Handle element defined in IEEE 802.11. When multiple TCLAS fields are present in the "LLTS Descriptor" field, a non-AP station sets this field to indicate the rule for using multiple TCLAS fields to identify RTA services. When an AP receives this field in the "LLTS Descriptor" field, it can determine how to use multiple TCLAS fields to identify services from upper layers.

[0108] The RTA-TSPEC field indicates the specifications and QoS requirements for the RTA service. When the AP receives this field, it can use the information in this field to decide whether to accept or reject the LLTS request. This field also contains information about the service direction under this LLTS (e.g., uplink, downlink, or bidirectional), which can be set in the "Direction" field of the "TS Information" field of the TSPEC element. The TSID field in the "TS Information" field of the TSPEC element can be set to indicate the TID of the RTA service belonging to the LLTS under this RTA-TSPEC. The "Access Policy" field in the "TS Information" field of the TSPEC element can be set to indicate the access method to be used for the LLTS under this RTA-TSPEC, such as EDCA, HCCA, HEMM, etc. (as defined in IEEE 802.11). The "User Priority" field in the TSPEC can be used to indicate the user priority of the RTA service belonging to the LLTS. For example, station 1 can set up LLTS with station 0. In this example, the LLID is set to "1" and the TSID is set to "8." Active retries for this RTA service should be scheduled to meet the QoS requirements.

[0109] The "Optional Sub-Element" field indicates the retransmission policy for the service under this LLTS. When the AP receives this field, it should provide a response to the non-AP station as to whether it will provide the requested LLTS for the service.

[0110] 4.2.3.RTA-TSPEC

[0111] Figure 10An example embodiment 150 of an RTA-TSPEC is illustrated with the following fields. The TSPEC field may be the same as the TSPEC element defined in IEEE 802.11. A non-AP sets this field to indicate the specifications and partial QoS requirements for the RTA service under this RTA-TSPEC. When an AP receives this field, it may use this information to estimate the resource allocation for transmitting the RTA service under this RTA-TSPEC. Based on this estimate, the AP may decide whether to accept the LLTS setup. The "RTA Attributes" field indicates the additional QoS requirements for the RTA service under this RTA-TSPEC. The "Reliability" field indicates the packet loss requirements for the RTA service under this RTA-TSPEC. When an AP receives this field, it should estimate the resource allocation for transmitting the RTA service under this RTA-TSPEC to ensure that the packet loss for the RTA service under this RTA-TSPEC is less than the packet loss indicated in the "Reliability" field, especially when active retry is enabled.

[0112] The "Jitter" field indicates the jitter requirement for delivering MSDUs or A-MSDUs belonging to LLTS under this RTA-TSPEC. A non-AP sets this field to request the AP to guarantee a maximum jitter limit for MSDUs or A-MSDUs belonging to LLTS under this RTA-TSPEC. The AP receives this field and estimates whether it can meet this request. For example, the difference between the maximum service interval and the minimum service interval should be less than the jitter to meet this request. The AP sets this field to indicate the jitter level it can support. When a non-AP receives this field, it either accepts the jitter provided by the AP or renegotiates with the AP.

[0113] The "MSDU Lifetime" field indicates the MSDU lifetime, which represents the time an MSDU can be stored in the queue. When the "Deterministic Service" field is set to the first state (e.g., "1"), the station sets this field to indicate the MSDU lifetime for the RTA service under this RTA-TSPEC. When a station receives this field and the "Deterministic Service" field is set to the first state (e.g., "1"), if the MSDU is not successfully transmitted within this MSDU lifetime, the MSDU is discarded. When the "Deterministic Service" field is set to the second state (e.g., "0"), this field is retained.

[0114] The "Deterministic Service" field is set by the station to indicate whether the MSDU of the RTA service under this RTA-TSPEC will be discarded when its lifetime expires. If the station sets this field to the first state (e.g., "1"), the MSDU of the RTA service under this RTA-TSPEC will be discarded when its lifetime expires; otherwise, the station sets this field to the second state (e.g., "0"). When the station receives this field set to the first state (e.g., "1"), the MSDU of the RTA service under this RTA-TSPEC will be discarded when its lifetime expires. When the station receives this field set to the second state (e.g., "0"), the MSDU of the RTA service under this RTA-TSPEC has no lifetime value.

[0115] The "Nominal Service Interval" field indicates the nominal / average time between the start times of two consecutive SPs. This field may be valid only when the "Service Type" subfield in the LLTS information is set to the first state (e.g., "1"). A non-AP sets this field to request the AP to guarantee the service interval of MSDUs or A-MSDUs belonging to LLTS under this RTA-TSPEC. The AP receives this field and estimates whether this request can be met. For example, the AP sets this field to indicate the nominal service interval it can provide. When a non-AP receives this field, it either accepts the service interval offered by the AP or renegotiates with the AP.

[0116] Optional child elements

[0117] Figure 11 An example embodiment 170 of an optional sub-element with the following fields is illustrated. When a non-AP station sets the following fields in an LLTS request frame, those fields indicate a request by the non-AP station to establish LLTS. When the AP receives this request, it can decide (determine) whether it can accept the request. When a non-AP station sets the following fields in an LLTS response frame to accept the LLTS setup, those fields indicate the LLTS setup. Both the AP and the non-AP station should follow the LLTS setup to perform active retries for RTA traffic under this LLTS.

[0118] The "Sub-element ID" field indicates the type of sub-element. Here, this field indicates that it is an optional sub-element of the LLTS Request element. The "Length" field indicates the length of the optional "Sub-element" field. The "LLTS Retransmission Policy" field indicates the retransmission policy used for LLTS. A non-AP station sets this field to request that this retransmission policy be applied to the RTA service under this LLTS. When an AP station receives this field, it decides whether to accept or reject the request. An AP station sets this field to indicate the request for the retransmission policy it provided when accepting LLTS setup. When a non-AP station receives this field, it can apply the retransmission policy provided by the AP station to the RTA service under this LLTS. If this field is set to "Active Retry," if the LLTS setup is successful, packets under this LLTS will be transmitted on a single link using active retry. If this field is set to "Active Retry with BA," if the LLTS setup is successful, packets under this LLTS will be transmitted on a single link using active retry. The sender of a packet can request Block ACK feedback by sending a Block ACK Request (BAR) frame to the receiver.

[0119] The "Active Retry Limit" field is set to limit the number of retransmissions of packets under this LLTS when active retry is applied. The number of retransmissions of each packet under this LLTS SHOULD not exceed the Active Retry Limit. If the number of retransmissions of a packet under this LLTS exceeds the Active Retry Limit, then that packet SHOULD be discarded.

[0120] The "MAC Protocol Data Unit (MPDU) Lifetime" field is set to indicate the lifetime of the MPDU under this LLTS. If the time since the MPDU arrived at the MAC layer is longer than the MPDU lifetime, then the lifetime of that MPDU expires and the MPDU should be discarded.

[0121] The "Allow Time Duplication" field can be implemented as a one-bit indication to indicate whether packet duplication in the time domain is allowed. When this field is set to the first state (e.g., "1"), a packet under this LLTS can be retransmitted after its previous transmission attempt within the same TXOP or a different TXOP on a single link. No feedback is required between the two transmission attempts. When this field is set to the second state (e.g., "0"), packet duplication in time is not allowed.

[0122] The "Allow Duplication on ML" field can be implemented as a one-bit indication to indicate whether packet duplication is allowed on multiple links. When this field is set to a first state (e.g., "1"), a packet under this LLTS can be transmitted on one link and retransmitted on another link. No feedback is required between two transmission attempts. When this field is set to a second state (e.g., "0"), packet transmission and its retransmission are only allowed on one link.

[0123] The "Maximum Number of Links" field is set to indicate the maximum number of links that can be used for active retry. When this field is set, the number of links composed of the combinations listed in the "Allowed Link Combinations" field cannot exceed the "Maximum Number of Links." When the "Allow Replication on ML" field is set to the second state (e.g., "0"), this field is reserved.

[0124] The "Allowed Link Combinations" field is set to indicate possible combinations of multiple links that can be used for active retry. A station can select one of the combinations to transmit a packet and actively retry on the links in that combination. It should be understood that the number of links in each combination cannot exceed the maximum number of links. When the "Allowed Duplication on ML" field is set to the second state (e.g., "0"), this field is reserved.

[0125] The "Allow Duplication on RU" field may provide an indication (e.g., a one-bit indication) to indicate whether duplicate packets are allowed to be transmitted across multiple RUs within a single MUPPDU / TB PPDU packet. "TB" indicates that the PPDU is trigger-based. When the indication (bit) is set to a first state (e.g., "1"), the station may use one RU to transmit a packet and use other RUs to transmit duplicates of the packet. Otherwise, if the indication (bit) is set to a second state (e.g., "0"), packet duplication within the RU is not allowed.

[0126] The "Maximum Number of RUs" field is set to indicate the maximum number of RUs in an MU PPDU / TB PPDU group that can be used for active retry. When this field is set, the number of RUs in a single MU PPDU or TB PPDU group listed in the "Allowed RU Combinations" field cannot exceed the maximum number of RUs. When the "Allow Duplicates on RUs" field is set to the second state (e.g., "0"), this field is reserved.

[0127] The "Allowed RU Combinations" field is set to indicate the possible combinations of multiple RUs in one MU PPDU / TB PPDU packet that can be used for active retry. The station can pick one of these combinations to transmit the packet and its active retry via the RUs in the combination. It should be recognized that the number of RUs in each combination cannot exceed the maximum number of RUs. This field is reserved when the "Allow Duplication on ML" field is set to the second state (e.g., "0"). It should be noted that for each combination, it can also indicate to which link this combination applies.

[0128] 4.2.5.LLTS Response Frame

[0129] Figure 12 An example embodiment 190 of an LLTS response frame is illustrated, having the following fields. The "Frame Control" field indicates the type of frame. The "Duration" field contains NAV information for CSMA / CA channel access. The "Address 1" field contains the address of the frame's receiver. The "Address 2" field contains the address of the station transmitting the frame. The "Address 3" field contains the BSSID. The "Sequence Control" field indicates the frame's sequence number. The "HT Control" field indicates additional control information for HT or VHT frames. The "Action" field indicates the action to be performed if this is an LLTS response frame.

[0130] The fields within the "Action" field include an LLTS Response element with the following subfields. The "Element ID" subfield indicates the type of element, in this case, an LLTS Response element. The "Length" subfield indicates the length of the LLTS Response element. The "LLTS Status List" subfield indicates the order of the "LLTS Status" fields. Each "LLTS Status" field is set to indicate an LLTS setup response for a service under specific specifications and classification information. Upon receiving this information, the receiving station can determine the result of the LLTS setup for the RTA service or changes to the existing LLTS.

[0131] 4.2.6. "LLTS Status" Field

[0132] Figure 13An example embodiment 210 of an LLTS status frame having the following fields is illustrated. The LLID field contains the identifier of the low-latency transport service. The LL Length field indicates the length of the LLTS Descriptor field. The Response Type field is set to indicate the type of LLTS setup result. When the AP sets the Response Type field to "Accept," the AP accepts the LLTS setup request from the non-AP station. The non-AP station receives this field and can determine that the LLTS setup was successful. When the AP sets the Response Type field to "Denied," the AP denies the LLTS setup request from the non-AP station. When a non-AP station receives this field, it may decide to attempt to initiate another LLTS setup with the AP. When the AP sets the Response Type field to "Terminate," the AP terminates the existing LLTS with the non-AP station. When a non-AP station receives this field, it knows (determines) that the LLTS with the corresponding LLID has terminated and should remove the LLTS.

[0133] The TCLAS field can be identical to the TCLAS element defined in IEEE 802.11. The AP sets this field to indicate information about traffic from upper layers. When a non-AP station receives this field, it can use this information to identify traffic arriving from upper layers under this TTLS when the traffic is uplink. The "LLTS Status" field can contain multiple TCLAS fields. The "TCLAS Handling" field can be identical to the TCLAS Handling element defined in IEEE 802.11. The AP sets this field to indicate the rules for using multiple TCLAS fields to identify RTA traffic when multiple TCLAS fields are present in the "LLTS Status" field. When a non-AP station receives this field in the "LLTS Status" field, it can determine how to use multiple TCLAS fields to identify traffic from upper layers.

[0134] The RTA-TSPEC field is Figure 9 The RTA-TSPEC element is identical to the RTA-TSPEC element defined in [1]. The AP sets this field to indicate the specifications and QoS requirements for the RTA service. When a non-AP station receives this field, it can understand (identify) the RTA-TSPEC under which the AP decided to accept or reject the LLTS request. This field also contains information about the direction of the RTA service under this LLTS (e.g., uplink, downlink, or bidirectional).

[0135] The "Optional Sub-Element" field is set by the AP to indicate the retransmission strategy for the service under this LLTS. When a non-AP station receives this field, it knows (determines) the retransmission strategy provided by the AP when the response type field is set to "Accept".

[0136] Tables 1 to 6 provide information about the above messages. In particular, Table 1 summarizes MLME-LLTS.request, Table 2 summarizes MLME-LLTS.indication, Table 3 summarizes MLME-LLTS.response, Table 4 summarizes MLME-LLTS.confirm, Table 5 summarizes MLME-LLTS-TERM.request, and Table 6 summarizes MLME-LLTS-TERM.indication.

[0137] Figure 14 An example embodiment 230 of a station deciding to apply an active retry policy to an RTA packet is illustrated. When a station has a packet to transmit 232, it checks 234 whether the packet belongs to an existing LLTS to which an active retry policy is applied. If the packet belongs to an existing LLTS, execution moves to block 238, and the station applies the active retry policy to the packet. Otherwise, if the packet does not belong to an existing LLTS, the station uses a conventional retransmission policy 236 in CSMA / CA for the packet.

[0138] Figure 15 An example embodiment 250 is illustrated in which a station utilizes active retry transmission of an RTA packet when packet duplication in the time domain is allowed. When a station is to utilize active retry transmission of an RTA packet and packet duplication in the time domain is allowed, the station contends for a channel, obtains channel access, and obtains a TXOP on link 252. A check is then made 254 as to whether the lifetime of the RTA packet has expired or whether the retry count exceeds a retry threshold. If either condition is met, the RTA packet is discarded 260. Otherwise, if neither condition is met, execution moves to block 256 and the station makes a transmission attempt on the packet without waiting for feedback. After the station completes its transmission attempt on the RTA packet, a check is made 258 as to whether the current TXOP has ended. If not, execution returns to block 254 to attempt transmission of the RTA packet again in the next TXOP. Otherwise, execution moves to block 252, allowing the station to contend for the channel again.

[0139] Figure 16 An example embodiment 270 of an MLD obtaining a TXOP for an RTA packet with active retries in a multi-link scenario is illustrated. When the MLD has RTA packets to transmit with active retries, it simultaneously contends 272 for channels on multiple links. A check 274 is performed to determine whether all links have simultaneously gained channel access. If the condition is true, the MLD reserves 276 the same TXOP duration on both links and transmits the initial transmission of the packet on link 1 and its retransmission on link 2. It should also be appreciated that the MLD may transmit another retransmission of the same packets on link 1, just as they were retransmitted on link 2, instead of the initial transmission of those packets.

[0140] Otherwise, if the links do not gain channel access simultaneously, execution proceeds to block 278, where the MLD first gains channel access on one link (represented by link 1) and transmits 280 an initial transmission (which may also be a retransmission) of the packet on link 1. A check 282 is performed to determine whether the MLD has gained channel access on another link (e.g., link 2) before the TXOP on link 1 ends. If this condition is met, the MLD reserves 286 the TXOP on link 2 until the reserved TXOP on link 1 ends, after which the MLD transmits a retransmission (active retry) 288 of the packet on link 2 during the TXOP to conclude the process. Otherwise, if the check 282 finds that the MLD did not gain channel access on another link (e.g., link 2) before the TXOP on link 1 ends, the MLD fails 284 to gain a TXOP on link 2, no active retry occurs on link 2, and the process ends.

[0141] It should be appreciated that the MLD may decide to discard packets transmitted during the current TXOP after the current TXOP ends. The MLD may also decide to retransmit those packets in the next TXOP if their lifetimes have not expired and their retry counts have not exceeded the active retry limit.

[0142] It should also be noted that MLD can obtain TXOPs on more than two links for active retry. The link that obtains the TXOP first is considered Link 1, and the other links follow the Link 2 rules explained in the flowchart. The link combination can be selected from the "Allowed Link Combinations" field in the LLTS settings.

[0143] It should also be noted that the method of obtaining TXOP as shown in the figure can also be used to transmit non-RTA packets.

[0144] 4.3. Fairness between STR AP MLD and non-STR non-AP MLD

[0145] like Figure 16 The alignment of the end times of TXOPs obtained on multiple links as explained in the flowchart in is intended to solve the fairness problem between STR AP MLD and non-STR non-AP MLD.

[0146] If the end times of the TXOPs are misaligned, the following problem arises. Let's assume that a STR AP MLD first obtains the first TXOP on Link 1. If it obtains channel access on another link (e.g., Link 2) before the end time of Link 1's TXOP, but reserves a TXOP with an end time later than the end time of Link 1's first TXOP, then a non-STR non-AP MLD cannot access the channel until the end time of Link 2's TXOP. However, during the period between the end times of Link 1 and Link 2's TXOPs, the AP MLD can still obtain channel access on Link 1. Then, if the AP obtains channel access and reserves another TXOP on Link 1 with an end time later than Link 2's TXOP, then the non-STR non-AP MLD cannot access the channel until the end time of Link 1's second TXOP, and so on. Therefore, in the worst case, the STR AP MLD will always occupy multiple links, while the non-STR non-AP MLD will never have a chance to access the channel.

[0147] Figure 17A and Figure 17B An example embodiment 290 of a STR AP MLD obtaining a TXOP on a multilink to transmit to a non-STR, non-AP MLD is illustrated, illustrating a method for resolving the fairness issue between STR AP MLDs and non-STR, non-AP MLDs, as described above. When a STR AP MLD has packet(s) 292 to transmit to a non-STR, non-AP MLD, it generates a random value 294 and sets it to the number of backoff slots. Note that each "slot" represents a time increment, such as 20 microseconds. Each station in the AP MLD then begins an independent countdown 296 to back off on its own link.

[0148] At block 298, a check is performed to determine if all stations of the AP MLD gain channel access simultaneously. If the condition is true, then the stations of the AP MLD retain 300 the same TXOP duration on all links to conclude the process.

[0149] Otherwise, if a station countdown of AP MLD backoff reaches zero, then the station obtains 302 channel access on its link and performs a move to Figure 17B It should be appreciated that, due to the different CCA busy times on each link, stations of the AP MLD may gain channel access at different times.

[0150] Therefore, at this point, one station of the AP MLD (represented by station 1) has gained channel access earlier than the other stations and has already reserved a TXOP on its link (represented by link 1). A check 304 is performed to determine whether another station of the AP MLD (represented by station 2) has gained channel access on its link (represented by link 2) before the end of the TXOP on link 1. If the condition is met, then station 2 can reserve 308 the TXOP on link 2 until the end time of the TXOP reserved on link 1. Otherwise, station 2 fails 306 to obtain a TXOP on link 2 and its backoff is reset.

[0151] It should be noted that if all stations of an AP MLD gain channel access simultaneously, they maintain the same TXOP duration on all links. All stations of an AP MLD reset their backoffs after the TXOP ends. The AP MLD sets the same backoff slot on multiple links to increase the chance of gaining channel access on multiple links simultaneously. The AP MLD may set different backoff slots on multiple links.

[0152] It should also be noted that the method of obtaining TXOP as shown in the figure can also be used to transmit either RTA packets or non-RTA packets.

[0153] Figure 18 An example embodiment 310 for transmitting an RTA packet when active retry is allowed on multiple RUs is illustrated. When active retry is allowed on multiple RUs, the AP contends for channel access and acquires a channel 312 for the RTA packet. A check 314 determines whether the transmission is uplink (UL). If it is uplink, then at block 316, the AP embeds the RU distribution for active retry in a trigger frame (TF) and transmits it to the station. The station transmits 320 the initial transmission (and optionally a retransmission) of the RTA packet in the TB PPDU packet using the RU allocated by the TF and the retransmission ends.

[0154] Otherwise, if the transmission is not for the UL, execution moves from block 314 to 318 and the AP allocates multiple RUs of the MU PPDU packet to transmit the initial transmission (and possibly retransmission) and retransmissions of the RTA packet before the process ends.

[0155] It should be appreciated that a TBPPDU or MU PPDU may only carry a retransmission of a packet if the initial transmission of the RTA packet has already been transmitted in a previous PPDU.

[0156] Figure 19An example embodiment 330 is shown in which a station discards an RTA packet that is allowed to be actively retried. A check 332 is performed to determine whether the number of packet retransmissions has reached the active retry limit or whether the packet's lifetime has expired. If either condition is met, the packet is discarded 334. Otherwise, execution moves from block 332 to block 336, and the station can retransmit the packet without receiving any feedback in the current TXOP.

[0157] Figure 20 A first example embodiment 350 is shown where a station transmits an RTA packet on a single link using active retry. This example can occur when the LLTS retransmission policy is set to "active retry" and packet duplication in the time domain is allowed. The network topology of this example is Figure 6 Shown in.

[0158] Sender station 1 352 transmits an RTA packet to receiver station 0 (AP) 354. Active retries are allowed to transmit RTA packets that have arrived 356 in the transmission queue. After the RTA packet arrives in the queue, sender station 1 contends 358 for the channel and obtains a TXOP duration 360. During the TXOP duration, station 1 can transmit the RTA packet 362 using two active retransmissions 366, 370. The time between the two packet transmissions can be an interframe spacing 364, 368, depicted as xIFS, however, SIFS, PIFS, or other spacings may be used without departing from the teachings of the present disclosure. It should be appreciated that transmissions from station 1 are performed without requiring receiver station 0 to transmit any feedback to station 1. When the packet reaches the active retry limit 372, station 1 stops retransmitting the RTA packet.

[0159] Figure 21 The example embodiment 390 is illustrated as Example 2 of Example 2 when a station transmits multiple RTA packets on a single link with active retry. This example occurs when the LLTS retransmission policy is set to "active retry" and duplication is allowed in time. The network topology of this example is Figure 5 Shown in.

[0160] Sender station 1 352 has two RTA packets (depicted as RTA packet #1 and RTA packet #2) to transmit to receiver station 0 (AP) 354. Active retries are allowed to transmit both RTA packets. The RTA packets arrive in queue 356 and sender station 1 contends 358 for the channel and, after backoff, obtains a TXOP duration 360. In this example, station 1 first transmits an initial transmission of all packets 392 and 396. It then begins a first retransmission of all packets 400 and 406, after which a second retransmission of RTA packet #2 is shown starting 410.

[0161] During the TXOP duration, station 1 can transmit RTA packets with active retransmissions.The time between the initial transmissions of the two packets may be the interframe spacing, depicted herein as xIFS 394, 404, although other spacings such as SIFS or PIFS may be used without limitation.

[0162] The sender station 1 may wait for another backoff time 398, 408 for a new retransmission of RTA packets #1 and #2. For example, the sender station 1 invokes backoff 398 for the first retransmission of RTA packets #1 and #2. It also invokes backoff 408 for the second retransmission of RTA packet #2. The time between retransmissions of two packets with the same retry count may also be xIFS or other interframe spacing.

[0163] However, sender station 1 stops retransmitting RTA packet #1 402 because the lifetime of that RTA packet has expired. Sender station 1 is also seen stopping 412 retransmitting RTA packet #2 because the number of retransmissions of that RTA packet has reached the active retry limit. As will be seen in the figure, receiver station 0 354 does not need to transmit any feedback to station 1 during this process.

[0164] Figure 22 The example embodiment 430 of Example 2-1 is illustrated as a station transmitting multiple RTA packets on a single link with active retry. This example occurs when the LLTS retransmission policy is set to "active retry" and packet duplication in the time domain is allowed. The network topology of this example is Figure 5 Shown in.

[0165] Sender station 1 352 is about to transmit two RTA packets, exemplified by RTA packet #1 and RTA packet #2, to receiver station 0 (AP) 354, and allows active retries to transmit both RTA packets. The RTA packets arrive in a queue 356. After the RTA packets arrive in the queue, sender station 1 contends for the channel 358 and acquires a TXOP duration 360. In this example, station 1 first transmits one packet (i.e., RTA packet #1) 432 using its active retries 436. It then transmits a second packet (i.e., RTA packet #2) 442 using its active retries 446 and 450, and so on. It is also seen that the retransmission of RTA packet #2 has possible backoffs 444 and 448.

[0166] During the TXOP duration, station 1 can transmit the RTA packet with two active retransmissions.Sender station 1 may wait for another backoff time 434, 440, 444, and 448 for a new transmission or retransmission of the RTA packet.

[0167] Sender station 1 stops retransmission 440 of RTA packet #1 because the lifetime of that RTA packet has expired. Sender station 1 stops retransmission 452 of RTA packet #2 because the number of retransmissions of that RTA packet has reached the active retry limit. Receiver station 0 354 does not need to transmit any feedback to station 1.

[0168] Figure 23 An example embodiment 470 is illustrated as Example 3 of Example 3 of a station transmitting an RTA packet on a single link with active retry when BA is enabled. This example occurs when the LLTS retransmission policy is set to "active retry with BA" and packet duplication in the time domain is allowed. The network topology of this example is Figure 6 Shown in.

[0169] Sender station 1 352 is about to transmit an RTA packet to receiver station 0 (AP) 354. Active retries are allowed to transmit the RTA packet. After the RTA packet arrives in the queue 356, sender station 1 contends 358 for the channel and obtains a TXOP duration 360. During the TXOP duration 360, station 1 can transmit the RTA packet 472 using two active retransmissions 476 and 480. The time between the two packet transmissions can be the interframe space (xIFS 474, 478, and 482, as shown in the figure), or another interval 486 (e.g., SIFS or PIFS, etc.). Receiver station 0 354 does not need to transmit any feedback to station 1. When the packet reaches the active retry limit, station 1 can stop retransmitting the RTA packet.

[0170] After station 1 finishes retransmitting the RTA packet, it may transmit a BAR frame 484 to request BA feedback to station 0. Station 0 then receives the BAR and sends back a BA 488 to indicate packet loss for the current packet.

[0171] The BA in this example may not be transmitted for retransmission, but rather for adaptation, such as rate adaptation and proactive retry limit adjustment, for future RTA packet transmissions.

[0172] Figure 24 An example embodiment 490 is illustrated as Example 4 of a station transmitting an RTA packet on a single link with active retry when BA is enabled. This example occurs when the LLTS retransmission policy is set to "active retry with BA" and packet duplication in the time domain is allowed. The network topology of this example is Figure 6 Shown in.

[0173] Sender station 1 352 has four RTA packets to transmit (illustrated here as RTA packet #1 492, RTA packet #2 496, RTA packet #3 512, and RTA packet #4 516) to receiver station 0 (AP) 354. Active retries are allowed to transmit RTA packets.

[0174] The RTA packets arrive 356 in the queue, and then the sending station 1 competes 358 for the channel and obtains the TXOP duration 360. In this example, station 1 first transmits the initial transmission 492, 496 of RTA packets #1 and #2. It then transmits the first retransmission 500, 504 of RTA packets #1 and #2.

[0175] In the lower portion of the figure, station 1 is seen obtaining a TXOP for RTA packets #3 and #4 for the second time. The RTA packet(s) arrive in the queue 506, and then the sending station 1 contends 508 for the channel and obtains a TXOP duration 510. Station 1 then transmits an initial transmission of RTA packet #3 512 and RTA packet #4 516, followed by the first retransmission of RTA packet #3 520 and RTA packet #4 524.

[0176] During the TXOP duration, station 1 can transmit RTA packets with active retransmissions.The time between two consecutive transmissions 494, 498, 502, 514, 518, 522, 526, 530 may include an interframe spacing, such as xIFS, SIFS, PIFS, or other interframe spacing mechanisms.

[0177] In this example, station 1 is shown obtaining a TXOP twice. During the first TXOP, RTA packet #1 and RTA packet #2 are transmitted. During the second TXOP, RTA packet #3 and RTA packet #4 are transmitted. After station 1 completes retransmitting RTA packet #4, it transmits a Block Acknowledgement Request (BAR) frame 528 to station 0 to request BA feedback. Station 0 receives the BAR and responds by sending back a BA 532 to indicate packet loss for the current packet and the previous RTA packets it received (i.e., RTA packets #1, #2, #3, and #4).

[0178] The BA in this example may not be transmitted for retransmission, but rather for adaptation of future RTA packet transmissions, such as rate adaptation and proactive retry limit adjustment.

[0179] Figure 25 An example embodiment 550 is illustrated as an example 5 of an example where a station transmits an RTA packet on a single link with active retry when BA is enabled. This example scenario occurs when the LLTS retransmission policy is set to "active retry with BA" and packet duplication in the time domain is allowed. The network topology of this example is Figure 6 Shown in.

[0180] Sender station 1 352 is about to transmit an RTA packet (RTA packet #1) to receiver station 0 (AP) 354. Active retries are allowed to transmit the RTA packet. The RTA packet 356 arrives in the queue, and sender station 1 contends 358 for the channel and obtains a TXOP duration 360. During the TXOP, station 1 is able to transmit 552 RTA packet #1 using active retransmissions. The time between the two packet transmissions may include a backoff time 554, after which station 1 performs the first retransmission 556 of RTA packet #1. At this point, the number of retransmissions has reached 558 the active retry limit.

[0181] After station 1 completes retransmitting the RTA packet, it transmits a BAR frame 562 to station 0 to request BA feedback. Station 0 receives the BAR and sends back a BA 566 to indicate packet loss information for the current packet. The time between the end of the first retransmission of RTA packet #1 and the BAR frame, and the time between the BAR and BA responses, can be the interframe spacing 560 and 564 (such as xIFS, SIFS, PIFS), or other spacing mechanisms.

[0182] The BA in this example may be transmitted not for retransmission but for adaptation (such as rate adaptation and proactive retry limit adjustment) to assist future RTA packet transmissions.

[0183] Figure 26 The example embodiment 570 is shown as Example 6 of Example 6 where a station transmits an RTA packet on multiple links with active retry. This example scenario occurs when the LLTS retransmission policy is set to "active retry" and packet duplication on multiple links is allowed. The network topology of this example is Figure 6 Shown in.

[0184] Sender MLD1 571 wants to transmit several RTA packets to receiver MLD2 (AP) (not shown) over multiple links. MLD1's station 3 (AP) 572 transmits a packet to MLD2's station 5 (not shown) over link 1, and MLD1's station 4 (AP) 574 transmits a packet to station 6 (not shown) over link 2. Active retries are allowed for transmitting RTA packets over multiple links. The RTA packet arrives 576, and stations 3 and 4 begin contending 578 and 580 for channels on both links 1 and 2.

[0185] During the TXOP on link 1, station 3 first obtains the TXOP duration 582 on link 1 and transmits its initial transmission of RTA packets, depicted as sending RTA packet #1 586, sending RTA packet #2 590, sending RTA packet #3 594, and sending RTA packet #4 598. The time between two packet transmissions can be an interframe spacing (xIFS), SIFS, PIFS, etc.

[0186] Station 4 obtains and retains the TXOP duration 584 on link 2 before the end of the TXOP on link 1. During the TXOP on link 2, station 4 transmits retransmissions of the RTA packets whose initial transmissions were transmitted during the TXOP on link 1. Specifically, station 4 sends first retransmissions 588, 592, and 596.

[0187] The time between two packet transmissions may be an inter-frame spacing, such as xIFS, SIFS, PIFS, or other spacing mechanisms as in other examples of the present disclosure.

[0188] It should be appreciated that if the TXOP duration on Link 2 is insufficient, Station 4 may not be able to retransmit all RTA packets. For example, as shown in this example, the first retransmission of RTA packet #4 is not retransmitted over Link 2 because it cannot be transmitted within the TXOP. RTA packet #4 may be discarded after the TXOP ends, even if its lifetime has not expired. Note that MLD2 does not need to transmit any feedback to indicate the success of the RTA packet transmission. It should also be noted that the number of backoff slots on both links can be the same. Stations 3 and 4 acquire the channel at different times during the countdown backoff period due to the CCA busy time.

[0189] Figure 27 The example embodiment 610 of Example 6-1 is illustrated as a station transmitting RTA packets on multiple links with active retry. This example scenario occurs when the LLTS retransmission policy is set to "active retry" and replication on multiple links is allowed, and as in the other examples, the use Figure 6 The network topology shown in .

[0190] Sender MLD1 571 transmits several RTA packets to receiver MLD2 (AP) (not shown) over multiple links. MLD1's station 3 572 transmits packets to MLD2's station 5 (not shown) over link 1, and MLD1's station 4 574 transmits packets to station 6 (not shown) over link 2. Active retries are allowed for the transmission of RTA packets over multiple links.

[0191] The RTA packet arrives 576 and stations 3 and 4 begin contending 578, 580 for channels on both Link 1 and Link 2. Station 3 first gains channel access on Link 1 and reserves the TXOP duration 582. Station 1 is then able to transmit an initial transmission of the RTA packet during the TXOP on Link 1. More specifically, in this example, station 3 sends 612, 616, 620, and 624 RTA packets #1, #2, #3, and #4.

[0192] As in other examples, the time between two packet transmissions can be an interframe spacing, such as xIFS, or other spacing mechanism. Based on the time when station 4 obtains the TXOP, the duration of xIFS can be adjusted to align 628 the end of the last PPDU transmitted in the TXOP on both links. For example, as shown in the figure, the end of the initial transmission of RTA packet #4 is aligned with the end of the first retransmission 626 of RTA packet #4. Since the transmission of RTA packets #1 to #4 on both links is known, the duration of xIFS can be calculated when station 4 obtains channel access on link 2. xIFS can be longer than SIFS but shorter than PIFS.

[0193] Station 4 acquires a TXOP duration 584 on link 2 and reserves it until the TXOP on link 1 ends. During the TXOP on link 2, station 4 transmits retransmissions 614, 618, 622, and 626 of RTA packets (RTA packets #1, #2, #3, and #4) whose initial transmissions were transmitted during the TXOP on link 1. The time between two packet transmissions is a form of interframe spacing, but since station 4 acquires the channel later than station 3, it is preferably a short interframe spacing (SIFS). The number of backoff slots on both links can be the same. Due to the CCA busy time during the countdown backoff period, stations 3 and 4 acquire the channel at different times.

[0194] Figure 28 The diagram shows an example embodiment 630 of Example 6-1-1 where a station transmits an RTA packet on multiple links using active retry. This example scenario occurs when the LLTS retransmission policy is set to "active retry" and packet replication on multiple links is allowed. The network topology of this example is Figure 6 This example shows that packet duplication in multi-link transmission can be performed when the end times of the reserved TXOPs on the two links are different, which occurs when the AP MLD and the non-AP MLD are STR. This can also occur when the AP MLD is either STR or NSTR, and the non-AP MLD is either STR or NSTR.

[0195] Sender MLD1 571 transmits several RTA packets to receiver MLD2 (AP) (not shown) over multiple links. MLD1's station 3 572 transmits packets to MLD2's station 5 (not shown) over link 1, and MLD1's station 4 574 transmits packets to station 6 (not shown) over link 2. Active retries are allowed for the transmission of RTA packets over multiple links.

[0196] The RTA packet arrives 576 and stations 3 and 4 begin contending 578, 580 for channels on both Link 1 and Link 2. Station 3 first acquires a TXOP duration 582 on Link 1. Station 1 is then able to transmit initial transmissions 632, 636, 640, and 644 of RTA packets (#1, #2, #3, and #4) during the TXOP on Link 1.

[0197] The time between two consecutive packet transmissions may be an inter-frame spacing, such as xIFS, SIFS, PIFS, or other spacing mechanism.

[0198] Station 4 obtains the TXOP duration 584 on link 2 before the end of the TXOP on link 1. Station 4 retains a TXOP whose end time is different from the end time of the TXOP on link 1. During the TXOP on link 2, station 4 transmits retransmissions 634, 638, 642, and 646 of the RTA packets (#1, #2, #3, and #4) whose initial transmissions were transmitted during the TXOP on link 1.

[0199] It should be appreciated that MLD2 does not need to transmit any feedback to indicate the success of the RTA packet transmission. The number of backoff slots on both links can be the same. Station 3 and station 4 acquire the channel at different times during the countdown backoff period due to the CCA busy time.

[0200] Figure 29 An example embodiment 650 of Example 6-2 is illustrated as an example of a station transmitting an RTA packet on multiple links with active retry when BA is allowed. This example scenario occurs when the LLTS retransmission policy is set to "active retry with BA" and packet replication on multiple links is allowed. The network topology of this example is again in Figure 6 Shown in.

[0201] Sender MLD1 571 transmits several RTA packets to receiver MLD2 (AP) (not shown) over multiple links. MLD1's station 3 572 transmits packets to MLD2's station 5 (not shown) over link 1, and MLD1's station 4 574 transmits packets to station 6 (not shown) over link 2. Active retries are allowed for the transmission of RTA packets over multiple links.

[0202] The RTA packet arrives 576 and stations 3 and 4 begin contending 578, 580 for channels on both Link 1 and Link 2. Station 3 first gains channel access and reserves a TXOP duration 582 on Link 1. Station 1 can then transmit the initial transmissions 652, 656, 660, and 664 of RTA packets (#1, #2, #3, and #4) during the TXOP on Link 1. The time between packet transmissions can be any desired interframe spacing, such as xIFS, SIFS, PIFS, or other spacing whose duration can be fixed (deterministic).

[0203] Station 4 obtains and reserves the TXOP duration 584 on link 2 until the TXOP on link 1 ends. During the TXOP on link 2, station 4 transmits retransmissions 654, 658, 662 of the RTA packet that it initially transmitted during the TXOP on link 1. Again, the time between the two packet transmissions may be an interframe spacing, such as xIFS, SIFS, PIFS, or other spacing mechanism.

[0204] In this example, station 4 decides to transmit a BAR frame 666 before the end of the TXOP to request BA feedback from station 6. BA feedback 668 should contain packet loss information for both links. By way of example, the BA frame may indicate that the initial transmission of RTA packets #1, #3, and #4 on link 1 was successful, while the initial transmission of RTA packet #2 failed. The first retransmission of RTA packets #1 and #3 was successful, but the first retransmission of RTA packet #2 failed.

[0205] The BA in this example may not be transmitted for retransmission but for adaptation of future RTA packet transmission (such as rate adaptation and active retry limiting). The BA can also be used to select which links will be selected to transmit RTA packets and their active retry to meet the packet loss requirements of the RTA service.

[0206] The number of backoff slots on both links can be the same. Station 3 and Station 4 gain channel access at different times during the countdown backoff period due to the CCA busy time. The BAR and BA frame formats are as follows: Figure 33 and Figure 34 Shown in.

[0207] Figure 30 The example embodiment 670 of Example 6-3 is illustrated as a station transmitting RTA packets on multiple links with active retry when BA is allowed. This example scenario occurs when the LLTS retransmission policy is set to "active retry" and packet duplication on multiple links is allowed. The network topology of this example is Figure 6 Shown in.

[0208] Sender MLD1 571 transmits several RTA packets to receiver MLD2 (AP) (not shown) over multiple links. MLD1's station 3 572 transmits packets to MLD2's station 5 (not shown) over link 1, and MLD1's station 4 574 transmits packets to station 6 (not shown) over link 2. Active retries are allowed for the transmission of RTA packets over multiple links.

[0209] The RTA packet arrives 576 and stations 3 and 4 begin contending 578, 580 for channels on both Link 1 and Link 2. Station 3 obtains a first TXOP duration 582 on Link 1. Station 3 can then transmit initial transmissions 672, 676, 680, and 684 of RTA packets (#1, #2, #3, and #4) during the TXOP on Link 1. The time between packet transmissions can be the interframe spacing xIFS, SIFS, PIFS, or a similar spacing mechanism.

[0210] Station 4 acquires and reserves the TXOP duration on link 2 before the end of the first TXOP 582 on link 1. During the first TXOP on link 2, station 4 transmits 674, 678, and 682 retransmissions of the RTA packets (#1, #2, and #3) whose initial transmissions were transmitted during the first TXOP on link 1. The time between the two packet transmissions can be an interframe spacing, such as xIFS, SIFS, PIFS, or a similar spacing mechanism. Station 4 may not be able to retransmit all RTA packets because the TXOP duration on link 2 is not long enough. For example, as shown in this example, the first retransmission of RTA packet #4 is not transmitted over link 2 because it cannot be transmitted within the TXOP interval 584.

[0211] After the first TXOP ends, stations 3 and 4 in this example reset their backoffs 686 and 688 to contend for channels on both Link 1 and Link 2. The number of backoff slots on both links can be the same. Stations 3 and 4 acquire the channel at different times during the countdown backoff period due to the CCA busy time.

[0212] Stations 4 and 3 then also obtain a second TXOP as shown. Station 4 obtains a second TXOP 690 on link 2 and transmits 692 a retransmission of RTA packet #4. Station 3 obtains a second TXOP 694 to continue transmitting initial transmissions 696, 700, and 704 on link 1 to send packets #5, #6, and #7. Station 4 is seen performing retransmissions 698, 702, and 706 on link 2 to send RTA packets #5, #6, and #7 that it first transmitted in the second TXOP on link 1. It should be noted that during the second TXOP on link 2, if the lifetime of RTA packet #4 has not expired, then station 4 can transmit its retransmissions, such as the first retransmission of RTA packet #4, during the second TXOP.

[0213] Figure 31 An example embodiment 710 is illustrated as an example 7 of a station transmitting an RTA packet on multiple links with active retry when BA is allowed. This example scenario occurs when the LLTS retransmission policy is set to "active retry with BA" and packet duplication in multiple links is allowed. The network topology of this example is Figure 6 Shown in.

[0214] Sender MLD1 571 transmits several RTA packets to receiver MLD2 (AP) (not shown) over multiple links. MLD1's station 3 572 transmits packets to MLD2's station 5 (not shown) over link 1, and MLD1's station 4 574 transmits packets to station 6 (not shown) over link 2. Active retries are allowed for the transmission of RTA packets over multiple links.

[0215] The RTA packet arrives 576, and stations 3 and 4 begin contending for channels 578 and 580 on both Link 1 and Link 2. Stations 3 and 4 simultaneously gain channel access 582 and 584 on Link 1 and reserve the TXOP duration. Station 1 transmits initial transmissions 712, 716, 720, and 724 of RTA packets (#1, #2, #3, and #4) during the TXOP on Link 1. Station 4 transmits 714, 718, and 722 on Link 2, which are retransmissions of RTA packets (#1, #2, and #3) whose initial transmissions were transmitted during the same TXOP on Link 1.

[0216] The time between two packet transmissions may be the inter-frame spacing xIFS, SIFS, PIFS, or a similar spacing mechanism whose duration may be fixed (deterministic).

[0217] Stations 3 and 4 may decide to transmit BAR frames 724, 726 before the end of the TXOP to request BA feedback from stations 5 and 6. The BAR and BA frames transmitted over link 2 are identical to those transmitted over link 1. The BA feedback 728, 730 preferably contains packet loss information for both links.

[0218] For example, the BA frame may indicate that the initial transmission of RTA packets #1 and #3 on link 1 was successful, while the initial transmission of RTA packet #2 failed, and similarly, the first retransmission of RTA packets #1 and #2 was successful, but the first retransmission of RTA packet #3 failed.

[0219] The BA in this example may not be transmitted for retransmission but for adaptation of future RTA packet transmissions (such as rate adaptation and proactive retry limiting). The BA may also be used to select which links will be used to transmit RTA packets and their proactive retry to meet the packet loss requirements of the RTA service.

[0220] It should be appreciated that it is possible that the number of backoff slots on both links may be the same. It should be noted that when one backoff time count reaches zero and the station waits for another PIFS time to access Link 1 and Link 2, Station 3 and Station 4 may obtain channel access on Link 1 and Link 2 simultaneously.

[0221] BAR and BA frame formats are Figure 33 and Figure 34 As shown in FIG. BAR and BA frames may only carry BA information of the link on which the BAR and BA frames are transmitted. For example, BAR and BA frames transmitted on link 1 may only carry BA information of link 1.

[0222] Figure 32 An example embodiment 750 is shown as an example 8 of a station utilizing active retry transmission of RTA packets on multiple links. The network topology of this example is Figure 6 Shown in.

[0223] AP MLD1 571 will receive several RTA packets from MLD2 (non-AP) (not shown) over multiple links. MLD1's Station 3 572 is associated with MLD2's Station 5 (not shown) over Link 1, and MLD1's Station 4 574 is associated with Station 6 (not shown) over Link 2. Active retries are allowed for the transmission of RTA packets over multiple links.

[0224] When stations 3 and 4 learn that an RTA packet has arrived in the queue, they simultaneously begin contending for channels on Link 1 and Link 2 (578, 580). Stations 3 and 4 simultaneously gain channel access on Link 1 (582) and Link 2 (584) and reserve the TXOP duration. Stations 3 and 4 transmit identical trigger frames (TFs) 752 and 754 to stations 5 and 6, respectively. Upon receiving the trigger frames, station 5 transmits 756 and 760 its initial transmission of RTA packets #2 and #3 during the TXOP on Link 1. Station 6 transmits 758 and 762 retransmissions of RTA packets #2 and #3, whose initial transmissions were transmitted during the TXOP on Link 1. The time between packet transmissions can be an interframe spacing (IFS), such as xIFS, SIFS, PIFS, or a similar spacing mechanism whose duration can be fixed (deterministic).

[0225] The format of the TF can be similar to that defined in IEEE 802.11ax. It should be noted that stations 3 and 4 can gain channel access at different times. If the TF ends on both links can be aligned, uplink transmissions and retransmissions over both links can occur, as shown in this example. The number of backoff slots on both links can be the same.

[0226] Figure 33 An example embodiment 770 of the format of a Block Acknowledgement Request (BAR) frame is illustrated. The purpose of this frame is to request Block Acknowledgement (BA) information on multiple links in one BA exchange. While the BA information exchange on each link can still follow the current IEEE 802.11 protocol, it is not limited to using that mechanism.

[0227] The BAR frame contains the following fields. The "Frame Control" field indicates the frame type. The "Duration" field contains the NAV information used for CSMA / CA channel access. The "RA" field contains the address of the frame's receiver. The "TA" field contains the address of the station transmitting the frame. The "BA Control" field indicates the type of BA request and the type of Block ACK request variant in the "BAR Information" field. The format of the "BA Control" field is shown in the lower part of the figure.

[0228] Specifically, in at least one embodiment, the bits between B5 and B11 in the BA Control field defined in the current IEEE 802.11 protocol that are reserved are used in the present disclosure. By way of example and not limitation, a bit in a subfield called the Multilink Mode field is used to indicate that the BAR frame will request information for multiple links. When the "Multilink Mode" field is set to a first state (e.g., "1"), the "BAR Information" field in the BAR frame will carry the corresponding BlockAckReq variants for the multiple links. When the "Multilink Mode" field is set to a second state (e.g., "0"), the "BAR Information" field will carry the corresponding BlockAckReq variants as defined in the current IEEE 802.11 protocol as shown in Table 7. The remaining bits of the "BA Control" field are the same as those defined in the current IEEE 802.11 protocol.

[0229] The "BAR Information" field is used to carry the corresponding BlockAckReq variant based on the setting in the "BA Control" field. In this case, the figure shows the format of the "BAR Information" field when the "Multi-Link Mode" field is set to the first state (e.g., "1"). In this way, when a station receives this BAR frame, it can send corresponding BA information for multiple links in a single BA frame. The subfields in the BAR Information are as follows.

[0230] The "Link Information" subfield indicates the link to which the following BlockAckReq variant applies. The "Length" subfield indicates the length of the "BlockAckReq Variant" field relative to the link. The "BlockAckReq Variant" subfield carries the corresponding BlockAckReq variant defined in IEEE 802.11. The BlockAckReq type and its corresponding parameter settings in the "BA Control" field are shown in Table 7. The receiving station can respond to the corresponding BA information for each link in accordance with the rules of the current IEEE 802.11 protocol and place them in a single BA frame. It should be noted that the above three fields are added to the "BAR Information" field for each link.

[0231] Figure 34 An example embodiment 790 of the format of a BA response frame is shown. The purpose of this frame is to respond with BA information on multiple links in one BA exchange. At the same time, the BA information exchange on each link can still follow the current IEEE 802.11 protocol.

[0232] The "Frame Control" field indicates the frame type. The "Duration" field contains the NAV information used for CSMA / CA channel access. The "RA" field contains the address of the frame's receiver. The "TA" field contains the address of the station transmitting the frame. The "BA Control" field indicates the type of BA request and the type of Block ACK request variant in the "BAR Information" field. The format of the "BA Control" field is shown in the lower portion of the figure.

[0233] Specifically, in at least one embodiment, the bits between B5 and B11 are reserved in the BA Control field defined in the current IEEE 802.11 protocol. By way of example and not limitation, the present disclosure uses one of these previously reserved bits as a "Multi-Link Mode" subfield to indicate that the BA frame will provide information about multiple links. When the "Multi-Link Mode" field is set to a first state (e.g., "1"), the "BA Information" field carries the corresponding BlockAck variants for the multiple links. When the "Multi-Link Mode" field is set to a second state (e.g., "0"), the "BA Information" field carries the corresponding BlockAck variants as defined in the current IEEE 802.11 protocol, as shown in Table 8. The remaining bits of the "BA Control" field are preferably the same as those defined in the current IEEE 802.11 protocol.

[0234] The "BA Information" field is used to carry the corresponding BlockAck variant according to the setting in the "BA Control" field. In this case, the figure shows the format of the "BA Information" field when the "Multi-Link Mode" field is set to the first state (e.g., "1"). In this way, when a station receives this BA frame, it can recognize that the "BA Information" field carries BlockAck variants for multiple links. The "Link Information" subfield indicates to which link the following BlockAck variant will apply. The "Length" subfield indicates the length of the "BlockAck Variant" field relative to the link. The "BlockAck Variant" subfield carries the corresponding BlockAck variant defined in IEEE802.11. The type of BlockAck in the "BA Control" field and its corresponding parameter settings are shown in Table 8. The receiving station can receive packet failure information for each link from the "BlockAck Variant" field. It should be noted that the above three fields are added to the "BA Information" field of each link.

[0235] Figure 35 The example embodiment 810 is shown as Example 9 where a station utilizes active retry transmission of RTA packets on multiple links. The network topology of this example is Figure 6 Shown in.

[0236] Sender MLD1 571 transmits several RTA packets to receiver MLD2 (AP) (not shown) over multiple links. MLD1's station 3 572 transmits packets to MLD2's station 5 (not shown) over link 1, and MLD1's station 4 574 transmits packets to station 6 (not shown) over link 2. Active retries are allowed for the transmission of RTA packets over multiple links.

[0237] After the RTA packet arrives, stations 3 and 4 begin contending for channels 578 and 580 on links 1 and 2 simultaneously. Station 3 obtains TXOP 582 on link 1 and station 4 obtains TXOP 584 on link 2. Stations 3 and 4 may obtain channel access on links 1 and 2 at different times, but their TXOP end times are the same. The duration of the TXOP on each link is truncated (ordered) by a downlink period (i.e., DL as shown in the figure) and an uplink period (i.e., UL as shown in the figure). The start times of the first DL periods 812 and 814 on the two links may be different, but the end times of those two DL periods should be aligned.

[0238] The figure then depicts interspersed UL and DL cycles 816, 818, 820, 822, 824, and 826, with the ends of these cycles on the two links aligned as shown. When a DL cycle is about to switch to an UL cycle, stations 3 and 4 can simultaneously transmit duplicate TFs on both links to request UL transmission. When the UL cycle ends, AP MLD can start another DL cycle 828 on both links, and backoffs 830 and 832 begin.

[0239] In both the DL and UL cycles, station 3 transmits or receives the initial transmission of a packet via link 1, and station 4 transmits or receives a retransmission of a packet via link 2. The first DL cycle in the figure can be aligned with the end time of the DL cycle using the method described in previous examples (such as Example 6-1). In addition, it should be noted that the number of backoff slots on both links can be the same. Stations 3 and 4 can acquire the channel at different times during the countdown backoff period due to the CCA busy time.

[0240] Figure 36 The example embodiment 850 is illustrated as an example 10 of a station transmitting an RTA packet on a single link with active retry. This example scenario occurs when the LLTS retransmission policy is set to "active retry" and packet duplication in the RU is allowed. The network topology of this example is Figure 6 is shown in, and Figure 36 Interactions between a receiver, illustrated as station 0 (AP) 852, and senders station 1 854 and station 2 856 are depicted.

[0241] Station 0 (AP) receives RTA packets from Stations 1 and 2. Active retries are allowed for RTA packet transmission. When Station 0 gains channel access, it sends a TF 858 to Stations 1 and 2. The format of the TF can be similar to, but not limited to, the TF defined in IEEE 802.11ax. Based on the TF, Station 0 assigns RU1 and RU3 to Station 1 for RTA packet transmission, and Station 0 assigns RU2 and RU4 to Station 2 for RTA packet transmission.

[0242] Station 1 transmits a frame having a header 860 and containing an initial transmission 864 of RTA packet #1 on RU1 and a retransmission 866 of RTA packet #1 on RU3.

[0243] Station 2 transmits a frame having a header 862 and containing an initial transmission 868 of RTA packet #2 on RU2 and a retransmission 870 of RTA packet #2 on RU4.

[0244] It should be appreciated that stations 1 and 2 may set the retry subfield to a first state (eg, "1") in the MAC header of the initial transmissions of RTA packets #1 and #2 for packet duplication detection.

[0245] Figure 37 The example embodiment 890 is illustrated as an example 11 of a station transmitting an RTA packet on a single link with active retry. This example scenario occurs when the LLTS retransmission policy is set to "active retry" and packet duplication in the RU is allowed. The network topology of this example is Figure 6 Shown in and Figure 36 Interactions between a receiver, illustrated as station 0 (AP) 892, and senders station 1 894 and station 2 896 are depicted.

[0246] Station 0 (AP) wants to transmit an RTA packet to station 1 and station 2. Active retries are allowed to transmit RTA packets. When station 0 obtains channel access, it sends a MU-PPDU packet to station 1 and station 2. The format of the MU-PPDU packet can be similar to the MU PPDU defined in IEEE 802.11ax. In this example, a packet with a header 898 is seen, where the RUs used are as follows. Station 0 uses RU1 to transmit the initial transmission 900 of RTA packet #1 and uses RU3 to transmit the retransmission 904 of RTA packet #1. Station 0 uses RU2 to transmit the initial transmission 902 of RTA packet #2 and uses RU4 to transmit the retransmission 906 of RTA packet #2. It should be noted that station 0 can set the retry subfield to the first state (e.g., "1") in the MAC header of the initial transmission of RTA packets #1 and #2 for packet duplication detection.

[0247] It should be appreciated that in this and previous examples, RUs may be selected for performing transmissions and retransmissions as desired and are therefore not limited by these specific illustrative examples.

[0248] 5. General Scope of the Embodiments

[0249] The enhancements described in the proposed technology can be readily implemented in various wireless network communication stations. It should also be appreciated that the wireless network communication station is preferably implemented as a computer comprising one or more computer processor devices (e.g., CPUs, microprocessors, microcontrollers, computer-enabled ASICs, etc.) and associated memory (e.g., RAM, DRAM, NVRAM, FLASH, computer-readable media, etc.) storing instructions, wherein the programming (instructions) stored in the memory are executed on the processor to perform the steps of the various processing methods described herein.

[0250] For simplicity of illustration, the computer and memory devices are selectively depicted, as one of ordinary skill in the art recognizes the use of computer devices to perform steps associated with digital wireless communication. The techniques presented are non-limiting with respect to memory and computer-readable media, as long as they are non-transitory and therefore do not constitute transient electronic signals.

[0251] The embodiments of the present technology may be described herein with reference to flowchart illustrations of the methods and systems according to the embodiments of the present technology, and / or processes, algorithms, steps, operations, formulas or other computational depictions that may also be implemented as computer program products. In this regard, each box or step of the flowchart, the combination of boxes (and / or steps) in the flowchart, and any process, algorithm, step, operation, formula or computational depiction may be implemented by various means, such as hardware, firmware and / or software comprising one or more computer program instructions contained in a computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors (including but not limited to general-purpose or special-purpose computers, or other programmable processing devices that produce machines) so that the computer program instructions executed on (one or more) computer processors or other programmable processing devices create means for implementing the specified (one or more) functions.

[0252] Thus, the blocks of the flowcharts described herein and the processes, algorithms, steps, operations, formulas, or calculations depictions support a combination of means for performing (one or more) specified functions, a combination of steps for performing (one or more) specified functions, and computer program instructions (such as implemented in computer-readable program code logic means) for performing (one or more) specified functions. It will also be understood that each block of the flowchart illustrations described herein and any process, algorithm, step, operation, formula, or calculation depictions and combinations thereof can be implemented by a dedicated hardware-based computer system or a combination of dedicated hardware and computer-readable program code that performs the specified (one or more) functions or (one or more) steps.

[0253] In addition, these computer program instructions, such as those embodied in computer-readable program code, may also be stored in one or more computer-readable memories or memory devices, which may 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 device produce an article of manufacture comprising instruction means for implementing the functions 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 operable steps to be performed on the computer processor or other programmable processing apparatus to produce a computer-implemented process such that the instructions executed on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the block(s), process(es), algorithm(s), step(s), operation(s), formula(s), or calculation(s) depiction(s) of the flowchart(s).

[0254] It will also be appreciated that the terms "programmed" or "program executable" as used herein 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 may be implemented as software, firmware, or a combination of software and firmware. The instructions may be stored locally in the device on a non-transitory medium, or may be stored remotely such as on a server, or all or part of the instructions may be stored locally and remotely. Remotely stored instructions may be downloaded (pushed) to the device by user initiation or automatically based on one or more factors.

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

[0256] It will be appreciated from the description herein that the present disclosure encompasses a number of embodiments including, but not limited to, the following:

[0257] 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured as a first wireless station for wirelessly communicating with at least one other wireless station on a local area network (WLAN) in a reception area of the first wireless station over at least one channel; (b) the first wireless station comprising a processor configured to operate on the WLAN; (c) a non-volatile memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform the following steps: (d) (i) operating the wireless communication circuitry as a wireless local area network (WLAN) station, the wireless local area network (WLAN) station being configured to support transmission over a network supporting carrier sense multiple access / collision avoidance (CSMA / CA) Real-time application (RTA) packets and non-real-time packets that are sensitive to communication delays, wherein the real-time application (RTA) traffic and the non-RTA traffic coexist and the RTA traffic is given a higher transmission priority than lower priority traffic; (d)(ii) distinguishing the real-time application (RTA) packets from the non-real-time application (non-RTA) packets; (d)(iii) setting an active retry policy for the RTA packets, wherein a station retransmits the RTA packets on a time, frequency, or other link according to the active retry policy without waiting for feedback; (d)(iv) setting a block acknowledgment protocol to receive feedback for adaptation of future packet transmissions; and (d)(v) discarding the RTA packet if a retry count of the RTA packet exceeds an active retry limit or the lifetime of the RTA packet has expired.

[0258] 2. An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry configured as a first wireless station for wirelessly communicating with at least one other wireless station on a local area network (WLAN) in a reception area of the first wireless station over at least one channel; (b) the first wireless station comprising a processor configured to operate on the WLAN; (c) a non-transitory memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform steps comprising: (d)(i) operating the wireless communication circuitry as a wireless local area network (WLAN) station, the wireless local area network (WLAN) station being configured to support transmission of real-time application (RTA) packets and non-real-time packets that are sensitive to communication delays over a network that supports carrier sense multiple access / collision avoidance (CSMA / CA) and multi-link operation, wherein the real-time application (RTA) traffic and the non-RTA traffic coexist and the RTA traffic is given a higher transmission priority than lower priority traffic; (d)(ii) distinguishing between real-time application (RTA) packets and non-real-time application (non-RTA) packets; (d)(iii) setting an active retry policy for the RTA packets, wherein the station retransmitting the RTA packet at a time and frequency or other link according to the active retry strategy without waiting for feedback; (d)(iv) setting an active retry strategy for the RTA packet in a multi-link scenario by a station including a multi-link device (MLD); (d)(v) the multi-link device (MLD) starting a countdown of a backoff time to contend for channel access on multiple links simultaneously; (d)(vi) when the backoff time on a first link counts down to zero, obtaining channel access for the first link by the multi-link device (MLD); (d)(vii) reserving a transmission mechanism by the multi-link device (MLD); (d)(x) resetting the backoff times on the first link and the other links when the TXOP on the first link ends.

[0259] 3. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit configured as a first wireless station for wirelessly communicating with at least one other wireless station on a local area network (WLAN) in a reception area of the first wireless station via at least one channel; (b) the first wireless station comprising a processor configured to operate on the WLAN; (c) a non-volatile memory storing instructions executable by the processor; and (d) wherein the instructions, when executed by the processor, perform: (d) (i) operating the wireless communication circuit as a wireless local area network (WLAN) station configured to support carrier sense multiple access / collision avoidance (CSMA / CA) and multi-link (d) (ii) distinguishing between real-time application (RTA) packets and non-real-time application (non-RTA) packets; and (d) (iii) setting an active retry policy for RTA packets in a multi-link scenario by a station including a multi-link device (MLD), the multi-link device (MLD) being either an access point multi-link device (AP-MLD) configured for simultaneous transmission / reception (STR) or a non-access point multi-link device (non-AP-MLD) not configured for simultaneous transmission / reception (non-STR). MLD); (d)(iv) obtaining, by the AP-MLD, a TXOP for transmission to a non-APMLD, starting with setting the backoff time on all links to a random number for contention for a channel; (d)(v) independently counting down, by the AP-MLD, the backoff time on each link so as to obtain channel access on that link when the backoff time on each link counts down to zero; (d)(vi) reserving the TXOP on the first link when the first link obtains channel access; (d)(vii) reserving the TXOP on the other link if the AP-MLD obtains channel access on the other link before the end of the TXOP for the first link, and limiting the end time of the TXOP on the other link to be no later than the end time of the TXOP for the first link; and (d)(viii) failing to obtain a TXOP on the first link or the other link when the AP-MLD does not obtain channel access before the end of the TXOP for the first link.

[0260] 4. A wireless communication system / device for performing packet transmission, wherein CSMA / CA is applied, and real-time application (RTA) services and non-RTA services coexist in the system / device, comprising: (a) a station sets an active retry strategy for RTA packets; (b) the station retransmits the RTA packets according to the time and frequency or other links under this active retry strategy without waiting for feedback; (c) the station sets a block ACK protocol to receive feedback for adaptation of future packet transmission; (d) if the retry count of the RTA packet exceeds the active retry limit or the lifetime of the RTA packet expires, the station discards the RTA packet.

[0261] 5. A wireless communication system / apparatus for performing packet transmission, wherein CSMA / CA is applied, and real-time application (RTA) traffic and non-RTA traffic coexist in the system / apparatus, comprising: (a) a station distinguishing between RTA traffic and non-RTA traffic; and (b) a station transmitting or retransmitting the same RTA packet multiple times in the same TXOP without waiting for feedback.

[0262] 6. A wireless communication system / device for performing packet transmission, wherein CSMA / CA is applied, and real-time application (RTA) services and non-RTA services coexist in the system / device, comprising: (a) a station distinguishing between RTA services and non-RTA services; (b) a station setting an active retry policy for the RTA services; and (c) a station transmitting or retransmitting the same RTA packet multiple times according to the active retry policy without waiting for feedback.

[0263] 7. A wireless communication system / device that performs packet transmission, wherein CSMA / CA is applied, real-time application (RTA) services and non-RTA services coexist in the system / device, and the RTA connection-oriented communication established between stations by the application is called an RTA session, including: (a) an initiator station sends a request frame for setting a low-latency transport service (LLTS) for a service used to identify the RTA session to a receiver station; (b) the receiver station that receives the request frame sends a response frame back to the initiator station; (c) when the initiator station receives a response frame granting LLTS, the LLTS is successfully established.

[0264] 8. The apparatus or system of any preceding embodiment, wherein the active retry policy for RTA packets further comprises establishing an active retry limit.

[0265] 9. The apparatus or system of any preceding embodiment, wherein the active retry policy for RTA packets further comprises allowing the active retry policy to be changed at any time.

[0266] 10. The apparatus or system of any preceding embodiment, wherein the active retry policy for RTA packets further comprises allowing a station setting the active retry policy to terminate the active retry policy at any time.

[0267] 11. An apparatus or system as in any preceding embodiment, wherein the instructions, when executed by a processor, further perform one or more steps, the one or more steps comprising retransmitting the same MAC protocol data unit (MPDU) in the same TXOP when retransmitting an RTA packet under the active retry policy.

[0268] 12. An apparatus or system as in any preceding embodiment, wherein the PPDU is a physical layer consistency procedure (PLCP) protocol data unit (PPDU); and wherein the instructions, when executed by a processor, further perform the following operations: enabling an access point (AP) station to retransmit the RTA packet under the active retry policy by transmitting an initial transmission of the RTA packet on a resource unit (RU) of a multi-user (MU) PPDU packet and transmitting a retransmission thereof on another RU of the MU-PPDU packet.

[0269] 13. An apparatus or system as in any preceding embodiment, wherein the PPDU is a physical layer consistency procedure (PLCP) protocol data unit (PPDU); and wherein the instructions, when executed by a processor, further perform the following operations: enabling a non-access point station to retransmit the RTA packet under the active retry strategy by transmitting an initial transmission of the RTA packet on a resource unit (RU) of a trigger-based (TB) PPDU packet and transmitting a retransmission thereof on another RU of the TB-PPDU packet.

[0270] 14. An apparatus or system as in any preceding embodiment, wherein the instructions, when executed by the processor, further perform the following operations: enabling a station to retransmit an RTA packet under the proactive retry policy by transmitting a retransmission of the RTA packet after the station completes its initial transmission of the RTA packet without receiving prior feedback regarding receipt of the packet.

[0271] 15. The apparatus or system of any preceding embodiment, wherein the instructions, when executed by a processor, further perform the following operations: adjusting the proactive retry limit for future transmissions based on feedback received by the station transmitting the RTA packet.

[0272] 16. The apparatus or system of any preceding embodiment, wherein the instructions, when executed by a processor, further perform the following operations: adjusting a modulation and coding scheme (MCS) being used based on feedback received by a station transmitting the RTA packet.

[0273] 17. The apparatus or system of any preceding embodiment, wherein the instructions, when executed by a processor, are for contending for channel access on a plurality of links further comprising reserving a transmission opportunity (TXOP) for non-RTA packet transmission as well as RTA packet transmission.

[0274] 18. The apparatus or system of any preceding embodiment, wherein the instructions, when executed by a processor, are for executing the active retry strategy for RTA packets in a multi-link scenario further comprising receiving a block acknowledgement (BA) frame to report packet loss for each link.

[0275] 19. The apparatus or system of any preceding embodiment, wherein a block acknowledgement (BA) frame received by a multi-link device (MLD) on one link is configured to contain packet loss information for the first link and the other links.

[0276] 20. An apparatus or system as in any preceding embodiment, wherein after the multi-link device (MLD) receives a block acknowledgment (BA) frame, the instructions, when executed by the processor, further utilize packet loss information in the BA frame when determining which link to use for future RTA packet transmissions.

[0277] 21. The apparatus or system of any preceding embodiment, wherein the instructions, when executed by a processor, for resetting backoff times on the first link and the other links further comprise resetting backoff times for an equal number of backoff slots on the first link and the other links.

[0278] 22. The apparatus or system of any preceding embodiment, wherein the station setting the active retry policy for the RTA packet performs setting the active retry limit.

[0279] 23. The apparatus or system of any preceding embodiment, wherein a station that sets an active retry policy for an RTA packet performs a change of the active retry policy at any time.

[0280] 24. The apparatus or system of any preceding embodiment, wherein a station that sets an active retry policy for an RTA packet terminates the active retry policy at any time.

[0281] 25. The apparatus or system of any preceding embodiment, wherein a station retransmitting an RTA packet under the active retry policy performs a retransmission of the same MAC protocol data unit (MPDU) in the same TXOP.

[0282] 26. An apparatus or system as in any preceding embodiment, wherein an AP that retransmits an RTA packet under such an active retry policy transmits the initial transmission of the RTA packet on a RU of a MU-PPDU packet and transmits its retransmission on another RU of that MU-PPDU packet.

[0283] 27. An apparatus or system as in any preceding embodiment, wherein a non-AP station that retransmits an RTA packet under such an active retry policy transmits an initial transmission of the RTA packet on a RU of a TB-PPDU packet and transmits its retransmission on another RU of that TB-PPDU packet.

[0284] 28. The apparatus or system of any preceding embodiment, wherein a station that retransmits an RTA packet under the active retry policy transmits the retransmission of the RTA packet immediately after the station completes the initial transmission of that RTA packet without receiving any feedback.

[0285] 29. The apparatus or system of any preceding embodiment, wherein the station receiving the feedback performs adjusting the proactive retry limit based on the feedback.

[0286] 30. The apparatus or system of any preceding embodiment, wherein the station receiving the feedback adjusts the MCS based on the feedback.

[0287] 31. The apparatus or system of any preceding embodiment, wherein the station that distinguishes RTA traffic from non-RTA traffic performs setting LLTS for RTA packets.

[0288] 32. The apparatus or system of any preceding embodiment, wherein a station that performs transmission or retransmission of an RTA packet without waiting for feedback then performs an active retry limit that sets a maximum number of retransmissions of the RTA packet using active retry.

[0289] 33. The apparatus or system of any preceding embodiment, wherein a station that transmits an RTA packet multiple times without waiting for feedback performs retransmissions of the same RTA packet at different times in the same TXOP.

[0290] 34. The apparatus or system of any preceding embodiment, wherein a station that transmits an RTA packet multiple times without waiting for feedback performs retransmission of the same RTA packet on different RUs of a single MU-PPDU or TB-PPDU.

[0291] 35. The apparatus or system of any preceding embodiment, wherein a station affiliated with an MLD that transmits an RTA packet multiple times on one link without waiting for feedback performs a procedure to have other stations affiliated with the same MLD retransmit the same RTA packet on other links.

[0292] 36. The apparatus or system of any preceding embodiment, wherein a station that transmits an RTA packet multiple times without waiting for feedback performs contention for the channel again when it transmits the same RTA packet again in the same TXOP.

[0293] 37. The apparatus or system of any preceding embodiment, wherein a station that transmits an RTA packet multiple times without waiting for feedback transmits the same RTA packet again in the same TXOP after an interframe space time.

[0294] 38. The apparatus or system of any preceding embodiment, wherein a station that transmits an RTA packet multiple times without waiting for feedback performs discarding the RTA packet if the retry count of the RTA packet exceeds an active retry limit or the lifetime of that packet expires.

[0295] 39. The apparatus or system of any preceding embodiment, wherein a station setting an active retry policy for RTA traffic performs a set block ACK protocol to request a block ACK for the RTA packet after a number of active retries of the RTA packet.

[0296] 40. The apparatus or system of any preceding embodiment, wherein the station that distinguishes RTA traffic from non-RTA traffic performs setting LLTS for RTA packets.

[0297] 41. The apparatus or system of any preceding embodiment, wherein a station that sets an active retry policy for an RTA service performs a change of the active retry policy at any time.

[0298] 42. The apparatus or system of any preceding embodiment, wherein a station setting an active retry policy for RTA traffic performs a set block ACK protocol to request a block ACK for the RTA packet after a number of active retries of the RTA packet.

[0299] 43. The apparatus or system of any preceding embodiment, wherein a station that transmits or retransmits an RTA packet without waiting for feedback performs an active retry limit that sets a maximum number of retransmissions of the RTA packet using active retry.

[0300] 44. The apparatus or system of any preceding embodiment, wherein a station that transmits or retransmits an RTA packet without waiting for feedback performs multiple retransmissions of the same RTA packet in the same TXOP.

[0301] 45. The apparatus or system of any preceding embodiment, wherein a station that transmits or retransmits an RTA packet multiple times without waiting for feedback performs retransmissions of the same RTA packet at different times in the same TXOP.

[0302] 46. The apparatus or system of any preceding embodiment, wherein a station that transmits or retransmits an RTA packet multiple times without waiting for feedback performs retransmission of the same RTA packet over different RUs of a single MU-PPDU or TB-PPDU.

[0303] 47. The apparatus or system of any preceding embodiment, wherein a station affiliated with an MLD that performs multiple transmissions or retransmissions of an RTA packet on one link without waiting for feedback can have other stations affiliated with the same MLD retransmit the same RTA packet through other links.

[0304] 48. The apparatus or system of any preceding embodiment, wherein a station that transmits or retransmits an RTA packet multiple times without waiting for feedback performs contention for the channel again when it transmits the same RTA packet again in the same TXOP.

[0305] 49. The apparatus or system of any preceding embodiment, wherein a station that transmits or retransmits an RTA packet multiple times without waiting for feedback performs transmission of the same RTA packet again in the same TXOP after an interframe space time.

[0306] 50. The apparatus or system of any preceding embodiment, wherein a station that transmits or retransmits an RTA packet multiple times without waiting for feedback performs a discard of the RTA packet if a retry count for that packet exceeds an active retry limit or the lifetime of the packet expires.

[0307] 51. The apparatus or system of any preceding embodiment, wherein the initiator station setting the LLTS performs setting an ID of the LLTS for distinguishing the LLTS of the initiator / receiver station from other LLTSs.

[0308] 52. The apparatus or system of any preceding embodiment, wherein the initiator station setting up the LLTS performs indicating QoS requirements, such as latency, jitter, and packet loss of the LLTS, in the request frame.

[0309] 53. An apparatus or system as in any preceding embodiment, wherein the initiator station setting up LLTS performs reuse of the TSPEC element and additional information as defined in IEEE 802.11 to indicate QoS requirements such as latency, jitter and packet loss, and specifications for LLTS in the request frame.

[0310] 54. The apparatus or system of any preceding embodiment, wherein the initiator station of setting up the LLTS performs reusing the TCLAS element as defined in IEEE 802.11 to identify whether the traffic from the upper layer belongs to the LLTS.

[0311] 55. The apparatus or system of any preceding embodiment, wherein the initiator station that sets up the LLTS performs setting up an active retry policy for the LLTS.

[0312] 56. The apparatus or system of any preceding embodiment, wherein a recipient station receiving the request frame for LLTS setup performs accepting the LLTS setup.

[0313] 57. The apparatus or system of any preceding embodiment, wherein a recipient station receiving a request frame for LLTS setup performs a rejection of LLTS setup.

[0314] 58. The apparatus or system of any preceding embodiment, wherein the recipient station sending the request frame for LLTS setup performs reuse of the TSPEC element and additional information as defined in IEEE 802.11 to indicate QoS parameters of LLTS in the request frame.

[0315] 59. The apparatus or system of any preceding embodiment, wherein successful setup and execution of the LLTS allows the initiator station to send a request frame to update the LLTS.

[0316] 60. The apparatus or system of any preceding embodiment, wherein the LLTS is successfully set up and allows the initiator station to send a request frame to terminate the LLTS.

[0317] 61. The apparatus or system of any preceding embodiment, wherein LLTS is successfully set up and executed to cause the recipient station to send a response frame terminating LLTS.

[0318] As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Reference to an object in the singular is not intended to mean "one and only one," but rather "one or more," unless explicitly stated.

[0319] Phrase constructs such as "A, B, and / or C" in this disclosure describe situations where A, B, or C can be present, or any combination of the items A, B, and C. Phrase constructs indicating that at least one of the listed elements is present, such as "at least one of," include any possible combination of the listed elements, as applicable.

[0320] References in this specification to "an embodiment," "at least one embodiment," or similar embodiment language indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases are not necessarily all referring to the same embodiment, or to a particular embodiment that is different from all other embodiments described. The embodiment language should be interpreted to mean that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method. Furthermore, when the present disclosure refers to an operation that "may" or "should" (or similar language) be performed by an instruction, this indicates that the operation is performed in at least one embodiment and / or mode of the present disclosure, and more generally, in most embodiments and / or modes of the present disclosure, but there may be circumstances where these instructions are overridden or otherwise not performed for any of a variety of reasons.

[0321] As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Reference to an object in the singular is not intended to mean "one and only one," but rather "one or more," unless explicitly stated.

[0322] Phrase constructs such as "A, B, and / or C" in this disclosure describe situations where A, B, or C can be present, or any combination of the items A, B, and C. Phrase constructs indicating that at least one of the listed elements is present, such as "at least one of," include any possible combination of the listed elements, as applicable.

[0323] References in this specification to "an embodiment," "at least one embodiment," or similar embodiment language indicate that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases are not necessarily all referring to the same embodiment, or to a particular embodiment that is different from all other embodiments described. The embodiment language should be interpreted as meaning that the particular features, structures, or characteristics of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method.

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

[0325] As used herein, the terms "approximately," "approximately," "substantially," and "about" are used to describe and explain small variations. When used in conjunction with an event or circumstance, the term can refer to instances where the event or circumstance occurred exactly as well as instances where the event or circumstance occurred approximately. When used in conjunction with a numerical value, the term can refer to a range of variation less than or equal to ±10% of the numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, "substantially" can refer to an angular variation less than or equal to ±10° of the numerical value, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

[0326] In addition, amounts, ratios and other numerical values may sometimes be presented herein in a range format. It should be understood that this range format is used for convenience and brevity and should be flexibly interpreted to include the values explicitly specified as the endpoints of the range, but also to include all individual values or subranges contained within the range, as if each value and subrange were explicitly specified. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly listed endpoints of about 1 and about 200, but also to include individual ratios such as about 2, about 3, and about 4, as well as subranges such as about 10 to about 50, about 20 to about 100, etc.

[0327] Although the description herein contains many details, these details should not be construed as limiting the scope of the present disclosure, but rather merely providing illustrations of some currently preferred embodiments. Therefore, it will be appreciated that the scope of the present disclosure fully encompasses other embodiments that become apparent to those skilled in the art.

[0328] All structural and functional equivalents to the elements of the disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims of this application. In addition, regardless of whether the elements, components, or method steps of the present disclosure are explicitly stated in the claims, these elements, components, or method steps are not intended to be exclusive to the public. The claimed elements herein should not be interpreted as "parts plus function" elements unless the phrase "parts for..." is used to explicitly describe the element. The claimed elements herein should not be interpreted as "step plus function" elements unless the phrase "step for..." is used to explicitly describe the element.

[0329] Table 1

[0330] MLME-LLTS.request

[0331]

[0332] Table 2

[0333] MLME-LLTS.indication

[0334]

[0335]

[0336] Table 3

[0337] MLME-LLTS.response

[0338]

[0339] Table 4

[0340] MLME-LLTS.confirm

[0341]

[0342]

[0343] Table 5

[0344] MLME-LLTS-TERM.request

[0345]

[0346] Table 6

[0347] MLME-LLTS-TERM.indication

[0348]

[0349]

[0350] Table 7

[0351] BlockAckReq frame variant encoding subfield value

[0352] GCR Multiple TIDs Compressed bitmap BlockAckReq frame variants 0 0 0 Basic BlockAckReq 0 0 1 Compressed BlockAckReq 0 1 0 Extended and compressed BlockAckReq 0 1 1 Multi-TID BlockAckReq 1 0 0 reserve 1 0 1 GCR BlockAckReq 1 1 0 reserve 1 1 1 reserve

[0353] Table 8

[0354] Multilink BlockAckReq frame variant encoding subfield value

[0355]

[0356]

Claims

1. An apparatus for wireless communication in a network, the apparatus comprising: a wireless communication circuit configured as a first wireless station for wirelessly communicating with at least one other wireless station on a wireless local area network WLAN in a reception area of the first wireless station via at least one channel; The first wireless station includes a processor configured to operate on a WLAN; non-transitory memory storing instructions executable by the processor; and When the instructions are executed by a processor, the following steps are performed: operating the wireless communication circuitry as a WLAN station configured to support transmission of RTA packets of real-time applications sensitive to communication delays and non-RTA packets over a network supporting Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA), wherein RTA traffic and non-RTA traffic coexist and RTA traffic is given a higher transmission priority than lower priority traffic; Distinguish between RTA groups and non-RTA groups; Setting an active retry policy for the RTA packet, wherein the station retransmits the RTA packet at a time and frequency or on another link according to the active retry policy without waiting for feedback; Setting up a block acknowledgment protocol to receive feedback for adaptation of future packet transmissions; as well as If the retry count of an RTA packet exceeds the active retry limit or the lifetime of the RTA packet has expired, the RTA packet is discarded.

2. The apparatus of claim 1, wherein the active retry policy for RTA packets further comprises establishing an active retry limit.

3. The apparatus of claim 1, wherein the active retry policy for RTA packets further comprises allowing the active retry policy to be changed at any time.

4. The apparatus of claim 1, wherein the active retry policy for RTA packets further comprises allowing a station setting the active retry policy to terminate the active retry policy at any time.

5. The apparatus of claim 1 , wherein the instructions, when executed by a processor, further perform one or more steps, the one or more steps comprising retransmitting the same MAC protocol data unit (MPDU) in the same transmission opportunity (TXOP) when retransmitting an RTA packet under the active retry policy.

6. The device according to claim 1, Wherein PPDU is physical layer consistency process PLCP protocol data unit; and The instructions, when executed by the processor, further perform the following operations: enabling the access point AP station to retransmit the RTA packet under the active retry strategy by transmitting the initial transmission of the RTA packet on the resource unit RU of the multi-user physical layer consistency process protocol data unit MU-PPDU packet and transmitting its retransmission on another RU of the MU-PPDU packet.

7. The device according to claim 1, Wherein PPDU is physical layer consistency process PLCP protocol data unit; and The instructions, when executed by the processor, further perform the following operations: enabling a non-access point station to retransmit the RTA packet under the active retry strategy by transmitting an initial transmission of the RTA packet on a resource unit RU of a triggered physical layer consistency procedure protocol data unit TB-PPDU packet and transmitting a retransmission thereof on another RU of the TB-PPDU packet.

8. The apparatus of claim 1 , wherein the instructions, when executed by the processor, further perform the following operations: enable a station to retransmit an RTA packet under the proactive retry policy by transmitting a retransmission of the RTA packet after the station completes its initial transmission of the RTA packet without receiving prior feedback regarding packet reception.

9. The apparatus of claim 1, wherein the instructions, when executed by a processor, further perform the following operations: adjusting the proactive retry limit for future transmissions based on feedback received by a station transmitting an RTA packet.

10. The apparatus of claim 1, wherein the instructions, when executed by a processor, further perform the following operations: adjusting a modulation and coding scheme (MCS) being used based on feedback received by a station transmitting the RTA packet.

11. An apparatus for wireless communication in a network, the apparatus comprising: a wireless communication circuit configured as a first wireless station for wirelessly communicating with at least one other wireless station on a wireless local area network WLAN in a reception area of the first wireless station via at least one channel; The first wireless station includes a processor configured to operate on a WLAN; non-transitory memory storing instructions executable by the processor; and When the instructions are executed by a processor, the following steps are performed: operating the wireless communication circuitry as a WLAN station configured to support transmission of real-time application (RTA) packets and non-RTA packets that are sensitive to communication delays over a network supporting carrier sense multiple access / collision avoidance (CSMA / CA) and multi-link operation, and wherein RTA traffic and non-RTA traffic coexist and RTA traffic is given a higher transmission priority than lower priority traffic; Distinguish between RTA groups and non-RTA groups; Setting an active retry policy for the RTA packet, wherein the station retransmits the RTA packet at a time and frequency or on another link according to the active retry policy without waiting for feedback; Setting an active retry policy for RTA packets in a multi-link scenario by a station including a multi-link device MLD; The MLD starts counting down the backoff time to compete for channel access on multiple links simultaneously; When the backoff time on the first link counts down to zero, the MLD obtains channel access for the first link; Reserving, by the MLD, a transmission opportunity TXOP for initial transmission of an RTA packet on the first link; If a backoff time on the first link counts down to zero before the TXOP on the first link ends, obtaining channel access on one or more other links; Before the TXOP on the first link ends, retaining the TXOP on the other link for transmitting the retransmission of the RTA packet on the other link; as well as When the TXOP on the first link ends, the backoff times on the first link and the other links are reset.

12. The apparatus of claim 11, wherein the contending for channel access on the plurality of links further comprises reserving a TXOP for non-RTA packet transmission and RTA packet transmission.

13. The apparatus of claim 11, wherein the proactive retry strategy for RTA packets in a multi-link scenario further comprises receiving a Block Acknowledgement (BA) frame to report packet loss for each link.

14. The apparatus of claim 13, wherein a BA frame received by the MLD on one link is configured to contain packet loss information for the first link and the other links.

15. The apparatus of claim 13, wherein after the MLD receives the BA frame, it utilizes packet loss information in the BA frame when determining which link to use for future RTA packet transmission.

16. The apparatus of claim 11, wherein resetting the backoff times on the first link and the other links further comprises resetting the backoff times for an equal number of backoff slots on the first link and the other links.

17. An apparatus for wireless communication in a network, the apparatus comprising: a wireless communication circuit configured as a first wireless station for wirelessly communicating with at least one other wireless station on a wireless local area network WLAN in a reception area of the first wireless station via at least one channel; The first wireless station includes a processor configured to operate on a WLAN; non-transitory memory storing instructions executable by the processor; and The instructions, when executed by a processor, perform: operating the wireless communication circuitry as a WLAN station configured to support transmission of real-time application (RTA) packets and non-RTA packets that are sensitive to communication delays over a network supporting carrier sense multiple access / collision avoidance (CSMA / CA) and multi-link operation, wherein RTA traffic and non-RTA traffic coexist and RTA traffic is given a higher transmission priority than lower priority traffic; Distinguish between RTA groups and non-RTA groups; Setting an active retry policy for RTA packets in a multi-link scenario by a station including a multi-link device MLD, which is either an access point multi-link device AP-MLD configured for simultaneous transmission / reception of STR, or a non-AP MLD not configured for STR; The AP-MLD obtains a transmission opportunity TXOP for transmitting to a non-AP MLD, starting with setting the backoff time on all links to a random number for contending for a channel; The AP-MLD independently counts down a backoff time on each link, so as to obtain channel access on each link when the backoff time on the link counts down to zero; When the first link obtains channel access, reserving a TXOP on the first link; If the AP-MLD obtains channel access on another link before the TXOP of the first link ends, retaining the TXOP on the other link and limiting the end time of the TXOP on the other link to be no later than the end time of the TXOP of the first link; as well as When the AP-MLD fails to obtain channel access before the TXOP of the first link ends, it cannot obtain a TXOP on the first link or the other link.

18. The apparatus of claim 17, wherein the active retry policy for RTA packets further comprises establishing an active retry limit, and controlling the active retry policy, including changing the active retry policy or terminating the active retry policy at any time.

19. The apparatus of claim 17, wherein the instructions, when executed by the processor, further perform the following operations: when retransmitting the RTA packet under the active retry policy, retransmitting the same MAC protocol data unit (MPDU) in the same TXOP.

20. The device according to claim 17, Wherein the PPDU includes a physical layer consistency process PLCP protocol data unit PPDU; and The instructions, when executed by a processor, further perform: enabling an access point (AP) station to retransmit the RTA packet under the active retry strategy by transmitting an initial transmission of the RTA packet on a resource unit (RU) of a multi-user physical layer consistency procedure protocol data unit (MU-PPDU) packet and transmitting a retransmission thereof on another RU of the MU-PPDU packet; and / or By transmitting an initial transmission of an RTA packet on an RU of a triggered physical layer consistency procedure protocol data unit TB-PPDU packet and transmitting a retransmission thereof on another RU of the TB-PPDU packet, a non-access point station is enabled to retransmit the RTA packet under the active retry strategy.

Images