Multilink steering and control in WLAN

Abstract

A method and apparatus for multilink (ML) steering and control in a wireless local area network (WLAN) is disclosed. [Solution] A station (STA) multilink device (MLD) can communicate over multiple links. The STA MLD may receive a first frame from an access point (AP) MLD on a first link of the multiple links, the ML element containing pause information indicating a period of time during which the STA MLD will pause transmission and reception on the first link. The STA MLD may transmit uplink (UL) traffic to the AP MLD on a second link of the multiple links during the indicated period of time, and the first and second links are multidirectional links. The STA MLD may transmit and receive non-synchronously (non-STR), while the AP MLD may be STR.

Description

Technical Field

[0001] (Cross - reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 062,164, filed Aug. 6, 2020, and U.S. Provisional Patent Application No. 63 / 109,221, filed Nov. 3, 2020, the contents of which are incorporated herein by reference.

Background Art

[0002] In multi - link operation between two multi - link devices, such as an access point (AP) and a non - AP station (STA), the multi - link devices can cooperate with each other regarding which link they are trying to use. Link selection is particularly important when supporting low - latency traffic with strict delay and reliability. In addition, the constraints imposed by non - simultaneous transmit and receive (STR) multi - link devices (e.g., AP multi - link devices and / or non - AP multi - link devices) that support simultaneous transmission or reception but not simultaneous transmission and reception further complicate the issues of link steering and control in multi - link operation. Therefore, a mechanism for efficiently, effectively managing, steering, and controlling link usage between multi - link devices is needed.

Summary of the Invention

[0003] A method and apparatus for multi-link (ML) steering and control in a wireless local area network (WLAN) is disclosed. A station (STA) multi-link device (MLD) can communicate over multiple links. The STA MLD can receive a first frame from an access point (AP) MLD on a first link of the multiple links, the ML element containing pause information indicating a period of time during which the STA MLD will pause transmitting and receiving on the first link. The STA MLD can transmit uplink (UL) traffic to the AP MLD on a second link of the multiple links during the indicated period of time, and the first and second links are multi-directional links. STA MLD can be non-simultaneous transmit and receive (non-STR), while AP MLD can be STR. [Brief explanation of the drawing]

[0004] A more detailed understanding can be obtained from the following description, which is given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D]This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing a conflict between ULs and DLs caused by non-default traffic identification (TID) versus link mapping. [Figure 3] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing an example of UL and DL conflict caused by long-duration transmission opportunities. [Figure 4] This diagram illustrates another exemplary message exchange procedure between MLDs over a multidirectional link, showing a conflict between ULs and DLs caused by non-default TID vs. link mapping. [Figure 5] This diagram illustrates another exemplary message exchange procedure between MLDs over a multidirectional link, showing real-time changes or delays in buffered frames. [Figure 6] This diagram illustrates another exemplary message exchange procedure between MLDs over a multidirectional link, showing a conflict between downlink (DL) trigger frame (TF) transmission and uplink (UL) enhanced distributed channel access (EDCA) transmission over different links. [Figure 7] This diagram illustrates another exemplary message exchange procedure between MLDs over a multidirectional link, showing that an MLD loses its network allocation vector (NAV) after sending a UL message over a different link. [Figure 8] This is a diagram illustrating an exemplary multi-link steering and control procedure between MLDs via a multi-directional link. [Figure 9]This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing an exemplary quick-trigger-enabled target wake time (TWT). [Figure 10] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing an exemplary third-party quick-trigger-enabled TWT. [Figure 11] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing another exemplary third-party quick-trigger-enabled TWT. [Figure 12] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing an exemplary quick-trigger-enabled TWT on different links. [Figure 13] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing a block append acknowledgment request and a buffer state indication using the block append acknowledgment. [Figure 14A] This is a diagram illustrating an example frame format for the Multilink (ML) Buffer Status Report (BSR) field. [Figure 14B] This is a diagram illustrating an example frame format for the Traffic Identifier (TID) Buffer Status Report (BSR) field. [Figure 14C] This is a diagram illustrating an exemplary frame format for the TID BSR control field. [Figure 15] This is a diagram illustrating an exemplary ML trigger procedure between MLDs via a multidirectional link. [Figure 16] This is a diagram illustrating an exemplary pause time procedure between MLDs via a multidirectional link. [Figure 17] This is a diagram illustrating an exemplary conditional TF procedure between MLDs via a multidirectional link. [Figure 18] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing that an AP MLD obtains a transmission opportunity (TXOP) using TID EDCA. [Figure 19] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing that an AP MLD acquires a Transmit Opportunity (TXOP) using an Access Category by sending a Trigger Frame (TF). [Figure 20] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing that the AP MLD uses knowledge of the final end time of a future TXOP. [Figure 21] This diagram illustrates an exemplary message exchange procedure between MLDs over a multidirectional link, showing the use of instructions to terminate TXOP early. [Figure 22] This is an example of the NAV configuration procedure for each subchannel. [Modes for carrying out the invention]

[0005] FIG. 1A is a diagram showing an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access content as described above through sharing of system resources including wireless bandwidth. For example, the communication system 100 can use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filter type OFDM, filter bank multicarrier (FBMC).

[0006] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d may all be referred to as stations (STAs) and may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile stations, multilink devices (MLDs), STA MLDs, fixed or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and medical applications (e.g., remote surgery), industrial devices and industrial applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. WTRU102a, 102b, 102c, and 102d can all be referred to as UE for compatibility purposes.

[0007] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN106, the Internet 110, and / or other network 112. By way of example, base stations 114a and 114b can be a base transceiver station (BTS), Node B, eNode B (eNB), home Node B, home eNode B, next generation Node B such as gNode B (gNB), new radio (NR) Node B, site controller, access point (AP), multi-link device (MLD), AP MLD, wireless router, and the like. Although base stations 114a and 114b are each shown as a single element, it will be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0008] Base station 114a may be part of RAN 104, which may also include other base stations such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and / or network elements (not shown). Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide coverage of radio services to a particular geographic area which may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, the base station 114a may use multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0009] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, the air interface 116 may be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0010] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a of RAN 104 and WTRU 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) and may establish an air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0011] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0012] In one embodiment, the base station 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which may establish an air interface 116 using NR.

[0013] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to and from multiple types of base stations (e.g., eNB and gNB).

[0014] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0015] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106.

[0016] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs using the same RAT or different RAT as RAN104. For example, in addition to being connected to RAN104 which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0017] CN106 may also function as a gateway to WTRU102a, 102b, 102c, and 102d for access to PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, which use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, Network 112 may include other CNs connected to one or more RANs that may use the same RAT as RAN 104 or different RATs.

[0018] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

[0019] Figure 1B is a system diagram showing an exemplary WTRU102. As shown in Figure 1B, the WTRU102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0020] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0021] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0022] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0023] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0024] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input from these. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in such memory.

[0025] The processor 118 may receive power from the power supply 134, but may also be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0026] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0027] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0028] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (e.g., associated with specific subframes of both UL (e.g., for transmission) and DL (e.g., for reception)) may be simultaneous and / or together. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (e.g., associated with specific subframes of either UL (e.g., for transmission) or DL ​​(e.g., for reception)).

[0029] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0030] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0031] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., in UL and / or DL. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c may communicate with each other via the X2 interface.

[0032] The CN106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although these elements are shown as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0033] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. MME162 may also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0034] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during eNode-B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0035] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0036] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0037] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

[0038] In a typical embodiment, the other network 112 may be a WLAN.

[0039] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points and APs of the BSS and one or more STAs associated with those APs (e.g., non-AP STAs). APs may have a Distribution System (DS) or access to another type of wired / wireless network (e.g., an interface) that carries traffic entering and / or leaving the BSS. Traffic originating outside the BSS and destined for an STA may reach the STA through an AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to an AP and then delivered to its respective destination. Traffic between STAs within the BSS may be transmitted, for example, via an AP; a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be peer-to-peer traffic, and therefore peer-to-peer traffic may be transmitted directly between a source STA and a destination STA (e.g., without passing through an AP) using a direct link setup (DLS). For example, DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) can communicate directly with each other. The IBSS mode of communication may be referred to as "ad-hoc" communication mode.

[0040] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain typical embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In the case of CSMA / CA, the STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time on a given BSS.

[0041] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0042] Very High Throughput (VHT) STAs may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The 40 MHz and / or 80 MHz channels mentioned above may be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data may pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to Medium Access Control (MAC).

[0043] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications (MTC) such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, including support for specific and / or limited bandwidths (e.g., support only for that). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0044] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy, an STA (supporting only the 1 MHz operating mode) transmitting to the AP may consider the entire available frequency band to be busy, even if most of the available frequency band is idle.

[0045] In the United States, the available frequency band that can be used by 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0046] Figure 1D is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN104 can also communicate with CN106.

[0047] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs while maintaining consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0048] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with an expandable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or expandable lengths (e.g., varying numbers of OFDM symbols and / or varying durations of absolute time).

[0049] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0050] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slice support, interaction between DC, NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0051] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. Although the aforementioned elements are shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may play roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of SMF183a and 183b for registration, management of registration areas, termination of non-access stratum (NAS) signals, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b may provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0053] SMF183a and 183b may be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b may select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0054] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN104, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of DL packets, and mobility anchoring.

[0055] CN106 can facilitate communication with other networks. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local DN185a, 185b via UPF184a, 184b through N3 interfaces to UPF184a, 184b and N6 interfaces between UPF184a, 184b and DN185a, 185b.

[0056] With regard to Figures 1A-1D and the corresponding descriptions in Figures 1A-1D, one or more of the functions described herein with respect to one or more of the WTRU102a-d, base stations 114a-b, e-nodes B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0057] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for the purpose of testing and / or performing testing using over-the-air wireless communication.

[0058] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0059] To improve spectral efficiency in WLANs, 802.11ac introduced downlink multi-user MIMO (MU-MIMO) transmission to multiple STAs within the same symbol time frame, for example, during a downlink (DL) OFDM symbol. Downlink MU-MIMO can be used with, but is not limited to, other protocols, including 802.11ah. Because downlink MU-MIMO can use the same symbol timing for multiple STAs, interference of waveform transmissions to multiple STAs may not be a problem. However, all STAs involved in MU-MIMO transmission with an AP (e.g., DL MU-MIMO transmission from AP to STA) may need to use the same channel or bandwidth, which may limit the operating bandwidth to the minimum channel bandwidth supported by the STA that is part of the MU-MIMO transmission with the AP.

[0060] The IEEE 802.11 Extremely High Throughput (EHT) Study Group can be considered the next major revision of the IEEE 802.11 standard following 802.11ax. EHT is formed to explore the possibility of further increasing peak throughput and improving the efficiency of IEEE 802.11 networks. For example, the main use cases and applications addressed in 802.11be may include high-throughput and low-latency applications such as Video-over-WLAN, augmented reality (AR), and virtual reality (VR).

[0061] Features in EHT and / or 802.11be may be used to achieve the goals of increasing peak throughput and improving efficiency, and include, but are not limited to, the following exemplary features: multi-AP, multi-band / multi-link, 320MHz bandwidth, 16 spatial streams, hybrid automatic repeat request (HARQ), AP coordination, and / or designs for 6GHz channel access.

[0062] 802.11be and / or EHT may include multilink operations, for example, non-simultaneous transmit and receive (non-STR) operations. In the following example of non-STR operation, an AP multilink device (MLD) may be capable of simultaneous transmit and receive (STR) on multiple links (for example, an AP MLD may transmit on a first link and receive simultaneously on a second link), and an STA MLD may be non-STR on one or more pairs of links (for example, if an STA MLD cannot transmit on a first link and receive simultaneously on a second link, the pair of links, the first and second, are considered non-STR pairs for the STA MLD). In one example of non-STR operation, a UL transmission from a non-AP MLD on the first link "Link 1" may interfere with a reception on the second link "Link 2". In this case, sync physical layer convergence procedure (PLCP) protocol data units (PPDUs) transmitted from an AP MLD to the same non-AP MLD on different links may have their PPDU ends aligned to reduce and / or avoid interference. In another example of non-STR operation, the NAV and / or PPDU length state may be received by an STA MLD on a second link, link 2, after transmission on a first link, link 1. In this case, the AP MLD may provide NAV-related information for link 2 on link 1 and / or increase clear channel assessment (CCA) sensitivity on link 2 without NAV. In an example of a non-STR STA MLD with single radio operation, the STA MLD may lose the NAV state of another link during transmission, and the STA MLD may lose the NAV state during data reception.

[0063] In the examples of non-STR operation described herein, unless otherwise specified, it can be assumed that AP is an AP MLD capable of STR, and STA is an STA MLD that may be non-STR. In the examples of non-STR operation described herein, unless otherwise specified, the length state of NAV and / or PPDU may be received by STA on a second link, link 2, after transmission on a first link, link 1. The examples described herein may include representative examples showing two multidirectional links, one or two STA MLDs, and / or one AP MLD, but can be generalized to other numbers of links (e.g., three or more links), STA MLDs (e.g., three or more STA MLDs), and / or AP MLDs not shown.

[0064] While not shown in all examples, it can be assumed that an STA MLD may have multiple STAs (e.g., internally or collated) for communication over multiple links. For example, an STA MLD may have STA1 for communication over link 1 and STA2 for communication over link 2. Similarly, an AP MLD may have multiple APs (e.g., internally or collated) for communication over multiple links. For example, an AP MLD may have AP1 for communication over link 1 and AP2 for communication over link 2. In the examples described herein, transmit, message, PPDU, information, frame, and / or data may be used interchangeably to describe information transmitted and received between communication devices. In one example, a non-STR STA MLD or non-STR AP MLD may communicate over multiple links using one transceiver or using multiple transceivers (e.g., one transceiver per link). Similarly, in one example, an STR STA MLD or STR AP MLD may communicate over multiple links using one transceiver or multiple transceivers (e.g., one transceiver per link). Communication between MLDs over an air interface may traverse different frequency bands / channels / subchannels, which may be referred to as links. The term "medium" may be used herein as a general term for the air interface between two MLDs. Sometimes, a link may include multiple channels or subchannels. An AP may allocate OFDMA resources to an STA with respect to resource units (RUs), which may represent a set of subcarriers to be used by the STA for communication.

[0065] For example, a conflict may occur between DL transmissions to a non-STR(STA)MLD on a first link (e.g., Link A or Link 1) and UL Extended Distributed Channel Access (EDCA) transmissions from the non-STR(STA)MLD on a second link (e.g., Link B or Link 2). Whether transmission and reception are possible between STR MLDs (e.g., APs) and non-STR MLDs (e.g., STAs) on a link may depend on the channel availability on that link and on the traffic direction of other links, which can lead to delays or high latency in the mapped traffic. Mechanisms and procedures for handling this conflict are described herein.

[0066] Figure 2 shows an exemplary message exchange procedure 200 between MLD205 (e.g., a non-STR STA MLD) and MLD207 (e.g., an STR AP MLD) via multidirectional links 201 and 202. The message exchange procedure 200 illustrates an example of UL and DL conflict caused by non-default traffic identification information (TID) versus link mapping. In one example, DL TIDy traffic 216 for MLD205 may be mapped to link 202, while the rest of the TID traffic may be mapped to link 201. DL TIDy traffic 216 may arrive at AP MLD207 for MLD205 (e.g., the traffic is received from the upper layer at the MAC layer).

[0067] During the time period in which MLD205's TID is used by MLD205 to send UL message 210 over link 201 (which can be acknowledged by MLD207 sending a block acknowledgement (BA) 214), AP MLD207 may interrupt the EDCA of TIDy, as shown in the exemplary message exchange procedure 200 (for example, because MLD205 cannot receive on link 202 while sending on link 201). During the time in which MLD205 is sending UL message 210 over link 201 using its TID, another OBSS / UL STA (not shown) may occupy the medium (channel) on link 202 by sending UL message 212 over link 202, continuing to transmit while MLD205 on link 201 is idle, and preventing AP MLD207 from performing the EDCA of TIDy before UL transmission from MLD205 is complete. Therefore, higher-priority TIDy will not be able to get an EDCA opportunity before UL transmissions from MLD205 stop.

[0068] Figure 3 shows an exemplary message exchange procedure 300 between MLD 305 (e.g., non-STR STA MLD) and MLD 307 (e.g., STR AP MLD) via multidirectional links 301 and 302. The message exchange procedure 300 illustrates an example of UL and DL competition caused by a long-duration transmission opportunity (TXOP) 308. In one example, DL TIDy traffic 316 for MLD 305 may be mapped to link 302, and the rest of the TID traffic for MLD 305 (e.g., UL traffic and / or DL ​​traffic) may be mapped to link 301.

[0069] As shown in Figure 3, the emergency DL TIDY traffic arrives on link 302 and overlaps with UL TXOP 308. AP MLD 307 may not be able to perform EDCA on link 302 to transmit emergency data with TIDY 316 on link 302 because MLD 305 is transmitting UL data 310 on link 301 (which may be acknowledged by MLD 407 transmitting BA 314). By the time UL TXOP 308 on link 301 finishes, the link 302 medium may experience a busy period 318 with other transmissions, and therefore the DL emergency data with TIDY 316 may be further delayed until after the busy period 318 on link 302.

[0070] Figure 4 shows another exemplary message exchange procedure 400 between MLD 405 (e.g., non-STR STA MLD) and MLD 407 (e.g., STR AP MLD) via multidirectional links 401 and 402. Message exchange procedure 400 illustrates an example of UL and DL conflict caused by non-default TID vs. link mapping. In one example, DL TIDy traffic 416 for MLD 405 may be mapped to link 402, while the rest of the TID traffic for MLD 405 (e.g., UL traffic and / or DL ​​traffic) may be mapped to link 401.

[0071] Transmissions on link 402 to / from MLD405 result in a busy medium 418 on link 402, which may hinder reception on link 401, particularly MLD405's ability to receive DL messages 410 (which MLD405 may acknowledge by sending BA 414). Furthermore, transmissions on link 402 may be restricted to triggering frame-based access, as MLD405 may park on a non-primary channel. Without a UL buffer state, AP MLD407 cannot know to send a trigger frame on link 402 and to stop DL transmissions 410 to MLD405 on link 401.

[0072] Figure 5 illustrates another exemplary message exchange procedure 500 between MLD505 and MLD509 (e.g., non-STR STA MLD) and MLD507 (e.g., STR AP MLD) via multidirectional links 501 and 502. The message exchange procedure 500 illustrates exemplary real-time changes or delays of buffered frames. During a media busy period 504 on link 501, AP MLD507 may buffer or queue trigger frames (TF) on link 502 of MLD505 and MLD509 against UL TIDs mapped to link 502.

[0073] AP MLD507 may wait until after a media busy period 506 on link 502 to obtain access to the channel on link 502 (e.g., using EDCA) in order to send TF518 to MLD505 and MLD507. During the media busy period 506 on link 501, UL / DL message transmissions 510 and BA514 may be exchanged on link 502. There may be a UL message transmission 516 from MLD505 on link 501 that overlaps in time with the TF transmission 518 to MLD505 and MLD509 before AP MLD507 obtains EDCA access to link 502 to send TF518, which cannot be handled by non-STR MLD505. In this case, AP MLD507 may reallocate the UL resource on link 502 for TF518 for MLD505 to another STA or MLD (i.e., AP MLD507 may dynamically change the resource used to send TF518). In another example (not shown), AP MLD507 may delay the transmission of TF518 until UL transmission 516 on link 501 is completed. In either case, there will be a delay in the transmission of TF518 queued for MLD505 and MLD509. In the case of multi-user EDCA (MU-EDCA) introduced in 802.11ax, the MU-EDCA parameter may provide a less aggressive EDCA compared to the TF's EDCA. In the example in Figure 5, the UL message transmission 516 from MLD505 on link 501 and the TF518 for MLD505 (and MLD509) on link 502 may be for different TIDs, so the MU-EDCA parameter may not be useful. UL transmission 516 cannot use the EDCA's MU-EDCA parameter.

[0074] Figure 6 shows another exemplary message exchange procedure 600 between MLD605 and MLD609 (e.g., non-STR STA MLD) and MLD607 (e.g., STR AP MLD) via multidirectional links 601, 602, and 603. The message exchange procedure 600 illustrates an exemplary conflict between DL trigger frame (TF) transmission 622 on link 603 and UL EDCA transmissions 618 and 620 on links 602 and 603. As shown in Figure 6, UL EDCA transmission 618 from MLD609, UL EDCA transmission 620 from MLD605, and / or BA transmissions 614 and 616 from MLD609 and MLD605, respectively, may conflict with the transmission of DL TF 622 from AP MLD607 to MLD605 and MLD609.

[0075] Non-STR MLD605 can be associated with AP MLD607 on links 601 and 603. The TIDx of MLD605 may be mapped to link 603, and the TIDy of MLD605 may be mapped to link 601. Non-STR MLD609 can be associated with AP MLD607 on links 602 and 603. The TIDx of MLD609 may be mapped to link 603. The TIDy of MLD609 may be mapped to link 602. Outside of the media busy period 604 on link 601, MLD605 may receive DL message transmission 608 from AP MLD607 and send BA616 and UL message transmission 620 to AP MLD607. On link 602, MLD609 may receive DL message transmission 610 from AP MLD607 and send BA614 and UL message transmission 618 to AP MLD607. AP MLD607 cannot send TF622 on link 603 to MLD605 and MLD609 during intermediate busy periods 606 and 612.

[0076] To transmit TF622 to non-STR MLD605 and non-STR MLD609 on link 603, AP MLD607 may verify that the scheduled trigger-based PPDU (TB-PPDU) on link 603 does not overlap with any of the receptions for MLD605 and MLD609 on links 601 and 602. AP MLD607 may verify that the duration of the PPDU carrying TF622 and the duration of the short interframe space (SIFS) after the PPDU do not overlap with either of the UL transmits 620 and 618 of MLD505 and MLD509, respectively.

[0077] As shown in Figure 6, when AP MLD607 transmits DL PPDU608 and DL PPDU610 to MLD605 and MLD609 on links 601 and 602, it cannot transmit TF622 to MLD605 and MLD609. For example, if the end of the PPDU carrying TF622 aligns with the end of DL PPDU607 to MLD605, the condition that there should be no duplicate PPDUs for MLD609 is violated. If the end of the PPDU carrying TF622 aligns with the end of DL PPDU to MLD609, the condition for PPDUs for MLD605 is violated. To satisfy both conditions, AP MLD607 may align the ends of multiple DL PPDU608 and / or DL ​​PPDU610 on multiple links 601 and 602 to multiple 605 and 609 by either padding or fragmentation. In this case, complexity and overhead increase with the number of STA-MLDs scheduled on TF622. Furthermore, there is no guarantee that media contention will succeed and that the PPDUs carrying TF622 will be transmitted before the end of aligned PPDUs on other links.

[0078] If AP MLD607 transmits TF622 for all MLD605 and MLD609 after DL frame exchange sequences 608 and 610 on other links 601 and 602, as shown in Figure 6, any MLD scheduled in TF622 that has a successful EDCA access on other links (601, 602) before the EDCA access of TF622 on link 603 may further delay or postpone the transmission of TF622. For TIDs mapped to links 601 and 602 for MLD605 and MLD609, the EDCA on links 601 and 602 does not have to follow the MU-EDCA parameters for the TID mapped to link 603.

[0079] The NAV / PPDU length state on the second link ("Link 2") after transmission (TX) on the first link ("Link 1") is described herein. Figure 7 illustrates another exemplary message exchange procedure 700 between MLD 705 (e.g., non-STR STA MLD) and MLD 707 (e.g., STR AP MLD) over multidirectional links 701 and 702. The message exchange procedure 700 shows an example where STA2 of MLD 705 loses NAV after UL message transmission 710 by STA1 of MLD 705 on link 701 (for STA1 of MLD 705, AP MLD 707 may send BA 714 on link 701). Because STA1 of MLD705 transmits on link 701, STA2 of MLD705 cannot perform Clear Channel Assessment (CCA), preamble detection, and / or decode NAV information on link 702, and therefore does not have updated NAV state / PPDU duration on link 702. When STA2 of MLD705 resumes EDCA on link 702, STA2 of MLD705 cannot detect UL transmissions 712 from hidden nodes that may be in BSS or overlapping BSS (OBSS) previously started during the EDCA suspension. Therefore, EDCA access by MLD705 on link 702 may cause collisions with other frames on link 702 whose PPDU duration / NAV is signaled by frames / preambles on link 702, during the time period when MLD705 was transmitting on link 701.

[0080] Mechanisms for link steering and control in multilink operation may be used. In multilink operation between two MLDs (e.g., AP MLD, non-STR AP MLD, STR AP MLD, non-AP STA, non-AP MLD, single-link or single-radio MLD, STR MLD, or non-STR MLD), the MLDs may coordinate with each other on which link to use. This coordination may be particularly important for low-latency traffic requiring support for strict delay and reliability requirements. The constraints imposed by non-STR APs and / or non-AP MLDs, which can only support simultaneous transmit or simultaneous receive, further complicate link steering and control in multilink operation. Mechanisms for efficiently and effectively managing, steering, and controlling link usage between MLDs are disclosed herein.

[0081] For example, the problem may relate to the NAV setting for non-primary channel transmission. For example, an STA may have its NAV setting on its primary (e.g., 20MHz) subchannel. This NAV setting may restrict the use of the non-primary (e.g., 20MHz) subchannel. For example, a non-AP STA may participate in a BSS operating at 80MHz. The STA may have the ability to operate on the 80MHz channel. The STA may have a NAV set based on monitoring on its primary 20MHz subchannel. Then, even if the secondary subchannel is idle, the STA may be unable to respond to trigger frames on the secondary 20MHz or secondary 40MHz subchannel.

[0082] In another example, the issue may relate to EDCA after triggered access in multilink operation. MU-EDCA (e.g., in 802.11ax) can have improved efficiency by favoring UL MU transmissions scheduled by the AP. Since the STA can also perform EDCA for UL access scheduled and unscheduled UL access by the AP, both the AP and STA can compete for access to the channel for the same traffic. This can cause collisions and degrade the performance of both the AP and STA. By prioritizing AP traffic and deprioritizing STA traffic (e.g., traffic from an 802.11ax STA), the desired proportion of UL OFDMA / MU transmissions can be achieved while maintaining a fair proportion of UL EDCA transmissions from legacy STAs.

[0083] In MU-EDCA, after an HE non-AP STA is scheduled by an AP, the HE non-AP STA may reduce the EDCA channel access probability. The MU-EDCA timer may be defined per AC so that the STA can reduce the medium / channel contention probability for the access category (AC) during the timer duration.

[0084] In Multi-Link Operation (MLO), non-AP MLDs can be scheduled for UL access on any link to which a UL TID is mapped, based on the UL buffer state of the non-AP MLD. Based on this mechanism, link A, which has successfully sent a TB-PPDU to an AC, may have its media contention priority reduced for that AC. On the non-AP STA side, this allows the non-AP MLD to perform successful TB-PPDU transmissions on other links B and C after effectively redirecting UL traffic to those other links for more aggressive EDCA access. AP MLDs may be aware of the congestion states of different links and the buffer state of non-AP MLDs, but the buffer state of non-AP MLDs may include a Buffer State Report (BSR) in the header of the Media Access Control (MAC) protocol data unit (MPDU) in previously transmitted TB-PPDUs. Assuming links B and C are congested, the AP may schedule only UL access for non-AP MLDs on link A to avoid EDCA access on links B and C. However, since EDCA priority reduction only occurs on link A, this may give non-AP MLDs more opportunities to perform (e.g., conflicting) access on links B and C, which may further increase congestion.

[0085] The BSR control information in the HE A control subfield may not be able to identify the TID of the buffered traffic. In an exemplary BSR control subfield, the access category index (ACI) bitmap subfield and the delta TID subfield may be used to indicate that the buffer state of one or more access categories (ACs) is included in the queue size all subfield. For example, if one bit in the ACI bitmap subfield (corresponding to AC1) may indicate traffic corresponding to TID1 and TID2, then TID1 may be mapped to link 1 and TID2 may be mapped to link 2. If the BSR in the HE A control subfield has one bit in the ACI bitmap subfield set to "1" and a delta TID subfield set to "0" (indicating that one TID has buffered traffic), the AP may not be able to determine which TID is requesting scheduling and will not know on which link to send the trigger frame for the buffered AC1.

[0086] A UL MU transmission (data) invalidation mechanism may be specified for multiple radio coexistence within a device, for example in 802.11ax, by performing a normal EDCA access instead of a triggered access. For example, an STA (having multiple radios) not scheduled for UL access by a TF may handle coexistence internally by choosing not to transmit during periods when another radio is receiving, or by reducing transmit power (and / or reducing the modulation and coding scheme, MCS) when another radio is receiving. If an STA is scheduled for UL access by a TF, control on the STA side may be lost, and coexistence may become an issue.

[0087] For example, in the case of a non-AP MLD, if Link 1 has a coexistence issue and disables UL MU transmission (data), AP MLD can still schedule access triggered on another Link 2 that does not have a coexistence issue. Using normal EDCA access on Link 1 could unintentionally steer traffic to Link 1 because Link 1 uses normal EDCA, which may have a higher EDCA access priority than Link 2, which uses MU-EDCA parameters.

[0088] A mechanism may be specified to prohibit non-default TID-to-link mapping for low-latency TIDs.

[0089] As described above, link access contention can occur when access for more urgent PPDUs on Link 2 is blocked by transmit activity on Link 1. An exemplary solution may allow more urgent PPDUs to compete for media access on Link 1 in addition to Link 2. Traffic identifiers (TIDs) and / or traffic stream identifiers (TSIDs) (TID / TSIDs) that meet certain criteria may be prohibited from being mapped to a subset of links. In this case, TIDs that meet certain criteria may be mapped to all links with non-STR constraints. Examples of criteria may include, but are not limited to, delay constraints, priority, and / or TID / TSID identification. For example, in the case of a TID mapped to Link 2, a Quality of Service (QoS) null frame for the TID may still be allowed to be transmitted on links where the TID is not mapped. The QoS null frame may be aggregated with a control response frame or transmitted individually to compete for media access on Link 1.

[0090] Multilink steering and control procedures may be used to address conflicts between DL transmissions to non-STR MLDs on link A and UL EDCA transmissions from on-STR MLDs on link B.

[0091] Figure 8 illustrates an exemplary multilink steering and control procedure 800 between an MLD 805 (e.g., a non-STR STA MLD) and an MLD 807 (e.g., an STR AP MLD) via multidirectional links 801 and 802. STA1 of MLD 805 communicates via link 801, STA2 of MLD 805 communicates via link 802, and similarly, AP1 of AP MLD 807 communicates via link 801, and AP2 of AP MLD 807 communicates via link 802. Procedure 800 includes an exemplary design of a multilink steering and control element 810 (equivalently a multilink element 810), which may be part of a beacon or other type of frame 808 transmitted by AP1 of AP MLD 807 over link 801. In one example, AP MLD 807 may recognize the next low-latency traffic (traffic with associated low-latency requirements) transmitted over link 802. In this case, AP MLD807 may instruct STA1 of MLD805 on link 801 to pause or delay transmission (and / or reception) on link 801 for the indicated time period 812. AP MLD807 or STA MLD805 may include this instruction in a beacon or frame 808 as part of multilink steering and control information, which can be implemented, for example, as a multilink steering and control element 810 (e.g., in the pause information field 854). During the period 812 in which MLD805 (e.g., STA1 of MLD805) pauses transmission / reception on link 801, MLD805 (e.g., STA2 of MLD805) may transmit a low-latency UL message 814 on link 802. Frame 808 may be transmitted by AP associated with AP MLD807, but a similar procedure may be applied to STA associated with another STA MLD (not shown).

[0092] All parts of the information, fields, subfields, or subsets of the multilink (ML) steering and control element 810 may be implemented as fields, or as subfields of any new or existing elements, fields, media access control (MAC) headers or PLCP headers, or as any control, data, management, or other type of frame. The multilink steering and control element 810 includes the following fields or subfields: the element identifier (ID) field 832, the length field 834, the element ID extension field 836, the link steering field 838, the link field count field 840, and / or link information (info) fields 8421-842. N This may include, but is not limited to, one or more of the following.

[0093] The element ID field 832 and the element ID extension field 836 can be combined to indicate that the ML element 810 is an ML steering and control element.

[0094] The length field may indicate the length of the ML element 810. The link steering field 838 may be used to indicate whether a receiving STA or a non-AP MLD or receiving MLD is recommended or instructed to use one or more links. In one example, the link steering field 838 may be implemented as a bitmap, where each bit indicates the link to be used. In another example, the link steering field 838 may be implemented as multiple subfields, where each subfield may contain the ID of the recommended or instructed link. An AP or AP MLD may use the link steering field 838 to recommend or instruct a receiving STA, a single-link radio STA, or a non-AP MLD or STA of a non-AP MLD to activate or monitor one or more links that can be set up or are available. An STA or non-AP MLD may use the link steering field 838 to recommend or instruct a receiving STA, AP, or AP MLD's AP or AP MLD to activate or monitor one or more links that can be set up or are available.

[0095] The link steering subfield 838 may contain one or more STA IDs, such as MAC addresses or associate IDs (AIDs), to indicate one or more STAs that are steering or instructed to activate one or more links. In addition, in the case of a non-STR STA, steering means that the STA or MLD stops transmitting on the uplink over its currently active link. The link steering subfield 838 may carry an instruction for a reverse trigger. If a reverse trigger is indicated by the link steering subfield 838, the STA or MLD that has stopped transmitting on the current link may transmit a reverse trigger when a new link is activated, and this reverse trigger may be an instruction for a transmitting MLD to transmit. The reverse trigger may be implemented by a control frame, management frame, or data frame (e.g., a power save-poll (PS-Poll) frame or data frame). The link field number field 840 may indicate the number of link fields N included in the ML steering and control element 810.

[0096] Each link field 8421~842 N This may include information or control information for each link in a set of links. A set of links may include links set up between an AP MLD and a non-AP MLD or a single-link MLD. A set of links may be a set of links supported by an AP MLD or a set of links supported by a non-AP MLD. A set of links may be a link that is active in an AP MLD or a link that is active in a single-link MLD or a non-AP MLD. Each link field 8421-842 N This may include, but is not limited to, one or more of the following information: the Link ID subfield 850, the Traffic Information (information, info) subfield 852, the Downtime Information (info) subfield 854, and / or the Allowed Transmission Time field 856. The Link ID subfield 850 may indicate the ID of each link and may use, for example, an integer, the channel number of the primary channel of the link, or any other type of identifier.

[0097] The traffic information subfield 852 may indicate the amount of traffic expected or buffered in the AP MLD 807 (i.e., the MLD that transmitted frame 808) on the link, as well as traffic priority and / or traffic delay. For example, each traffic information subfield 852 may include several subfields (not explicitly shown) corresponding to access categories or priorities such as low-latency traffic. Each subfield of the traffic information subfield 852 may be 1 bit to indicate that there is traffic of the corresponding category (e.g., AC and / or priority) buffered in the transmitting STA MLD. Each subfield of the traffic information subfield 852 may include detailed information on how much traffic is buffered or the delay associated with the corresponding AC traffic or priority. In one example, only traffic with the highest priority or the strictest delay requirements may be shown in the traffic information field 852. In another example, only the traffic information field 852 may be shown for links where the transmitting STA MLD or AP MLD recommends or directs the receiving STA / MLD in the link steering field 838. In a different example of a receiving STA, the traffic information field 852 may indicate the order of active links supported by the transmitting STA or MLD and the receiving STA or MLD, or set up between them. In this case, the explicit link ID 850 may not be included.

[0098] The pause information field 854 may be used to instruct the receiving STA MLD 805 to pause its transmission on the same link (link 801) for the indicated time period 812. The time period during which the receiving STA / MLD pauses (e.g., pause time) may allow other STA / MLD or AP / MLD to access the medium. The pause time may allow an AP or STA or MLD to transmit to the receiving STA on one or more links (e.g., if the receiving STA may be a non-STR AP MLD or a non-STR non-AP MLD). The allowed transmission time field 856 may indicate a continuous allowed transmission time to be used by one or more receiving STAs or MLDs on a particular link and / or the indicated link in link ID 850.

[0099] The traffic information field 852, the idle information field 854, and the allowable transmission time field 856 may be designed differently. For example, each of the traffic information field 852, the idle information field 854, and the allowable transmission time field 856 may contain multiple subfields, so that each subfield is associated with a specific link (for example, a link set up between a transmitting STA or MLD and a receiving STA or MLD, or a link supported by a transmitting STA or MLD). In some cases, the link ID field 850 may not be explicitly used or required.

[0100] As shown in Figure 8, the multilink steering and control procedure 800 may include the AP or AP MLD 807 transmitting a beacon, short beacon, FILS discovery frame, or other type of management or control frame to one or more STAs or MLDs or groups of MLDs (including STA MLD 805). The beacon or other frame 808 may include an ML steering and control element 810 that the receiving STA MLD 805 can use to be steered or directed to one or more links as indicated in the link steering field 838. If two or more links are indicated in the link steering field 838 for a single-link MLD, it may imply that the single-link MLD can monitor a set of multiple links. If two or more links are indicated in the link steering field 838 for a non-STR MLD, it may imply that the non-STR MLD can monitor multiple links. If the link steering subfield 838 indicates a reverse trigger for a non-STR MLD, the non-STR MLD may transmit a reverse trigger, e.g., a trigger frame or a PS-Poll frame, and the reverse trigger may be transmitted simultaneously in the UL in a synchronous or link-aggregated manner. If two or more links are indicated in the link steering field 838 for an STR MLD, it may imply that the STR MLD may monitor a set of links. If the link steering subfield 838 indicates a reverse trigger for an STR MLD, the STR MLD may transmit a reverse trigger, e.g., a trigger frame or a PS-Poll frame. A reverse trigger frame may be used to trigger a transmission for a received MLD. Reverse trigger frames may be transmitted simultaneously in the UL in a synchronous or link-aggregated manner. Reverse trigger frames may be transmitted individually on each link at an earlier time than channel access on that link.

[0101] An AP or AP MLD may include the ML steering and control elements 810 in any type of management or control frame addressed to a particular STA or MLD to indicate that it is directing or steering the STA or MLD to one or more links, as indicated in the link steering field 838. If two or more links are indicated in the link steering field 838 for a single-link MLD, it may imply that the single-link MLD may monitor a set of links. If the link steering subfield 838 indicates a reverse trigger, the single-link MLD may transmit a reverse trigger to trigger a transmission to that single-link MLD when it successfully accesses a medium on one or more links. If two or more links are indicated in the link steering field 838 for a non-STR MLD, it may imply that the non-STR MLD may monitor a set of links. If the link steering subfield 838 indicates a reverse trigger for a non-STR MLD, the non-STR MLD may transmit reverse triggers, e.g., trigger frames or PS-Poll frames, that are being transmitted simultaneously in the UL in a synchronized or link-aggregated manner. If two or more links are indicated in the link steering field for STR MLD, it may imply that STR MLD can monitor a set of links. If the link steering subfield 838 indicates a reverse trigger for STR MLD, STR MLD may transmit a reverse trigger, such as a trigger frame or PS-Poll frame. A reverse trigger frame may be used to trigger a transmission to the MLD. Reverse trigger frames may be transmitted simultaneously in the UL in a synchronous or link-aggregated manner. Reverse trigger frames may also be transmitted individually on each link at an earlier time than channel access on that link.

[0102] An AP or MLD may transmit a frame 808 containing ML steering and control elements 810 to indicate the traffic load on one or more links to one or more STAs or MLDs. This may provide information about the amount of buffered traffic, and / or priority and latency associated with the traffic on one or more links. Such information may be included in a data frame, e.g., the MAC and / or PLCP header, or aggregated in an aggregated MAC Protocol Data Unit (A-MPDU), or in a BA or multi-STA BA (M-BA) or other type of response frame to notify a receiving STA of potentially more urgent traffic on one or more links. In an alternative design, the TID of the buffered traffic may be indicated, and a receiving STA or MLD may be able to determine which link to monitor based on the TID-to-link mapping established by the STA or MLD. A non-STR STA or MLD may suspend its current transmission on the currently active link to monitor the link of its choice, potentially selecting the highest priority or lowest latency data as indicated by the ML steering and control elements 810. A non-STR MLD may also send one or more reserved trigger frames on one or more links of its choice. Reverse trigger frames can be PS-Polls or trigger frames and may be sent simultaneously and synchronously on two or more links.

[0103] An AP or MLD may transmit a frame 808 containing ML steering and control elements 810 to indicate a pause duration (in the pause information field 854) to one or more STAs or MLDs on one or more links. An STA or MLD receiving the ML steering and control elements 808 containing a pause duration for one or more links, for example, a non-STR MLD, may stop accessing the media for at least the duration indicated in the pause duration on the indicated links. The STA or MLD may switch to monitoring the links indicated in the link steering field 838. The pause duration may begin after the receiving STA or MLD has finished transmitting its current frame or completed its current TXOP.

[0104] An AP or MLD may transmit a frame 808 containing ML steering and control elements 810 to one or more STAs or MLDs to indicate the permissible transmit time (in the permissible transmit time field 856) on one or more links. An STA or MLD, for example, a non-STR MLD, a single-link MLD, or an STR MLD, may receive the ML steering and control elements 810 containing the permissible transmit time indication 856 for one or more links and reduce its maximum transmit time or TXOP to be less than that indicated in the permissible transmit time field 856.

[0105] As shown in Figure 8 with respect to the multilink steering and control procedure 800, a non-AP STA or non-AP MLD may perform multilink steering and control in any of the following exemplary procedures. For example, a non-AP STA or non-AP MLD may include ML steering and control elements within a data frame (e.g., within a header) or within another type of management or control frame to which the STA or MLD is to be steered or directed to one or more links, as indicated in the link steering field. If two or more links are indicated in the link steering field for a non-STR MLD, it may mean that the non-STR MLD can monitor a set of links. If a reverse trigger is indicated for a non-STR MLD, the non-STR MLD may transmit a reverse trigger, e.g., a trigger frame or PS-Poll frame, being transmitted simultaneously in the UL in a synchronous or link-aggregated manner to trigger a transmission from the transmitting STA or MLD. If two or more links are indicated in the link steering field for an STR MLD, it may mean that the STR MLD can monitor a set of links. If a reverse trigger is indicated for STR MLD, STR MLD may send a reverse trigger, such as a trigger frame or PS-Poll frame. A reverse trigger frame may be used to trigger a transmission to the MLD. Reverse trigger frames may be sent simultaneously in the DL in a synchronous or link-aggregated manner. Reverse trigger frames may also be sent individually on each link at an earlier time than channel access on that link.

[0106] A non-AP STA or non-AP MLD may include multilink steering and control elements (equivalently multilink elements) within any type of management or control frame addressed to a particular STA or MLD to indicate that the AP or MLD is directed to or steering to one or more links, as indicated in the link steering field. If two or more links are indicated in the link steering field for a non-STR MLD, it may mean that the non-STR MLD is able to monitor a set of links. If a reverse trigger is indicated for a non-STR MLD, the non-STR MLD may transmit reverse triggers, e.g., trigger frames or PS-Poll frames, simultaneously transmitted in the DL in a synchronous or link-aggregated manner. If two or more links are indicated in the link steering field for an STR MLD, it may imply that the STR MLD may monitor a set of links. If a reverse trigger is indicated for an STR MLD, the STR MLD may transmit reverse triggers, e.g., trigger frames or PS-Poll frames. Reverse trigger frames may be used to trigger transmissions to the MLD. Reverse trigger frames may be transmitted simultaneously in the UL in a synchronous or link-aggregated manner. Reverse trigger frames may also be transmitted individually on each link at an earlier time than channel access on that link.

[0107] A non-AP STA or non-AP MLD may transmit a frame containing ML steering and control elements to indicate the traffic load on one or more links to one or more STAs or MLDs. The ML steering and control elements may provide information about the amount of buffered traffic, and / or priority and latency associated with traffic on one or more links. Such information may be included in a data frame, e.g., a MAC / PLCP header, or in an A-MPDU, or aggregated into a BA or M-BA or other type of response frame, to notify a receiving STA of potentially more urgent traffic on one or more links. In one example, the TID of the buffered traffic may be indicated, and the receiving STA or MLD may be able to calculate which links to monitor based on the TID-to-kink mapping established by the STA or MLD. A non-STR STA or MLD may suspend its current transmission on its currently active link and potentially monitor a link of its choice that has the highest priority data or low latency data, as indicated in the ML steering and control elements. A non-STR MLD may also transmit one or more reserved triggers on one or more links of its choice. A reverse trigger can be a PS-Poll or a trigger frame, and can be transmitted simultaneously and synchronously over two or more links.

[0108] A non-AP STA or non-AP MLD may transmit a frame containing ML steering and control elements to indicate a downtime on one or more links to one or more STAs or MLDs. An STA or MLD receiving ML steering and control elements indicating a downtime for one or more links, for example, a non-STR MLD, may suspend its media access for at least the indicated downtime on the associated links. The STA or MLD may switch to monitoring the links indicated in the link steering field of the ML steering and control elements. The indicated downtime may begin after the receiving STA or MLD has finished transmitting its current frame or completed its current TXOP.

[0109] A non-AP STA or non-AP MLD may transmit a frame containing ML steering and control elements to indicate the permissible transmit time on one or more links to one or more STAs or MLDs. An STA or MLD, for example, a non-STR MLD or a single-link MLD or STR MLD, may receive the ML steering and control elements, including the permissible transmit time for one or more links, and reduce its maximum transmit time or TXOP to be less than the duration indicated in the permissible transmit time field.

[0110] Embodiments for a quick-trigger TWT are described herein.

[0111] A mechanism for trigger-enabled target wake time (TWT) may be used to prohibit EDCA and may be useful to resolve conflicts between DL transmissions to non-STRU MLDs on a first link and UL EDCA transmissions on a second link, and / or NAV / PPDU length states on the second link after transmissions on the first link. A TWT requesting STA cannot send frames to a TWT response STA outside of the negotiated TWT scheduling period (SP), and should not send frames not included in the HE TB PPDU within the trigger-enabled TWT SP to the TWT response STA. For example, an AP MLD may add an instruction on link 1 to indicate a quick trigger-enabled TWT on link 1 to give access to DL TIDY or trigger frames on link 2. An AP MLD may add an instruction on link 1 to indicate a quick trigger-enabled TWT on link 2.

[0112] In a quick-trigger-enabled TWT, instead of completely stopping EDCA access, a set of alternative EDCA parameters may be used to perform a (less aggressive) EDCA. Examples of alternative EDCA parameters include, but are not limited to, longer competition windows, larger inter-frame spacing, or different CCA thresholds. A quick-trigger-enabled TWT may run on the same links described herein.

[0113] Figure 9 shows an exemplary message exchange procedure 900 between an MLD 905 (e.g., a non-STR STA MLD) and an MLD 907 (e.g., an STR AP MLD) via multidirectional links 901 and 902. The message exchange procedure 900 shows an exemplary quick-trigger-enabled TWT 925 assigned by the TXOP responder. For example, the quick-trigger-enabled TWT 925 may be assigned by the AP MLD 907 and can address the problem described in Figure 2 by reducing the delay caused by high-priority TIDY DL traffic from the MLD 905 on link 902.

[0114] Similar to the exemplary scenario shown in Figure 2, during the time period in which the TID of MLD905 is used by MLD905 to send UL message 910 on link 901 (which AP MLD907 may acknowledge by sending BA914, 920), AP MLD907 may interrupt EDCA for TIDy for MLD905 on link 902. During the time in which MLD905 is sending UL message 910 on link 901 using its TID, another OBSS / UL STA (not shown) may occupy the medium (channel) on link 902 by sending UL message 912 on link 902, continuing to transmit while MLD905 on link 901 is idle, and delaying AP MLD907 from performing EDCA for TIDy.

[0115] For example, AP MLD907 may provide MLD905 with information to enable TWT925. This information may be included in a PPDU carrying a responsive frame, such as a BA920, transmitted from AP MLD907 to MLD905 over link 901, or in a PPDU carrying an inviting frame (e.g., a DL / UL frame 1012 on link 1001, as shown in Figure 10). The information to enable TWT925 may include, but is not limited to, any of the following: Quick-triggered TWT indication, end time and / or duration of the quick-triggered TWT 925 for the current link 901 or indicated link (e.g., link 901 or 902), start time of the quick-triggered TWT 925 for the current link 901 or indicated link, identification information (ID) of the link 901 STA MLD (e.g., ID of MLD 905) to which the quick-triggered TWT 925 may be applied or followed by the quick-triggered TWT 925, ID of link 902 to which the AP MLD 907 may be used to send a PPDU to the STA MLD 905, TID / TSID on link 902 to which the AP MLD 907 may be used to send a PPDU to the STA MLD 905, indication of whether other links (e.g., link 903, not shown) also have the same quick-triggered TWT 925 as on link 901, alternative EDCA parameters, and / or criteria for early termination of the TWT 925.

[0116] An STA MLD905 on link 901 may resume its EDCA following the termination of a TXOP911 that has a PPDU (e.g., BA920) carrying a quick-trigger-enabled TWT instruction (such as "MLD905 EDCA allowed" as shown in Figure 9, or "N-STR EDCA allowed" as shown in Figure 11). If a non-STR MLD905 applying a quick-trigger-enabled TWT acquires a TXOP913 before a TWT925, the TXOP may terminate before the start time of the quick-trigger-enabled TWT925.

[0117] The duration of "MLD905 EDCA allowed" on link 901 shown in Figure 9 (or the duration of "N-STR EDCA allowed" shown in Figure 11) can be derived from the pending NAV / PPDU duration on link 902 plus the remaining EDCA counter for link 902 in AP MLD907 (i.e., link 902 AP MLD907 cannot transmit before the end of the "MLD905 EDCA allowed" duration). During the "MLD905 EDCA allowed" period, MLD905 can send UL message 922 to AP MLD907 and may receive BA924 before the start of TWT925.

[0118] A quick-trigger TWT925 may be applicable to a non-STR STA MLD905 associated with the receiver address (RA) of a responsive frame (e.g., BA920) and may be referred to as a responsive frame quick-trigger TWT. A quick-trigger TWT925 may be applicable to a non-STR STA MLD905 associated with the RA of an inviting frame (e.g., DL / UL frame 1012 in Figure 10) and may be referred to as an inviting frame quick-trigger TWT. A quick-trigger TWT925 may be any other or all applicable non-STR STA MLDs (including additional STA MLDs not shown) operating on link 901 and may be referred to as third-party quick-trigger TWTs (examples of which are shown in Figures 10 and 11 and described below). During TWT925, MLD905 may receive DL message 926 for TIDy from AP MLD907, and AP MLD907 may send TF928 to MLD905 (and / or other STA MLDs not shown). After TWT925, MLD905 may resume sending UL message 930 to AP MLD907 on link 901 using TID.

[0119] Figures 10 and 11 show examples of third-party quick-trigger-enabled TWTs. Figure 10 is a diagram of an exemplary message exchange procedure 1000 between MLDs 1005, 1009 (e.g., non-STR STA MLDs) and 1007 (e.g., STR AP MLDs) over multidirectional links 1001 and 1002. Other MLDs / OBSSs (not shown) may use media as reflected by media busy periods 1010 on link 1001 and 1016 on link 1002. In one example, DL / UL PPDUs 1012 and BAs 1014 on link 1001 may not be transmitted by or intended to be received by MLD 1005 or MLD 1009. The transmitter of PPDU 1012 carrying an invitation frame may signal in the PPDU (e.g., in the PPDU's preamble) that a response frame in response to the PPDU (e.g., the PPDU carrying BA 1014) may carry a quick-trigger-enabled TWT instruction. The transmitter of PPDU carrying an invitation frame may be a non-AP MLD (not shown), in other words, a third-party quick-trigger-enabled TWT. During the triggered TWT 1025, and if the medium on link 1002 is busy for a longer period, AP MLD 1007 may transmit TF 1020 on link 1002 to MLD 1005 and MLD 1009 (TF 1020 may have been previously buffered by AP MLD 1007 for MLD 1005 and 1009 for TIDs mapped to link 1002). During the triggered TWT1025, another STR STA MLD (not shown) may send UL message 1018 to AP MLD1007 on link 1001.

[0120] Figure 11 shows an exemplary message exchange procedure 1100 between MLDs 1105, 1109 (e.g., non-STR STA MLDs) and 1107 (e.g., STR AP MLDs) via multidirectional links 1101 and 1102. Other MLDs / OBSSs (not shown) may use media so as to be affected by media busy periods 1110 on link 1101 and 1116 on link 1102. For example, DL / UL PPDU 1112 and BA 1114 on link 1101 may not be transmitted by MLD 1105 or MLD 1109, or may not be intended to be received. The transmitter of PPDU 1112 carrying an inviting frame may signal in the PPDU (e.g., in the PPDU's preamble) that a response frame in response to the PPDU (e.g., the PPDU carrying BA 1114) may carry a quick-trigger-enabled TWT instruction. The transmitter of the PPDU carrying an inviting frame may be an STR non-AP MLD (not shown), in other words, a third-party quick-trigger-enabled TWT. During the triggered TWT 1125, which begins after the media on link 1102 has been busy for a longer period, AP MLD 1107 may send TF 1120 on link 1102 to MLD 1105 and MLD 1109 (TF 1110 may have been previously buffered by AP MLD 1107 for MLD 1105 and 1109 for TID mapped to link 1102). During the time period 1123 in which N-STR EDCA is permitted, prior to the start of the triggered TWT 1025, other STR STA MLDs (not shown) may send UL message 1118 (e.g., BSR) on link 1101 to AP MLD 1107.

[0121] In the examples described herein (for example, the examples in Figures 9, 10, and 11), if the PPDU carrying a quick-trigger-enabled TWT instruction is a legacy PPDU (e.g., a non-HT (replica) PPDU carrying a responsive BA frame), the responsive BA frame may be a multi-STA BA (MBA) frame. In one example, an ack type value (e.g., a reserved ack type value) may be used in the AID TID information field in the BA frame to signal the presence of a subsequent quick-trigger-enabled TWT instruction. In one example, the AID11 field of the AID TID information field may be used to specify whether the frame is a responsive frame quick-trigger-enabled TWT (e.g., set to the AID of the unicast receiver of the responsive frame) or a third-party quick-trigger-enabled TWT (e.g., set to the broadcast AID). The (non-STR)STA ​​of the MLD operating on Link 1 (the first MD link) may be required to read the MBA frame without responding to its own transmission for a third-party quick-trigger-enabled TWT instruction.

[0122] In the examples described herein (for example, the examples in Figures 9, 10, and 11), if the PPDU carrying the quick-trigger-enabled TWT instruction is a legacy PPDU (e.g., a non-HT (replica) PPDU carrying a responsive frame), the responsive frame may be a control wrapper frame. The control wrapper frame may include an HT control field that can be used to signal the quick-trigger-enabled TWT instruction. The quick-trigger-enabled TWT may have pre-negotiated parameters. A non-STR STA MLD operating on Link 1 may be required to read the HT control field for instructing a third-party quick-trigger-enabled TWT, even if it is not addressed by the control wrapper frame. The control wrapper frame may have a first address set to a broadcast address and may include an MBA that signals the AID of the intended STA for the BA, but the third-party STA may parse the HT control field of the control wrapper frame.

[0123] In the examples described herein (e.g., the examples in Figures 9, 10, and 11), if the PPDU carrying the quick-trigger-enabled TWT instruction is a legacy PPDU (e.g., a non-HT (replicated) PPDU carrying a responsive frame), the NAV of the MPDU in the PPDU may be set to a value less than or equal to the interframe spacing (IFS) (e.g., short IFS (SIFS), arbitrary IFS (AIFS), or distributed coordination function (DCF) IFS (DIFS)) in order to function as an implicit instruction for the quick-trigger-enabled TWT. The quick-trigger-enabled TWT may have pre-negotiated parameters. The NAV duration may signal whether it is a responsive frame quick-trigger-enabled TWT or a third-party quick-trigger-enabled TWT, and / or other parameters related to the TWT described herein.

[0124] In further examples, a quick-trigger-enabled TWT instruction may be a signal in the PHY preamble or a signal in one or more bits during scrambler initiation that is not used by BW signaling. A quick-trigger-enabled TWT instruction may be in a separate frame aggregated with a responsive / inviting frame addressed to the same STA in an AMPDU. The instruction may be in a separate frame addressed to another (non-STR) STA (e.g., broadcast) other than the RA of the responsive / inviting frame, and the frame may be included in a MU-PPDU. A quick-trigger-enabled TWT instruction may be a field in an invitation / response frame. The instruction may be a field in a frame that does not carry data, such as a QoS null frame. A frame that does not carry data may be addressed to the RA of the invitation / response frame or to another non-STR STA (e.g., broadcast). A quick-trigger-enabled TWT is not preceded by the period during which EDCA may be permitted for non-STR STAs on link 1. Other MLDs may be third parties to DL / UL / BA exchanges on link 1.

[0125] Quick-trigger-enabled TWT parameters can be pre-negotiated. Using pre-negotiated parameters, the quick-trigger TWT instruction can be shortened. The shortened instruction can signal the start of the TWT, or the start of the EDCA tolerance period preceding the TWT. The pre-negotiated parameters may be all or a subset of the parameters related to the quick-trigger-enabled TWT. The pre-negotiated parameters may include, but are not limited to, the TWT duration, the unit / scaling factor of the TWT duration, the ID of Link 2 on which the AP MLD wishes to send the PPDU to the STA MLD, an instruction whether other links (e.g., Link 3) also have the same quick-trigger-enabled TWT as Link 1, and / or criteria for early termination of the TWT. If the unit of the TWT duration is pre-negotiated, the quick-trigger TWT instruction may include a number x, and the actual TWT duration may be x times the unit of the TWT duration. One example of a criterion for early termination of a TWT is that if the MLD receives a DL PPDU from the AP on Link 2 after the TWT on Link 1 has started, the TWT may be terminated and EDCA may be initiated on Link 1. The criterion may have additional limitations. For example, a limitation may be that if the TWT is an inviting / responding frame quick-trigger compatible TWT, the DL PPDU may be addressed to the STA of the MLD on Link 2.

[0126] The TXOP responder (e.g., AP MLD) may request the MLD's Link 1 STA (i.e., the TXOP holder) to allocate additional time in the TXOP (i.e., duration in the soliciting frame / NAV) for sending a response PPDU carrying the response frame and the quick-trigger TWT instruction. For example, if the response frame is a quick-trigger TWT, the quick-trigger TWT instruction may be carried in a control wrapper frame in a non-HT (overlap) PPDU, and the STA sending the soliciting frame may take the size of the control wrapper frame into consideration when allocating NAV. Similarly, if the response frame is a quick-trigger TWT, the quick-trigger TWT instruction may be carried in a separate frame, both frames may be carried in a PPDU that allows an AMPDU as a payload, and the STA sending the soliciting frame may take the size of the AMPDU into consideration when allocating NAV. Similarly, if a third-party quick-trigger TWT is a TWT instruction carried in a separate frame located within a RU in a responsive MU-PPDU, the STA sending the inviting PPDU may, when allocating NAV, take into account the duration required for the TWT instruction frame transmitted in the RU. The Resource Unit (RU) size and MCS for transmitting the TWT instruction frame may be pre-negotiated parameters. Requests for allocating additional NAV for a responsive PPDU may be signaled in an add block acknowledgement (ADDBA) exchange or in a procedure used for TID-to-link mapping.

[0127] The exemplary procedure may be used for quick-trigger TWTs on different links. Figure 12 illustrates an exemplary message exchange procedure 1200 between MLD 1205 (e.g., non-STR STA MLD) and MLD 1207 (e.g., STR AP MLD) over multi-directional links 1201 and 1202. The message exchange procedure 1200 shows an exemplary quick-trigger TWT 1225 on a different link 1202. During the time period in which the TID of MLD 1205 is used by MLD 1205 to send UL message 1210 on link 1201 (which can be acknowledged by AP MLD 1207 sending BA 1214), AP MLD 1207 may interrupt or suspend the EDCA for TIDy for MLD 1205 on link 1202. During the time period in which MLD1205 is transmitting UL message 1210 on link 1202 using TID, another OBSS / UL STA (not shown) may occupy the medium (channel) on link 1202 by transmitting UL message 1212 on link 1201. The PPDU carrying the responsive frame BA1214 may have a quick-trigger-enabled TWT instruction that assigns TWT1225 on link 1202. TWT1225 on link 1202 may start immediately after the end of the PPDU carrying the instruction in BA1214. Following TWT1225, AP MLD1207 may restart EDCA for TIDy for MLD1205 on link 1202. Link 1201 AP MLD1207 may allocate the duration of TWT1224 such that it is greater than or equal to the NAV timer value observed by Link 1202 AP MLD1207 / remaining PPDU duration at the end of the PPDU carrying the TWT instruction (BA1214). The NAV may be an intraBSS NAV or a basic NAV, or the larger of the two, if Link 2 AP maintains two NAV timers. The TWT may be terminated early if MLD1205 (e.g., Link 1202 STA of MLD1205) receives a frame on Link 1202 that sets up the NAV.In examples not explicitly shown, TWT may terminate prematurely if MLD1205 (e.g., link 1202 STA of MLD1205) receives frames to configure intraBSS NAV on link 1202 and frames to configure basic NAV on link 2. During TWT1225, MLD1205 (e.g., link 1202 STA of MLD1205) may respond to a trigger frame (not shown) if there is no information regarding basic NAV.

[0128] A mechanism for buffer state indication in ADDBA exchange may be used. In multi-link transmissions, a non-STR non-AP MLD may transmit / receive over one link. During that time, the non-STR non-AP MLD may not be able to track the NAV settings over other links and therefore may delay its transmission over other links. For example, if transmission / reception over link 1 is slow (e.g., involving ADDBA request / response exchanges, and / or data and BA exchanges), transmission over link 2 may be delayed for a long time. If the non-STR non-AP MLD has traffic on link 2 with low latency requirements, the MLD may need to drop some packets.

[0129] In this case, procedures may be used in the ADDBA request / response frame exchange to indicate ML traffic status, buffer status, and / or QoS requirements across multiple links. Figure 13 is a diagram of an exemplary message exchange procedure 1300 between MLD 1305 and MLD 1309 (e.g., non-AP MLD and / or AP MLD) over multidirectional links 1301 and 1302. For further illustration, the STAs in MLD 1305 and 1309 are shown (STA11 of MLD 1305 is used for communication on link 1301, STA12 of MLD 1305 is used for communication on link 1302, STA21 of MLD 1309 is used for communication on link 1301, and STA22 of MLD 1309 is used for communication on link 1302). Figure 13 shows an exemplary procedure 1300 for buffer state instruction using an additional block acknowledgment request 1310 / additional block acknowledgment 1314 (ADDBA Req / Resp) over multiple links 1301 and 1302. In this example, MLD 1305 can operate on both links 1301 and 1302 using STA 11 and STA 12, respectively. MLD 1309 can operate on both links 1301 and 1302 using STA 21 and STA 22, respectively. STA 11 has traffic to STA 21 over link 1301 and can set up a block ACK agreement by using ADDBA request frames 1310 and ADDBA response frames 1314 on link 1301. Meanwhile, STA 22 may have buffered traffic on link 1302 for STA 21.

[0130] STA11 may be the initiator of a BA agreement via link 1301. STA11 may sense the medium and acquire a channel via link 1301. STA11 may send an ADDBA request frame 1310 to STA21. In addition to other information carried in the ADDBA request frame 1301 (e.g., block acknowledgment action field, block acknowledgment parameter set field, block acknowledgment timeout value field, and / or block acknowledgment start sequence control field), STA11 may use fields / subfields to indicate that MLD 1305 may anticipate ML traffic status, buffer status, and / or QoS requirements for one or more or all operational links. For example, a single bit in the ADDBA request frame 130 may be used to request status reporting for all operational links. For example, the requirements may be per link with explicitly carried link IDs. For example, a link bitmap may be used to request buffer status for one or more links. For example, the requirements may be per TID. For example, a TID bitmap can be used to request buffer state for one or more TIDs. In one example, the requirement might be per Access Category Index (ACI). For example, an ACI bitmap can be used to request buffer state for one or more TIDs.

[0131] When an ADDBA request frame 1310 is received at MLD 1309 via link 1301, STA 21 may respond with an ADDBA response frame 1314. In addition to other information carried in the ADDBA response frame 1314 (e.g., block acknowledgment action field, block acknowledgment parameter set field, block acknowledgment timeout value field, and / or block acknowledgment start sequence control field), STA 21 may use fields / subfields to indicate traffic status, buffer status, and / or QoS requirements for one or more or all operational links. For example, a single bit in the ADDBA response frame 1314 may request a status report for all operational links. For example, the requirements may be per link, with explicitly carried link IDs. For example, a link bitmap may be used to request buffer status for one or more links. In one method, the requirements may be per TID. For example, a TID bitmap may be used to request buffer status for one or more TIDs. In one example, the requirement may be per Access Category Index (ACI). For example, an ACI bitmap may be used to request buffer status for one or more TIDs. In one example, an ACI bitmap may be indicated in a modified HT control field carried within the MAC header. In one example, the modified HT control field may be reused in several modifications or reinterpretations. A BSR control subfield may be used, and the BSR control subfield may be completely reused. The information carried in the BSR control subfield may be interpreted per link instead of / or per link in addition to per link.

[0132] In another example, an EHT-modified HT control field may be included in the ADDBA response frame 1314. In this case, both the originating STA and the responding STA (e.g., STA11 and STA21) may support or be capable of supporting the EHT-modified HT control field. Exemplary control fields may be defined as ML BSR or multi-TID BSR. An exemplary frame format for an ML BSR field 1400A is shown in Figure 14A. An ML BSR 1400A may include a link bitmap subfield 1401. For example, a "1" in the link bitmap field 1401 may indicate that the corresponding link may have a subsequent BSR report. The size of the ML BSR control subfield 1400A may depend on the number of "1s" in the link bitmap field 1401. For example, if there are K "1s" in the link bitmap 1401, there will be K corresponding BSR link subfields 14021-1402 K This is possible. Each BSR link subfield 14021~1402 K This may include information (not explicitly shown) as defined in 802.11ax, such as the ACI bitmap, delta TID, ACI high, scaling factor, queue size high, and / or queue size all.

[0133] An exemplary frame format for the TID BSR field 1400B is shown in Figure 14B. For example, the TID BSR field 1400B may contain a TID bitmap subfield 1404. A "1" in the TID bitmap field 1404 may indicate that the corresponding TID may have a subsequent BSR report. The size of the TID BSR control subfield 1400B may depend on the number of "1s" in the TID bitmap field 1404. For example, if there are K "1s" in the TID bitmap field 1404, there will be K corresponding BSR reports TID14061~1406 K Subfields are possible. Each BSR TID subfield 14061~1406 KThis may include information such as a scaling factor and / or TID queue size (not explicitly shown). The scaling factor may indicate units in the TID queue size. The TID queue size subfield may indicate the buffer size of the TID. For example, the low-latency TID BSR control subfield may be used to indicate a low-latency TID buffer state. An exemplary low-latency TID BSR control subfield 1400C is shown in Figure 14C. Low-latency TIDs may be predefined / predetermined. A low-latency TID can be a set of TIDs with low-latency requirements, and therefore a low-latency TID can be a subset of all TIDs. When the low-latency TID BSR control subfield 1400C is used, it may report the buffer state corresponding to a TID with low-latency requirements. The low-latency TID BSR subfield 1400C is a low-latency ITD bitmap subfield 1408, and K BSR TID subfields 14101-1410 K It may include the following.

[0134] Referring to Figure 13, in one example, several fields of the ADDBA response action frame 1314 may be modified to carry any one or more of the information described above. In one example, fields may be included in the ADDBA response action frame 1314 to carry the information described above. Upon receiving the ADDBA response frame 1314, the MLD 1305 can know the buffer state of the MLD 1309. The MLD 1305 may continue to receive transmissions on link 1301 (e.g., DL transmissions to STA 11 1316) using the negotiated BA agreement, provided that the QoS requirements for the buffered traffic can be met on other links after the data / BA transmission on link 1301.

[0135] In an example not shown in Figure 13, upon receiving the ADDBA response frame 1315, MLD 1305 can know the buffer state of MLD 1309 and, if it cannot meet the QoS requirements for the buffered traffic after data / BA transmission on link 1302, or if the buffered traffic on link 1301 may have strict latency / jitter requirements, it can switch to another link (e.g., link 1302) or activate link 1302. For example (not explicitly shown in Figure 13), STA 11 may send a multilink request frame to STA 21 to indicate operation on link 1302. If either MLD 1305 or 1309 cannot have STR capability over multiple links, the ML request frame may be interpreted as a request to switch operation to link 1302. If both MLD 1305 and 1309 can have STR capability over multiple links, the ML request frame may be interpreted as a request for active operation on link 1302. The ML request frame may indicate a time period for operation on link 1302. In the ML request frame, STA11 may maintain a BA agreement between STA11 and STA21 on link 1301. STA11 may indicate a time period for maintaining the BA agreement. Upon receiving the ML request frame, STA21 may send an ML response frame to STA11. In the ML response frame, STA21 acknowledges the multilink operation request and may switch to link 1302 immediately after the ML response frame.

[0136] As described in the example above, an ADDBA request / response frame may carry an ML BSR control subfield, a TID BSR control subfield, or a low-latency TID BSR control subfield. However, other frames (e.g., frames with a MAC header containing an HT control field) may carry the aforementioned subfields and may be used to exchange buffer states on other links. Based on the buffer states on other links, the MLD may choose to switch links, activate more links, or remain on the current link. BSR subfields as described herein may be responsive or non-responsive. In a responsive BSR report, one or more fields in the ADDBA request frame or other frame solicit a BSR in the ADDBA response frame. In a non-responsive BSR report, the STA / MLD may add a BSR subfield to its MAC header without request.

[0137] ML triggers can be used to resolve conflicts between DL transmissions to non-STR MLDs on link A and UL EDCA transmissions from non-STR MLDs on link B. The exemplary procedure may enable rapid transmission over a different link. Figure 15 shows an exemplary ML trigger procedure 1500 between MLD 1505 (e.g., non-STR STA MLD) and MLD 1507 (e.g., STR AP MLD) via multidirectional links 1501 and 1502. For further illustration, the STA in MLD 1505 and the AP in AP MLD 1507 are shown (STA 11 of MLD 1505 is used for communication on link 1501, STA 12 of MLD 1505 is used for communication on link 1502, AP 11 of AP MLD 1507 is used for communication on link 1501, and AP 12 of AP MLD 1507 is used for communication on link 1502). AP1 may have traffic to send to STA11 via link 1501, and AP1 may check whether STA12 has UL traffic to send to AP2 via link 1502.

[0138] AP1 (of AP MLD1507) may sense the medium and acquire a channel via link 1501. AP1 may send a buffer status report poll (BSRP) trigger frame (TF) 1510 to STA11 (of STA MLD1505). In the BSRP TF 1510, AP1 may indicate that the requested BSR may be on one or more or all links. In one example, the BSRP trigger frame 1510 may include a field from 802.11ax. AP and STA may exchange capability elements to indicate whether they support ML and / or ML BSR. For example, if both AP1 and STA11 have ML capability and can support ML BSR, STA11 may transmit BSR frame 1512 to AP MLD1507. AP1 may treat BSR1512 as an MLD level BSR. If AP1 does not have ML capability and / or cannot support ML, STA11 may treat BSRP TF1510 as an STA level via link 1501. If AP1 has ML capability and STA11 cannot support ML and / or ML BSR, STA11 may report BSR1512 as an STA level via link 1501. AP1 may treat the report as an STA level via link 1501.

[0139] In one example, an ML BSRP trigger frame 1510 may be defined. In one example (not explicitly shown in Figure 15), a new trigger type value may be defined to indicate ML BSRP. In one example, reserved bits in the common information field or user information field may be used to indicate that BSRP TF1510 may request reporting across multiple links. In one example, one of the above indications may be used to indicate ML BSRP. Trigger-dependent common information fields and / or trigger-dependent user information fields may be presented to carry more detailed ML information, for example, to indicate on which links / TIDs BSRP can be triggered. A bitmap of links or TIDs may be carried in the trigger-dependent common information or trigger-dependent user information fields.

[0140] For example, a low-latency ML BSRP trigger frame may be defined. One bit per field may be used to indicate a low-latency ML BSRP trigger frame. For example, the trigger type field or reserved bits may be used. In one example, all low-latency TID buffer status reports are requested. In another example, a low-latency TID bitmap may be carried to indicate which TID buffer status reports are requested. The low-latency TID bitmap may be carried in a trigger-dependent common information field or a trigger-dependent user information field.

[0141] Referring to Figure 15, upon receiving a BSRP trigger frame 1510 from AP1, STA11 may respond on link 1501 with a BSR frame 1512. In one example, the BSR frame 1512 may be reinterpreted as an ML BSR depending on the capabilities of the STA / MLD (e.g., STA11 on MLD1505). In one example, a modified BSR subfield may be used, as described above. In one example, a queue size subfield carried in the QoS control field may be used. The queue size field may be considered the queue size of MLD1505. The QoS control field may carry the queue size for one TID. For example, STA11 may select one TID that may have the most restricted QoS requirements, latency requirements, and / or jitter requirements to report. TIDs can be on the same link (e.g., link 1501) or different links (e.g., link 1502).

[0142] Referring to Figure 15, AP1 may transmit an ML trigger frame (ML TF) 1514. Transmission of the ML TF frame 1514 may occur during the SIFS duration following the completion of reception of the BSR frame 1512, and / or during a TXOP separate from BSR 1512. The ML TF 1514 may be a new type of trigger frame, or a new type of control / management frame, or an existing control / management / data frame, with some modifications or reinterpretations. The ML TF frame 1514 may trigger a target receiver (e.g., MLD 1505) to activate one or more links that may have UL traffic with a specific TID.

[0143] In one example, an ML TF frame 1514 may activate one or more links for a specific time period, the duration of which may be indicated in the ML TF frame 1514. Following this time period, the target receiver (e.g., MLD 1505) may switch back to the link activated by the ML TF frame 1514 or deactivate the link. The ML TF frame 1514 may indicate the link to be activated. In one example, the ML TF 1514 may indicate a TID that the receiver (e.g., MLD 1505) can transmit. Based on the TID-to-link mapping, the MLD 1505 can know which links it can activate. In one example, UL transmission over a newly activated link may be trigger-based only. In one example, UL transmission over a newly activated link may be possible after a predefined / predetermined period or after the MLD 1505 has acquired the NAV configuration on link 1502.

[0144] In one example, ML TF1514 may activate one or more links without time limits, and / or ML TF1514 may indicate which links should be activated. In one example, ML TF1514 may indicate TIDs that a receiver (MLD1505) may transmit. Based on the TID link mapping, a receiving STA11 can know which links it may activate. In one example, UL transmission over a newly activated link may be trigger-based only. In one example, UL transmission over a newly activated link may be possible after a predefined / predetermined period, or after STA12 can acquire NAV settings on link 1502. While STA11 and AP1 exchange frames (e.g., BSRP TF1510, BSR frame 1512, and / or ML TF1514) on link 1501, STA21 may not be able to transmit and receive on link 1501 because link 1502 is a non-STR link pair for MLD1505. After AP1 transmits ML TF1514 on link 1501, MLD1505 can know which links it can activate. In the example shown in Figure 15, MLD1505 can activate STA12 on link 1502. AP2 on link 1502 may transmit TF1518 to trigger a transmission from STA12. STA12 may then transmit data (or other type) frame 1520. AP2 may transmit ACK or BA frame 1522 on link 1502. Depending on the information carried by ML TF1514, activation of link 1502 may occur for a certain period of time. In this case, after the period during which link 1502 is active, MLD1505 switches back to the original link (e.g., link 1501) and can neither transmit (Tx) nor receive (Rx) on link 1502 (indicated as no Tx / Tx1524). Similarly, before ML TF1514, MLD1505 cannot transmit or receive on link 1502 (indicated as no Tx / Tx1516).

[0145] Another exemplary procedure may use an ML TF to announce the next UL OFDMA-based random access (UORA) trigger transmission on a different link / TID. In this case, the associated or unassociated STA on link 1 (e.g., where the link ML TF is sent) may know that its STA may soon have the opportunity to transmit a UL frame on link 2 (e.g., where the link UORA trigger is about to be transmitted). For example, an AP MLD may transmit an ML TF on link 1 to announce the next transmission of a UORA frame on one or more links / TIDs. The ML TF may include, but is not limited to, a link or TID bitmap, where "1" in the bitmap may indicate the link or TID on which a UORA frame may be transmitted, and / or UORA-related information fields, which may include, for example, an AID12 field to indicate that the UORA trigger is for the associated or unassociated STA. In this example, if there is a UORA opportunity in another link, the ML TF may be used to carry information. The ML TF can be generalized to carry information if there will be a UL transmission opportunity in another link. In one example, other types of control, management, and / or data frames may be used to indicate a link or TID bitmap and / or UORA-related information. For example, the corresponding information may be carried in the control field of the MAC header in the frame.

[0146] A procedure for DL / UL responsive frames on Link 1, indicating the buffer state and / or priority of a bufferable unit (Bu) on Link 2, can be used to resolve conflicts between DL transmissions to non-STR MLDs on Link A and UL EDCA transmissions from non-STR MLDs on Link B. Similar to the examples shown in Figures 2, 3, and 4, the buffer state of a TID mapped to Link 2 can be signaled in the PPDU carrying responsive frames on Link 1. This signaling may allow the Link 1 AP or STA of the MLD1 to be less aggressive in transmissions on Link 1 and to have more opportunities to receive on Link 2. Mechanisms for signaling the buffer state may, for example, use the AP PS buffer state subfield in the QoS control field, the queue size subfield in the QoS control field, and / or the BSR in the HE variation of the HT control field. The first two mechanisms (i.e., the AP PS buffer state subfield in the QoS control field, and the queue size subfield in the QoS control field) may not be permitted on link 1 for QoS frames of TIDs mapped to link 2. This restriction can be mitigated by the procedure for prohibiting non-default TID-to-link mapping for low-latency TIDs and the multilink steering and control procedures described above. The second and third mechanisms (i.e., the queue size subfield in the QoS control field, and the BSR in the HE variation of the HT control field) may not be useful in the situations shown in Figures 2 and 3 because they are not transmitted in the DL direction. In some cases, responsive control frames may need to be sent in non-HT (replicated) PPDU frames, which may disable AMPDU aggregation.

[0147] Similar to the example of the quick-trigger-enabled TWT described above, a control wrapper frame may be used as a control response frame. The AP / MLD1 may be allowed to detect a UL / DL TID mapped to another link using a BSR control subfield (part of the A control subfield) or a new control field for reporting buffer status (e.g., as described above for buffer status indication in ADDBA exchange). The BSR control subfield, or the new control field for reporting buffer status, may further allow buffer status signaling in the DL direction. For example, a buffer status report may implicitly function as an instruction for the receiver to terminate the TXOP early, reduce the aggressiveness of the EDCA, and / or temporarily suspend the EDCA on link 1 for a certain (or predetermined) duration, or until a frame (e.g., the frame carrying the reported TID) is received on link 2 from the sender of the report. A buffer status report may also indicate that the TF is being buffered for transmission on link 2.

[0148] The control field may be specified to signal that an STA on Link 1 may need to temporarily suspend EDCA or use alternative EDCA parameters to perform access on Link 1. Examples of alternative EDCA parameters may include, but are not limited to, a longer competition window, a larger inter-frame space, and / or a different CCA threshold. The control field may further include, but are not limited to, the (partial / broadcast) identification information of a third-party non-STR STA, instructions for all (non-STR) STAs on Link 1 and instructions for all (non-STR) STAs on Link 1 whose MLD has a TID mapped to Link 2, the ID of Link 2 for expecting DL / UL transmissions, Link 2 traffic priority / TID / TSID, EDCA pause time, and / or IDs of alternative EDCA parameters. Upon receiving this control field / subfield (for example, in a frame not addressed to an AP / non-STR MLD), the AP MLD and / or non-STR MLD may perform a reduced / paused EDCA access after the current TXOP and / or terminate the current TXOP on Link 1. The paused / reduced access on Link 1 may be terminated when the AP MLD and / or non-STR MLD receive a DL / UL PPDU on Link 2 from the AP MLD and / or non-AP MLD, or based on the end of the duration signaled in the control field.

[0149] Similar to the example of the quick-triggered TWT described above, the frame may be aggregated with the control response frame in AMPDU and / or carried in a PPDU format that allows AMPDU aggregation. The frame may include the control fields described above and / or buffer state indications of the TID mapped to link 2. The frame may be transmitted in a separate (broadcastable) RU in the MU / TB-PPDU along with the control response frame. The frame may include the control fields described above and / or an indication of the buffer state of the TID / TSID mapped to Link 2. In one example, the frame described above may be a QoS null frame. In this case, the QoS null frame of the TID / TSID may be permitted to be transmitted on a link where the TID / TSID is not mapped. Similar to the example of the quick-triggered TWT described above, an indication that there is some (higher priority) traffic buffered on another link may be signaled in the PHY header in the PPDU carrying the control response frame, or in one or more bits in the scrambler initiation that are not used by bandwidth (BW) signaling in the PLPC service data unit (PSDU) carrying the control response frame. The mechanism described above for DL / UL-responsive frames on Link 1, indicating the buffer state and / or priority of the BU on Link 2, may also be applied to solicit PPDUs transmitted by either an AP or a non-AP STA. In this case, the TXOP responder (e.g., STA / MLD) may perform an alternative / reduced / paused EDCA access after the current TXOP. The above mechanism may also be applied to a responsive PPDU sent by a non-AP STA. In this case, the TXOP holder (e.g., AP / MLD) may perform a reduced / paused EDCA access after the current TXOP and / or terminate the current TXOP.

[0150] Procedures for APs indicating EDCA pauses can be used to resolve conflicts between DL transmissions to non-STR MLDs on link A and UL EDCA transmissions from non-STR MLDs on link B. Figure 16 shows an exemplary pause procedure 1600 between MLDs 1605 and 1609 (e.g., non-STR STA MLDs) and MLD 1607 (e.g., STR AP MLD) via multidirectional links 1601, 1602, and 1603. The exemplary pause procedure 1600 shows an exemplary AP MLD 2607 indicating an EDCA pause as part of DL message transmissions 1610 and 1608 to MLDs 1605 and 1609 on links 1601 and 1602, respectively, to allow the transmission of TF 1620 on another link 1603. Outside of the media busy period 1604 on link 1601, MLD 1605 may receive DL message transmission 1610 from AP MLD 1607 and transmit BA 1616. On link 1602, MLD 1609 may receive DL message transmission 1608 from AP MLD 1607 and transmit BA 1614. AP MLD 1607 cannot transmit TF 1620 to MLD 1605 and MLD 1609 on link 1603 during media busy periods 1606 and 1612.

[0151] AP MLD1607 may indicate the current EDCA pause time on link 1601 to one or more (non-STR)MLD1605 received on link 1601 after the current (shortened / prematurely terminated) TXOP1613. Similarly, AP MLD1607 may indicate the current EDCA pause time on link 1602 to one or more (non-STR)MLD1609 received on link 1602 after the current (shortened / prematurely terminated) TXOP. This may allow sufficient time for AP MLD1607 to compete for access on another link 1603 to transmit TF1620 and / or DL ​​data (not explicitly shown). The pause time setting may be based on the observed NAV / PPDU duration on link 1603, the remaining EDCA counter on link 1603 when the pause time indication is transmitted on link 1601 and / or 1602, and / or the length of the TXOP on other links acquired by AP MLD1607. After receiving DL PPDU 1610 on link 1601, MLD 1605 receiving on link 1601 (non-STR) may pause its EDCA counter on link 1601 for the indicated pause duration 1617, or may continue its EDCA counter during the pause, and when the counter reaches zero, it may not perform a transmission on link 1601. After the EDCA pause duration 1617, MLD 1605 may send UL message 1622 on link 1601, assuming that the medium on link 1601 is available. Similarly, MLD 1609 may not send a UL message on link 1602 until after the EDCA pause duration 1619 and until the medium on link 1602 is no longer busy.

[0152] A pause instruction may occur during a broadcast / multicast RU that should be received by MLD1605 and 1609 intended for TF1620 (or DL ​​data) on link 1603, even if MLD1605 and MLD1609 are not intended receivers of the PPDU for data reception on link 1601 or 1602. The instruction may include a list of IDs associated with MLD1605 and 1609, which are intended receivers of TF1620 (or DL ​​data) to be transmitted on link 1603. In one example, instead of pause time, DL PPDU1610 and / or 1608 from AP MLD1607 on links 1601 and / or 1602, respectively, may indicate alternative EDCA parameters. Alternative EDCA parameters may provide a better access probability for TF1620 (or DL ​​data) transmissions on link 1603 from AP MLD1607, giving a higher probability that TF1620 (or DL ​​data) transmissions on link 1603 occur before access on links 1601 and / or 1602 from any (non-STR) MLD1605 or 1609 that are potential recipients of TF1620 (or DL ​​data). The pause time may also be implemented in the form of an MLD-specific NAV on link 1601 or 1602. Only MLD1605 and 1609, which are potential recipients of TF1620 (or DL ​​data) on link 1603, will observe this NAV. As described above, after the pause duration 1617 (and 1619), non-STA MLD1605 (and 1609) may resume their EDCA on links 1601 (and 1602), respectively. Before the end of the pause duration 1617 (and 1619), after the SIFS following the PPDU carrying TF1620 (or DL ​​data) on link 1603, (non-STR) MLD1605 or 1609 may resume its EDCA on link 1601 or 1602, respectively. Following the transmission of TF1620, TB-PPDU1624 may be transmitted from MLD1605 and / or MLD1609 to AP MLD1607 on link 1603 (MLD1605 and MLD1609 may be capable of simultaneous transmission on multiple links).

[0153] Procedures for conditional TFs for another link (e.g., link C) may be used to resolve conflicts between DL transmissions to non-STR MLDs on link A and UL EDCA transmissions from non-STR MLDs on link B. For example, an MLD (e.g., AP MLD) may contain a conditional TF for another link in a PPDU transmitted by AP MLD on link A. The conditional TF may have the same format as other TFs, except that the allocation is for another link (e.g., link C) and the allocation is conditional on receiving a scheduled preamble on link C within an indicated time window. An MLD that is a potential TB-PPDU transmitter on link B may receive the conditional TF on link A. Similar to EDCA pause instructions, the conditional TF may be in a broadcast / multicast RU that should be received by an MLD intended for the TF on link B, even if the MLD is not the intended receiver of the PPDU for data reception on link A.

[0154] Figure 17 illustrates an exemplary conditional TF procedure 1700 between MLDs 1705 and 1709 (e.g., non-STR STA MLDs) and MLD 1707 (e.g., STR AP MLD) via multidirectional links 1701, 1702, and 1703. Outside of a media busy period 1704 on link 1701, MLD 1705 may receive a DL message transmission 1710 from AP MLD 1707 and transmit a BA 1716. AP MLD 1707 may not transmit DL messages to MLDs 1705 and 1709 on link 1703 during an intermediate busy period 1706.

[0155] On link 1702, MLD 1709 may receive DL message transmission 1708 from AP MLD 1707 and transmit BA 1714. MLD 1705 and MLD 1709 may receive conditional TFs as part of DL message transmissions 1710 and 1708 on links 1701 and 1702, respectively. Upon receiving a DL preamble (not shown) from AP MLD 1707 on link 1703, MLD 1705 and 1702 derive, based on the preamble, the time to perform an energy detection (ED) check and the power for TB-PPDU transmissions 1720 from 1705 and 1709. The conditional TF may indicate the allocated RU on link 1703. In this case, MLD1705 and 1709 may refrain from performing UL access after BA1716 and 1614 (i.e., EDCA pause times 1717 and 1719), respectively, and may perform trigger-based (TB) access after waiting for the completion of PPDU1712 on link 1703. After the SIFS duration following the end of DL PPDU1712 on link 1703, EDCA on links 1701 and 17022 may resume, and in this example, MLD1705 may perform a simultaneous UL transmission 1718 (based on EDCA) on link 1701 and a UL TB-PPDU transmission 1720 (based on triggered access) on link 1703.

[0156] Figure 18 shows an exemplary message exchange procedure 1800 between MLD 1805 (e.g., a non-STR STA MLD) and MLD 1807 (e.g., a STR AP MLD) via multidirectional links 1801 and 1802. The message exchange procedure 1800 shows an exemplary AP MLD 1807 on link 1802, which receives TXOP 1822 using TIDY EDCA (when DL TIDY traffic arrives 1817), but sends DL data 1820 to another AC / STA / TID (not shown) before MLD 1805 stops UL transmission 1616 on link 1801.

[0157] During the time period in which MLD1805 is sending UL message 1810 on link 1801 (which can be acknowledged by receiving BA1814 from AP MLD1807), another OBSS / UL STA (not shown) may occupy the medium (channel) on link 1802 by sending UL message 1812 on link 1802. AP MLD1807 on link 1802 may reserve a time period for transmission on link 1802 (i.e., obtain TXOP1822) by transmitting on link 1802 to another TID / STA (not shown) or by triggering a transmission (or both) until (non-STR)MLD1805 on link 1801 can receive it on link 1802. As shown in Figure 18, to avoid the problems described with respect to Figure 2, after the arrival of TIDy traffic 1817 for MLD1805 on link 1802, AP MLD1807 may compete for the channel on link 1802 by using TIDy's AC or any other AC to win EDCA access on link 1802 and occupy the channel on link 1802. Before MLD1805 terminates UL transmission 1816 on link 1801, AP MLD1807 may send DL PPDU 1820 to another STA with an AC of lower or higher priority than TIDy, and / or AP MLD1807 may receive ACK / BA 1826 from the other STA. The MPDU of PPDU1820 may be fragmented, or the PSDU of PPDU1820 may be padded to allow AP MLD1807 to transmit a subsequent DL PPDU1824 (with TIDy) to MLD1805 on link 1802 within the same TXOP1822 after MLD1805 has stopped transmitting 1816 on link 1801 (at this point MLD1805 can process simultaneous reception, so even if MLD1805 is receiving BA1818 on link 1801, MLD1805 can start receiving on link 1802). AP MLD1807 may receive BA1826 and 1828 from the respective STA / MLD1805 in response to DL PPDU1820 and 1824. Following TXOP1822 on link 1802, MLD1805 may resume UL transmission 1830 on link 1801.

[0158] In another example, an AP MLD on link 2 can reserve a channel on link 2 until a (non-STR) MLD on link 1 can receive it on link 2 by sending a trigger frame. Figure 19 shows an exemplary message exchange procedure 1900 between an MLD 1905 (e.g., a non-STR STA MLD) and an MLD 1907 (e.g., an STR AP MLD) over multidirectional links 1901 and 1902. The message exchange procedure 1900 shows an exemplary AP MLD 1907 on link 1902 obtaining a TXOP 1932 by using an arbitrary AC by sending a TF 1918 to another STA (not shown) before the MLD 1905 stops sending UL data 1916 on link 1901. During the time period in which MLD1905 is sending UL message 1910 on link 1901 (which can be acknowledged by receiving BA1914 AP MLD1907), another OBSS / UL STA (not shown) may occupy the medium (channel) on link 1902 by sending UL message 1912 on link 1902. As shown in Figure 19, after the arrival of TIDY traffic 1917 for MLD1905 on link 1902, AP MLD1807 may reserve the channel on link 1902 using TF1918. TF1918 may be addressed to another STA (not shown) or may trigger a UORA transmission. AP MLD1907 on link 1902 may indicate the UL duration of TB-PPDU1920 in TF1918 so that AP MLD1907 can initiate DL TIDY transmission 1926 to MLD1905 on link 1902 within the same TXOP1932 (i.e., after UL transmission 1916 by MLD1905 on link 1901, which can be acknowledged by BA1922). In other words, the end of transmission by BA1922 on link 1901 and the end of transmission by BA1924 on link 1902 can be synchronized.Following TXOP1932 on link 1902 (and DL transmissions of DL PPDU1926 and BA1928), MLD1905 may resume UL transmission 1930 on link 1901. Transmissions to MLD1905 on link 1902 (and similarly to MLD1805 on link 1802 in Figure 18) may include frames necessary for protection (e.g., from the vicinity of MLD1902 on link 1902) and / or signaling for MLD1905 to switch its receiving radio resources to link 1902.

[0159] The example described above may incorporate additional requirements (see, for example, Figure 21 below) to terminate the TXOP of the STA MLD on Link 1 earlier (e.g., to terminate UL transmission 1916 from MLD 1905 on Link 1901 earlier), thereby allowing the STA MLD to receive DL TIDy traffic on Link 1902 earlier. The duration of a CF-End frame (i.e., a control frame that terminates the TXOP) transmitted by the STA MLD on Link 1 can be counted toward the time after which the AP MLD can begin transmitting to the STA MLD on Link 2. Triggered transmissions or DL ​​transmissions to other STAs prior to the transmission to MLD1 on Link 2 within the TXOP cannot be counted toward the TXOP limit of the AC (e.g., the AC for TIDy) that acquires the TXOP. For example, if the TXOP limit for TIDy is zero, the AP may transmit one or more PPDUs in the TXOP before the transmission to MLD1 on Link 2 within the TXOP.

[0160] Figure 20 is a diagram of an exemplary message exchange procedure 2000 between MLD2005 (e.g., a non-STR STA MLD) and MLD2007 (e.g., a STR AP MLD) via multidirectional links 2001 and 2002. The message exchange procedure 2000 shows an exemplary AP MLD2007 using knowledge of the final end time t of a future TXOP. During the time period in which MLD2005 is sending UL message 2010 on link 2001 (which can be acknowledged by receiving BA2014 from AP MLD2007), another OBSS / UL STA (not shown) may occupy the medium (channel) on link 2002 by sending UL message 1812 on link 2002.

[0161] Following the arrival of TIDY traffic 2017 for MLD2005 on link 2002, AP MLD2007 on link 2002 may transmit frame 2018 to indicate the requirement that any TXOP initiated after frame 2018 should be completed before time t. This requirement may apply only to intraBSS STA (not explicitly shown) and / or OBSS STA (not explicitly shown) on this link 2002. Time t may be the time after MLD2005 on link 2001 has stopped UL transmit 2016 (including possible CF-end frames), at which point MLD2005 may begin receiving on link 2002. MLD2005 may receive BA2022 on link 2001 acknowledging UL transmit 2016. Following time t, AP MLD2007 may transmit DL PPDU2026 (with TIDi) to MLD2005 on link 2002, and MLD2005 may transmit BA2028 on link 2002 to acknowledge receipt of PPDU2026. Following TXOP2024 on link 2002, MLD2005 may resume UL transmission 2030 on link 2001.

[0162] To resolve conflicts between DL transmissions to non-STR MLDs on Link A and UL EDCA transmissions from non-STR MLDs on Link B, additional mechanisms, including imposed requirements, may be used in combination with any of the mechanisms described above. Operating Mode (OM) control signaling may be performed implicitly and / or explicitly on a per-link and / or per-MLD basis. For example, OM control transmitted on a link may indicate that UL MU is disabled, UL MU data is disabled, and / or extended range single user (ER SU) is disabled, only on that link. In another example, OM control may apply to Link 2 but be transmitted on Link 1, and the control may explicitly signal the identification information of Link 2. If an AP MLD signals that a link is either UL MU disabled or UL MU data disabled, the AP MLD may not transmit control fields for quick-trigger-enabled TWT instructions, EDCA pause instructions, and / or BSRs (or alternative EDCA parameters) to be applied on the link. In this case, with respect to the control fields for quick-trigger-enabled TWT instructions, EDCA pause instructions, and / or BSRs (or alternative EDCA parameters) to be applied on link 1 to provide access opportunities on link 2, a later transmitted PPDU may include traffic indication map (TIM) elements (e.g., STAs with TIM bits set to 1) indicating which STAs on link 1 can apply the TWT instructions / EDCA pause instructions / control fields for the BSRs (or alternative EDCA parameters) on link 1. Link 1 STAs of MLDs not shown in the TIM bitmap (e.g., those with TIM bits set to zero) can perform EDCA access without restriction (e.g., prematurely terminating quick-triggered TWTs). Subsequently transmitted PPDUs may be transmitted over Link 2.

[0163] Figure 21 illustrates an exemplary use of an instruction to terminate a TXOP early (relative to the TXOP's original termination time). Methods in the previous section, such as quick-trigger-enabled TWT instructions / EDCA pause time / control fields for BSR or alternative EDCA parameters, can also be used as instructions to terminate the current TXOP early. This can address the problem shown in Figure 3. In this case, the TXOP holder may need to send a CF-End frame on Link 1 after the frame carrying the instruction. As an alternative to further reduce the delay on Link 2, the CF-End may be sent by the sender of the instruction to terminate the current TXOP early (e.g., by the AP on Link 1). In this case, the IFS between the frame carrying the instruction and the CF-End frame may be greater than the SIFS to avoid collisions between the CF-End transmission and data transmission if the frame carrying the instruction is lost at / not received by the TXOP holder.

[0164] Figure 21 shows an exemplary message exchange procedure 2100 between MLD2105 and MLD2109 (e.g., non-STR STA MLD) and MLD2107 (e.g., STR AP MLD) over multidirectional links 2101 and 2102. The message exchange procedure 2100 illustrates an example of early termination of TXOP2117 on link 2101. In one example, while MLD2105 is transmitting UL traffic 2110 on link 2101, DL TIDy traffic 2113 may arrive at AP MLD2107 for MLD2105 and be mapped to link 2102. The BA2112 sent by AP MLD2107 to MLD2105 (to acknowledge receipt of UL PPDU2110) may indicate a request to MLD2105 to early terminate DL BSR for TIDy and / or its current TXOP2117 on link 2101. CF-END message 2114 may be sent by AP MLD2107 (e.g., during the PIFS duration after BA2112) or by MLD2105 (e.g., during the ISF duration after BA2112), at which point AP MLD2107 may send a subsequent DL PPDU2116 (with TIDy) on link 2102 to MLD2105. UL transmission 2118 from another MLD2109 on link 2101 (acknowledged by BA2120) may temporally overlap with DL PPDU2116.

[0165] The application of early termination of a TXOP may not be limited to non-STR STAs. For example, if DL data for more latency-sensitive TIDz traffic mapped to Link 1 arrives on AP MLD during a UL TXOP of MLD 1 on Link 1, this procedure can also be used by AP to early terminate the UL TXOP. In the example described above, a DL / UL transmission from MLD1 to MLD1 on Link 2 may include an indication that it is the last transmission / MPDU. In this case, MLD1 / AP MLD can resume its interrupted transmission on Link 1. The indication may be an end of service period (EOSP) field in the QoS control field, or a further data field in the frame control field.

[0166] A mechanism for per-subchannel NAV configuration for non-primary channel transmissions may be used to address issues related to NAV configuration for non-primary channel transmissions for multidirectional links. In an 802.11 system, the capabilities of APs and non-AP STAs may differ. For example, an AP may be capable of operating on a broadband channel, e.g., a channel with a 320 MHz bandwidth. A non-AP STA may receive or monitor a relatively smaller bandwidth channel than the AP, e.g., a 20 MHz or 80 MHz subchannel. A non-AP STA may configure NAV based on frames received on a subchannel with a relatively smaller bandwidth. Traditionally, NAV configuration can maintain predictions of future traffic on the medium based on duration information it announces in the MAC headers of several frames. NAV configuration may be available on a primary 20 MHz subchannel. In the following example, the subchannel may refer to a 20 MHz bandwidth channel.

[0167] In 802.11be, some information carried in the legacy signal (L-SIG) field and / or the universal signal (U-SIG) field may be modulated and repeated via subchannels (e.g., 20 MHz) and may be useful for NAV setting. For example, the TXOP duration field may allow a receiver STA that detects the U-SIG field but does not detect any MAC frames in the PPDU to set the NAV based on the TXOP duration. In addition, the puncturing information field may allow the receiving STA to know which subchannels are punctured and which will be punctured in the TXOP. Based on at least the above information, an unintended STA, including an OBSS STA, may know which subchannels may be occupied and for how long they may be occupied. Thus, a per-subchannel base NAV may be possible or can be set.

[0168] Figure 22 shows an exemplary NAV configuration procedure 2200 for each subchannel. The exemplary NAV configuration procedure 2200 for each subchannel may use the U-SIG field to configure the base NAV configuration for each subchannel. As shown in Figure 22, STA2205 may monitor one or more subchannels, for example, its primary subchannel 2201 (e.g., primary 20MHz subchannel or primary 80MHz subchannel). STA2205 may detect transmissions. Because STA2205 cannot monitor the entire bandwidth of a transmitted PPDU, it may not always be able to detect data transmissions. However, STA2205 may be able to detect one or more signaling fields in the PLCP header that may be transmitted through a subchannel such as the 20MHz subchannel. By decoding the signaling fields of the transmitted PPDU (e.g., the U-SIG field), STA2205 may determine, for example, BSS color, bandwidth, puncturing information, DL / UL information, and / or the duration of TXOP2211.

[0169] In the case of BSS color, if the BSS color cannot be the associated BSS color of STA2205, STA2205 may consider the transmission to be from OBSS, and if not, it may be from its own BSS. The bandwidth field may indicate the bandwidth of the PPDU. 802.11 channeling and signaling over 5GHz and 6GHz may allow STA2205 to uniquely know the start and end frequencies of a channel when it detects a signal on at least one 20MHz subchannel in the bandwidth. For example, STA2205 may monitor subchannels 2201 and 2202. STA2205 may detect nothing on subchannel 2202 but detect a transmission on subchannel 2201. It may detect a U-SIG field or other type of PHY SIG field on subchannel 2201. The puncturing information field may indicate which subchannels are punctured. In one example, a TXOP owner may keep the puncturing information the same throughout the entire TXOP. For example, the TXOP owner may allow TXOP participants to add more punctured subchannels within the same TXOP2211. However, subchannel 2202, which is punctured at the start of TXOP2211, may remain punctured throughout the entire TXOP2211. Based on DL / UL information, STA2205 may know whether the transmission may be from an AP or a non-AP STA. The TXOP duration field may indicate the duration of TXOP2211. Based on the information obtained above, STA2205 may set per-subchannel NAVs 2221, 2223, and 2224 for subchannels 2201, 2203, and 2204, respectively. STA2205 may not have any NAV on subchannel 2202 because it is punctured (or the NAV value for subchannel 2202 is zero). For example, STA2205 can maintain intraBSS NAV2221, 2223, and 2224 for each subchannel, and interBSS NAV2221_1, 2223_1, and 2224_1 for each subchannel.In another example, the STA2205 could maintain an intraBSS NAV across the entire bandwidth and maintain interBSS NAVs 2221, 2223, and 2224 for each subchannel.

[0170] In the example shown in Figure 22, STA2205 may observe / detect a U-SIG on channel 2201 (Ch2201). STA2205 may determine that the transmission may be from an OBSS AP (not explicitly shown). The AP may be operating on an 80MHz channel, and / or the punctured subchannel is channel 2202. In this example, STA2205 may be operating on the same 80MHz channel as the OBSS AP. STA2205 may configure NAV2221, 2223, and 2224 for subchannels 2201, 2203, and 2204 based on the duration of TXOP2211 (which STA2205 can decode). NAV2221 / 2223 / 2224 may be updated based on the duration field in the MAC header when STA2205 decodes a MAC frame carried by a detected PPDU (e.g., any PPDU detected by STA2205). The use of NAV2221 / 2223 / 2224 per subchannel may be similar to that of NAVs such as intraBSS NAV and interBSS NAV. For example, interBSS NAV and intraBSS NAV on a primary 20MHz subchannel can be considered and used as conventional interBSS NAV and intraBSS NAV.

[0171] In trigger-based transmissions, if the CS request subfield in the received trigger frame is set (i.e., carrier sensing is required), the inter-BSS NAV on the primary 20MHz subchannel and the inter-BSS NAV on the assigned subchannels may be considered to determine whether the STA can respond to the trigger frame. If one or more per-subchannel NAV counters on the assigned subchannels are greater than zero (i.e., indicating that one or more assigned subchannels are busy), the STA may not be able to respond to the trigger frame. If the NAV counters on all assigned subchannels are zero, the virtual CS may indicate that the assigned subchannels are idle. In one example, the STA may be able to respond to the trigger frame. In another example, the STA may check the physical CS before responding to the trigger frame. If the NAV counters on some assigned subchannels are zero, but those on other assigned subchannels are greater than zero, the STA may respond using one of the methods mentioned below. For example, the trigger frame may allocate a 40MHz RU to the STA for uplink transmission. The NAV for each subchannel may indicate that one 20MHz subchannel may be idle while other 20MHz subchannels are busy.

[0172] In one example, the STA may respond to the trigger frame via a RU on an available subchannel. The STA may use any RUs that are available within the initially assigned RU. In the example above, the AP may assign the STA 484 tone RUs (corresponding to approximately 40 MHz) in the trigger frame. Due to the per-channel NAV, the STA may be able to respond on the first 20 MHz subchannel. Thus, the STA may have 242 tone RUs to respond. The STA may follow other instructions in the trigger frame for UL transmission. In one embodiment, the STA cannot respond to the trigger frame because the CS is indicated to be busy on the assigned RU.

[0173] In another example, the AP may have a smaller RU indication in the user information subfield and / or common information subfield of the trigger frame sent to the STA. When a smaller RU indication is set, the STA may be allowed to respond to the trigger frame using RUs that may belong to the assigned RU. When a smaller RU indication is not set, the STA may not be allowed to respond to the trigger frame using RUs that may belong to the assigned RU. This method may apply to all or some trigger frame types, regardless of the use of per-subchannel NAV. In the example described above, physical carrier sensing (CS) may be performed before the STA responds to the trigger frame. Note that interBSS NAV may be referred to as basic NAV.

[0174] Exemplary procedures may be used to set MU-EDCA parameters and / or timers for MLs. Non-AP MLDs may use a single MU-EDCA timer per AC for multiple links; for example, the MUEDCATimer[AC] variable per MLD may be updated with the values ​​described below. The updated MUEDCATimer[AC] may be started at the end of an immediate acknowledgment if the TB / SU PPDU transmitted on any active link contains at least one QoS data frame for that AC that requires an immediate acknowledgment. The updated MUEDCATimer[AC] may be started at the end of a TB / SU PPDU transmitted on any active link if the TB / SU PPDU does not contain any QoS data frames for that AC that require an immediate acknowledgment, but contains at least one QoS data frame for that AC.

[0175] If the advertised MU-EDCA timer values ​​for each link on all active links for the AC (e.g., broadcast using beacon frames on each link) are the same, a non-AP MLD may use a common value as the MU-EDCA timer for the AC. If the advertised MU-EDCA timer values ​​for each link on all active links for the AC are not the same, a non-AP MLD may use a minimum value as the MU-EDCA timer for the AC. If the advertised MU-EDCA timer values ​​for each link on all active links for the AC are not the same, a non-AP MLD may use a maximum value as the MU-EDCA timer for the AC. An AC's active link may be a set of links to which the AC's TID is mapped. An AC's active link may be a set of links to which the AC's TID is mapped, and which are not in a PS mode dose state for a non-AP STA. An AP MLD may signal alternative or additional MU-EDCA set elements or MU-EDCA parameters and may include alternative / common MU-EDCA timers in unicast signaling. The MU-EDCA timer value in the (re)association response or another unicast DL frame may differ from the MU-EDCA timer signaled in the beacon frame. The AP MLD may signal an alternative or additional set of arbitration interframe spacing number (AIFSN) or contention window (ECW)_min / max values ​​common to all active links in the (re)association response or another unicast DL frame. The signaled AIFSN or ECW_min / max value may differ from the AIFSN or ECW_min / max value signaled in the beacon frame.

[0176] If the UL TIDs of the same AC are mapped to disparate pairs of links (i.e., different TIDs of the same AC do not share any common links), and the BSR carried in the HE control information / field cannot provide explicit identification information for the TID of the buffered data, then the BSR from a non-AP MLD for the AC may be required to be carried in the QoS control field or a newly defined field. The BSR field may explicitly identify the TID of the buffered traffic. The BSR field may contain a bitmap in which each bit corresponding to the TID indicates the presence of buffered traffic for that TID. The BSR field may contain a bitmap or identification information for the AC of the buffered traffic, along with a subsequent bitmap or identification field for further identification of the TID of the identified AC having the buffered traffic.

[0177] The MU-EDCA timer for each MLD may be defined per TID, rather than per AC. MUEDCATimer[TID] may start at the end of an immediate acknowledgment if the TB / SU PPDU transmitted on any active link contains at least one QoS data frame for that TID requiring an immediate acknowledgment. MUEDCATimer[TID] may start at the end of a TB / SU PPDU transmitted on any active link if the TB / SU PPDU does not contain a QoS data frame for that TID requiring an immediate acknowledgment, but contains at least one QoS data frame for that TID. The value of the MUEDCATimer[TID] timer may be determined using a similar mechanism as described above (i.e., based on per-link parameters being broadcast, or based on parameters from unicast signaling).

[0178] AP MLDs and non-AP MLDs may be required not to map two different UL TIDs for the same AC to two disparate pairs of links. Upon receiving a BSR for a particular AC without knowing the TIDs of the buffered traffic, the AP may schedule UL access on a link that lies at the intersection of two pairs of links mapped to two TIDs for the same AC. AP MLDs and non-AP MLDs may be required to map two different UL TIDs for the same AC to the same pair of links. Upon receiving a BSR for a particular AC without knowing the TIDs of the buffered traffic, the AP may schedule UL access on any of the active links in a pair. If a non-AP MLD signals UL MU(data) deactivation for link 1, and the MU-EDCA timer (per MLD) is running for a TID mapped to that link that is also mapped to another link 2 where UL MU(data) is not deactivated, then it may be necessary that the MU-EDCA parameter (for link 1) be available for EDCA access on link 1. In the case of an N-STR link pair, if a non-AP MLD signals UL MU(data) deactivation for one link, the signaling may implicitly indicate to the AP MLD that the other link is also UL MU(data) deactivated.

[0179] In some examples relating to inter / intra BSS NAV per subchannel, in the case of MU PPDU, a non-AP STA may monitor at least the primary subchannel, inspect the NAV in the PHY or MAC header, and / or inspect puncturing information in the NAV with PHY SIG configured per subchannel. 80MHz and 160MHz channels cannot have overlap, but 320MHz channels can. In the case of 320MHz channels, an indication may be used to show the exact 320MHz channel location in the U-SIG. Therefore, the examples described herein may apply to inter-BSS NAV. In some examples relating to MU-EDCA, improved efficiency may be obtained by prioritizing MU transmission. For example, HE non-AP STAs may reduce the probability of EDCA channel access only when they are scheduled by APs. Both APs and STAs may compete to access the channel for the same traffic. This can lead to collisions and performance degradation.

[0180] In some examples related to MU-EDCA in ML, the MU-EDCA timer may be used per link and / or per MLD for AC. As mentioned above, non-AP STAs may reduce the probability of EDCA access when they are scheduled by AP. The MU-EDCA timer may be used per link and / or per MLD for AC. In the case of an EDCA timer per MLD, the signaling of the timer value may not reuse the same value in the MU-EDCA parameter element, because if the value for N links is the same, then N different values ​​for N links will reuse the value in the MU-EDCA parameter element. For triggers to start / reset the timer, an ACK of the TB-PPDU for any link may be used to restart the timer. In another example, other MU-EDCA parameters (e.g., CW / AIFSN) may be maintained per link.

[0181] Examples of the same AC's TID mapped to different links are described herein. Link mapping may be defined per TID. BSR in QoS control may be per TID. For example, AC1 may be (TID1, TID2). TID1 is mapped to link 1 and TID2 is mapped to link 2. UL BSR in QoS control may be reported for TID1. If a per-MLD MU-EDCA timer is used, the MU-EDCA timer[AC1] may not apply to link 2. Examples of UL MU(data) disabling in ML are described herein. UL MU(data) signaling may be disabled in ML scenarios. Signaling may be per link or per N-STR link pair (link 1, link 2). For example, if link 1 signals that UL MU(data) is disabled, this may implicitly indicate that link 2 UL MU is also disabled. Relationships with per-MLD MU-EDCA timers may be described herein. If Link 1 signals UL MU disablement while the MU-EDCA timer is running, Link 1 may use normal EDCA parameters, while other links use MU-EDCA parameters for the same AC. A non-AP STA that sends a frame to the AP with an OM control subfield containing a value of 1 in the UL MU Disable subfield, or a value of 0 in the UL MU Disable subfield and a value of 1 in the UL MU Data Disable subfield, will not participate in UL MU operation. Therefore, it is exempt from updating its EDCA access parameters to values ​​included in the MU-EDCA parameter set elements as defined in this subclose. Link 1 may still use MU-EDCA parameters because MLD can still be scheduled on other links that do not have coexistence issues.

[0182] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. An access point (AP) multilink device (MLD), A receiver configured to receive a frame containing control elements indicating the priority associated with data traffic associated with a link between a non-AP station (STA) MLD and another MLD, the delay associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD, and the traffic identifier (TID) associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD, A processor configured to determine a schedule for data traffic relating to the non-AP STA MLD based on the received frame, A transmitter configured to transmit data traffic to the non-AP STA MLD based on the determined schedule, AP MLD characterized by having the following features.

2. The AP MLD according to claim 1, characterized in that the control element enables the AP MLD to satisfy the priority associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD, and the delay associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD.

3. The AP MLD according to claim 1, characterized in that the data traffic is associated with the TID.

4. The AP MLD according to claim 3, wherein the data traffic associated with the TID is transmitted to the non-AP STA MLD in accordance with the priority and delay associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD.

5. The AP MLD according to claim 1, characterized in that the AP MLD is composed of a plurality of links between the non-AP STA MLD and the AP MLD.

6. The AP MLD according to claim 1, characterized in that the control element is received in a data frame.

7. The AP MLD according to claim 1, characterized in that the control element is received in a media access control (MAC) header.

8. A method for use in an access point (AP) multilink device (MLD), Receiving a frame that includes control elements indicating the priority associated with data traffic associated with a link between a non-AP station (STA) MLD and another MLD, the delay associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD, and the traffic identifier (TID) associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD, Based on the received frames, a schedule is determined for the data traffic relating to the non-AP STA MLD, To transmit data traffic to the non-AP STA MLD based on the determined schedule. A method characterized by comprising:

9. The method according to 8, characterized in that the control element enables the AP MLD to satisfy the priority associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD, and the delay associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD.

10. The method according to 8, characterized in that the data traffic is associated with the TID.

11. The method according to 10, characterized in that the data traffic associated with the TID is transmitted to the non-AP STA MLD in accordance with the priority and delay associated with the data traffic associated with the link between the non-AP STA MLD and the AP MLD.

12. The method according to 8, characterized in that the AP MLD is composed of a plurality of links between the non-AP STA MLD and the AP MLD.

13. The method according to 8, characterized in that the control element is received in a data frame.

14. The method according to 8, characterized in that the control element is received in a media access control (MAC) header.

15. A station (STA) multilink device (MLD), A processor configured to generate a frame including control elements indicating the priority associated with the data traffic associated with the link between the STA MLD and the access point (AP) MLD, the delay associated with the data traffic associated with the link between the STA MLD and the AP MLD, and the traffic identifier (TID) associated with the data traffic associated with the link between the STA MLD and the AP MLD, A transmitter configured to transmit the frame including the control elements to the AP MLD, A receiver configured to receive data traffic from the AP MLD based on the control element via the link between the STA MLD and the AP MLD, STA MLD is characterized by having the following features.

16. The STA MLD according to claim 15, characterized in that the data traffic is received by the STA MLD such that the priority and delay associated with the data traffic are satisfied.

17. The STA MLD according to claim 15, wherein the receiver is further configured to receive data traffic from different links associated with the AP MLD.

18. The STA MLD according to claim 17, characterized in that the different links associated with the AP MLD are selected based on the control element.

19. The STA MLD according to 17, wherein the different links associated with the AP MLD are selected based on the priority associated with the data traffic or based on the delay associated with the data traffic.

Images