Multi-link steering and control in WLANs.

Abstract

A method and apparatus are disclosed for multilink (ML) steering and control in a wireless local area network (WLAN). A station (STA) multilink device (MLD) may communicate over multiple links. The STA MLD may receive a first frame comprising an ML element from an access point (AP) MLD on a first link of the multiple links, the ML element including dormancy information indicating a time period during which the STA MLD will dormant on the first link. The STA MLD may transmit uplink (UL) traffic to the AP MLD on a second link of the multiple links and during the indicated time period, the first link and the second link being multidirectional links. The STA MLD may be non-simultaneous transmit and receive (non-STR), and the AP MLD may be STR-capable.

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 August 6, 2020, and U.S. Provisional Patent Application No. 63 / 109,221, filed November 3, 2020, the contents of which are incorporated herein by reference. [Background technology]

[0002] In multilink operation between two multilink devices, such as an access point (AP) and a non-AP station (STA), the multilink devices may coordinate with each other regarding which link they intend to use. Link selection is particularly important when low-latency traffic with strict delay and reliability is supported. In addition, constraints imposed by non-simultaneous transmit and receive (STR) multilink devices (e.g., AP multilink devices and / or non-AP multilink devices), which support either simultaneous transmission or simultaneous reception but not simultaneous transmission and reception, further complicate the problem of link steering and control in multilink operation. Therefore, a mechanism is needed to efficiently and effectively manage, steer, and control link usage between multilink devices. Summary of the Invention

[0003] A method and apparatus are disclosed for multi-link (ML) steering and control in a wireless local area network (WLAN). A station (STA) multi-link device (MLD) may communicate over multiple links. The STA MLD may receive a first frame comprising an ML element from an access point (AP) MLD on a first link of the multiple links, the ML element including dormancy information indicating a time period during which the STA MLD will dormant on the first link. The STA MLD may transmit uplink (UL) traffic to the AP MLD on a second link of the multiple links and during the indicated time period, the first link and the second link being multidirectional links. The STA MLD may be non-simultaneous transmit and receive (non-STR), and the AP MLD may be STR-capable. [Brief explanation of the drawings]

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D]1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2] 1 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link illustrating UL and DL conflicts caused by non-default traffic identification (TID) to link mapping. [Figure 3] 1 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link, illustrating an example of UL and DL contention caused by a long duration transmission opportunity. [Figure 4] 10 is a diagram of another exemplary message exchange procedure between MLDs over a multi-directional link illustrating a conflict between UL and DL caused by a non-default TID-to-link mapping. [Figure 5] 10 is a diagram of another exemplary message exchange procedure between MLDs over a multi-directional link illustrating real-time modification or delay of buffered frames. [Figure 6] FIG. 10 is a diagram of another exemplary message exchange procedure between MLDs over a multi-directional link, illustrating contention between a downlink (DL) trigger frame (TF) transmission and an uplink (UL) enhanced distributed channel access (EDCA) transmission on different links. [Figure 7] 10 is a diagram of another exemplary message exchange procedure between MLDs over a multi-directional link, showing the MLD losing its network allocation vector (NAV) after transmitting a UL message on a different link. [Figure 8] FIG. 1 is a diagram of an exemplary multi-link steering and control procedure between MLDs over a multi-directional link. [Figure 9]1 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link showing an exemplary quick trigger-enabled target wake time (TWT). [Figure 10] 10 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link illustrating an exemplary third-party quick trigger-enabled TWT. [Figure 11] 10 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link, illustrating another exemplary third-party quick trigger-enabled TWT. [Figure 12] 1 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link, showing exemplary quick trigger-enabled TWTs on different links. [Figure 13] 10 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link illustrating buffer status indication using block addition acknowledgement requests and block addition acknowledgements. [Figure 14A] 1 is a diagram of an example frame format of a Multilink (ML) buffer status report (BSR) field. [Figure 14B] FIG. 1 is a diagram of an example frame format for a traffic identifier (TID) buffer status report (BSR) field. [Figure 14C] FIG. 10 is a diagram of an example frame format for a TID BSR control field. [Figure 15] FIG. 1 is a diagram of an exemplary ML trigger procedure between MLDs over a multi-directional link. [Figure 16] FIG. 10 illustrates an exemplary idle time procedure between MLDs over a multi-directional link. [Figure 17] FIG. 10 is a diagram of an exemplary conditional TF procedure between MLDs over a multi-directional link. [Figure 18] 1 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link showing an AP MLD obtaining a transmission opportunity (TXOP) using TID EDCA. [Figure 19] 1 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link, showing an AP MLD obtaining a transmission opportunity (TXOP) using an access category by transmitting a trigger frame (TF). [Figure 20] 10 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link, showing that the AP MLD uses knowledge of the latest end time of a future TXOP. [Figure 21] 10 is a diagram of an exemplary message exchange procedure between MLDs over a multi-directional link illustrating the use of an indication to terminate a TXOP early. [Figure 22] 10 is an example of a procedure for setting a NAV for each sub-channel. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may 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 filtered OFDM, filter bank multicarrier (FBMC), etc.

[0006] 1A, communications system 100 may include wireless 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a multi-link device (MLD), a STA MLD, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

[0008] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The 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 a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

[0009] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the air interface 116, which may be any suitable wireless 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 noted above, the communications system 100 may be a multiple-access system and may use one or more channel access schemes, such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a of the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the 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, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the 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 the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

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

[0014] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology 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, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0015] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a location such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

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

[0017] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 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 that 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. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104 or a different RAT.

[0018] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114b that may use an IEEE 802 wireless technology.

[0019] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0020] The processor 118 may be a general-purpose processor, a special-purpose 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 the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the 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) over 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 IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0022] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use 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 wireless signals over the air interface 116.

[0023] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, 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 WTRU 102 may be coupled to and may receive user-entered data from 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). 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 and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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, etc. In other embodiments, the processor 118 may access information and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0025] The processor 118 may receive power from the power source 134, but may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, 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) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0027] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the 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, etc. The peripherals 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

[0028] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe on both the UL (e.g., for transmission) and DL (e.g., for reception)) may be simultaneous and / or joint. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate 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, the WTRU 102 may include a half-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe on either the UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be joint.

[0029] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

[0030] The RAN 104 may include eNodeBs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0031] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. in the UL and / or DL. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

[0033] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0034] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0035] The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0036] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Furthermore, the CN 106 may provide the WTRUs 102a, 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.

[0037] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

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

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

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

[0041] High Throughput (HT) STAs may use 40 MHz wide channels 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] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz-wide channels. The 40 MHz and / or 80 MHz-wide channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be transmitted to the Medium Access Control (MAC).

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

[0044] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the 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) configuration can depend on the condition of the primary channel. For example, if the primary channel is busy, a STA transmitting to the AP (that only supports 1 MHz mode of operation) may cause all of the available frequency bands to be considered busy, even if most of the available frequency bands are 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] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

[0047] While the RAN 104 may include gNBs 180a, 180b, and 180c, it will be understood that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, transmit wireless signals to and / or receive wireless signals from the WTRU 102a using multiple antennas. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, and the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0048] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time).

[0049] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0051] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are shown as part of the CN 106, it will be understood that any of these elements may also be owned and / or operated by an entity other than the CN operator.

[0052] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of the SMF 183a, 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0053] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 106 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 106 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0054] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as packet routing and forwarding, user plane policy enforcement, support for multi-homed PDU sessions, handling user plane QoS, DL packet buffering, mobility anchoring, etc.

[0055] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 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, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0056] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0057] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or an 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 communication network to test other devices in the communication 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 communication network. The emulation devices may be directly coupled to another device for testing and / or conducting tests using over-the-air wireless communication.

[0058] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network 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 (which may include, e.g., one or more antennas) may be used by the emulation devices 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 in the same symbol time frame, e.g., during a downlink (DL) OFDM symbol. Downlink MU-MIMO can be used with other protocols, including, but not limited to, 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 an issue. However, all STAs involved in MU-MIMO transmission with an AP (e.g., DL MU-MIMO transmission from an AP to a STA) may be required to use the same channel or band, which may limit the operating bandwidth to the minimum channel bandwidth supported by the STAs that are 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, in 802.11be, the main use cases and applications addressed 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 increased peak throughput and improved efficiency, including, but not limited to, the following example features: multi-AP, multi-band / multi-link, 320 MHz bandwidth, 16 spatial streams, hybrid automatic repeat request (HARQ), AP cooperation, and / or design for 6 GHz channel access.

[0062] 802.11be and / or EHT may include multi-link operation, including, for example, non-simultaneous transmit and receive (non-STR) operation. In the following example of non-STR operation, an AP multi-link device (MLD) may be capable of simultaneous transmit and receive (STR) on multiple links (e.g., an AP MLD may transmit on a first link and simultaneously receive on a second link), and a STA MLD may be non-STR on one or more paired links (e.g., if a STA MLD cannot transmit on a first link and simultaneously receive on a second link, the pair of the first and second links is considered a non-STR pair of STA MLDs). In one example of non-STR operation, UL transmissions from a non-AP MLD on a first link "Link 1" may interfere with reception on a 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 align the ends of the PPDUs to reduce and / or avoid interference. In another example of non-STR operation, NAV and / or PPDU length status may be received by a 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 one example of non-STR STA MLD with single radio operation, the STA MLD may lose NAV status of another link during transmission, and the STA MLD may lose NAV status during data reception.

[0063] In examples directed to non-STR operation described herein, it may be assumed that the AP is the STR-capable AP MLD and the STA is the non-STR-capable STA MLD, unless otherwise specified. In examples of non-STR operation described herein, unless otherwise specified, the NAV and / or PPDU length status may be received by the 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 multi-directional links, one or two STA MLDs, and / or one AP MLD, but may be generalized to other numbers of links (e.g., more than two links), STA MLDs (e.g., more than two STA MLDs), and / or AP MLDs not shown.

[0064] Although not shown in all examples, it may be assumed that a STA MLD may comprise multiple STAs (e.g., internal or co-located) for communicating over multiple links. For example, a STA MLD may comprise STA1 for communicating over link 1 and STA2 for communicating over link 2. Similarly, an AP MLD may comprise multiple APs (e.g., internal or co-located) for communicating over multiple links. For example, an AP MLD may comprise AP1 for communicating over link 1 and AP2 for communicating over link 2. In the examples described herein, transmission, 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 a 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 an STR AP MLD may communicate over multiple links using one transceiver or multiple transceivers (e.g., one transceiver per link). Communications between MLDs over the air interface may pass through 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. The AP may assign OFDMA resources to STAs in terms of resource units (RUs), which may indicate a set of subcarriers to be used by the STAs for communication.

[0065] In one 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 Enhanced Distributed Channel Access (EDCA) transmissions from the non-STR (STA) MLD on a second link (e.g., Link B or Link 2). The ability to transmit and receive between the STR MLD (e.g., AP) and the non-STR MLD (e.g., STA) on a link may depend on the channel availability of that link and on the traffic direction of the other link, which may lead to delays or high latency for the mapped traffic. Mechanisms and procedures for handling this conflict are described herein.

[0066] 2 is a diagram of an example message exchange procedure 200 between an MLD 205 (e.g., a non-STR STA MLD) and an MLD 207 (e.g., an STR AP MLD) over multidirectional link 201 and multidirectional link 202. Message exchange procedure 200 illustrates an example of UL and DL contention caused by a non-default traffic identification (TID)-to-link mapping. In one example, DL TIDy traffic 216 for MLD 205 may be mapped to link 202, while the remainder of the TID traffic may be mapped to link 201. DL TIDy traffic 216 may arrive at the AP MLD 207 for MLD 205 (e.g., traffic received at the MAC layer from higher layers).

[0067] During the time period when the MLD 205's TID is used by the MLD 205 to transmit a UL message 210 on link 201 (which may be acknowledged by the MLD 207 by transmitting a block acknowledgment (BA) 214), the AP MLD 207 may suspend EDCA for TIDy, as shown in example message exchange procedure 200 (e.g., because the MLD 205 cannot receive on link 202 while transmitting on link 201). During the time period when the MLD 205 is transmitting a UL message 210 on link 201 using the TID, other OBSS / UL STAs (not shown) may occupy the medium (channel) on link 202 by transmitting a UL message 212 on link 202, and may continue transmitting when the MLD 205 on link 201 is idle, preventing the AP MLD 207 from performing EDCA for TIDy before the UL transmission from the MLD 205 is finished. Therefore, the higher priority TIDy does not get an EDCA opportunity before the UL transmission from MLD 205 stops.

[0068] 3 is a diagram of an example message exchange procedure 300 between an MLD 305 (e.g., a non-STR STA MLD) and an MLD 307 (e.g., an STR AP MLD) over multidirectional link 301 and multidirectional link 302. Message exchange procedure 300 illustrates an example of UL and DL contention 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 remainder of the TID traffic for MLD 305 (e.g., UL traffic and / or DL ​​traffic) may be mapped to link 301.

[0069] 3 , urgent 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 urgent data with TIDy 316 on link 302 because MLD 305 is transmitting UL data 310 on link 301 (which MLD 407 may acknowledge by transmitting BA 314). By the time UL TXOP 308 on link 301 ends, link 302 medium may experience a busy period 318 with other transmissions, and thus, DL urgent data with TIDy 316 may be further delayed until after the busy period 318 on link 302.

[0070] 4 is a diagram of another example message exchange procedure 400 between an MLD 405 (e.g., a non-STR STA MLD) and an MLD 407 (e.g., an STR AP MLD) over multidirectional link 401 and multidirectional link 402. Message exchange procedure 400 illustrates an example of UL and DL contention caused by a non-default TID-to-link mapping. In one example, DL TIDy traffic 416 for MLD 405 may be mapped to link 402, and the remainder 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 MLD 405 can cause a medium busy 418 on link 402 and interfere with reception on link 401, particularly the ability of MLD 405 to receive DL messages 410 (which can be acknowledged by MLD 405 transmitting BA 414). Furthermore, transmissions on link 402 can be restricted to trigger frame-based access because MLD 405 may park on a non-primary channel. In the absence of UL buffer conditions, AP MLD 407 would not know to send trigger frames on link 402 and stop DL transmissions 410 on link 401 to MLD 405.

[0072] 5 is a diagram of another example message exchange procedure 500 between MLD 505 and MLD 509 (e.g., non-STR STA MLDs) and MLD 507 (e.g., STR AP MLD) over multidirectional link 501 and multidirectional link 502. Message exchange procedure 500 illustrates an example real-time modification or delay of buffered frames. During a medium busy period 504 on link 501, AP MLD 507 may buffer or queue trigger frames (TFs) on link 502 of MLD 505 and MLD 509 for the UL TID mapped to link 502.

[0073] The AP MLD 507 may wait until after a medium busy period 506 on link 502 to obtain access to a channel on link 502 (e.g., using EDCA) to transmit TF 518 to MLD 505 and MLD 507. During the medium busy period 506 on link 501, UL / DL message transmissions 510 and BA 514 may be exchanged on link 502. Before the AP MLD 507 obtains EDCA access to link 502 to transmit TF 518, there may be a UL message transmission 516 from MLD 505 on link 501 that overlaps in time with the TF transmission 518 to MLD 505 and MLD 509, which may not be processed by the non-STR MLD 505. In this case, the AP MLD 507 may reallocate the UL resources on link 502 for the TF 518 for MLD 505 to another STA or MLD (i.e., the AP MLD 507 may dynamically change the resources used to transmit TF 518). In another example of this case (not shown), the AP MLD 507 may delay transmission of the TF 518 until the UL transmission 516 on link 501 finishes. In either case, the transmission of the TF 518 queued for the MLD 505 and MLD 509 is delayed. In the case of multi-user EDCA (MU-EDCA) introduced in 802.11ax, the MU-EDCA parameters may provide less aggressive EDCA compared to the EDCA of the TF. In the example of FIG. 5, the UL message transmission 516 from the MLD 505 on link 501 and the TF 518 for the MLD 505 (and MLD 509) on link 502 may be for different TIDs, so the MU-EDCA parameters may not be useful. The UL transmission 516 may not use the MU-EDCA parameters of the EDCA.

[0074] 6 is a diagram of another example message exchange procedure 600 between MLDs 605 and 609 (e.g., non-STR STA MLDs) and MLD 607 (e.g., STR AP MLD) over multidirectional links 601, 602, and 603. Message exchange procedure 600 illustrates an example contention between a DL trigger frame (TF) transmission 622 on link 603 and UL EDCA transmissions 618 and 620 on links 602 and 603. As shown in FIG. 6, UL EDCA transmission 618 from MLD 609, UL EDCA transmission 620 from MLD 605, and / or BA transmissions 614 and 616 from MLDs 609 and 605, respectively, may conflict with a DL TF 622 transmission from AP MLD 607 to MLDs 605 and 609.

[0075] A non-STR MLD 605 may be associated with an AP MLD 607 on links 601 and 603. The TIDx of the MLD 605 may be mapped to link 603, and the TIDy of the MLD 605 may be mapped to link 601. A non-STR MLD 609 may be associated with the AP MLD 607 on links 602 and 603. The TIDx of the MLD 609 may be mapped to link 603. The TIDy of the MLD 609 may be mapped to link 602. Outside of a medium busy period 604 on link 601, the MLD 605 may receive a DL message transmission 608 from the AP MLD 607 and may send a BA 616 and a UL message transmission 620 to the AP MLD 607. On link 602, MLD 609 may receive DL message transmission 610 from AP MLD 607 and may send BA 614 and UL message transmission 618 to AP MLD 607. AP MLD 607 may not send TF 622 to MLD 605 and MLD 609 on link 603 during intermediate busy periods 606 and 612.

[0076] To transmit TF 622 to non-STR MLD 605 and non-STR MLD 609 on link 603, AP MLD 607 may verify that the scheduled trigger-based PPDU (TB-PPDU) on link 603 does not overlap with any of the receptions for MLD 605 and MLD 609 on links 601 and 602. AP MLD 607 may verify that the duration of the PPDU carrying TF 622 and the time period of the short interframe space (SIFS) after the PPDU do not overlap with any of the UL transmissions 620 and 618 of MLD 505 and MLD 509, respectively.

[0077] 6, when AP MLD 607 transmits DL PPDU 608 and DL PPDU 610 to MLD 605 and MLD 609 on links 601 and 602, AP MLD 607 cannot transmit TF 622 to MLD 605 and MLD 609. For example, if the end of the PPDU carrying TF 622 aligns with the end of DL PPDU 607 to MLD 605, the condition that PPDUs do not overlap for MLD 609 is violated. If the end of the PPDU carrying TF 622 aligns with the end of DL PPDU to MLD 609, the PPDU condition for MLD 605 is violated. To satisfy both conditions, AP MLD 607 may align the end of DL PPDU 608 and / or DL ​​PPDU 610 to multiple links 601 and 602 with multiple links 605 and 609 by either padding or fragmentation. In this case, the complexity and overhead increases with the number of STA-MLDs scheduled in TF 622. Furthermore, there is no guarantee that medium contention will be successful and that the PPDU carrying TF 622 can be transmitted before the end of aligned PPDUs on other links.

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

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

[0080] Mechanisms for link steering and control of multi-link operation may be used. In multi-link 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 links to use. This coordination may be particularly important for low-latency traffic that requires support for strict delay and reliability requirements. Constraints imposed by non-STR APs and / or non-AP MLDs, which may only support simultaneous transmission or simultaneous reception, further complicate link steering and control in multi-link operation. Mechanisms for efficiently and effectively managing, steering, and controlling link usage between MLDs are disclosed herein.

[0081] In one example, the problem may be related to the NAV setting of non-primary channel transmissions. In one example, a STA may have its NAV set in its primary (e.g., 20 MHz) subchannel. This NAV setting may limit the use of the non-primary (e.g., 20 MHz) subchannel. For example, a non-AP STA may join a BSS with 80 MHz operation. The STA may have the capability to operate on an 80 MHz channel. The STA may have a NAV set based on monitoring on its primary 20 MHz subchannel. The STA may then be unable to respond to trigger frames on the secondary 20 MHz subchannel or the secondary 40 MHz subchannel, even if the secondary subchannel is idle.

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

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

[0084] In Multi-Link Operation (MLO), a non-AP MLD can be scheduled for UL access on any link to which its UL TID is mapped based on the non-AP MLD's UL buffer status. Based on this mechanism, link A, which has successfully transmitted a TB-PPDU for an AC, can reduce the priority of medium contention for that AC. On the non-AP STA side, this effectively redirects UL traffic to other links B and C for more aggressive EDCA access, after which the non-AP MLD can perform successful TB-PPDU transmission on these other links. The AP MLD may be aware of the congestion status of different links and the non-AP MLD's buffer status, which may be contained in a buffer status report (BSR) in the header of a medium access control (MAC) protocol data unit (MPDU) in a previously transmitted TB-PPDU. Assuming that links B and C are congested, the AP may schedule only UL access for non-AP MLD on link A to avoid EDCA access on links B and C. However, because EDCA priority reduction occurs only on link A, this may give more opportunities for non-AP MLD to perform (e.g., conflicted) 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, an access category index (ACI) Bitmap subfield and a delta TID subfield may be used to indicate that the buffer status of one or more access categories (ACs) is included in the Queue Size All subfield. In one example, if one bit in the ACI Bitmap subfield (corresponding to AC1) may indicate traffic corresponding to TID1 and TID2, 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 the delta TID subfield set to "0" (indicating one TID has buffered traffic), the AP may not be able to determine which TID is requesting scheduling and may not know on which link to send a trigger frame for the buffered AC1.

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

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

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

[0089] As described above, link access contention may occur when the access of a more urgent PPDU on Link 2 is blocked by transmission activity on Link 1. In an exemplary solution, more urgent PPDUs may be allowed to contend for medium 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. In one example, for 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 to which the TID is not mapped. The QoS Null frame may be aggregated with a control response frame or transmitted individually to contend for medium access on Link 1.

[0090] Multi-link steering and control procedures may be used to address contention between DL transmissions to a non-STR MLD on link A and UL EDCA transmissions from an on-STR MLD on link B.

[0091] 8 is a diagram of an example 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) over multidirectional link 801 and multidirectional link 802. STA1 of MLD 805 communicates over link 801, and STA2 of MLD 805 communicates over link 802; similarly, AP1 of AP MLD 807 communicates over link 801, and AP2 of AP MLD 807 communicates over link 802. Procedure 800 includes an example design of a multilink steering and control element 810 (equivalently, 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 upcoming low latency traffic (traffic with associated low latency requirements) transmitted over link 802. In this case, the AP MLD 807 may indicate to STA1 of the MLD 805 on link 801 to pause or delay transmission (and / or reception) on link 801 for the indicated time period 812. The AP MLD 807 or the STA MLD 805 may include this indication in a beacon or frame 808, for example, as part of multilink steering and control information, which may be implemented as a multilink steering and control element 810 (e.g., in pause information field 854). During the period 812 that the MLD 805 (e.g., STA1 of the MLD 805) pauses transmission / reception on link 801, the MLD 805 (e.g., STA2 of the MLD 805) may transmit a low latency UL message 814 on link 802. Although the frame 808 may be transmitted by an AP associated with the AP MLD 807, a similar procedure may apply to STAs associated with another STA MLD (not shown).

[0092] Any part of the information, field, subfield, or subset of the Multilink (ML) steering and control element 810 may be implemented as a field, or any new or existing element, field, or subfield of a Medium Access Control (MAC) header or PLCP header, or any control, data, management, or other type of frame. The Multilink steering and control element 810 may include the following fields or subfields: an element identifier (ID) field 832, a length field 834, an element ID extension field 836, a link steering field 838, a number of link fields field 840, and / or link information (info) fields 8421-8422. N The parameters may include, but are not limited to, one or more of:

[0093] The element ID field 832 and the element ID extension field 836 may 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 the receiving STA or 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, with each bit indicating a link to be used. In another example, the link steering field 838 may be implemented as multiple subfields, with each subfield containing the ID of a recommended or instructed link. The AP or AP MLD may use the link steering field 838 to recommend or instruct the receiving STA, single-link radio STA, or non-AP MLD or non-AP MLD STA to activate or monitor one or more links that may be set up or available. The STA or non-AP MLD may use the link steering field 838 to recommend or instruct the receiving STA, AP, or AP MLD to activate or monitor one or more links that may be set up or available.

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

[0096] Each link field 8421~842 N may contain information or control information for each link in the set of links. The set of links may include links set up between AP MLD and non-AP MLD or single-link MLD. The set of links may be links supported by AP MLD or a set of links supported by non-AP MLD. The set of links may be links active in AP MLD or links active in single-link MLD or non-AP MLD. Each link field 8421-842 Nmay include, but are not limited to, one or more of the following information: a link ID subfield 850, a traffic information (info) subfield 852, a pause information (info) subfield 854, and / or an allowed transmission time field 856. The link ID subfield 850 may indicate the ID of the respective link, and may use as the indication, for example, an integer, a channel number of the link's primary channel, 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 the frame 808) for 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 one 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 about 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 strictest delay requirements may be indicated in the traffic information field 852. In another example, the traffic information field 852 is only indicated for links for which the transmitting STA MLD or AP MLD is recommending or directing the receiving STA / MLD in the link steering field 838. In another example, the traffic information field 852 may be indicated in order of the active links supported by or set up between the sending STA or MLD and the receiving STA or MLD. In this case, an explicit link ID 850 may not be included.

[0098] The idle information field 854 may be used to indicate to the receiving STA MLD 805 to suspend its transmissions on the same link (link 801) for the indicated time period 812. The time period during which the receiving STA / MLD is quiescent (e.g., the idle time) may allow other STA / MLDs or AP / MLDs to access the medium. The idle time may allow the 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 the 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 allowed transmission time field 856 may be designed differently. For example, the traffic information field 852, the idle information field 854, and the allowed transmission time field 856 may each include multiple subfields, whereby each of the subfields is associated with a particular link (e.g., a link set up between or supported by a transmitting STA or MLD and a receiving STA or MLD). In some cases, the link ID field 850 may not be explicitly used or needed.

[0100] As shown in FIG. 8, the multi-link steering and control procedure 800 may include an 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 MLDs (including the STA MLD 805). The beacon or other frame 808 may include an MLD steering and control element 810 that the receiving STA MLD 805 may use to steer or direct to one or more links as indicated in the link steering field 838. If more than one link is 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 multiple links. If more than one link is indicated in the link steering field 838 for a non-STR MLD, it may imply that the non-STR MLD may monitor multiple links. If the link steering subfield 838 indicates a reverse direction trigger for a non-STR MLD, the non-STR MLD may transmit a reverse direction trigger, e.g., a trigger frame or a PS-Poll frame, and the reverse direction trigger may be transmitted simultaneously in the UL in a synchronized or link-aggregated manner. If two or more links are indicated in the link steering field 838 for the STR MLD, it may imply that the STR MLD may monitor a set of links. If the link steering subfield 838 indicates a reverse direction trigger for the STR MLD, the STR MLD may transmit a reverse direction trigger, e.g., a trigger frame or a PS-Poll frame. The reverse direction trigger frame may be used to trigger transmissions for the receiving MLD. The reverse direction trigger frame may be transmitting simultaneously in the UL in a synchronized or link-aggregated manner. The reverse direction trigger frame may be transmitted individually on each of the links at an earlier time of channel access on that link.

[0101] An AP or AP MLD may include the ML steering and control element 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 more than one link is 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 direction trigger, the single-link MLD may send a reverse direction trigger to trigger transmission to the single-link MLD if it successfully accesses the medium on one or more links. If more than one link is 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 direction trigger for a non-STR MLD, the non-STR MLD may send reverse direction triggers, e.g., trigger frames or PS-Poll frames, transmitting simultaneously on the UL in a synchronized or link-aggregated manner. If more than one link is indicated in the link steering field for the STR MLD, it may imply that the STR MLD may monitor a set of links. If the link steering subfield 838 indicates a reverse direction trigger for the STR MLD, the STR MLD may transmit a reverse direction trigger, such as a trigger frame or a PS-Poll frame. The reverse direction trigger frame may be used to trigger transmissions to the MLD. The reverse direction trigger frames may be transmitting simultaneously in the UL in a synchronized or link aggregated manner. The reverse direction trigger frame may also be transmitted individually on each of the links at an earlier time of channel access on that link.

[0102] An AP or MLD may transmit a frame 808 including an ML steering and control element 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 the priority and delay associated with the traffic on one or more links. Such information may be included in a data frame, e.g., a MAC and / or PLCP header, or aggregated in an aggregated MAC Protocol Data Unit (A-MPDU) or a BA or multi-STA BA (M-BA) or other type of response frame, to inform the receiving STA of potentially more imminent traffic on one or more links. In another design, the TID of the buffered traffic may be indicated, and the receiving STA or MLD may be able to determine which link to monitor based on a TID-to-link mapping established by the STA or MLD. A non-STR STA or MLD may stop its current transmission on a currently active link to monitor the link of its choice, potentially selecting the highest priority or low latency data, as indicated in the ML steering and control element 810. A non-STR MLD may also transmit one or more reservation trigger frames on one or more links of its choice. The reverse direction trigger frames may be PS-Poll or trigger frames and may be transmitted in a synchronized manner on two or more links simultaneously.

[0103] An AP or MLD may transmit a frame 808 including an ML steering and control element 810 to indicate the idle duration (in the idle information field 854) to one or more STAs or MLDs on one or more links. A STA or MLD, e.g., a non-STR MLD, receiving the ML steering and control element 808 including the idle time for one or more links may cease accessing the medium for at least the time indicated in the idle time on the indicated links. The STA or MLD may switch to monitoring the links indicated in the link steering field 838. The idle time may start after the receiving STA or MLD finishes transmitting its current frame or completes its current TXOP.

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

[0105] As described with respect to the multi-link steering and control procedure 800 in FIG. 8 , a non-AP STA or non-AP MLD may perform multi-link steering and control in any of the following example procedures. In one example, a non-AP STA or non-AP MLD may include an MLD steering and control element in a data frame (e.g., in a header) or other type of management or control frame in which the STA or MLD is to be steered or directed to one or more links as indicated in the link steering field. If more than one link is indicated in the link steering field for a non-STR MLD, it may mean that the non-STR MLD may monitor a set of links. If a reverse direction trigger is indicated for a non-STR MLD, the non-STR MLD may send reverse direction triggers, e.g., trigger frames or PS-Poll frames, transmitting simultaneously in the UL in a synchronized or link-aggregated manner to trigger transmissions from the transmitting STA or MLD. If more than one link is indicated in the link steering field for a STR MLD, it may mean that the STR MLD may monitor a set of links. If a reverse direction trigger for the STR MLD is indicated, the STR MLD may transmit a reverse direction trigger, such as a trigger frame or a PS-Poll frame. The reverse direction trigger frame may be used to trigger transmissions to the MLD. The reverse direction trigger frames may be transmitted simultaneously in the DL in a synchronized or link-aggregated manner. The reverse direction trigger frames may also be transmitted individually on each of the links at an earlier time of channel access on that link.

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

[0107] A non-AP STA or non-AP MLD may transmit a frame including an ML steering and control element to indicate the traffic load on one or more links to one or more STAs or MLDs. The ML steering and control element may provide information regarding the amount of buffered traffic and / or the priority and delay associated with the traffic on one or more links. Such information may be included in a data frame, e.g., a MAC / PLCP header, or aggregated in an A-MPDU or BA or M-BA or other type of response frame, to notify the receiving STA of potentially more imminent 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 link to monitor based on the TID-to-kink mapping established by the STA or MLD. A non-STR STA or MLD may stop current transmission on its currently active link and potentially monitor a link of its choice with the highest priority or low latency data, as indicated in the ML steering and control element. A non-STR MLD may also transmit one or more reservation triggers on one or more links of its choice. The reverse direction trigger may be a PS-Poll or a trigger frame, which may be transmitted simultaneously in a synchronized manner on two or more links.

[0108] A non-AP STA or non-AP MLD may transmit a frame including an ML steering and control element to indicate an idle time on one or more links to one or more STAs or MLDs. A STA or MLD, e.g., a non-STR MLD, that receives an ML steering and control element indicating an idle time for one or more links may suspend its medium access for at least the indicated idle time 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 element. The indicated idle time may start after the receiving STA or MLD finishes transmitting its current frame or completes its current TXOP.

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

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

[0111] The mechanism for trigger-enabled target wake time (TWT) can be used to inhibit EDCA and can be useful for resolving conflicts between DL transmissions to a non-STRU MLD on a first link and UL EDCA transmissions on a second link, and / or NAV / PPDU length conditions on the second link after transmissions on the first link. A TWT-requesting STA cannot transmit frames to a TWT-responding STA outside the negotiated TWT scheduling period (SP) and should not transmit frames to a TWT-responding STA that are not included in a HE TB PPDU within a trigger-enabled TWT SP. In one example, an AP MLD can add an indication on Link 1 to indicate a quick-trigger-enabled TWT on Link 1 to provide an access opportunity for DL ​​TIDy or trigger frames on Link 2. The AP MLD can add an indication on Link 1 to indicate a quick-trigger-enabled TWT on Link 2.

[0112] In a quick-trigger-enabled TWT, as an alternative to completely shutting down EDCA access, a set of alternative EDCA parameters may be used to perform (less aggressive) EDCA. Examples of alternative EDCA parameters include, but are not limited to, a longer contention window, a larger inter-frame space, or a different CCA threshold. A quick-trigger-enabled TWT may be performed on the same link as that described herein.

[0113] 9 is a diagram of an example 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) over multidirectional link 901 and multidirectional link 902. Message exchange procedure 900 shows an example quick-trigger-enabled TWT 925 allocated by a TXOP responder. For example, the quick-trigger-enabled TWT 925 may be allocated by the AP MLD 907 and may address the problem described in FIG. 2 by reducing the delay incurred by high-priority TIDy DL traffic from the MLD 905 on link 902.

[0114] 2, during the time period when the TID of MLD 905 is used by MLD 905 to transmit UL message 910 on link 901 (which may be acknowledged by AP MLD 907 by transmitting BAs 914, 920), the AP MLD 907 may suspend EDCA for TIDy for MLD 905 on link 902. During the time period when MLD 905 is transmitting UL message 910 on link 901 using the TID, other OBSS / UL STAs (not shown) may occupy the medium (channel) on link 902 by transmitting UL message 912 on link 902, and may continue transmitting when MLD 905 on link 901 is idle, causing the AP MLD 907 to delay performing EDCA for TIDy.

[0115] In one example, the AP MLD 907 may provide the MLD 905 with information for enabling the TWT 925. The information for enabling the TWT 925 may be included in a PPDU carrying a response-type frame, such as BA 920, transmitted from the AP MLD 907 to the MLD 905 on link 901, or in a PPDU carrying a solicitation-type frame (e.g., DL / UL frame 1012 on link 1001 shown in FIG. 10). The information for enabling the TWT 925 may include, but is not limited to, any of the following information: a quick trigger-enabled TWT indication, an end time and / or duration of the quick trigger-enabled TWT 925 for the current link 901 or the indicated link (e.g., link 901 or 902), a start time of the quick trigger-enabled TWT 925 for the current link 901 or the indicated link, an identification (ID) of the link 901 STA MLD (e.g., the ID of the MLD 905) that may apply or follow the quick trigger-enabled TWT 925, an ID of the link 902 that may be used by the AP MLD 907 to send PPDUs to the STA MLD 905, a TID / TSID on the link 902 that may be used by the AP MLD 907 to send PPDUs to the STA MLD 905, an indication of whether other links (e.g., link 903, not shown) also have the same quick trigger-enabled TWT 925 as on link 901, alternative EDCA parameters, and / or criteria for early termination of the TWT 925.

[0116] A STA MLD 905 on link 901 may resume its EDCA following the termination of a TXOP 911 having a PPDU (e.g., BA 920) carrying a quick-trigger-enabled TWT indication ("MLD 905 EDCA accepted" as shown in FIG. 9, or "N-STR EDCA accepted" as shown in FIG. 11). If a non-STR MLD 905 applying quick-trigger-enabled TWT acquires a TXOP 913 before a TWT 925, the TXOP may terminate before the start time of the quick-trigger-enabled TWT 925.

[0117] The "MLD 905 EDCA Allowed" duration on link 901 shown in Figure 9 (or the "N-STR EDCA Allowed" duration shown in Figure 11) may be derived from the pending NAV / PPDU duration on link 902 plus the remaining EDCA counter for link 902 in the AP MLD 907 (i.e., link 902 AP MLD 907 may not transmit before the end of the "MLD 905 EDCA Allowed" duration). During the "MLD 905 EDCA Allowed" period, the MLD 905 may send a UL message 922 to the AP MLD 907 and may receive a BA 924 before the start of TWT 925.

[0118] The quick trigger-enabled TWT 925 may be applicable to a non-STR STA MLD 905 associated with a receiver address (RA) of a solicited frame (e.g., BA 920) and may be referred to as a solicited frame quick trigger-enabled TWT. The quick trigger-enabled TWT 925 may be applicable to a non-STR STA MLD 905 associated with an RA of a solicited frame (e.g., DL / UL frame 1012 in FIG. 10) and may be referred to as a solicited frame quick trigger-enabled TWT. The quick trigger-enabled TWT 925 may be applicable to any other or all non-STR STA MLDs (including additional STA MLDs not shown) operating on the link 901 and may be referred to as a third-party quick trigger-enabled TWT (examples of which are shown in FIGS. 10 and 11 and described below). During TWT 925, the MLD 905 may receive a DL message 926 for TIDy from the AP MLD 907, which may send a TF 928 to the MLD 905 (and / or other STA MLDs not shown). After TWT 925, the MLD 905 may resume sending UL messages 930 to the AP MLD 907 over link 901 using the TID.

[0119] 10 and 11 are examples of a third-party quick trigger-enabled TWT. Figure 10 is a diagram of an example message exchange procedure 1000 between an MLD 1005, an MLD 1009 (e.g., a non-STR STA MLD) and an MLD 1007 (e.g., an STR AP MLD) via multidirectional link 1001 and multidirectional link 1002. Other MLDs / OBSSs (not shown) may be using the medium, as reflected by medium busy period 1010 on link 1001 and medium busy period 1016 on link 1002. In one example, DL / UL PPDUs 1012 and BAs 1014 on link 1001 may not be transmitted or may not be intended to be received by MLD 1005 or MLD 1009. The transmitter of the PPDU 1012 carrying the solicitation-type frame may signal in the PPDU (e.g., in the preamble of the PPDU) that a response-type frame responding to the PPDU (e.g., a PPDU carrying a BA 1014) may carry a quick-trigger-capable TWT indication. The transmitter of the PPDU carrying the solicitation-type frame may be an STR non-AP MLD (not shown), in other words, a third-party quick-trigger-capable TWT. During the triggered TWT 1025, and once the medium on link 1002 is busy for a longer period, the AP MLD 1007 may transmit the TF 1020 on link 1002 to the MLD 1005 and MLD 1009 (the TF 1020 may have been previously buffered by the AP MLD 1007 for the MLDs 1005, 1009 for the TIDs mapped to link 1002). During the triggered TWT 1025, other STR STA MLDs (not shown) may send UL messages 1018 to the AP MLD 1007 on link 1001.

[0120] 11 is a diagram of an example message exchange procedure 1100 between an MLD 1105, an MLD 1109 (e.g., a non-STR STA MLD), and an MLD 1107 (e.g., an STR AP MLD) via multidirectional link 1101 and multidirectional link 1102. Other MLDs / OBSSs (not shown) may use the medium as affected by a medium busy period 1110 on link 1101 and a medium busy period 1116 on link 1102. In one example, a DL / UL PPDU 1112 and a BA 1114 on link 1101 may not be transmitted or may not be intended to be received by the MLD 1105 or MLD 1109. The transmitter of a PPDU 1112 carrying a solicitation-type frame may signal in the PPDU (e.g., in the preamble of the PPDU) that a response-type frame responding to the PPDU (e.g., a PPDU carrying BA 1114) may carry a quick trigger-enabled TWT indication. The transmitter of the PPDU carrying the solicitation frame may be an STR non-AP MLD (not shown), in other words, a third-party quick-trigger-enabled TWT. During a triggered TWT 1125, which starts after the medium on link 1102 has been busy for a longer period, the AP MLD 1107 may transmit a TF 1120 on link 1102 to the MLD 1105 and MLD 1109 (the TF 1110 may have been previously buffered by the AP MLD 1107 for the MLDs 1105, 1109 for the TID mapped to link 1102). During the time period 1123 during which N-STR EDCA is allowed, prior to the start of the triggered TWT 1025, another STR STA MLD (not shown) may transmit a UL message 1118 (e.g., a BSR) to the AP MLD 1107 on link 1101.

[0121] In examples described herein (e.g., those in FIGS. 9, 10, and 11), if the PPDU carrying the quick-trigger-capable TWT indication is a legacy PPDU (e.g., a non-HT (duplicate) PPDU carrying an acknowledged BA frame), the acknowledged 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 to signal the presence of a quick-trigger-capable TWT indication following the AID TID information field in the BA frame. In one example, the AID11 field of the AID TID information field may be used to specify whether the frame is an acknowledged frame quick-trigger-capable TWT (e.g., set to the AID of a unicast receiver of the acknowledged frame) or a third-party quick-trigger-capable TWT (e.g., set to the broadcast AID). A (non-STR) STA of an MLD operating on link 1 (the first MD link) may be required to read the MBA frame without responding to its own transmission for an indication of a third-party quick-trigger-capable TWT.

[0122] In examples described herein (e.g., the examples in FIGS. 9, 10, and 11), when the PPDU carrying the quick trigger-capable TWT indication is a legacy PPDU (e.g., a non-HT (duplicate) PPDU carrying a response-type frame), the response-type frame may be a control wrapper frame. The control wrapper frame may include an HT control field that may be used to signal the quick trigger-capable TWT indication. The quick trigger-capable 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 the indication of a third-party quick trigger-capable 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 in which the AID of the intended STA for the BA is signaled, but the third-party STA may parse the HT control field of the control wrapper frame.

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

[0124] In further examples, the quick trigger-capable TWT indication may be a signal in the PHY preamble or in one or more bits in the scrambler start that are not used by BW signaling. The quick trigger-capable TWT indication may be in a separate frame aggregated with a solicited / solicited frame addressed to the same STA in an AMPDU. The indication may be in a separate frame addressed to other (non-STR) STAs (e.g., broadcast) other than the RA of the solicited / solicited frame, and the frame may be included in an MU-PPDU. The quick trigger-capable TWT indication may be a field in a solicited / solicited frame. The indication may be a field in a frame that does not carry data, such as a QoS null frame. The frame that does not carry data may be addressed in the RA of the solicited / solicited frame or addressed to other non-STR STAs (e.g., broadcast). The quick trigger-capable TWT is not preceded by a period during which EDCA may be allowed for non-STR STAs on link 1. Another MLD may be a third party to the DL / UL / BA exchange on link 1.

[0125] Quick trigger-enabled TWT parameters may be pre-negotiated. Using the pre-negotiated parameters, the quick trigger TWT indication may be shortened. The shortened indication may signal the start of the TWT or the start of the EDCA allowance 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 for the TWT duration, the ID of Link 2 for which the AP MLD desires to send PPDUs to the STA MLD, an indication of 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 indication may include a number x, and the actual TWT duration may be x times the unit of the TWT duration. An example of a criterion for early termination of a TWT may be that if the MLD receives a DL PPDU from the AP on link 2 after the TWT on link 1 has started, it may terminate the TWT and start EDCA on link 1. The criterion may have additional restrictions. For example, the restriction may be that if the TWT is a solicited / responded frame quick trigger-enabled TWT, the DL PPDU is addressed to the STAs of the MLD on link 2.

[0126] The TXOP responder (e.g., AP MLD) may request that the MLD's link 1 STA (i.e., the TXOP holder) allocate additional time in the TXOP (i.e., duration in the solicitation-type frame / NAV) for the transmission of a response PPDU carrying a solicited frame and a quick-trigger TWT indication. For example, in the case of a solicited-frame quick-trigger TWT, the quick-trigger TWT indication may be carried in a control wrapper frame in a non-HT (overlapping) PPDU, and the STA transmitting the solicited frame may take the size of the control wrapper frame into account when allocating the NAV. Similarly, in the case of a solicited-frame quick-trigger TWT, the quick-trigger TWT indication may be carried in a separate frame, and both frames may be carried in a PPDU that allows an AMPDU as payload, and the STA transmitting the solicited frame may take the size of the AMPDU into account when allocating the NAV. Similarly, in the case of a third-party quick-trigger TWT with a TWT indication carried in a separate frame located in the RU in a solicited MU-PPDU, the STA transmitting the solicited PPDU may take into account the duration required for the TWT indication frame transmitted in the RU when allocating a NAV. The resource unit (RU) size and MCS for transmitting the TWT indication frame may be pre-negotiated parameters. A request to allocate an additional NAV for the solicited PPDU may be signaled in an add block acknowledgment (ADDBA) exchange or in the procedure used for TID-to-link mapping.

[0127] An exemplary procedure may be used for quick trigger TWT on different links. Figure 12 is a diagram of an exemplary message exchange procedure 1200 between an MLD 1205 (e.g., a non-STR STA MLD) and an MLD 1207 (e.g., an STR AP MLD) over multidirectional link 1201 and multidirectional link 1202. Message exchange procedure 1200 shows an exemplary quick trigger TWT 1225 on 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 may be acknowledged by AP MLD 1207 by sending BA 1214), AP MLD 1207 may suspend or pause EDCA for TIDy for MLD 1205 on link 1202. During the time period when MLD 1205 is transmitting UL message 1210 on link 1202 using the 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 acknowledged frame BA 1214 may have a quick trigger enabled TWT indication that allocates TWT 1225 on link 1202. TWT 1225 on link 1202 may start shortly after the end of the PPDU carrying the indication in BA 1214. Following TWT 1225, AP MLD 1207 may resume EDCA for TIDy for MLD 1205 on link 1202. The link 1201 AP MLD 1207 may allocate the duration of the TWT 1224 to be greater than or equal to the NAV timer value / remaining PPDU duration observed by the link 1202 AP MLD 1207 at the end of the PPDU carrying the TWT indication (BA 1214). The NAV may be the intra-BSS NAV or basic NAV, or the larger of the two, if the link 2 AP maintains two NAV timers. The TWT may be terminated early if the MLD 1205 (e.g., its link 1202 STA) receives a frame on link 1202 that sets the NAV.In an example not explicitly shown, a TWT may be terminated early if the MLD 1205 (e.g., link 1202 STA of the MLD 1205) receives a frame setting an intra-BSS NAV on link 1202 and a frame setting a basic NAV on link 2. During the TWT 1225, the MLD 1205 (e.g., link 1202 STA of the MLD 1205) may respond to a trigger frame (not shown) if it has no information about the basic NAV.

[0128] A mechanism for buffer status indication in ADDBA exchanges may be used. In multiple 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 may therefore delay its transmission over the other links. For example, if transmission / reception over link 1 takes a long time (e.g., involving ADDBA request / response exchanges and / or data exchanges and BA exchanges), transmission over link 2 may be delayed for a long time. If a 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 to indicate ML traffic state, buffer state, and / or QoS requirements over multiple links in an ADDBA request / response frame exchange. Figure 13 is a diagram of an example message exchange procedure 1300 between MLD 1305 and MLD 1309 (e.g., non-AP MLD and / or AP MLD) over multidirectional link 1301 and multidirectional link 1302. For further illustration, the STAs in MLDs 1305 and 1309 are shown (STA 11 of MLD 1305 is used to communicate on link 1301, STA 12 of MLD 1305 is used to communicate on link 1302, STA 21 of MLD 1309 is used to communicate on link 1301, and STA 22 of MLD 1309 is used to communicate on link 1302). 13 shows an example procedure 1300 for buffer status indication using additional block acknowledgment requests 1310 / additional block acknowledgments 1314 (ADDBA Req / Resp) over multiple links 1301, 1302. In this example, MLD 1305 may operate on both links 1301 and 1302 using STA11 and STA12, respectively. MLD 1309 may operate on both links 1301 and 1302 using STA21 and STA22, respectively. STA11 may have traffic to STA21 over link 1301 and may set up a Block Ack agreement by using ADDBA request frame 1310 and ADDBA response frame 1314 on link 1301. Meanwhile, STA22 may have traffic buffered on link 1302 for STA21.

[0130] STA11 may be the initiator of a BA agreement over link 1301. STA11 may sense the medium and acquire a channel over 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., the block acknowledgment action field, the block acknowledgment parameter set field, the block acknowledgment timeout value field, and / or the block acknowledgment initiation sequence control field), STA11 may use a field / subfield to indicate that the MLD 1305 may expect ML traffic status, buffer status, and / or QoS requirements for one or more or all operational links. In one example, a single bit in the ADDBA request frame 1300 may be used to request status reports for all operational links. In another example, the requirement may be per link with the link ID explicitly conveyed. For example, a link bitmap may be used to request buffer status for one or more links. In one example, the requirement 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 requirements may be per Access Category Index (ACI). For example, an ACI bitmap may be used to request buffer status for one or more TIDs.

[0131] When the ADDBA request frame 1310 over link 1301 is received at the MLD 1309, the STA 21 may respond with an ADDBA response frame 1314. In addition to other information carried in the ADDBA response frame 1314 (e.g., the block acknowledge action field, the block acknowledge parameter set field, the block acknowledge timeout value field, and / or the block acknowledge initiation sequence control field), the STA 21 may use fields / subfields to indicate traffic conditions, buffer conditions, and / or QoS requirements for one or more or all operational links. In one example, a single bit in the ADDBA response frame 1314 may request status reports for all operational links. In one example, the requirement may be per link with an explicitly conveyed link ID. For example, a link bitmap may be used to request buffer conditions for one or more links. In one method, the requirement may be per TID. For example, a TID bitmap may be used to request buffer conditions for one or more TIDs. In one example, the requirement may be per Access Category Index (ACI). For example, the ACI bitmap may be used to request buffer status for one or more TIDs. In one example, the ACI bitmap may be indicated in a modified HT control field carried in the MAC header. In one example, the HE modified HT control field may be reused with some modification or reinterpretation. The BSR control subfield may be used, or the BSR control subfield may be reused entirely. The information carried in the BSR control subfield may be interpreted per MLD instead of / 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 the EHT Modified HT Control field or may have the capability to support the EHT Modified HT Control field. An exemplary control field may be defined as an ML BSR or a Multi-TID BSR. An exemplary frame format of the ML BSR field 1400A is shown in FIG. 14A. The 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 "1"s in the Link Bitmap field 1401. For example, if there are K "1"s in the Link Bitmap 1401, then there may be K corresponding BSR Link subfields 14021-14022. K Each BSR link subfield 14021 to 1402 K may include information (not explicitly shown) as specified in 802.11ax, such as ACI bitmap, delta TID, ACI high, scaling factor, queue size high, and / or queue size all.

[0133] An example frame format of the TID BSR field 1400B is shown in FIG. 14B. For example, the TID BSR field 1400B may include 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 "1"s in the TID Bitmap field 1404. For example, if there are K "1"s in the TID Bitmap field 1404, then there are K corresponding BSR TIDs 14061-14062. K There can be subfields: Each BSR TID subfield 14061 to 1406 Kmay include information (not explicitly shown) such as a scaling factor and / or a TID queue size. The scaling factor may indicate units in the TID queue size. The TID queue size subfield may indicate the buffer size of the TID. In one example, a low latency TID BSR control subfield may be used to indicate low latency TID buffer status. An exemplary low latency TID BSR control subfield 1400C is shown in FIG. 14C. Low latency TIDs may be predefined / predetermined. Low latency TIDs may be a set of TIDs with low latency requirements, and thus low latency TIDs may be a subset of all TIDs. If the low latency TID BSR control subfield 1400C is used, it may report buffer status corresponding to TIDs with low latency requirements. The low latency TID BSR subfield 1400C includes a low latency ITD bitmap subfield 1408 and K BSR TID subfields 14101 to 1410. K and

[0134] 13 , in one example, some 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 may know the buffer status of the MLD 1309. The MLD 1305 may continue to receive transmissions (e.g., DL transmissions to STA11 1316) on link 1301 using the negotiated BA agreement if the QoS requirements of the buffered traffic can be met on other links after the data / BA transmission on link 1301.

[0135] In one example not shown in FIG. 13 , upon receiving the ADDBA response frame 1315, the MLD 1305 can know the buffer status of the MLD 1309, and if the QoS requirements of the buffered traffic cannot be met after transmitting data / BA 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 FIG. 13 ), STA 11 may send a multilink request frame to STA 21 to indicate operation on link 1302. If one of the MLDs 1305, 1309 may not have STR capability over multiple links, the ML request frame may be considered a request to switch operation to link 1302. If both the MLDs 1305, 1309 may have STR capability over multiple links, the ML request frame may be considered a request for active operation on link 1302. The ML request frame may indicate a time period for operating 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 may confirm the multilink operation request and switch to link 1302 immediately after the ML response frame.

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

[0137] ML triggering may be used to resolve contention between DL transmissions on link A to a non-STR MLD and UL EDCA transmissions on link B from the non-STR MLD. The exemplary procedure may quickly allow transmissions on another link. FIG. 15 is a diagram of an exemplary ML triggering procedure 1500 between an MLD 1505 (e.g., a non-STR STA MLD) and an MLD 1507 (e.g., an STR AP MLD) over multidirectional links 1501 and 1502. For further illustration, STAs in the MLD 1505 and APs in the AP MLD 1507 are shown (STA 11 of the MLD 1505 is used to communicate on link 1501, STA 12 of the MLD 1505 is used to communicate on link 1502, AP 11 of the AP MLD 1507 is used to communicate on link 1501, and AP 12 of the AP MLD 1507 is used to communicate on link 1502). AP1 may have traffic to send to STA11 over link 1501, and AP1 may check whether STA12 has UL traffic to send to AP2 over link 1502.

[0138] AP1 (of AP MLD 1507) may sense the medium and acquire the channel over link 1501. AP1 may send a buffer status report poll (BSRP) trigger frame (TF) 1510 to STA11 (of STA MLD 1505). AP1 may indicate in the BSRP TF 1510 that the requested BSR is available on one or more or all links. In one example, the BSRP trigger frame 1510 may include a field from 802.11ax. The 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 send a BSR frame 1512 to the AP MLD 1507. AP1 may treat the BSR 1512 as an MLD-level BSR. If AP1 may not have ML capability and / or may not support ML, STA11 may treat BSRP TF 1510 as a STA level via link 1501. If AP1 may have ML capability and STA11 may not support ML and / or ML BSR, STA11 may report BSR 1512 as a STA level via link 1501. AP1 may treat the report as a 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 FIG. 15), a new trigger type value may be defined to indicate an ML BSRP. In one example, a reserved bit in the common information field or user information field may be used to indicate that the BSRP TF 1510 may request reports over multiple links. In one example, one of the indications described above may be used to indicate an ML BSRP. A trigger-dependent common information field and / or a trigger-dependent user information field may be present to carry more detailed ML information, for example, to indicate on which links / TIDs the BSRP may trigger. A bitmap of links or TIDs may be carried in the trigger-dependent common information or trigger-dependent user information field.

[0140] In one example, a low latency ML BSRP trigger frame may be defined. One bit / field may be used to indicate the low latency ML BSRP trigger frame. For example, a trigger type field or a reserved bit may be used. In one example, all low latency TID buffer status reports are requested. In one 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 the trigger-dependent common information field or the trigger-dependent user information field.

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

[0142] 15, AP1 may transmit an ML trigger frame (ML TF) 1514. The transmission of the MLTF frame 1514 may be a SIFS duration after the end of reception of the BSR frame 1512 and / or may be in a separate TXOP from the 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 modification or reinterpretation. The ML TF frame 1514 may trigger a target receiver (e.g., MLD 1505) to activate one or more links on which the receiver may have UL traffic with a particular TID.

[0143] In one example, the ML TF frame 1514 may activate one or more links for a specific period of time, which may be indicated in the ML TF frame 1514. Following this period of time, the target receiver (e.g., the 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., the MLD 1505) may transmit. Based on the TID-to-link mapping, the MLD 1505 may know which link it may activate. In one example, UL transmission over the newly activated link may be trigger-based only. In one example, UL transmission over the newly activated link may be possible after a predefined / predetermined period of time or after the MLD 1505 acquires a NAV setting on the link 1502.

[0144] In one example, the ML TF 1514 may activate one or more links without time limitations and / or the ML TF 1514 may indicate the link to be activated. In one example, the ML TF 1514 may indicate the TID that the receiver (MLD 1505) may transmit. Based on the TID-link mapping, the receiving STA 11 may know which link it may activate. In one example, UL transmission over the newly activated link may be trigger-based only. In one example, UL transmission over the newly activated link may be possible after a predefined / predetermined period of time or after the STA 12 may acquire a NAV setting on the link 1502. While STA11 and AP1 exchange frames (e.g., BSRP TF 1510, BSR frame 1512, and / or ML TF 1514) 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 MLD 1505. After AP1 sends ML TF 1514 on link 1501, MLD 1505 may know which link it may activate. In the example shown in FIG. 15 , MLD 1505 may activate STA12 on link 1502. AP2 on link 1502 may send TF 1518 to trigger transmission from STA12. STA12 may then transmit a data (or other type) frame 1520. AP2 may send an ACK or BA frame 1522 on link 1502. Depending on the information conveyed by the ML TF 1514, activation of link 1502 may be for a period of time. In this case, after the period of time that link 1502 is active, the MLD 1505 switches back to the original link (e.g., link 1501) and may neither transmit (Tx) nor receive (Rx) on link 1502 (shown as No Tx / Tx 1524). Similarly, prior to the ML TF 1514, the MLD 1505 may not transmit or receive on link 1502 (shown as No Tx / Tx 1516).

[0145] Another example procedure may use an ML TF to announce an upcoming UL OFDMA-based random access (UORA) trigger transmission on another link / TID. In this case, associated or unassociated STAs on Link 1 (e.g., the link on which the ML TF is transmitted) may know that they may soon have an opportunity to transmit an UL frame on Link 2 (e.g., the link on which the UORA trigger is about to transmit). For example, an AP MLD may transmit an ML TF on Link 1 to announce the upcoming 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 a "1" in the bitmap may indicate a link or TID on which a UORA frame may be transmitted, and / or a UORA-related information field, which may include, for example, an AID12 field to indicate that the UORA trigger is for an associated or unassociated STA. In this example, the ML TF may be used to carry information if there is a UORA opportunity in the other link. The ML TF may be generalized to carry information if there will be an UL transmission opportunity in the other link. In one example, other types of control, management, and / or data frames may be used to indicate link or TID bitmaps 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] Procedures for DL / UL acknowledged frames on Link 1, indicating the buffer status and / or priority of bufferable units (Bu) on Link 2, may be used to resolve contention between DL transmissions on Link A to a non-STR MLD and UL EDCA transmissions on Link B from a non-STR MLD. Similar to the examples shown in Figures 2, 3, and 4, the buffer status of TIDs mapped to Link 2 may be signaled in PPDUs carrying acknowledged frames on Link 1. This signaling may allow a Link 1 AP or STA of MLD 1 to be less aggressive in transmitting on Link 1 and allow more opportunities to receive on Link 2. Mechanisms for signaling buffer status may use, for example, the AP PS Buffer Status subfield in the QoS Control field, the Queue Size subfield in the QoS Control field, and / or the BSR in the HE variant of the HT Control field. The first two mechanisms (i.e., the AP PS Buffer Status subfield in the QoS Control field and the Queue Size subfield in the QoS Control field) may not be allowed on Link 1 for QoS frames of TIDs mapped to Link 2. This restriction can be alleviated by the procedure of prohibiting non-default TID-to-link mapping for low-latency TIDs and the multilink steering and control procedure described above. The second and third mechanisms (i.e., the Queue Size subfield in the QoS Control field and the BSR in the HE variant of the HT Control field) may not be useful for the situations of Figures 2 and 3 because they are not transmitted in the DL direction. In some cases, acknowledged control frames may need to be sent in non-HT (duplicated) PPDU frames, which may disable AMPDU aggregation.

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

[0148] A control field may be defined to signal that STAs on link 1 may have 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 contention window, a larger interframe space, and / or a different CCA threshold. The control field may further include, but is not limited to, a (partial / broadcast) identity of third-party non-STR STAs, an indication of all (non-STR) STAs on link 1 and an indication of all (non-STR) STAs on link 1 whose MLD has a TID mapped to link 2, an ID of link 2 for which to expect DL / UL transmissions, link 2 traffic priority / TID / TSID, EDCA suspend time, and / or an ID of an alternative EDCA parameter. Upon receiving this control field / subfield (e.g., in a frame not addressed to the AP / non-STR MLD), the AP MLD and / or non-STR MLD may perform 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 stopped when the AP MLD and / or non-STR MLD receives a DL / UL PPDU on link 2 from the AP MLD and / or non-AP MLD, or based on the expiration of the duration signaled in the control field.

[0149] Similar to the example for the quick trigger-enabled TWT described above, the frame may be aggregated with the control response frame in an AMPDU and / or may be carried in a PPDU format that allows AMPDU aggregation. The frame may include the control fields described above and / or an indication of the buffer status of the TID mapped to link 2. The frame may be transmitted in a separate (broadcast) 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 status of the TID / TSID mapped to link 2. In one example, the frame described above may be a QoS Null frame. In this case, a QoS Null frame for a TID / TSID may be allowed to be transmitted on a link to which the TID / TSID is not mapped. Similar to the example for the quick-trigger-enabled 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 start 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 acknowledged frames on link 1, indicating the buffer status and / or priority of the BU on link 2, may also be applied to solicited PPDUs sent by either APs or non-AP STAs. 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 acknowledged PPDUs sent by non-AP STAs. 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] The procedure for an AP to indicate EDCA idle time may be used to resolve contention between DL transmissions to a non-STR MLD on link A and UL EDCA transmissions on link B from the non-STR MLD. Figure 16 is a diagram of an example idle time procedure 1600 between MLDs 1605 and 1609 (e.g., non-STR STA MLDs) and MLD 1607 (e.g., STR AP MLD) over multidirectional links 1601, 1602, and 1603. The example idle time procedure 1600 shows an example AP MLD 2607 indicating EDCA idle time as part of DL message transmissions 1610 and 1608 to MLDs 1605 and 1609 on links 1601 and 1602, respectively, to allow transmission of TF 1620 on another link 1603. Outside of medium busy period 1604 on link 1601, MLD 1605 may receive DL message transmission 1610 from AP MLD 1607 and may send BA 1616. On link 1602, MLD 1609 may receive DL message transmission 1608 from AP MLD 1607 and may send BA 1614. AP MLD 1607 may not send TF 1620 to MLD 1605 and MLD 1609 on link 1603 during medium busy periods 1606 and 1612.

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

[0152] The dormancy indication may be in a broadcast / multicast RU to be received by the intended MLDs 1605 and 1609 for the TF 1620 (or DL ​​data) on link 1603, even if the MLDs 1605 and 1609 are not the intended receivers of the PPDU for data reception on links 1601 or 1602. The indication may include a list of IDs associated with the MLDs 1605 and 1609 that are the intended recipients of the TF 1620 (or DL ​​data) to be transmitted on link 1603. In one example, instead of a dormancy time, the DL PPDUs 1610 and / or 1608 from the AP MLD 1607 on links 1601 and / or 1602, respectively, may indicate alternative EDCA parameters. The alternative EDCA parameters may provide a better access probability for a TF 1620 (or DL ​​data) transmission on link 1603 from the AP MLD 1607, because it provides a high likelihood that a TF 1620 (or DL ​​data) transmission on link 1603 occurs before access on links 1601 and / or 1602 from any (non-STR) MLD 1605 or 1609 that is a potential recipient of the TF 1620 (or DL ​​data). The quiet time may also be implemented in the form of an MLD-specific NAV on link 1601 or 1602. Only the MLDs 1605 and 1609 that are potential recipients of the TF 1620 (or DL ​​data) on link 1603 observe this NAV. As explained above, after the quiet duration 1617 (and 1619), the non-STA MLDs 1605 (and 1609) may resume their EDCA on links 1601 (and 1602), respectively. Before the end of the pause duration 1617 (and 1619), but SIFS after the PPDU carrying TF 1620 (or DL ​​data) on link 1603, the (non-STR) MLD 1605 or 1609 may resume its EDCA on link 1601 or 1602, respectively. Following the transmission of TF 1620, a TB-PPDU 1624 may be transmitted from MLD 1605 and / or MLD 1609 to AP MLD 1607 on link 1603 (MLD 1605 and MLD 1609 may be capable of simultaneous transmission on multiple links).

[0153] A procedure for a conditional TF for another link (e.g., link C) may be used to resolve contention between a DL transmission on link A to a non-STR MLD and a UL EDCA transmission on link B from the non-STR MLD. For example, an MLD (e.g., AP MLD) may include a conditional TF for another link in a PPDU transmitted by the 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 receipt of a preamble on the scheduled link C during the 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 the EDCA dormancy indication, the conditional TF may be broadcast / multicast in RUs to be received by the intended MLD 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] 17 is a diagram of an example 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 link 1701, multidirectional link 1702, and multidirectional link 1703. Outside of a medium busy period 1704 on link 1701, MLD 1705 may receive a DL message transmission 1710 from AP MLD 1707 and may send a BA 1716. AP MLD 1707 may not send DL messages to MLDs 1705 and 1709 on link 1703 during medium busy period 1706.

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

[0156] 18 is a diagram of an exemplary message exchange procedure 1800 between an MLD 1805 (e.g., a non-STR STA MLD) and an MLD 1807 (e.g., an STR AP MLD) over multidirectional link 1801 and multidirectional link 1802. Message exchange procedure 1800 shows exemplary AP MLD 1807 on link 1802 obtaining a TXOP 1822 using TIDy EDCA (when DL TIDy traffic arrives 1817), but transmitting 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 when MLD 1805 is transmitting UL message 1810 on link 1801 (which may be acknowledged by receiving BA 1814 from AP MLD 1807), other OBSS / UL STAs (not shown) may occupy the medium (channel) on link 1802 by transmitting UL message 1812 on link 1802. AP MLD 1807 on link 1802 may reserve a time period for transmission on link 1802 (i.e., obtain TXOP 1822) by transmitting or triggering transmission (or both) on link 1802 to other TID / STAs (not shown) until the (non-STR) MLD 1805 on link 1801 can receive on link 1802. 18, to avoid the problems described with respect to FIG. 2, after the arrival of TIDy traffic 1817 for MLD 1805 on link 1802, the AP MLD 1807 may contend for a channel on link 1802 using the AC of TIDy or any other AC to win EDCA access on link 1802 and occupy the channel on link 1802. Before MLD 1805 completes UL transmission 1816 on link 1801, the AP MLD 1807 may transmit a DL PPDU 1820 to another STA with an AC of lower or higher priority than TIDy, and / or the AP MLD 1807 may receive an ACK / BA 1826 from another STA. The MPDU of PPDU 1820 may be fragmented, or the PSDU of PPDU 1820 may be padded to allow the AP MLD 1807 to transmit a subsequent DL PPDU 1824 (with TIDy) to the MLD 1805 on link 1802 within the same TXOP 1822 after the MLD 1805 stops transmitting 1816 on link 1801 (at which point the MLD 1805 can start receiving on link 1802 even though the MLD 1805 is receiving BA 1818 on link 1801 because the MLD 1805 can handle simultaneous reception). The AP MLD 1807 may receive BAs 1826 and 1828 from the respective STAs / MLDs 1805 in response to the DL PPDUs 1820 and 1824.Following the TXOP 1822 on link 1802, the MLD 1805 may resume UL transmission 1830 on link 1801.

[0158] In another example, the AP MLD on link 2 can reserve a channel on link 2 until the (non-STR) MLD on link 1 can receive on link 2 by transmitting a trigger frame. Figure 19 is a diagram of 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. Message exchange procedure 1900 shows an exemplary AP MLD 1907 on link 1902 obtaining a TXOP 1932 by using an optional AC by transmitting a TF 1918 to another STA (not shown) before MLD 1905 stops transmitting UL data 1916 on link 1901. During the time period when MLD 1905 is transmitting UL message 1910 on link 1901 (which may be acknowledged by receiving BA 1914 AP MLD 1907), other OBSS / UL STAs (not shown) may occupy the medium (channel) on link 1902 by transmitting UL message 1912 on link 1902. As shown in FIG. 19 , after the arrival of TIDy traffic 1917 for MLD 1905 on link 1902, AP MLD 1807 may reserve a channel on link 1902 using TF 1918. TF 1918 may be addressed to other STAs (not shown) or may trigger a UORA transmission. The AP MLD 1907 on link 1902 may indicate the UL duration of the TB-PPDU 1920 in TF 1918 so that after the AP MLD 1907 transmits an ACK / BA 1924 to the PPDU 1920 on link 1902, the AP MLD 1907 may begin a DL TIDy transmission 1926 to the MLD 1905 on link 1902 within the same TXOP 1932 (i.e., after the UL transmission 1916 by the MLD 1905 on link 1901, this may be acknowledged by BA 1922). In other words, the end of the transmission of BA 1922 on link 1901 may be synchronized with the end of the transmission of BA 1924 on link 1902.Following TXOP 1932 on link 1902 (and DL transmission of DL PPDU 1926 and BA 1928), MLD 1905 may resume UL transmission 1930 on link 1901. Transmissions to MLD 1905 on link 1902 (and similar to MLD 1805 on link 1802 in FIG. 18 ) may include frames required for protection (e.g., from neighbors of MLD 1902 on link 1902) and / or signaling for MLD 1905 to switch its receive radio resources to link 1902.

[0159] The example described above may incorporate an additional requirement (e.g., see FIG. 21 described below) to terminate the TXOP of the STA MLD on link 1 early (e.g., terminate the UL transmission 1916 from MLD 1905 on link 1901 early), thereby allowing the STA MLD to receive DL TIDy traffic on link 1902 sooner. The duration of the CF-End frame (i.e., the control frame that terminates the TXOP) transmitted by the STA MLD on link 1 may 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 a transmission to MLD1 on link 2 in the TXOP may not count toward the TXOP limit of the AC obtaining the TXOP (e.g., the AC for TIDy). For example, if the TXOP limit for TIDy is zero, the AP may transmit one or more PPDUs in the TXOP before a transmission to MLD1 on link 2 in the TXOP.

[0160] 20 is a diagram of an example message exchange procedure 2000 between an MLD 2005 (e.g., a non-STR STA MLD) and an MLD 2007 (e.g., an STR AP MLD) over multidirectional link 2001 and multidirectional link 2002. Message exchange procedure 2000 shows an example AP MLD 2007 using knowledge of the end time t of the latest of future TXOPs. During the time period when MLD 2005 is transmitting an UL message 2010 on link 2001 (which may be acknowledged by receiving a BA 2014 from the AP MLD 2007), another OBSS / UL STA (not shown) may occupy the medium (channel) on link 2002 by transmitting an UL message 1812 on link 2002.

[0161] After the arrival of TIDy traffic 2017 for MLD 2005 on link 2002, AP MLD 2007 on link 2002 may transmit frame 2018 to indicate a requirement that any TXOP started after frame 2018 should end before time t. This requirement may apply only to intra-BSS STAs (not explicitly shown) on this link 2002 and / or may apply to OBSS STAs (not explicitly shown). Time t may be the time after MLD 2005 on link 2001 stops UL transmission 2016 (including a possible CF-end frame), at which point MLD 2005 can begin receiving on link 2002. MLD 2005 may receive BA 2022 acknowledging UL transmission 2016 on link 2001. Following time t, the AP MLD 2007 may transmit a DL PPDU 2026 (with TIDy) to the MLD 2005 on link 2002, and the MLD 2005 may transmit a BA 2028 on link 2002 to acknowledge receipt of the PPDU 2026. Following a TXOP 2024 on link 2002, the MLD 2005 may resume UL transmissions 2030 on link 2001.

[0162] Additional mechanisms, including requirements imposed to resolve conflicts between DL transmissions on link A to a non-STR MLD and UL EDCA transmissions on link B from the non-STR MLD, 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, an OM control sent on a link may indicate that UL MUs are disabled, that UL MU data is disabled, and / or that extended range single user (ER SU) is disabled on that link only. In another example, OM control may apply to link 2, but may be sent on link 1, and the control may explicitly signal the identity of link 2. The AP MLD may not transmit the quick-trigger capable TWT indication, EDCA idle time indication, and / or control fields for BSR (or alternative EDCA parameters) to be applied on the link if the non-AP MLD has signaled that the link is either UL MU Disabled or UL MU Data Disabled. In this case, a PPDU transmitted later without specific identification of the MLD / STA (e.g., broadcast) for the quick-trigger capable TWT indication, EDCA idle time indication, and / or control fields for BSR (or alternative EDCA parameters) to be applied on link 1 to provide an access opportunity on link 2 may include a traffic indication map (TIM) element (e.g., STAs with the TIM bit set to 1) informing which STAs on link 1 may apply the TWT indication / EDCA idle time indication / control fields for BSR (or alternative EDCA parameters) on link 1. Link 1 STAs of the MLD that are not indicated in the TIM bitmap (e.g., those with the TIM bit set to zero) may perform EDCA access without restriction (e.g., terminate a quick-trigger-enabled TWT early). Subsequent PPDUs may be transmitted on Link 2.

[0163] Figure 21 shows an example use of an indication to terminate a TXOP early (relative to the TXOP's original end time). The methods in the previous section, such as the quick-trigger-enabled TWT indication / EDCA idle time / control field for BSR or alternative EDCA parameters, can also be used as an indication to terminate the current TXOP early. This may 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 indication. As an alternative to further reduce the delay on link 2, the CF-End can be sent by the sender of the indication to terminate the current TXOP early (e.g., by the AP on link 1). In this case, the IFS between the frame carrying the indication and the CF-end frame may be greater than SIFS to avoid collisions between the CF-End transmission and data transmissions if the frame carrying the indication is lost / not received by the TXOP holder.

[0164] 21 is a diagram of an exemplary message exchange procedure 2100 between MLD 2105 and MLD 2109 (e.g., non-STR STA MLDs) and MLD 2107 (e.g., STR AP MLD) via multidirectional link 2101 and multidirectional link 2102. Message exchange procedure 2100 illustrates an example of early termination of a TXOP 2117 on link 2101. In one example, while MLD 2105 is transmitting UL traffic 2110 on link 2101, DL TIDy traffic 2113 may arrive at AP MLD 2107 for MLD 2105 and be mapped to link 2102. BA 2112 sent by AP MLD 2107 to MLD 2105 (to acknowledge receipt of UL PPDU 2110) may indicate a DL BSR for TIDy and / or a request for MLD 2105 to early terminate its current TXOP 2117 on link 2101. The CF-END message 2114 may be transmitted by the AP MLD 2107 (e.g., the PIFS duration after BA 2112) or may be sent by the MLD 2105 (e.g., the ISF duration after BA 2112), at which point the AP MLD 2107 may transmit a subsequent DL PPDU 2116 (with TIDy) to the MLD 2105 on link 2102. A UL transmission 2118 from another MLD 2109 on link 2101 (acknowledged by BA 2120) may overlap in time with the DL PPDU 2116.

[0165] The application of terminating a TXOP early may not be limited to non-STR STAs. For example, if DL data for more delay-sensitive TIDz traffic mapped to Link 1 arrives at the AP MLD during MLD 1's UL TXOP on Link 1, this procedure can also be used by the AP to terminate the UL TXOP early. The DL / UL transmission from MLD 1 to MLD 1 on Link 2 in the example described above may include an indication that it is the last transmission / MPDU. In this case, MLD 1 / 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 setting for non-primary channel transmissions can be used to address issues related to NAV setting for non-primary channel transmissions for multi-directional links. In an 802.11 system, the capabilities of APs and non-AP STAs can vary. For example, an AP may be capable of operating on a wideband channel, e.g., a channel having 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 set its NAV based on frames received on a subchannel with a relatively smaller bandwidth. Conventionally, NAV setting may maintain a prediction of future traffic on the medium based on duration information announced in the MAC header of some frames. NAV setting may be available on a primary 20 MHz subchannel. In the following example, 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, which may be modulated and repeated over (e.g., 20 MHz) subchannels, 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 its NAV based on the TXOP duration. In addition, the puncturing information field may allow a receiving STA to know which subchannels have been punctured and will be punctured in the TXOP. Based on at least the above information, unintended STAs, including OBSS STAs, may be able to know which subchannels may be occupied and for how long. Therefore, a per-subchannel based NAV may be possible or may be set.

[0168] FIG. 22 is a diagram of an example per-subchannel NAV setting procedure 2200. The example per-subchannel NAV setting procedure 2200 may use a U-SIG field to set a NAV setting on a per-subchannel basis. As shown in FIG. 22, the STA 2205 may monitor one or more subchannels, such as its primary subchannel 2201 (e.g., a primary 20 MHz subchannel or a primary 80 MHz subchannel). The STA 2205 may detect a transmission. Because the STA 2205 cannot monitor the entire bandwidth of the transmitted PPDU, it may not always be able to detect a data transmission. However, the STA 2205 may be able to detect one or more signaling fields in a PLCP header that may be transmitted over a subchannel, such as a 20 MHz subchannel. By decoding the signaling field (e.g., a U-SIG field) of the transmitted PPDU, the STA 2205 may determine, for example, the BSS color, bandwidth, puncturing information, DL / UL information, and / or the duration of the TXOP 2211.

[0169] In the case of a BSS color, if the BSS color cannot be the STA 2205's associated BSS color, the STA 2205 may consider the transmission to be from a BSS; otherwise, it may be from its own BSS. The bandwidth field may indicate the bandwidth of the PPDU. 802.11 channelization and signaling across 5 GHz and 6 GHz may allow the STA 2205 to uniquely know the start and end frequencies of a channel when it detects a signal on at least one 20 MHz subchannel in the bandwidth. For example, the STA 2205 may monitor subchannels 2201 and 2202. The STA 2205 may not detect anything on subchannel 2202, but may 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, the TXOP owner may keep the puncturing information the same throughout the TXOP. In one example, the TXOP owner may allow TXOP participants to add more puncturing subchannels during the same TXOP 2211. However, subchannel 2202, which was punctured at the beginning of TXOP 2211, may be punctured during the entire TXOP 2211. Based on the DL / UL information, the STA 2205 may know that the transmission may be from an AP or a non-AP STA. The TXOP duration field may indicate the duration of the TXOP 2211. Based on the information obtained above, the STA 2205 may set per-subchannel NAVs 2221, 2223, and 2224 for subchannels 2201, 2203, and 2204, respectively. The STA 2205 may not have any NAV on subchannel 2202 (or the NAV value for subchannel 2202 is zero) because it is punctured. In one example, STA 2205 may maintain intra BSS NAVs 2221, 2223, and 2224 for each sub-channel and inter BSS NAVs 2221_1, 2223_1, and 2224_1 for each sub-channel.In another example, the STA 2205 may maintain an intra-BSS NAV over the entire bandwidth and inter-BSS NAVs 2221, 2223, and 2224 for each sub-channel.

[0170] In the example shown in FIG. 22, STA 2205 may observe / detect a U-SIG on channel 2201 (Ch2201). STA 2205 may determine that the transmission may be from an OBSS AP (not explicitly shown). The AP may be operating on an 80 MHz channel, and / or the punctured subchannel is channel 2202. In this example, STA 2205 may operate on the same 80 MHz channel as the OBSS AP. STA 2205 may set NAVs 2221, 2223, and 2224 for subchannels 2201, 2203, and 2204 based on the duration of TXOP 2211 (which STA 2205 may decode). NAVs 2221 / 2223 / 2224 may be updated based on the duration field in the MAC header when STA 2205 decodes a MAC frame carried by a detected PPDU (e.g., any PPDU detected by STA 2205). The use of NAV 2221 / 2223 / 2224 per subchannel can be similar to NAVs such as Intra BSS NAV and Inter BSS NAV, etc. In one example, Inter BSS NAV and Intra BSS NAV on the primary 20 MHz subchannel can be viewed and utilized as conventional Inter BSS NAV and Intra BSS 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 20 MHz 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 of the 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 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 40 MHz RU to the STA for uplink transmission. The NAV per subchannel may indicate that 20 MHz subchannels may be idle and other 20 MHz subchannels may be busy.

[0172] In one example, the STA may respond to the trigger frame via an RU on an available subchannel. The STA may use an RU that may be within the first assigned RU. In the example above, the AP may assign a 484-tone RU (corresponding to approximately 40 MHz) to the STA in the trigger frame. The per-channel NAV may allow the STA to respond on the first 20 MHz subchannel. Thus, the STA may use a 242-tone RU to respond. The STA may follow other instructions in the trigger frame for UL transmission. In one embodiment, the STA may not respond to the trigger frame because the CS is indicated as 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 the 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 the 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 be applied 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 inter-BSS NAV may be referred to as basic NAV.

[0174] An example procedure may configure MU-EDCA parameters and / or timers for MLD. Non-AP MLD may use a single MU-EDCA timer per AC for multiple links, e.g., the MUEDCATimer[AC] variable per MLD may be updated with the value described below. The updated MUEDCATimer[AC] may start at the end of an immediate acknowledgment if a TB / SU PPDU transmitted on any active link contains at least one QoS data frame for that AC that requires immediate acknowledgment. The updated MUEDCATimer[AC] may start at the end of a TB / SU PPDU on any active link if a transmitted TB / SU PPDU does not contain any QoS data frames for that AC that require immediate acknowledgment, but does contain at least one QoS data frame for that AC.

[0175] If the MU-EDCA timer values ​​advertised per link on all active links for an AC (e.g., broadcast using beacon frames on each link) are the same, the non-AP MLD may use a common value as the MU-EDCA timer for the AC. If the MU-EDCA timer values ​​advertised per link on all active links for an AC are not the same, the non-AP MLD may use the minimum value as the MU-EDCA timer for the AC. If the MU-EDCA timer values ​​advertised per link on all active links for an AC are not the same, the non-AP MLD may use the maximum value as the MU-EDCA timer for the AC. The active links for an AC may be the set of links to which the TID of the AC is mapped. The active links for an AC may be the set of links that are not in PS mode doze state for non-AP STAs and to which the TID of the AC is mapped. The AP MLD may signal alternate or additional MU-EDCA set elements or MU-EDCA parameters and may include alternate / common MU-EDCA timers in unicast signaling. The MU-EDCA timer values ​​in the (re)association response or another unicast DL frame may differ from the MU-EDCA timers 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 ​​that are common on all active links in the (re)association response or another unicast DL frame. The signaled AIFSN or ECW_min / max values ​​may differ from the AIFSN or ECW_min / max values ​​signaled in the beacon frame.

[0176] If UL TIDs of the same AC are mapped to disjoint sets 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 of the TID of the buffered data, the BSR from the 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 include a bitmap where each bit corresponding to a TID indicates the presence of buffered traffic for that TID. The BSR field may include a bitmap or identification of the AC of the buffered traffic, along with a subsequent bitmap or identification field to further identify the TID of the identified AC that has buffered traffic.

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

[0178] AP MLD and non-AP MLD may be required to avoid mapping two different UL TIDs of the same AC to two disjoint sets of links. Upon receiving a BSR for a particular AC without knowing the TID of the buffered traffic, the AP may schedule UL access on a link that is in the intersection of two sets of links mapped to two TIDs for the same AC. AP MLD and non-AP MLD may be required to map two different UL TIDs of the same AC to the same set of links. Upon receiving a BSR for a particular AC without knowing the TID of the buffered traffic, the AP may schedule UL access on any of the active links in the set. When a non-AP MLD signals UL MU (data) disabling for link 1, it may be required that if the MU-EDCA timer (per MLD) (for that TID or for the AC to which the TID belongs) is running for a TID mapped to that link that is also mapped to another link 2 where the UL MU (data) has not been disabled, the MU-EDCA parameters (for link 1) may be used for EDCA access on link 1. In the case of an N-STR link pair, when a non-AP MLD signals UL MU (data) disabling for one link, the signaling may implicitly indicate to the AP MLD that the other link has also been UL MU (data) disabled.

[0179] In some examples involving per-subchannel inter / intra BSS NAV, for MU PPDUs, non-AP STAs may monitor at least the primary subchannel, inspect the NAV in the PHY or MAC header, and / or inspect the puncturing information in the per-subchannel PHY SIG-configured NAV. While 80 MHz and 160 MHz channels may not have overlap, 320 MHz channels may. For 320 MHz channels, an indication may be used to indicate the exact 320 MHz channel location in the U-SIG. Thus, the examples described herein may apply to inter-BSS NAV. In some examples involving MU-EDCA, improved efficiency may be obtained by prioritizing MU transmissions. For example, HE non-AP STAs may reduce EDCA channel access probability only when they are scheduled by the AP. Both the AP and STAs may compete to access the channel for the same traffic. This may result in 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 described above, non-AP STAs may reduce EDCA access probability when they are scheduled by the AP. The MU-EDCA timer may be used per link and / or per MLD for AC. For a per-MLD EDCA timer, the timer value signaling may not reuse the same value in the MU-EDCA parameter element because if the value for N links is the same, N different values ​​for N links reuse the value in the MU-EDCA parameter element. For a trigger to start / reset the timer, the ACK of a 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 TIDs of the same AC 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 per-MLD MU-EDCA timers are used, MU-EDCA timer [AC1] may not apply to link 2. Examples of UL MU (data) disabling in ML are described herein. Signaling of UL MU (data) 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, it may implicitly indicate that link 2 UL MU is also disabled. The relationship with per-MLD MU-EDCA timers may be described herein. If link 1 signals UL MU Disable while the MU-EDCA timer is running, link 1 may use normal EDCA parameters, and other links use MU-EDCA parameters for the same AC. Non-AP STAs that transmit frames 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, do not participate in UL MU operations. They are therefore exempt from updating their EDCA access parameters to the values ​​contained in the MU-EDCA Parameter Set element as specified in this subclause. Link 1 may still use MU-EDCA parameters because MLD may still be scheduled on other links that do not have coexistence issues.

[0182] Although features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium 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 in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A station (STA) multi-link device (MLD), comprising: a processor configured to generate a frame including a control element indicating a priority associated with data traffic associated with a link between the STA MLD and another MLD, a delay associated with the data traffic associated with the link between the STA MLD and another MLD, and a traffic identifier (TID) associated with the data traffic associated with the link between the STA MLD and another MLD; a transmitter configured to transmit the frame including the control element to the other MLD; The STA MLD is characterized by comprising:

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

3. a receiver configured to receive the data traffic associated with the TID from the other MLD.

2. The STA MLD of claim 1, further comprising:

4. 4. The STA MLD of claim 3, wherein the data traffic associated with the TID is received in accordance with the priority associated with the data traffic associated with a link between the STA MLD and another MLD and the delay associated with the data traffic associated with the link between the STA MLD and another MLD.

5. The STA MLD of claim 1 , wherein the STA MLD is configured with a plurality of links between the STA MLD and the other MLD.

6. The STA MLD of claim 1 , wherein the control element is transmitted in a data frame.

7. The STA MLD of claim 1 , wherein the control element is transmitted in a Medium Access Control (MAC) header.

8. The STA MLD of claim 1, wherein the other MLD is an access point (AP) MLD.

9. A method for use in a STA multi-link device (MLD), comprising: generating a frame including a control element indicating a priority associated with data traffic associated with a link between the STA MLD and another MLD, a delay associated with the data traffic associated with the link between the STA MLD and another MLD, and a traffic identifier (TID) associated with the data traffic associated with the link between the STA MLD and another MLD; transmitting the frame including the control element to the other MLD; A method comprising:

10. The method of claim 9, wherein the control element enables the other MLD to satisfy the priority associated with the data traffic associated with the link between the STA MLD and the other MLD and the delay associated with the data traffic associated with the link between the STA MLD and the other MLD.

11. receiving the data traffic associated with the TID from the other MLD; 10. The method of claim 9, further comprising:

12. 12. The method of claim 11, wherein the data traffic associated with the TID is received according to the priority associated with the data traffic associated with a link between the STA MLD and another MLD and the delay associated with the data traffic associated with the link between the STA MLD and another MLD.

13. 10. The method of claim 9, wherein the STA MLD is configured with multiple links between the STA MLD and the other MLDs.

14. 10. The method of claim 9, wherein the control element is transmitted in a data frame.

15. 10. The method of claim 9, wherein the control element is transmitted in a Medium Access Control (MAC) header.

16. The method of claim 9, wherein the other MLD is an access point (AP) MLD.

Images