Methods for enabling multi-link wlans

Abstract

To provide systems, methods, and devices for enabling multi-link WLANs.SOLUTION: As disclosed herein, there may be systems, methods, and devices for enabling multi-link wireless local area networks (WLANs). One or more non-AP station (STA) multi-link devices (MLDs) and one or more Access Point (AP) MLD may establish a multi-link association between each other, thereby establishing a multi-link connection that enables improved and more efficient wireless communication.SELECTED DRAWING: Figure 3B

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 873,587, filed July 12, 2019, and U.S. Provisional Patent Application No. 62 / 932,840, filed November 8, 2019, the contents of which are hereby incorporated by reference.

[0002] TECHNICAL FIELD The present disclosure relates to wireless communications, and more particularly to systems, methods, and devices that enable multi-link WLANs. [Background technology]

[0003] In wireless local area networks, new use cases are emerging as the state of wireless technologies evolves, and there is now a need for more efficient use of the spectrum that those wireless technologies utilize, particularly in 802.11 systems, to address those new use cases. Summary of the Invention

[0004] As disclosed herein, there may be systems, methods, and devices that enable a multilink wireless local area network (WLAN). There may be procedures by which one or more base station (STA) devices and one or more access point (AP) devices establish multilink associations between the one or more devices, thereby establishing a multilink connection that enables improved and more efficient wireless communication. There may be a multilink channel feedback protocol for load balancing and optimal performance. There may be a multilink operating mode adjustment procedure. There may be one or more multilink architectures and addressing protocols to handle multilink communications. Additionally, there may be a multilink frame number allocation protocol. There may also be a multilink acknowledgment procedure for multilink transmissions.

[0005] 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 refer to like elements and in which: [Brief explanation of the drawings]

[0006] [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 example wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to an 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 an embodiment. [Figure 1D] 1B is a system diagram illustrating a further example RAN and a further example CN that can be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 1E] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 2] 1 is a flow chart of an embodiment of a multilink discovery and association procedure. [Figure 3A] 1 is a diagram of an embodiment of an 802.11 architecture. [Figure 3B] FIG. 1 is a diagram of an embodiment of a multi-link architecture. [Figure 3C] FIG. 1 is a diagram of an embodiment of a multi-link GLK architecture. [Figure 4] FIG. 10 is a diagram of the MSB of the FN field as refragmentation in an MPDU BAR of an embodiment. [Figure 5] FIG. 10 is a diagram of an example of current PTK derivation. [Figure 6] FIG. 1 is a diagram of a nonce field in an example CCMP. [Figure 7] FIG. 1 is a diagram of a nonce field of an example GCMP. [Figure 8] FIG. 10 is a diagram of an example procedure for multilink delayed block acknowledgment. [Figure 9] FIG. 10 is a diagram of an example procedure for multilink immediate block acknowledgment. [Figure 10] FIG. 10 is a diagram of an example procedure for multi-link multi-base station acknowledgment. DETAILED DESCRIPTION OF THE INVENTION

[0007] 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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-tailed unique word discrete Fourier transform spread OFDM (ZT UW DTS-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multicarrier (FBMC).

[0008] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be appreciated 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” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as a UE. As discussed herein, a WTRU may be interchangeably referred to as a STA, and a STA may be interchangeably referred to as a WTRU, and as disclosed herein, a STA and a WTRU may be equivalent and / or identical. Furthermore, as discussed herein, there may be various embodiments that refer to a base station (STA), and it is contemplated that those STAs may be both AP STAs or non-AP STAs.Furthermore, each STA and / or WTRU may be a multi-link device and may be referred to interchangeably as a STA MLD, a WTRU MLD, or an AP MLD.

[0009] 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 NodeB, an eNodeB, a Home NodeB, a Home eNodeB, a Next Generation NodeB such as a gNodeB (gNB), a New Radio (NR) NodeB, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0010] The base station 114a may be part of the RAN 104 / 113, 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 wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage for wireless services in 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 scenario, the base station 114a may include three transceivers, one for each sector of the cell. In one scenario, the base station 114a may utilize multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0011] 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).

[0012] More specifically, as mentioned above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a and the WTRUs 102a, 102b, and 102c in the RAN 104 / 113 may establish the air interface 116 using Wideband CDMA (WCDMA) or may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed Uplink (UL) Packet Access (HSUPA).

[0013] In one scenario, 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).

[0014] In one scenario, 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.

[0015] In one scenario, 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 implement both LTE radio access and NR radio access, e.g., using a dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0016] In other scenarios, the base station 114a and the WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, 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), and GSM EDGE (GERAN).

[0017] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a localized area such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), and a roadway. In one scenario, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another scenario, the base station 114b and the WTRUs 102c, 102d may implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another scenario, the base station 114b and the WTRUs 102c, 102d may establish a picocell or femtocell utilizing 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 be required to access the Internet 110 via the CN 106.

[0018] The RAN 104 / 113 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, delay, error resilience, reliability, data throughput, and mobility requirements. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, 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 / 113 and / or the CN 106 may communicate directly or indirectly with other RANs that utilize the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] 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 circuit-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 Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 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 utilize the same RAT as the RAN 104 / 113 or a different RAT.

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

[0021] 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 subcombination of the above elements while remaining consistent with an embodiment.

[0022] 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 in conjunction with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, 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.

[0023] 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 scenario, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one scenario, 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 scenario, 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.

[0024] 1B, the transmit / receive element 122 is depicted as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize MIMO technology. Thus, in one scenario, 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.

[0025] The transceiver 120 may be configured to modulate signals to be 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, for example, NR and IEEE 802.11.

[0026] The processor 118 of the WTRU 102 may be coupled to and may receive user input 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 output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may obtain 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 scenarios, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as located on a server or home computer (not shown).

[0027] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components within the WTRU 102. The power source 134 may be any suitable device for powering 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.

[0028] 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 over the air interface 116 from base stations (e.g., base stations 114a, 114b) and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information using any suitable location determination method while remaining consistent with an embodiment.

[0029] 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 e-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 modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, which 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, and / or a humidity sensor.

[0030] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing via a processor (e.g., a separate processor (not shown) or the processor 118). In one scenario, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

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

[0032] 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 one scenario, the eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0033] 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, scheduling of users in the UL and / or DL, etc. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with each other over an X2 interface.

[0034] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the above elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0035] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, 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.

[0036] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNodeB handover, 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.

[0037] 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.

[0038] 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 communication 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. In addition, 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.

[0039] Although in Figures 1A-1E, the WTRU is described as a wireless terminal, it is contemplated that in certain representative scenarios, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with a communication network.

[0040] 1D is a system diagram illustrating an example RAN 104 and CN 106. As described 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.

[0041] The RAN 104 may include gNBs 180a, 180b, and 180c, although 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 scenario, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNB 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a, for example, using multiple antennas. In one scenario, 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, while the remaining component carriers may be on a licensed spectrum. In one scenario, the gNBs 180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0042] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a 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 different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting for different lengths of absolute time).

[0043] 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). 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 / connect to a gNB 180a, 180b, 180c while also communicating with / connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle 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, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0044] 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, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b and 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 over the Xn interface.

[0045] 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 each of the above elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

[0046] 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 act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, and mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. Different network slices may be established for different use cases, such as services relying on Ultra-Reliable Low-Latency (URLLC) access, services relying on eMBB access, and / or services for Machine-Type Communication (MTC) access, etc. The AMF 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 LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0048] 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 184a, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihoming PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0049] 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 serves as an interface between the CN 106 and the PSTN 108. In addition, 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 scenario, the WTRUs 102a, 102b, 102c may be connected to local data networks (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.

[0050] 1A-1E 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, APs 190a-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 to simulate network and / or WTRU functionality.

[0051] The emulation device may be designed to perform one or more tests of other devices in a laboratory environment and / or in 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 device may be directly coupled to another device for testing purposes and / or may perform tests using over-the-air wireless communication.

[0052] One or more emulation devices may perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test lab and / or in a test scenario in an undeployed (e.g., test) wired and / or wireless communication network to perform tests 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, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0053] Additionally / alternatively, one or more or all of the functions described herein for one or more of the STAs 102a-d, APs 190a-d, and / or any other device(s) described herein, such as AP STAs and non-AP STAs, may be logical entities. Each logical entity may be contained in one or more physical devices and / or enclosures. For example, there may be two logical APs contained in one physical multilink device (MLD), and the MLD may be referred to as an AP regardless of whether it includes two or more logical APs. In another example, there may be two logical STAs in one physical enclosure (e.g., an MLD smartphone), and the physical enclosure may be referred to as an STA regardless of whether it includes two or more logical STAs. A physical enclosure or MLD may contain one or more logical entities of one or more devices, such as a single enclosure containing two logical STAs and two logical APs. As discussed herein, an MLD may be, or may be interchangeable with, an AP MLD and / or a non-AP MLD.

[0054] Additionally / alternatively, a channel may be used interchangeably with a link as discussed herein.

[0055] In some embodiments, the other network 112 in Figure 1A may be a wireless local area network (WLAN) such as defined by IEEE 802.11. Figure 1E is a system diagram illustrating an example communication system (e.g., a WLAN).

[0056] WLANs in infrastructure basic service set (BSS) 191a and 191b mode may each have access points (APs) 190a and 190b for the BSSs 191a and 191b, respectively, and one or more WTRUs (e.g., STAs) 102a-e associated with the APs 190a, 190b. As discussed herein, a given BSS may be referred to as a network and may refer to communications occurring logically. The APs 190a, 190b may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS (not shown). Traffic to the WTRU originating from a BSS (e.g., 191a, 191b) may arrive through the AP (e.g., 190a, 190b) and be delivered to the WTRU. Traffic originating from WTRUs 190c-e to destinations outside the BSS 191a may be transmitted to the AP 190a to be delivered to the respective destinations. Traffic between WTRUs 190c-e within the BSS 191a may be transmitted through the AP 190a, for example, where the source WTRU 102c can transmit traffic to the AP 190a, which can deliver the traffic to the destination STA 190d. Traffic between WTRUs (e.g., 190c-e) within a BSS (e.g., 191a) may be considered peer-to-peer traffic and may be referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source WTRU and a destination WTRU (e.g., directly between them) via direct link setup (DLS). In some cases, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS).

[0057] In some cases, a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. IBSS mode communication is sometimes referred to herein as "ad hoc" mode communication.

[0058] 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 width dynamically set via signaling. 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 one representative embodiment, for example, in an 802.11 system, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., every STA), 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. Within a given BSS, one STA (e.g., only one station) may transmit at any given time.

[0059] A high-throughput (HT) STA may use a 40-megahertz-wide channel for communication, for example, by combining a primary 20-megahertz channel with an adjacent or non-adjacent 20-megahertz channel to form a 40-megahertz-wide channel.

[0060] A very high throughput (VHT) STA may support channels that are 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide. A 40 MHz and / or 80 MHz channel may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel encoding, the data may be passed 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 onto 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 sent to the media access control (MAC).

[0061] Sub-1 GHz mode operation is supported by 802.11af and 802.11ah. The 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 an embodiment, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited functionality, including, for example, support for certain bandwidths and / or limited bandwidths (e.g., only support for them). The MTC device may include a battery with a battery life above a threshold (eg, to maintain a very long battery life).

[0062] WLAN systems capable of supporting multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel may be set and / or limited by a STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 1 MHz mode, the primary channel may be 1 MHz wide, 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) setting may depend on the status of the primary channel. For example, if the primary channel is busy because a STA (that only supports a 1 MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and available for use.

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

[0064] Generally, High-Efficiency WLAN (HEW) can address the need for broadband spectrum for wireless users to enhance the quality of service experienced by all users in many usage scenarios, including high-density scenarios in the 2.4 GHz, 5 GHz, and 6 GHz bands. Use cases that support dense deployment of APs and STAs and associated radio resource management (RRM) technologies may be included in HEW. Potential applications for HEW can include usage scenarios such as high-user density scenarios (such as train stations, stadium events, enterprise / retail environments), and address increased reliance on wireless services for video / data distribution and medical applications. HEW may be implemented in 802.11ax.

[0065] Potential applications for HEW may include, but are not limited to, usage scenarios such as data distribution for stadium events, high user density scenarios such as train stations or enterprise / retail environments, and evidence of increased reliance on wireless services for video distribution and medical applications.

[0066] Additionally, 802.11ax can accommodate traffic for various scenarios with short packets, including virtual office, TCP ACK, video streaming ACK, device / controller (mouse, keyboard, game control, etc.), access-probe request / response, network selection-probe request, ANQP, and / or network management-control frames.

[0067] Also, for 802.11ax, there may be multi-user (MU) mechanisms, including UL OFDMA and DL OFDMA, and UL MU-MIMO and DL MU-MIMO. Furthermore, there may be mechanisms for multiplexing UL random access for different purposes, which may also be included in 802.11ax.

[0068] 802.11 Extreme High Throughput (EHT) may follow 802.11ax. EHT can address increased peak throughput and improve the efficiency of 802.11 networks. EHT may be included in 802.11be. One use case for 802.11be may include applications requiring high throughput and low latency, such as video over WLAN, augmented reality (AR), and / or virtual reality (VR). EHT and 802.11be may employ one or more mechanisms to achieve the goals of increased peak throughput and improved efficiency, such as multi-AP, multi-band / multi-link, 320 MHz bandwidth, 16 spatial streams, HARQ, full duplex (time and frequency domain), AP coordination, semi-orthogonal multiple access (SOMA), and / or new designs for 6 GHz channel access.

[0069] For 802.11be multi-link operation, there may be a high-level MAC architecture that enables multi-link operation, there may also be duplicate and replay detection for multiple links, and there may also be different modes of multi-channel / multi-band operation that can provide gains for multi-band / multi-link operation.

[0070] Generally, to achieve improvements in the 802.11 field, there may be several issues that need to be addressed, such as multi-link multi-AP association, dynamic feedback for load balancing and interference management; multi-link Tx / RX operating mode adjustment; multi-link architecture (e.g., multi-link non-AP device architecture, multi-link MAC architecture, multi-link design, and 802.11akMAC architecture); frame number allocation (e.g., multi-link acknowledgment for fragmented packets, packet number allocation, fragmentation across multiple STAs / APs); and / or multi-link acknowledgment.

[0071] Regarding the issue of multi-link multi-AP association, both the AP and the STA may be multi-link devices. In addition, there may be multiple APs in a multi-AP set, and the STA and AP may need to be informed of each other's capabilities and priorities and may perform appropriate association procedures for optimal performance and accurate configuration of the multi-link operating mode.

[0072] In one approach to addressing the above problem, there may be efficient discovery and association procedures that enable optimal performance for multi-link operation. A multi-link AP, which may be several multi-APs, may advertise one or more of its multi-link capability parameters and multi-link operation parameters in one or more of elements such as a multi-link capabilities element; a multi-link operation element; a real-time capabilities element; and / or a real-time operation element in its beacon, short beacon, fast initial link setup (FILS) discovery frame, and unicast or broadcast probe response.

[0073] The multilink capability element may include one or more of the following parameters for the multilink capabilities supported by the AP: number of bands; number of channels; multilink mode; maximum (max.) number of channels or links currently supported per device; maximum channel width supported per device; and / or channel aggregation mode.

[0074] The number of bands parameter can indicate the number of bands that the transmitting AP or transmitting multi-AP set supports, which may be indicated using a bitmap to indicate one or more bands including less than 1 GHz band, 2.4 GHz band, 5 GHz band, 3.5 GHz band, and 6 GHz band.

[0075] The number of channels parameter may be used to indicate the number of channels or links that a transmitting AP or multi-AP set can support for one or more supported bands.

[0076] The multi-link mode parameter may indicate one or more modes in which multi-link operation can be supported, including channel independent operation, channel aggregation, load balancing, dynamic channel selection, and dynamic AP selection.

[0077] The maximum number of simultaneously supported channels per device parameter can specify the maximum number of simultaneously supported channels per multilink device or per multilink STA. For example, this may be for individual channels or 20 MHz bandwidth channels.

[0078] The maximum supported channel width per device parameter may specify the maximum channel width that can be supported (eg, 80 megahertz, 160 megahertz, 240 megahertz, 320 megahertz, etc.).

[0079] The security mode parameter can specify whether security should be done for each link per device, or for the home / control / association channels, or whether security should be done again by the master AP and applied to all links that can be used with the virtual AP ID.

[0080] The channel aggregation mode parameter can specify whether channel aggregation should be contiguous or non-contiguous. In another embodiment, this parameter may be defined for each supported band to specify whether channel aggregation should be contiguous or non-contiguous for that band.

[0081] The multilink operation element may indicate current multilink operation parameters, such as: active band; active channel; home / anchor channel / association / control channel; virtual AP ID; multilink BSS color; security mode; and / or current multilink channel set.

[0082] The active bands parameter can define the current active bands used by the transmitting AP or multi-AP set for multi-link operation, which may be indicated using a bitmap to indicate one or more bands including below 1 GHz, the 2.4 GHz band, the 5 GHz band, the 3.5 GHz band, and the 6 GHz band.

[0083] The active channel parameters may indicate the active channels used for multilink operation. In one embodiment, a bitmap is used to indicate the active channels used for multilink operation. In another embodiment, a bitmap is used per active band to indicate the active channels used for multilink operation per band. In another embodiment, a list of fields may be used to describe one or more active channels that are currently active as multilink channels. Each of the fields may include one or more of the following: channel width, number of channels, channel operating class, etc.

[0084] The Home / Anchor Channel / Association / Control Channel parameters may specify a home channel, or anchor channel, association channel, and / or control channel, which may be used by the STA to perform association and exchange control channels, or may be used as a default channel when participating in multilink operation.

[0085] The Virtual AP ID parameter indicates the ID of the virtual AP for which the multi-AP set is represented. This may be the BSSID or MAC address, which can be the ID of the AP serving the anchor or association channel, or the MAC address for a higher-level Service Access Point (SAP) that connects to the DS.

[0086] The multi-link BSS color parameter identifies a multi-link AP device. The BSS color may be the same for links associated with the same multi-link AP device if the multi-link AP device is not capable of performing independent TX / RXMAC operations for different links. The multi-link BSS color may be different for links associated with the same multi-link AP device if the multi-link AP device is capable of performing independent TX / RXMAC operations for the links. One or more multi-link BSS colors may be provided for different links associated with the same multi-link AP device, and sensitivity levels may also be included for those multi-link BSS colors with respect to other MLDs to adjust their CCA levels when receiving one of those multi-link transmissions, determine whether the medium is idle or busy, and determine whether special reuse should occur.

[0087] The security mode parameter specifies the current security mode, e.g., security may be performed for each link per device, or security should be performed for the home / control / association channel, or security should be performed by the master AP, and applies to all links that can be used with the virtual AP ID.

[0088] The current multilink channel set parameter may include one or more multilink channel sets that the STA can use as a fixed set of channels for multilink operation. The STA may select one or more sets of such channels after association.

[0089] The real-time capability element may include the following parameters: delay; jitter; traffic spec; number of simultaneous streams; and / or capabilities to indicate real-time traffic capabilities such as number of simultaneous real-time traffic channels.

[0090] The delay parameter defines the maximum and / or minimum delay that an AP or multi-AP set can provide.

[0091] The jitter parameter defines the maximum and / or minimum delay that an AP or multi-AP set can introduce.

[0092] The traffic specification parameters define the traffic specifications that an AP or multi-AP set can provide.

[0093] The number of simultaneous streams parameter indicates the number of simultaneous real-time traffic streams that an AP or multi-AP set can support.

[0094] The number of simultaneous real-time traffic channels parameter indicates the number of simultaneous channels that can be used to support one real-time traffic stream.

[0095] The real-time operational elements may define current parameters for the real-time traffic streams, such as delay; jitter; traffic specifications; number of additional streams; number of simultaneous real-time traffic channels; and / or current set of simultaneous real-time traffic channels.

[0096] The delay parameter defines the current maximum and / or minimum delay that an AP or multi-AP set can provide.

[0097] The jitter parameter defines the current maximum and / or minimum delay that an AP or multi-AP set can provide.

[0098] The traffic specification parameters define the traffic specifications for any additional real-time traffic that the AP or multi-AP set may carry, such as priority or data rate.

[0099] The number of additional simultaneous streams parameter indicates the number of additional simultaneous real-time traffic streams that the AP or multi-AP set can currently support.

[0100] The number of simultaneous real-time traffic channels parameter indicates the current number of simultaneous channels that can be used to support one real-time traffic stream.

[0101] The current simultaneous real-time traffic channel set parameter indicates the current set of simultaneous channels that can be used to support real-time traffic streams.

[0102] A multilink device, which may include one or more multilink STAs, may advertise its multilink capabilities, real-time capabilities, and one or more of multilink requests and real-time link requests in one or more of the following elements in its probe request, association request: a multilink capability element; a multilink request element; a real-time capability element; and / or a real-time request element.

[0103] The multilink capability element may include one or more of the parameters for the multilink capabilities supported by the STA, such as the number of bands, the number of channels, the multilink mode, the maximum number of simultaneously supported channels (max.), and / or the channel aggregation mode.

[0104] The Number of Bands parameter indicates the number of bands supported by the transmitting STA or device, which may be indicated using a bitmap to indicate one or more bands including below 1 GHz, the 2.4 GHz band, the 5 GHz band, the 3.5 GHz band, and the 6 GHz band.

[0105] The number of channels parameter may be used to indicate the number of channels that the transmitting STA is capable of supporting in one or more supported bands.

[0106] The multi-link mode parameter indicates one or more modes in which multi-link operation can be supported, and may include channel independent operation, channel aggregation, load balancing, dynamic channel selection, or dynamic AP selection.

[0107] The maximum number of simultaneously supported channels parameter specifies the maximum number of simultaneously supported channels. For example, this may be in terms of individual channels or channels of 20 megahertz bandwidth.

[0108] The maximum supported channel width parameter defines the maximum channel width that can be supported, for example, 80 megahertz, 160 megahertz, 240 megahertz, or 320 megahertz.

[0109] The channel aggregation mode parameter specifies whether channel aggregation should be contiguous or non-contiguous. In another embodiment, this parameter may be defined for each supported band to specify whether channel aggregation should be contiguous or non-contiguous for that band.

[0110] The multilink request element may indicate a request for multilink operation, such as the following parameters: requested band, requested channel, virtual STA ID, and / or requested multilink channel set.

[0111] The requested bands parameter specifies the requested active bands to be used for multilink operation, which may be indicated using a bitmap to indicate one or more bands, including below 1 GHz, the 2.4 GHz band, the 5 GHz band, the 3.5 GHz band, and the 6 GHz band.

[0112] The requested channel parameters may indicate the requested channels for multilink operation. In one embodiment, a bitmap is used to indicate the requested channels to be used for multilink operation. In another embodiment, a bitmap is used per requested band to indicate the requested channels to be used for multilink operation per band. In another embodiment, a list of fields may be used to describe one or more requested channels as multilink channels. Each of the fields may include one or more of a channel width, a channel number, a channel operating class, or the like.

[0113] The Virtual STA ID parameter indicates the ID of the virtual STA to which the multilink device is represented. This may be a MAC address, which can be the ID of the STA operating on the anchor channel or association channel, or the MAC address for the upstream SAP connected to the DS.

[0114] The requested multilink channel set parameters may include one or more multilink channel sets that the STA can use as a fixed set of channels for multilink operation.

[0115] The real-time capability element may include the following parameters: delay, jitter, and / or the capability to indicate real-time traffic capabilities such as the number of simultaneous real-time traffic channels.

[0116] The delay parameter defines the maximum and / or minimum delay that a STA or device can introduce.

[0117] The jitter parameter defines the maximum and / or minimum delay that a STA or device can introduce.

[0118] The number of simultaneous real-time traffic channels parameter indicates the number of simultaneous channels that can be used to support one real-time traffic stream.

[0119] The real-time request element specifies parameters for the requested real-time traffic streams, such as the following parameters: delay, jitter, traffic specification, requested number of simultaneous streams, requested number of simultaneous real-time traffic channels, and / or requested set of simultaneous real-time traffic channels.

[0120] The delay parameter defines a maximum delay and / or a minimum delay.

[0121] The jitter parameters define the maximum and / or minimum delay required.

[0122] The traffic specification parameters define the traffic specifications for the requested real-time traffic stream, such as priority and data rate.

[0123] The requested number of simultaneous streams parameter indicates the number of real-time traffic streams requested.

[0124] The desired number of simultaneous real-time traffic channels parameter indicates the desired number of simultaneous channels that can be used to support one real-time traffic stream.

[0125] The requested number of simultaneous real-time traffic channel sets parameter indicates the requested set of simultaneous channels that can be used to support real-time traffic streams.

[0126] In an embodiment, there may be a multilink multi-AP discovery and association procedure. A multilink AP that may be a member of a multi-AP set may advertise one or more of its multilink capabilities, multilink operation elements, real-time capabilities elements, and / or real-time operation elements of one or more of the APs in the multi-AP set in one or more of its beacons, short beacons, FILS discovery frames, and elements in unicast or broadcast probe responses.

[0127] A multilink AP may advertise the supported bands, which can be either contiguous or non-contiguous, as well as the supported bands and supported channels for each supported multilink operating mode and supported channel aggregation mode. It may also advertise the maximum number of channels per multilink device and the maximum channel bandwidth per channel. In addition, it may also advertise the supported security modes, which may include setting up security for each link individually or setting up security once by the master AP and security to be applied to all links associated with non-AP multilink devices.

[0128] A multilink AP may advertise the currently active bands and channels used for multilink operation. It may also indicate one or more multilink channel sets that STAs may request to use for its multilink operation. It may also advertise a home / association / control channel over which control signaling and association may occur for any non-AP devices. In addition, it may advertise one or more virtual AP IDs that non-AP multilink devices should use to connect to the AP or multi-AP set. It may also advertise one or more multilink BSS colors along with the sensitivity levels associated with the one or more multilink BSS colors when determining whether a channel is idle or busy or when determining whether to perform spatial reuse.

[0129] A multilink AP may advertise its real-time traffic support capabilities, including the maximum and minimum delay or jitter the AP may be able to support and / or the maximum amount of real-time traffic or number of real-time traffic streams it can support. It may also advertise the maximum number of simultaneous channels it supports per multilink device.

[0130] A multi-link AP may advertise its real-time traffic operating parameters, including the maximum and minimum delay or jitter that the AP or multi-AP set (MAP) can currently provide, and / or how much additional real-time traffic or number of real-time traffic streams it can support. It may also advertise the current real-time traffic concurrent channel set being used.

[0131] A multilink non-AP device, which may include one or more non-AP STAs, may advertise one or more of its multilink capabilities, multilink operation requirements, real-time capabilities, and / or real-time operation requirements in one or more of the elements in its probe request frame or association request frame.

[0132] A multi-link non-AP device may advertise the supported bands, which can be either contiguous or non-contiguous, as well as the supported bands and supported channels for each supported multi-link operating mode and supported channel aggregation mode. It may also advertise the maximum number of channels per multi-link device and the maximum channel bandwidth per channel. In addition, it may also advertise the supported security modes, which may include setting up security for each link individually or setting up security once by the master AP and security to be applied to all links associated with the non-AP multi-link device.

[0133] A multi-link non-AP device may advertise its real-time traffic support capabilities, including the maximum and minimum delay or jitter that the multi-link device (MLD) can support and / or the maximum amount of real-time traffic or number of real-time traffic streams it can support. It may also advertise the maximum number of simultaneous channels for real-time traffic that it supports.

[0134] A multi-link non-AP device may advertise its real-time traffic requirements, including the maximum and minimum delay or jitter that the MLD is requesting and / or how much real-time traffic or how many real-time traffic streams it is requesting. It may also indicate a request to use a real-time traffic concurrent channel set.

[0135] A multilink non-AP STA device may discover a multilink AP or MAP by monitoring the discovery channel or any channel for beacons, short beacons, FILS discovery frames, or probe responses, or it may transmit a probe request frame that may include a multilink capability element and / or a real-time capability element. It may also include a multilink request element and a real-time traffic request element to indicate its requested multilink operation or a request for real-time traffic. A multilink non-AP STA device may switch to the home / association / control channel if it has received such information from a FILS discovery frame or other type of frame, and may transmit a probe request frame or monitor beacons, short beacons, or probe response frames. It may also transmit a probe request frame on the channel on which it received the FILS discovery frame of the appropriate multilink AP or MAP.

[0136] A member of a multilink AP or MAP may receive the probe request and may respond with a unicast or broadcast probe response or beacon, which may include a multilink capability element, a multilink operation element, a real-time capability element, or a real-time operation element to advertise its multilink and real-time support capabilities and operation parameters for its multilink and real-time traffic operation. MLDs and MAPs may not respond if the probe request includes parameters for real-time traffic or multilink operation requests that the MLD or MAP cannot support.

[0137] If a multilink non-AP STA device discovers a suitable multilink AP or MAP by inspecting received beacons, short beacons, FILS discovery frames, and / or probe responses, it may follow the supported security mode to establish security with the multilink AP or MAP. For example, the MLD may send an authentication frame request indicating that it is establishing multilink security, including the address of the master AP ID or virtual AP ID. If the receiving multilink AP or MAP member is not the master AP or AP representing the virtual AP ID, it may forward the authentication request to the master AP. The master AP or virtual AP may establish authentication and keys for each link in the multilink channel set. In another embodiment, authentication and keys may be the same for the links in the multilink channel set, which may be associated with the virtual AP ID and virtual STA ID. In another embodiment, authentication and keys may be established for the link on which the authentication request / response exchange occurs. Authentication and keys for the remainder of the multilink channel set may be established (for each of the links, or for the home / anchor / association link) when the multilink operating mode is set after association is performed and successful. In addition, the master AP may perform authentication for all member APs in the MAP. In another embodiment, authentication and keys may be established for the link between the master AP and the MLD or the link between the responding slave AP and the MLD on the link where the authentication request / response exchange occurs. Authentication and keys for the multilink channel set and the rest of the MAP set may be established when the multilink operating mode is set (for each of the links or for the home / anchor / association link) after association is performed and successful.

[0138] A multilink non-AP device may send an association request, which may include a virtual AP ID, to a multilink AP or MAP to request association with the AP or MAP. The association request may include a request for multilink operational parameters, such as the requested band, channel set, and channel, as well as real-time traffic specifications and parameters that need to be supported. The multilink AP or master AP at the MAP may evaluate the request and determine whether it can support the request. It may respond with an association response indicating the assigned channel set, assigned band, assigned channel aggregation mode, and the multilink operational mode of the STA. In one implementation, the association response is sent only on the channel on which the association request was received. The association response may indicate the BSSID and multilink color with which the STA should associate on the indicated band and indicated channel, along with one or more channels and channel widths for one or more bands.

[0139] The association response may include one association ID (AID) associated with the multilink non-AP STA device. The AID may be an ID assigned by the AP to the non-AP STA during association. The AID may be the same for all links operating on all multilink channel sets, may be associated with a virtual AP ID, or may be for a virtual STA ID. In one embodiment, the AID may simply be for a STA ID or may be associated with the BSSID of the AP operating on the link on which the association request / response exchange occurs. There may be additional AIDs assigned to STA IDs associated with the same multilink non-AP STA device operating on other links of the same multilink channel set.

[0140] FIG. 2 shows an example of a multilink discovery, association, and operation procedure. At 201, a non-AP multilink device (e.g., one or more logical STAs or WTRUs) may transmit a probe request including the non-AP multilink device's multilink capability information. The non-AP multilink device's multilink capability information may be in an element or subelement of the probe request. The probe request may be sent to one or more multilink AP (logical and / or physical) devices. At 202, one or more multilink APs may transmit a probe response indicating their multilink capabilities in response to the probe request. The probe response may include information about the capabilities of the one or more multilink APs. This information may also be a beacon. The beacon may have one or more multilink capability elements and / or subelements that include this information. This information may include the multilink capabilities of the one or more multilink APs and / or the operating parameters of the one or more multilink APs.

[0141] At 203, the non-AP multilink device may initiate multilink association on the association channel based on one or more pieces of multilink AP information. In one example, association may occur if the non-AP multilink device discovers at least one suitable multilink AP of one or more multilink APs based on the multilink AP information. At 204, the non-AP multilink device may negotiate multilink operation parameters for multiple links on a single link as part of the association or after association. At 205, the non-AP multilink device may perform multilink operation as negotiated (e.g., during association).

[0142] In another example similar to FIG. 2 , there may be a method implemented by a wireless transmit / receive unit (WTRU) multilink device (MLD) (e.g., a non-AP STA) for multilink communication. The WTRU MLD may send a probe request to an access point (AP) MLD (e.g., an AP STA), and the probe request may include an indication of the WTRU MLD's multilink capabilities. The WTRU MLD may receive a response to the probe request from the AP MLD, and the response may include AP MLD information, and the AP MLD information may include an indication of the AP's multilink capabilities and the AP MLD's multilink parameters. The WTRU MLD may then use the AP MLD information to initiate association with the AP MLD. Once associated, the WTRU MLD can communicate with the AP MLD or multiple AP MLDs over multiple links. Both the WTRU MLD and the AP MLD may have a logical entity (e.g., a physical layer) for each link of the multiple links. Both the WTRU MLD and the AP MLD may each have multiple MAC layers, one of which interfaces with the upper layer and one of which interfaces with each of the logical entity physical layers (e.g., lower MAC). In one or more instances, the response may be a beacon, and the beacon includes a capabilities element. In one or more instances, the capabilities element may include AP MLD information. In one or more instances, initiating may further include negotiating AP MLD multilink operation parameters based on the AP MLD information. In one or more instances, negotiating may occur over a single link.

[0143] Regarding the issue of dynamic feedback for load balancing and interference management, load balancing may be a multi-link application, and to optimally benefit from load balancing, the AP and STAs need to be aware of the interference as well as the real-time load for each of the available channels.

[0144] To address the above issues, there may be an efficient monitoring and feedback mechanism for the AP and STAs to exchange status regarding channel quality and interference. A multi-link AP device may periodically schedule sounding for all channels for STAs to perform channel measurements. Such sounding may be performed by transmitting short packets such as null data packets (NDP) frames. In one embodiment, sounding may also be performed by regular packets such as beacons, short beacons, or short FILS discovery frames.

[0145] A multi-link device may maintain the same Time Synchronization Function (TSF) timer for all its links.

[0146] A multilink AP device may advertise the schedule of its frames in its beacon, short beacon, FILS discovery frame, or other frame. For example, a multilink AP device may include an offset for its beacon, short beacon, or FILS discovery frame. The offset may use the same TSF timer for the channel or an individual TSF timer, and may be relative to the current target beacon transmit time (TBTT) or the target transmit time of the FILS discovery frame on the current channel.

[0147] A Multilink non-AP device may periodically measure the channel by using an offset or schedule for received sounding frames, FILS discovery frames, or other types of frames. If it measures the channel, it may provide feedback to the Multilink AP. The feedback may be triggered by a trigger frame by the Multilink AP.

[0148] For example, a multilink AP may transmit an NFRP frame triggering an NDP feedback report for multilink feedback. The NFRP may include a starting channel number and the number of channels to be fed back. In another embodiment, the NFRP may include a bitmap for the links to be fed back. A multilink non-AP device may transmit an NDP feedback report using multiple symbols, with each symbol representing a bit for feedback for a specific channel, corresponding to a request included in the NFRP frame. It may also transmit the NDP report on a different RU. For example, a bit associated with a specific RU may be a feedback report for a specific link or channel as requested by the NFRP frame.

[0149] In another embodiment, a multilink AP may request multilink feedback in an EHT control header as part of a PHY header or a MAC header. The EHT control header requesting multilink feedback may include a starting channel number and the number of channels to be fed back. In another embodiment, the request may include a bitmap of the links to be fed back. A multilink non-AP device may send a multilink feedback report in an EHT control field in a MAC header or a PHY header in a subsequent frame sent to the multilink AP.

[0150] In addition, a multilink AP may include a link activity indicator element in its beacon, short beacon, or FILS discovery frame. The link activity indicator may include activity details for each link in the multilink channel set. In one embodiment, the link activity indicator may be in the form of a bitmap. If the bit association with a link is indicated as "0," it means that the link may be considered saturated with traffic, while "1" may indicate that traffic may be light on that link and additional traffic may be added on that link. In another embodiment, more bits may be associated with each link in the multilink set, for example, two bits may be used to indicate the level of activity for a particular link. For example, "0" means very little activity on that link, "1" means some traffic on that link, "2" means heavy traffic on that link, and "3" means saturated traffic on that link. Multilink non-AP STAs may use the received link activity indicator to determine whether they want to move to another link to achieve better performance. The selection may be based on both the sounding results as well as the link activity indicator. It should be noted that the values provided herein are only examples, and any value may be used as long as it serves as an indication to achieve the same functionality as discussed herein, e.g., the value may be arbitrary, random, algorithmically determined, determined based on an identifier, continuous, pre-configured, or determined in real time, etc.

[0151] Such a link activity indicator may also be included in the MAC header, such as in the EHT A-Control field in the MAC header or PHY header. The inclusion of such a link activity indicator may be considered as a recommendation for the receiving STA to switch to one or more of the recommended links, such as links with light traffic. The decision by the STA may also be based on the channel quality sounding results as described above.

[0152] Control frames; Multilink feedback requests or responses may also be made through newly designed frames such as control frames, such as multilink feedback request or response frames.

[0153] A multilink feedback request or response may be made for the control / anchor / association channel or for all channels. A multilink feedback request or response may be made for any link on any channel for any other channel.

[0154] Regarding the issue of multi-link TX / RX operating mode adjustment, a WLAN device may be operating in different modes for transmitting and receiving depending on the current application and power level.

[0155] To address the above issues, a protocol may exist that allows STAs and APs to adjust TX and RX operating modes to support efficient and power-efficient operation. A multilink STA device may initiate a TX and RX operating mode change by sending a multilink operating mode change (OMC) request to a multilink AP. The request may be addressed to the master AP, a virtual AP, or one of the member APs of the MAP. It may be sent on the home / anchor / control channel or on any link. However, the request frame may be sent on the link that is functioning after the multilink operating mode change. The multilink operating mode change request may also be sent as part of an EHT control header in the MAC header or PHY header. A multilink STA may include one or more bitmaps indicating requested changes for link operation on different channels. One bitmap may be used for multiple active bands, or one or more bitmaps may be used per supported band. A "0" for a particular link or channel means that the channel or link is requested or remains inactive. A "1" for a particular link or channel means that the channel or link is requested to be activated or remains active. In another embodiment, the channel set number may be used to indicate a request to change to a new multilink channel set. In yet another embodiment, some links may be requested to be active by a multilink non-AP device, and the exact active link or channel may be determined by the multilink AP. A separate bitmap may be used for real-time simultaneous link / channel requests. In one embodiment, a bitmap for all members of a MAP may be included to indicate a request to switch to a different member AP in the MAP or a request to switch to another link on the same or a different member AP in the MAP.

[0156] A multi-link operational mode change request may be triggered by changes in the number of traffic streams, the number of active real-time traffic streams, the power level of the device, the interference level of one or more links, and / or traffic saturation for one or more links.

[0157] A member AP of the MAP may forward the request to the master AP. The multilink AP or master AP may respond with a multilink operational mode change response frame (i.e., it may occur through the member AP from which the request was received). The response may be addressed to the virtual STA ID or the STA that sent the request. It may be sent on the home / anchor / control channel or any link. However, the response frame may be sent on the link that is functioning after the multilink operational mode change. The multilink operational mode change response frame may also be sent as part of the EHT control header in the MAC header or PHY header. A multilink AP or master AP device may include one or more bitmaps to indicate assigned links or channels. One bitmap may be used for multiple active bands, or one or more bitmaps may be used for each supported band. A "0" for a particular link or channel means that the channel or link is not assigned or remains inactive. A "1" for a particular link or channel means that the channel or link is assigned to the multilink STA device or remains active. In another embodiment, a channel set number may be used to indicate the assignment of a new multilink channel set to a multilink STA device. In yet another embodiment, several links may be assigned to be active for a multilink non-AP device. A separate bitmap may be used for real-time simultaneous link / channel assignment. In one embodiment, a bitmap for all members of a MAP may be included to indicate a request to switch to a different member AP in the MAP, or a request to switch to another link on the same or a different member AP in the MAP.

[0158] A multilink AP device or master AP may initiate a multilink operational mode change by sending a multilink operational mode change (OMC) request to a multilink non-AP device (e.g., STA / WTRU). The request may be addressed to a virtual STA ID or a non-AP STA operating on that link. It may be sent on the home / anchor / control channel or any link. However, the request frame may be sent on the link that is functioning after the multilink operational mode change. The multilink operational mode change request may also be sent as part of an EHT control header in the MAC header or PHY header. A multilink AP may include one or more bitmaps to indicate requested changes for link operation on different channels. One bitmap may be used for multiple active bands, or one or more bitmaps may be used for each supported band. A "0" for a particular link or channel means that the channel or link is requested or remains inactive. A "1" for a particular link or channel means that the channel or link is requested to be activated or remains active. In another embodiment, a channel set number may be used to indicate a request to change to a new multilink channel set. In yet another embodiment, several links may be requested to be active by the multilink AP device. A separate bitmap may be used for real-time simultaneous link / channel assignment. In one embodiment, a bitmap for all members of a MAP may be included to indicate a request to switch to a different member AP in the MAP, or to switch to another link on the same or a different member AP in the MAP.

[0159] A multi-link operational mode change request may be triggered by changes in the number of traffic streams, the number of active real-time traffic streams, the power level of the device, the interference level of one or more links, and / or traffic saturation for one or more links.

[0160] The multilink STA device may respond with a multilink operational mode change response frame. The response may be addressed to the virtual AP ID or the AP that sent the request. It may be sent on the home / anchor / control channel or any link. However, the response frame may be sent on the link that is functioning after the multilink operational mode change. The multilink operational mode change response frame may also be sent as part of an EHT control header in the MAC header or PHY header. In one embodiment, the multilink operational mode change response frame sent by a multilink non-AP STA device may simply be an acknowledgment or rejection of the request by the master AP or virtual AP ID, or the AP that sent the request.

[0161] A multilink device may start using a new multilink operating mode only if it is acknowledged by the multilink AP and STAs.

[0162] Regarding the problem of multi-link non-AP device architecture, both the AP and the STA may be multi-link devices. In addition, there may be multiple APs in a multi-AP set (e.g., co-located with the AP multi-link device), where it is necessary to track the data flow through which STA / link packets are forwarded. This problem may be addressed by an efficient multi-link non-AP device architecture and an address protocol that ensures robust communication.

[0163] In one embodiment, a multilink non-AP STA device may be represented by a virtual STA ID that may be indicated by the device in its probe requests, association requests, or other types of control or management frames. The virtual STA ID may be used on all links to identify a multilink non-AP device. A multilink non-AP STA device operating on any link or channel may filter and receive packets addressed to the virtual STA ID along with the MAC address of the STA operating on that link or channel. A multilink STA or non-AP device may be associated with a virtual STA ID and assigned an AID, and may be identified as such on all links.

[0164] In one embodiment, a Multilink AP device may be represented by a virtual AP ID, which may be indicated in its probe response, association response, beacon or short beacon or FILS discovery frame, or other type of control or management frame. The virtual AP ID may be used on all links to identify the Multilink AP device. A Multilink AP device operating on any link or channel may filter and receive packets addressed to the virtual AP ID as well as the MAC address of the AP operating on that link or channel. A Multilink AP device may be assigned an AID associated with the virtual AP ID and may be identified as such on all links by all member APs in the MAP.

[0165] In one embodiment, all multilink AP devices belonging to the same multi-AP set may be represented by a virtual AP ID, which may be indicated by one or more devices in their probe responses, association responses, beacons or short beacons, or FILS discovery frames, or other types of control or management frames. The virtual AP ID may be used on all links to identify the multi-AP set of multilink APs. Any multilink AP device in the multi-AP set operating on any link or channel may filter and receive packets assigned to the virtual AP ID and / or the MAC addresses of that AP or all APs operating on that link or channel. In one embodiment, multilink STA devices associated with the multi-AP set may be assigned a single AID associated with the virtual AP ID and may be identified as such on all links by all member APs in the MAP. In one embodiment, multilink STA devices may be assigned an AID having two parts: one part common to all links and a link-specific part that can identify the link or APs operating on that link.

[0166] Packets transmitted to a multilink STA device may include a virtual STA ID. In one embodiment, frames transmitted to a multilink STA device may have a destination address (DA) or receiving address (RA) set to the virtual STA. In one embodiment, packets transmitted to a multilink STA device may have the RA address set to the MAC address of the STA operating on that link or channel and the DA address set to the virtual STA ID. The BSSID may be set to the virtual AP ID or the BSSID of the transmitting AP operating on that link. In one embodiment, a multilink STA device may be assigned an AID having two or three parts, one part common to all links or all member APs in a MAP, a second part a link-specific part that can identify the link or APs operating on that link, and a third part that can identify a specific member AP.

[0167] A multilink STA device may respond, for example, with a traffic indication map indication or a null data packet (NDP) feedback report poll, or any other AID scheme, when one of the following situations may occur:

[0168] The indicated AID may be equal to the AID assigned to the multilink STA device.

[0169] The indicated AID may be equal to the common AID portion, and the derived frame may indicate a virtual AP ID.

[0170] The indicated AID may be equal to a combination of the assigned common AID portion and the assigned link-specific AID portion, and the derived frame may indicate a virtual AP ID or a BSSID that is specific to the AP operating on the appropriate link and on which the derived frame is received.

[0171] The indicated AID may be equal to a combination of an assigned link-specific AID portion and an assigned member AP-specific AID portion together with an assigned common AID portion, and the derived frame may indicate a virtual AP ID or a BSSID that is specific to an AP operating on the appropriate link on which the derived frame is received, and / or the derived frame may indicate a virtual AP ID or a BSSID that is specific to a member AP of the MAP.

[0172] Packets, such as data packets, transmitted by a multilink STA device may include a virtual STA ID that identifies a multilink non-AP STA device. In one embodiment, a frame, such as a data frame, transmitted to a multilink STA device may have the Address 3 field or Address 4 field set to the virtual STA ID. The MAC or PHY header of the frame may also carry an indication that it is a multilink packet and may carry the virtual STA ID. In one embodiment, a packet transmitted to a multilink STA device may have the RA Address or Address 1 field set to the MAC address of the STA operating on that link or channel and the Address 3 field set to the virtual STA ID. The Address 2 field may be set to a virtual AP ID or the BSSID of the transmitting AP operating on that link. In addition, the Address 3 field may be set to the virtual AP ID. Alternatively or additionally, the BSS Color field in the PHY header may be set to Multilink BSS Color, Multilink Multi-AP BSS Color, or Multi-AP BSS Color to indicate that the transmitted packet is a Multilink Addressed PPDU, Multilink Multi-AP PPDU, or Multi-AP PPDU. A STA may filter and set its NAV based on multi-link, multi-AP, or multi-AP multi-link BSS color.

[0173] Packets transmitted to a multilink STA device may include a virtual STA ID. In one embodiment, a frame transmitted to a multilink STA device may have the DA address, RA address, or Address 1 set to the virtual STA ID. In one embodiment, a packet transmitted to a multilink STA device may have the RA address or Address 1 set to the MAC address of the STA operating on that link or channel, and the DA address set to the virtual STA ID. The BSSID or Address 2 field may be set to the virtual AP ID or the BSSID of the transmitting AP operating on that link. Packets transmitted to a multilink STA device may include the BSSID or MAC address of the transmitting AP on that link or in a multi-AP BS in the Address 2 field and the virtual AP ID in the Address 3 field. Packets specifically targeted to a STA of a multilink STA device operating on a particular link may be identified by including the MAC address of the STA (e.g., in the RA Address or Address 1 field). The source address in a downlink packet may be set to the virtual AP ID if the frame is initiated by the master AP. The source address field may be set to the MAC address of the AP operating on the link if it is link specific and not initiated by the master AP.

[0174] Packets sent to a Multilink AP device may include a virtual AP ID. In one embodiment, frames sent to a Multilink AP device may have the DA Address, RA Address, or Address 1 field set to the virtual AP ID. In one embodiment, packets sent to a Multilink AP device may have the RA Address or Address 1 field set to the MAC address of the AP operating on that link or channel, and the DA Address or Address 3 field set to the virtual AP ID. The BSSID or Address 3 field may be set to the virtual AP ID or the BSSID of the AP operating on that link. The TA Address or Address 2 field may be set to the virtual STA ID of the transmitting non-AP STA. Packets specifically targeted to an AP of a Multilink AP device operating on a particular link may be identified, for example, by including the MAC address of the AP in the RA Address field. The source address in an uplink packet may be set to the virtual AP ID if the frame is meant to be forwarded to the master AP or DS. The source address field may be set to the MAC address of the AP operating on that link if it is link-specific and not meant to be sent to the master AP or DS.

[0175] In another embodiment, both the To DS field and the From DS field may be set to 1 so that Address 4 can be used by EHT STAs to recognize that the transmitted packet is a Multilink packet. In a Multilink packet to a non-AP STA, Address 1 may be set to the MAC ID of the receiving STA on that link or channel, Address 2 may be set to the virtual AP STA or the MAC address of the transmitting AP on that link or channel, Address 4 may be set to the virtual AP ID, and Address 3 may be set to the virtual STA ID. In a Multilink packet to an AP, Address 1 may be set to the MAC ID of the receiving AP on that link or channel, Address 2 may be set to the virtual STA ID or the MAC address of the transmitting STA on that link or channel, Address 3 may be set to the virtual AP ID, and Address 4 may be set to the virtual STA ID.

[0176] When the receiving STA or AP receives a multilink packet, which may be indicated by an indication in the PHY header or MAC header, which may be one specific bit, or which may be by a "To DS" bit or a "From DS" bit, the receiving STA or AP may interpret the address field as described above.

[0177] Regarding the issue of multi-link MAC architecture, if a multi-link device has multiple subordinate MAC SAPs with one single MAC SAP going to / coming from the DS, further design may be required to facilitate the disclosed architecture to enable correct multi-link operation.

[0178] Figure 3A is a diagram of an example 802.11 legacy MAC architecture. Figure 3B is a diagram of an example multi-link MAC architecture. Figure 3C is a diagram of a multi-link GLKMAC architecture. Like numbers correspond to like elements throughout Figures 3A, 3B, and 3C.

[0179] In FIG. 3A, existing 802.11 and 802.1 architectures generally have several concepts regarding protocol entities, peers, layers, services, and clients. Within those concepts, there exists the practice of infinite stacking of protocol entities. In the illustrated embodiment, STA 310 may communicate over wireless media 304 to AP 320A via a single link 307. Each entity may have an uncontrolled (U) port and a controlled (C) port. Generally, the flow of data through various layers is shown as it travels to / from AP 320A and to / from DS 336 to STA 310A. In relevant part, legacy configurations may have a single MAC 312 and PHY 313 for STA 310A, and similarly, AP 320A may have a single MAC 322 and PHY 323.

[0180] Considering Figure 3A, to address multi-link approaches (e.g., links 307A, 307B, and 307C), there may be multiple lower MAC SAPs below the upper MAC SAP that collectively act as a device MAC function layer for the multi-link scenario, as shown in Figure 3B. The introduction of this additional layer (e.g., lower MAC) can bring new / improved and / or additional sets of peer, layer functions, and services to its clients. Thus, as described herein, a peer set of MAC SAPs may exist to address the above issues.

[0181] In an AP such as multi-link AP 320B, there may be an upper MAC SAP (e.g., upper MAC SAP 312U) that can be between the DSs (e.g., collectively 335 and 336), or an IEEE 802.1x layer 321 that can be just below the DSs, and multiple single link MAC SAPs 322LC, 322LB, 322LA, each with its own PHY layer (e.g., PHY1 323A, PHY2 323B, PHY3 323C) that necessarily creates an individual logical AP for each link (e.g., links 307A, 307B, and 307C). To the DS, this upper MAC SAP can appear to be a standard 802.11 MAC SAP and provide all 802.11 expected services to the DS, and the DS can similarly provide all existing 802.11 expected services to this upper MAC SAP. In addition to the currently defined services, there may be additional services discussed herein that can be provided by the Upper MAC SAP.

[0182] In a non-AP STA, such as multi-link STA 310B, there may be a peer upper MAC SAP 312U that may also reside below the LLC layer or below the 802.1X layer 311, as well as above multiple single link MAC SAPs 312LA, 312LB, and 312LC (e.g., again each with their own PHY layers PHY1 313A, PHY2 313B, PHY3 313C).

[0183] The MAC services provided by the upper MAC layer (e.g., 312U and / or 322U) may include all of the services provided by any legacy 802.11 MAC services and may also provide additional services that optimize the transmission of frames over multiple 802.11 single links. These additional services may include additional A-MAC Service Data Unit (MSDU) aggregation / de-aggregation capabilities, additional fragmentation / defragmentation capabilities, sequence number allocation services, PS deferral queuing and routing services, packet number allocation, and other services as disclosed herein.

[0184] Regarding the issue of multilink design and 802.11ak MAC architecture, in some situations, 802.11ak can replace DSs (e.g., 335 and 336) with direct links to 802.1 switches (e.g., 340), which manage data flow over the 802.11 links. FIG. 3C is a diagram of an example multilink generic link (GLK) architecture (e.g., 802.11ak). As illustrated in FIG. 3B, the multilink architecture can introduce an additional MAC SAP layer to address multilink scenarios, and the manner in which 802.11ak operates and how this impacts the requirements for upper MAC SAPs that map / manage data flow to / from lower MAC SAPs may need to be addressed in consideration of how this issue is approached. In particular, there may be multilink channel feedback procedures for load balancing and optimal interference control as disclosed herein.

[0185] The roles of the upper MAC SAPs (e.g., 311 and 321) in the 802.11ak MAC architecture shown in FIG. 3C may be similar and / or identical to those in the non-802.11ak MAC architecture of FIG. 3B. The upper MAC may provide the functionality of the legacy 802.11 MAC SAP for the GLK link and a MAC SAP that provides services. As shown in FIG. 3C, there may be two possible direct links 351 and 352 that run throughout the overall architecture; they can be independent and need not both be present. Link 351 line indicates a link connecting two LLC sublayers (e.g., 341B-341D), and link 352 line indicates a link connecting two 802.1Q MAC relay entities (e.g., 341A-341C). Both of them may be peer-to-peer links 351 and 352, and may use multiple 802.11 MAC / PHY links (e.g., 307A, 307B, 307C, etc.) to provide the wireless interconnect portion of the links.

[0186] Regarding the issue of multilink acknowledgment for fragmented packets in a multilink, multi-AP environment, each packet transmitted by a particular AP on a particular link may be fragmented into several fragments. If an acknowledgment (e.g., BA) needs to be transmitted on different links that may be associated with different APs, the receiving AP may not know the number of fragments transmitted. An acknowledgment protocol may need to be designed to ensure that fragmented transmissions can be accurately acknowledged. For example, in the current ACK and Block ACK for 11ax, MAC Protocol Data Units (MPDUs) for fragmentation levels 1-3, when received by different APs, cannot convey how many fragments are in the MPDU and whether all fragments are received. Additionally, there is a need to address scenarios where fragments are missed, such as a protocol for APs to communicate retransmissions of missed fragments.

[0187] In one scenario, there may be a multilink acknowledgment for fragmented packets that may include methods for processing MSDUs, and these methods may also be applicable to MMPDUs when describing MSDUs. For illustrative purposes, in this scenario, there may be multiple uncontrolled APs, each of which may transmit MPDUs from the same traffic ID (TID) to the same non-AP STA. The APs may operate on different channels or different bands. MSDUs to non-AP STAs may be received at each forwarding AP from a central entity. The central entity may maintain an originator scoreboard for TIDs to perform retransmission of reported missing MPDUs based on a status indication from the forwarding AP that receives a Block ACK (BA) bitmap or ACK sent from the non-AP STA. As discussed herein, this central entity may be referred to as an anchor AP. Different forwarding APs may appear to non-AP STAs to have the same or different MAC addresses. In the case of different MAC addresses in different forwarding APs, non-AP STAs may treat the sequence numbers of MPDUs from different APs as being from the same sequence number space.

[0188] The anchor AP may maintain a record of which APs forward which MSDUs (i.e., the forwarding APs of an MSDU). There may be more than one forwarding AP for an MSDUn at the same time if the anchor AP wishes to reduce delay and / or increase the reliability of the MSDUn.

[0189] A status indication may be generated from the forwarding AP of the MSDUn to the anchor AP. The indication may identify the success / failure of the MSDUn (fragment). The indication may indicate that the forwarding AP of the MSDUn does not buffer the MSDUn for transmission due to acknowledgment or (repeated) failure of the MSDUn. The status indication may be generated by an AP that is not the forwarding AP of the MSDUn, but the AP generates the indication based on the BA bitmap received from the non-AP STA. The status indication may include a refragmentation indication, described below, that identifies bitmaps from different fragmentation instances (e.g., fragmentation is performed differently in different fragmentation instances). The status indication when generated by the forwarding AP may include a fragmentation pointer, described below, so that the anchor AP can instruct different forwarding APs to perform the same fragmentation of the MSDUn.

[0190] A flush indication may be generated from the anchor AP to the forwarding AP of the MSDUn to identify the MSDUn(fragment) and flush the buffered MSDUn(fragment) at the forwarding AP. This indication may be generated by the anchor AP because it has received an acknowledgment for the MSDUn (from another AP) or because the anchor AP wants to retransmit the MSDUn(fragment) from another AP that is not currently the forwarding AP of the MSDUn.

[0191] Timer x may be started in the anchor AP when it forwards MSDUn to the forwarding AP. When the timer expires, the anchor AP may send a flush indication to the forwarding AP of MSDUn to flush any buffered MSDUn (fragments).

[0192] Timer x may be started in both the anchor AP and the forwarding AP of MSDUn when the anchor forwards MSDUn to the forwarding AP. When timer x expires, the forwarding AP may flush the buffered MSDUn (fragments) without a flush indication from the anchor AP.

[0193] Within the duration of timer x, the forwarding AP of MSDUn may not flush the buffer of MSDUn until it receives a flush indication for MSDUn from the anchor AP.

[0194] Each forwarding AP may have an independent CSMA / CA and may perform several retransmissions. When a status indication identifying a missing MSDUn (fragment) is received from APy, but MSDUn has still been forwarded to APx for transmission, the anchor AP may wait for timer x to expire before it initiates a retransmission of MSDUn (fragment), where timer x starts when MSDUn is forwarded to APx. Alternatively, the anchor AP may wait for a status indication from APx indicating a flush of MSDUn before it initiates a retransmission of MSDUn (fragment).

[0195] In one scenario, fragmentation may be prohibited. In this scenario, the same MSDUn may be transmitted by different APs. When setting up a Block Ack agreement, the originator (AP) may send an ADDBA request frame indicating no fragmentation by setting the "no fragmentation" field to 1 in the Add BLOCK Acknowledgement Extension element. For TIDs without a Block Ack agreement, fragmentation of the MSDU may be prohibited at the transmitter. Alternatively, retransmissions of the MSDU may be fragmented. Based on "More Fragments" = 0 and (Fragment Number) FN = 0, non-AP STAs may correctly receive retransmissions of the MSDU and discard previously received fragments of the MSDU.

[0196] In one scenario, retransmissions / duplicate transmissions may be commanded to be sent from the same AP. In this manner, fragmentation of MSDUs may be allowed. In one case, all MSDUs from the same TID to the same non-AP STA may be forwarded to the same AP for transmission. In this case, an originator scoreboard may be maintained by the transmitting / forwarding AP for the TID.

[0197] When the anchor AP receives a status indication indicating a missing MSDUn or fragment(s) of the MSDUn, it may send a retransmit indication identifying the MSDUn (fragment) to the previous forwarding AP of the MSDUn. The status indication may be generated by an AP that is not the forwarding AP of the MSDUn. The same fragments of the original transmission may be retransmitted from the same forwarding AP.

[0198] In one scenario, missing fragments may be identified. There may be three levels in 11ax dynamic fragmentation. In level 1 or 2, there may be at most one fragment of the same MSDU in a PSDU. In the acknowledgment in level 1 or 2 methods, the success / failure status of each fragment may not be identified because the originator implicitly knows the status of the transmitted fragments corresponding to the status of the MPDU signaled in the acknowledgment.

[0199] In a non-colocated multi-AP environment, if a Level 1 or 2 mechanism is used, and if the MSDUn status indication is received from an AP that is not the MSDUn forwarding AP, the anchor AP may not be able to identify the missing fragments, and the overall success / failure status of the MSDUn may be based on the indication. Only the MSDUn forwarding AP knows how to interpret the acknowledgment. To address this situation, an acknowledgment such as a Level 3 bitmap (e.g., k bits per MSDU) may be used.

[0200] In 802.11ax Level 3 acknowledgments, bits in the bitmap corresponding to received fragments are set to 1, otherwise the bits are set to 0. With this mechanism, when receiving a status indication from an AP that is not the forwarding AP for MSDUn, the anchor AP is unable to identify missing fragments and the overall success / failure status of MSDUn based on the indication because the anchor AP does not know how many fragments the forwarding AP sent for the MPDU. For example, if the maximum fragments allowed per MSDU k=4, and the bitmap for MSDUn=1110, the anchor AP may not know whether MSDUn has three fragments and whether all have been received, or if MSDUn has four fragments, that the first three have been received.

[0201] To address this issue, the bitmap generation can be revised when the receiver receives the last fragment or only fragments. The bit positions for the same MPDU following the bit position of the last fragment may be set to 1. For example, in Table 1, k may be equal to 4.

[0202] [Table 1]

[0203] In this way, the anchor AP can know whether to generate a retransmission indication to the forwarding AP of the MSDUn. If an indication is generated, the missing FN may be either explicitly identified to the forwarding AP (e.g., FN=0, FN=1 in row "0011") or implicitly identified (e.g., FN>=2 in row "1100").

[0204] In one case, the same fragmentation may exist in multiple APs. Multiple forwarding APs of MSDUn may use the same fragmentation. The status indication may indicate a fragment pointer to the anchor AP, which may include the starting octet length of each fragment and the number of fragments. The anchor AP may allocate additional forwarding APs of MSDUn to replace the most recent forwarding AP, or may allocate a new forwarding AP of MSDUn. The allocation may include the fragment pointer. In this case, a retransmission from another (i.e., new) forwarding AP may include only the missing fragments not delivered by the original (i.e., old) forwarding AP. Alternatively, the fragment pointer may be communicated directly from the original forwarding AP of MSDUn to the new / additional forwarding AP of MSDUn.

[0205] In one example, when an MSDUn is forwarded to a forwarding AP, the fragment pointer is determined by the anchor AP and indicated to each forwarding AP of the MSDUn. In this case, fragment transmission may be performed simultaneously or independently by all forwarding APs of the MSDUn. The BA bitmap can be understood by all forwarding APs of the MSDUn, regardless of the number of retransmissions performed independently.

[0206] In one case, there may be refragmentation and / or different fragmentation in the new / additional Forwarding AP. The assigned new / additional Forwarding AP of MSDUn may not need to recognize fragment pointers from the original / old Forwarding AP. The additional / new Forwarding AP of MPDUn may perform different fragmentation. Each Forwarding AP may explicitly or implicitly include a refragmentation indication in the MPDU or Block Ack Request (BAR).

[0207] If different forwarding APs have different MAC addresses, the implicit refragmentation indication may be based on the MAC address of the forwarding AP. Fragments of the same MPDUn from different TAs may require separate buffers for reassembly at non-AP STAs. The RA in the ACK / BA can identify which forwarding AP's fragments the non-AP STAs should acknowledge.

[0208] An explicit refragmentation indication may be included in the MPDU, BAR, and BA. The indication may be a number where a larger / smaller number can mean a more immediate fragmentation / transmission of the MSDUn.

[0209] When a non-AP STA receives an MPDU that is a fragment of an MSDUn, it may take one or more actions: it may maintain a different reassembly buffer for the MSDUn for each refragmentation indication, and / or it may maintain only a reassembly buffer for the most recent refragmentation indication of the MSDUn, and fragments with older fragmentation indication(s) may be flushed.

[0210] A BA sent from a non-AP STA may include a corresponding refragmentation indication mapped to the refragmentation indication of the MPDU it acknowledges.

[0211] Alternatively, the channel / band or non-MAC address identifier of the AP from which the MPDU is received or to which the BA is transmitted may serve as an implicit refragmentation indication. For example, for a non-AP STA, identical MPDUs received from different APs or on different channels are not guaranteed to have identical fragmentation and may be reassembled independently.

[0212] In one case, a refragmentation indication may be present in an MPDU or BAR, as shown in the example of Figure 4. As shown, the sequence control field of the MPDU may include a fragment number (FN) 402 (e.g., B0-B3) and a sequence number (SN) 403 (e.g., B4-B15). The most significant bit (MSB) of the FN 402 field may be used as the refragmentation indication, as shown as the shaded bit 404. For example, if there is a maximum of 4 fragments per MSDU allowed, the 2 MSBs (e.g., B2 and B3) of the FN field (e.g., ≡ 0) may be used as a refragmentation indication. The refragmentation indication may be incremented / decremented for each new / additional forwarding AP in MSDUn. The value of this indication may be assigned by the anchor AP. For example, in the original transmission from forwarding AP x, the MSDU is fragmented into 3 fragments. The 2 MSBs (e.g., B2 and B3) of the FN field may be set to 00 and the 2 LSBs may be set as 00-10 for FN=0-2. For transmission, an MSDU may be fragmented into two fragments. The two MSBs of the FN field may be set as 01, and the two LSBs may be set as 00-01 for FN=0-1. The receiver may not use fragments from different refragmentation indications to reassemble the MSDU. For the above example, when the receiver receives an MPDU with a newer refragmentation indication=01 and SN=n, it may discard buffered fragments with refragmentation indication=00 and SN (sequence number)=n that cannot be reassembled into an MSDU.

[0213] In one case, there may be a refragmentation indication in the Block Ack. To signal the value of the refragmentation indication, a reserved bit in the BA control field, a reserved value in the TID_INFO, the FN subfield, the Per AID TID Info subfield, or a combination of these reserved fields / values may be used. The value may not be identical to the value of the refragmentation indication in the corresponding MPDU or BAR, but the value signaled in the MPDU / BAR and the value signaled in the BA may have a one-to-one mapping, so that the (anchor) AP can accurately interpret the reception status of the indicated refragmentation instance.

[0214] Regarding packet number (PN) assignment, in a multi-link multi-AP environment, each packet transmitted by a particular AP may need to be assigned a packet number that will be used for the encryption algorithm. Generally, if different APs use the same key, packet numbers should not be repeated. The problem rephrased may be how to design a packet assignment protocol to ensure that packet numbers are not repeated by APs in the same multi-AP set that use the same key.

[0215] In one case, a different key may be used on each AP. If different forwarding APs appear to non-AP STAs to have different MAC addresses, reusing an existing Transient Key (TK) generation can generate a different TK for each forwarding AP. This can avoid the problem of APs sending different MPDUs assigning the same PN to non-AP STAs.

[0216] During the four-way handshake, the MAC address of the forwarding AP' may be provided to the supplicant (e.g., a non-AP STA). For example, the address may be indicated in a first message from the authenticator (e.g., an AP) to the supplicant (e.g., a STA).

[0217] Alternatively, an additional input may be added to the pseudorandom function (PRF) corresponding to the index (i) of the forwarding AP. Figure 5 is a diagram of an example PTK derivation. In this example, the index i corresponding to the forwarding AP may be concatenated with the current B parameter of the PRF-Length(K, A, B), for example, and used to derive the pairwise TK (PTK) 503 of the forwarding AP from the Pairwise Master Key (PMK) 501, where B = Min(AA, SPA) || Max(AA, SPA) || Min(ANonce, SNonce) || Max(ANonce, SNonce) || i. In this alternative, the authenticator may indicate the maximum number of PTKs to be derived (i.e., the range of i) prior to key derivation. The anchor AP may then assign the forwarding AP corresponding to index i. The PTK 503 may be used to determine the EAPOL-Key 504, EAPOL-Key 505, and Temporal Key 506. PTK 503 is a concatenation of EAPOL-Key 504, EAPOL-Key 505, and Temporal Key 506. EAPOL-Key 504 is used to provide data origin authenticity in 4-way handshake and group key handshake messages, EAPOL-Key 505 is used to provide data confidentiality in 4-way handshake and group key handshake messages, and Temporal Key 506 is used to protect individually addressed communications between the AP and STAs outside of 4-way handshake and group key handshake messages.

[0218] In some cases, the same key may be used on each AP. Some scenarios may prohibit fragmentation or may use fragmentation in a particular manner. For example, fragmentation may not be allowed in the forwarding AP of MSDUn. Alternatively, methods related to fragmentation across multiple STAs / APs as described herein may be used so that the forwarding AP of MSDUn does not need to fragment MSDUs. In either scenario, the anchor AP may assign packet numbers (PNs) such that there is a one-to-one mapping between MSDUs and MPDUs.

[0219] In one scenario, there may be a partitioned PN space based on the maximum number of forwarding APs. PN assignment may be hierarchical. The anchor AP may determine a subset of bits based on the maximum number of forwarding APs, and each forwarding AP may independently assign the remaining bits. For example, if there are four forwarding APs, the anchor AP may assign the two MSBs of PNs 00-11 to each of the APs. Each AP then independently generates the LSB of the PN. In this example, three PNs are generated by the same forwarding AP of an MSDU, where an MSDUn is fragmented into three MPDUs. The three PNs have two common MSBs and different LSBs. PNs generated at different forwarding APs may have different two MSBs but the same LSB.

[0220] In one scenario, the PN space may be partitioned based on the maximum number of fragments. PNs may be generated by the anchor AP at intervals equal to the maximum number of fragments allowed for non-AP STAs. For example, if the maximum number of fragments allowed is 4, when the anchor AP forwards MSDUn to forwarding APx, it may also have PNx, where PNx%4=0 (PNx Mod4 equals zero). The actual PN contained in the MPDU is PNn+FN, where FN is the fragmentation number of the MSDUn fragment. When the anchor AP forwards an MSDU to an additional forwarding APy of MSDUn, a new PN=PN may be generated for the same MSDUn, where PNy%4=0.

[0221] In one scenario, there may be variation in the nonce without partitioning the PN space. In this alternative, the values of the nonce field may be partitioned into separate sets. Nonce fields for different security protocols may be shown in FIGS. 6 and 7. FIG. 6 is a diagram of an example nonce field in a counter mode CBC-MAC protocol (CCMP), which may include a nonce flag 611, a STA MAC address 612 identified by A2, and / or a PN 613. Each octet 601 of bits may represent 8 bits, and a nonce flag 611 (e.g., O1) may represent four priority bits 621 (e.g., B0-B3), one management bit 622 (e.g., B4), one PN1 bit 623 (e.g., B5), and / or two zeros 624 (e.g., B6 and B7). FIG. 7 is a diagram of an example nonce for a Galois / Counter Mode Protocol (GCMP), which may include A2 711 and a PN 712.

[0222] The PN may be assigned by the forwarding AP, and the PN is generated independently by each forwarding AP without partitioning the number space. If different forwarding APs have different MAC addresses, the uniqueness of the nonce is guaranteed. If different forwarding APs have the same MAC address (A2), the non-AP STA and the forwarding AP may use the forwarding AP index, which can be mapped to the channel / band of the PPDU. For example, A2 may be used to construct the nonce = original A2 + AP index.

[0223] The PN may be assigned by the anchor AP, and the PN is generated by the anchor AP without considering the number of fragments generated at the forwarding AP (e.g., incremented by 1 for each MSDU). A new PN may be generated for retransmission of an MSDU to a different forwarding AP. Non-AP STAs and forwarding APs may use the FN to modify the A2 field (e.g., A2 may be used to construct nonce = original A2 + FN).

[0224] With regard to fragmentation across multiple STAs / APs, current fragmentation designs may not be sufficient to improve data flow balance across available links, improve latency, and improve reliability. In other words, the question is how to design more efficient fragmentation in other parts of the multi-link MAC architecture.

[0225] In one case, fragmentation may exist across multiple STAs / APs. The upper MAC layer may manage data flow to / from the lower MAC SAP before it, and if it does so, the peer upper MAC layer may also manage data flow to / from the lower MAC SAP before it. Data flow management may include packet fragmentation, packet aggregation, multi-packet encoding / decoding, packet redundancy, packet retransmission, fragment retransmission, fragmentation of aggregated packets for retransmission, ACK management, block ACK management, HARQ management, and data management functions. These capabilities may be used to improve data flow balance over available links (e.g., each link may be managed to provide a data rate consistent with the link conditions and radio load for the channel), increase effective data flow rate (i.e., enhanced throughput), reduce latency, and / or increase transmission reliability (fragmentation may include some redundancy).

[0226] In one scenario, there can be improved data flow balance. The upper MAC can be aware of the throughput and latency of all the individual lower MACs it manages based on their performance. In addition, WLAN radio measurements for each individual upper MAC may be available. This information can be used by the upper MAC to distribute data flows across each available link, improving the overall performance of a multi-link link (e.g., an effective link formed by combining multiple links). The upper MAC can optimize the link for one particular metric or a combination of metrics, such as data rate, latency, reliability, or any other performance metric. This can be done dynamically to manage the link (e.g., individual link loads) based on real-time or near-real-time link information, based on longer-term performance averages, or based on any other combination of performance metrics.

[0227] In one scenario, effective data flow can be increased. The effective data flow through the multilink links can combine the throughput of the individual links to generate an effective bandwidth much greater than that of either individual link. Current broadband 802.11 links rely on broadband channels (e.g., 80, 160 MHz) to provide high throughput. However, these broadband channels can have issues with narrowband traffic (e.g., 20 MHz) sharing portions of these broadband channels, resulting in packet loss or packet delay, so various MAC methods (e.g., overhead) are employed to ensure coexistence of the narrowband and broadband channels. While multiple channels can be combined to enable broadband throughput data rates, aggregation of channels via multilink does not require all channels to be cleared for simultaneous transmission. Additionally, multilink can enable the ability to combine links that do not use channels in the same band (2.4 GHz, 5 GHz, or 6 GHz). This can allow multi-link devices to significantly increase effective channel bandwidth, thus enabling throughput capabilities beyond the currently permitted 20, 40, 60, 80, or 160 MHz bandwidths. For example, the effective channel bandwidth could consist of two 20-megahertz channels in the 2.4 gigahertz band, three 80-megahertz channels in the 5 gigahertz band, and a 40-megahertz channel in the 6 gigahertz band, resulting in an effective bandwidth of 400 megahertz. In addition to the ability to combine these channel resources into a wide effective bandwidth, each channel can be optimized based on wireless link performance and link availability, thereby enabling optimization of the entire network while still achieving desired throughput targets.

[0228] In one scenario, latency can be reduced. The MAC disclosed herein can also optimize overall link performance with respect to latency. Because 802.11 uses contention-based channel access, access to any given resource can be delayed depending on which resource is in use. If data transmission relies on a single link for transmission, the transmission delay depends on a single channel contention mechanism. However, when multilink is used, channel contention is distributed across multiple channels, with each channel having its own channel contention mechanism. This distribution across multiple channels can have the effect of reducing latency, since data can be transmitted on whichever channel is first available. The next packet can then be transmitted on any available channel, and so on, which statistically reduces the latency for transmission.

[0229] In one scenario, reliability can be increased. The upper MAC can also optimize the overall link performance for reliability. This can be achieved by sending redundant packets over multiple links and combining the received packets at the MAC. Also, packets can be coded so that portions of the packet are sent over multiple links and then the coded and received packets are combined to increase the reliability of the multi-link link.

[0230] Regarding the issue of multi-link acknowledgment, WLAN devices may be operating on different links for transmission. To reduce signaling overhead and provide a flexible and low-latency feedback mechanism, acknowledgments for previous transmissions over multiple links or aggregated acknowledgments may be used. To address this issue, there may be detailed procedures for negotiating data transmissions and acknowledgments over multiple links, such as a multi-link acknowledgment procedure.

[0231] With multi-link transmission, a STA capable of operating on more than one link (i.e., a multi-link capable STA) may communicate with another multi-link capable STA through more than one link. As discussed herein, a link may refer to a band or a channel. In one architecture, a multi-link capable STA may have a unique MAC address across multiple links. Transmissions over multiple links may share the same sequence number space, so that a receiver may be able to order packets received from different links. In one embodiment, data transmissions and acknowledgments may be for different links. Alternatively, data transmissions may be carried on N links and acknowledgments may be carried on M links.

[0232] The STA and AP may exchange their multilink acknowledgment capabilities using management / control frames, such as probe request, probe response, beacon, association, and / or reassociation frames.

[0233] In one case, there may be a multilink delayed block acknowledgment (ACK). To enable multilink acknowledgment, a need exists for a modified approach to Block ACK negotiation and procedures. Figure 8 is a diagram of an example procedure with delayed Block ACK.

[0234] 8, a first STA, such as STA 801, may initiate a Block ACK negotiation with a second STA, such as STA 802. STA 801 may acquire a channel on link 810 and may send a Multilink (ML) Add Block ACK (ADDBA) Request frame at 811 to STA 802. In the ML ADDBA Req frame, STA 801 may include the Multilink negotiation, sequence_space, TID settings, buffer_size, and / or other relevant information disclosed herein.

[0235] The buffer_size is a subfield that can be used for buffer size negotiation between the transmitting STA(s) and the receiving STA(s). In one method, the transmitting STA(s) and the receiving STA(s) may negotiate the buffer size for each link. A link index may be used for this negotiation. The STA may maintain a buffer for each link. Each link may have a different buffer size. In one method, the transmitting STA(s) and the receiving STA(s) may negotiate the total buffer size for all available operational links. The STA may maintain a buffer for all links.

[0236] sequence_space is a subfield that can indicate whether the same sequence space can be used for multiple links. In the case where multiple sequence spaces can be used for multiple links, a link index may be used along with the sequence number to assemble the packet.

[0237] The multilink negotiation subfield may be one or more pieces of information such as: acknowledgement_link; ACK_in_different_link; multilink ACK / BA aggregation; cross_link_fragmentation; and / or operating_link.

[0238] The acknowledgement_link subfield may indicate whether an acknowledgement can be sent on that link. In one method, a link bitmap may be used. For example, a receiving STA may operate on N links, and the bitmap may carry N bits. Each bit may indicate whether the corresponding link can be used to send the acknowledgement(s). In one method, a link index may be explicitly carried to indicate the corresponding link(s) that can be used to send the acknowledgement. A special link index may be used to indicate that all of the links can be used.

[0239] ACK_in_different_link is a subfield that can indicate an acknowledgment that can be sent on a link different from the data link. In one way, if this is signaled, STA2 may be allowed to send a Block ACK on a link that can be more readily available than the rest of the links.

[0240] Multilink ACK / BA Aggregation is a subfield that can indicate whether multilink aggregation ACK / BA is allowed, where multilink aggregation ACK / BA is a procedure that allows an ACK / BA sent on link k to indicate data transmission on links (L1...LM).

[0241] Cross_link_fragmentation is a subfield that can indicate whether fragmented MSDUs can be carried on multiple links.

[0242] Operating_links is a subfield that can indicate the operating links of the transmitting STA. Alternatively, this subfield may be used to negotiate the operating links between the transmitting STA(s) and the receiving STA(s). For example, the transmitting STA may include its operating links in this subfield in an ADDBA request frame. The set of operating links may be represented as S_tx. The receiving STA may select links in S_tx that the receiving STA can operate on and place them in the Operating_links subfield when the receiving STA transmits back an ADDBA response frame.

[0243] 8, STA 802 may respond to STA 801 with a Block Ack negotiation. In particular, STA 802 may transmit a multilink (ML) ADDBA response frame at 812 to STA 802. STA 801 may include one or more pieces of information in the ML ADDBA request frame. In the ML ADDBA response frame, STA 802 may indicate its configuration. Upon receiving the response, STA 801 may adjust its BA transmission procedure accordingly.

[0244] The above-mentioned ADDBA request / response frame exchange may occur on other link(s) (e.g., link 820). The exchange may also vary in some aspects. In one example, STA 801 may acquire channels over all links and transmit ADDBA request frames over all links simultaneously. In one example, STA 801 may perform independent EDMA / CA on multiple links, and STA 801 may transmit immediately after acquiring a link. In some examples, ADDBA request / response frames may be defined using the following: ADDBA request / response frames may be replicated over multiple links, with each frame carrying multi-link information; and / or ADDBA request / response frames may be different over multiple links, with each frame carrying multi-link common information and link-dependent information.

[0245] After the ADDBA Req / Resp exchange, STA 801 may transmit data frames on links 810 and 820 (e.g., 813, 814, 823, 824). The transmissions may follow the settings negotiated in the ADDBA Req / Resp frames (e.g., 811, 812, 821, 822).

[0246] After transmitting the data frame, the STA 801 may transmit a BA request frame 815. In this frame, the STA 801 may indicate whether an immediate or delayed BA is requested. The STA 801 may also indicate whether a multilink BA or a multilink aggregation BA can be requested. In the embodiment of FIG. 8, a delayed BA may be requested.

[0247] The STA 802 may respond after receiving the BA request frame with an ACK frame 816 , which acknowledges the most recent BA request frame 815 .

[0248] Based on the ADDBA negotiation, the STA 802 may prepare one or more links (e.g., 810 and / or 820) for transmission. Generally, an ACK / BA may include an acknowledgement for MPDUs from multiple links / APs and / or an acknowledgement for a QoS data frame with two or more TIDs using a BA. It should be noted that if multi-link aggregation is agreed upon, the STA 802 may transmit a multi-link aggregation BA 817, and BAs for one link (e.g., 810) and / or all links (e.g., aggregated 810 and 820) may be transmitted on another link (e.g., 820). See, for example, the BA 817 transmitted on link 820 at 832. All examples and functions described with link 810 may also be performed by link 820, and vice versa.

[0249] Although only two STAs are explicitly shown in FIG. 8, there may be four STAs (e.g., one at each end of the link), each link may correspond to its own link between two logical STAs, and there may be multiple logical STAs in each physical STA unit / enclosure (e.g., each of STA810 and STA820).

[0250] In one case, as opposed to the example of FIG. 8 showing a BA request, a multilink immediate Block ACK procedure may exist, as shown in FIG. 9. Variations to the Block ACK negotiation and procedure may exist to enable multilink acknowledgment. As shown, multilink ADDBA request / response frame exchanges (e.g., 911, 912, 921, 922) may occur on one or more links (e.g., 910 and 920) as disclosed herein. After the ADDBA Req / Resp exchanges (e.g., 911, 912, 921, 922), STA 901 may transmit data frames (e.g., 913, 914, 923, 924) on links 910 and 920. The transmissions may follow the settings negotiated in the ADDBA Req / Resp frames (e.g., 911, 912, 921, 922).

[0251] After transmitting the data frame, the STA 901 may transmit a BA request frame (e.g., 925) on one of the links (e.g., 920). In this frame, the STA 901 may indicate whether an immediate or delayed BA is requested. The STA 901 may also indicate whether a multilink BA or a multilink aggregation BA can be requested. In one example, the BA may be transmitted on the same link as the BAR. In one example, the STA 901 may transmit a BAR on link 920, which implicitly indicates that the BA transmission should also be on link 920. In one embodiment, an immediate multilink aggregation BA 926 is requested.

[0252] The STA 902 may prepare a multi-link aggregation BA and may transmit it (eg, 926) on the transmitted link BAR.

[0253] Similarly, for Figure 8, although only two STAs are explicitly shown, there may be four logical STAs (e.g., one at each end of the link), each link may correspond to its own link between two logical STAs, and there may be multiple logical STAs in each physical STA unit / enclosure (e.g., each of STA910 and STA920).

[0254] In one case, a multi-link BA may exist over the home link. The home link may be predefined or agreed upon by the AP and associated STAs. A simplified ADDBA request / response frame exchange may be used. In this frame exchange, the STAs may negotiate that a multi-link BA may be allowed. BAR and BA frames may be transmitted over the home link. The home link procedure / negotiation may be similar to other negotiations / procedures as disclosed herein.

[0255] In one case, a multi-link BA frame may be present. In the procedures described above, with reference to Figures 8 and 9, reference is made to STAs that may be non-AP STAs and / or AP STAs. In the procedures described above, with reference to Figures 8 and 9, some frames may need to be modified. For example, the Multi-Link BA Capability element and / or the Multi-Link ADDBA Request and Multi-Link ADDBA Response may be defined as action frames. The Multi-link ADDBA Request / Response frame action field format may be defined in Table 2. The underlined fields in Table 2 may be modified. The italicized fields may be modified or reinterpreted to fit the multi-link mechanism as described herein.

[0256] [Table 2]

[0257] The Block Ack Action field values may be modified in Table 3. Two new fields may be added: ML ADDBA Request and ML ADDBA Request.

[0258] [Table 3]

[0259] The Block Ack Parameter Set field may be modified in Table 4. A new field, Link, with x bits is added. In one way, the Link field may indicate the link for both data and acknowledgment transmission. In one way, the Link may have two subfields. One subfield may be for the data link and another subfield may be for the acknowledgment link.

[0260] [Table 4]

[0261] The Block Ack Timeout Value field may indicate the timeout value for the BA on all links. In one embodiment, the peer link Block Ack Timeout value may be conveyed.

[0262] The Block Ack Starting Sequence Control may be a sequence number space used for all links and this field may indicate the starting sequence for frames across all links. In one embodiment, multiple sequence number spaces are used for multiple links and this field may indicate the peer link starting sequence.

[0263] Table 5 shows an example including a Block Ack Request (BAR) frame. The underlined fields may be modified to accommodate a Multi-Link BAR (ML BAR).

[0264] [Table 5]

[0265] The BAR Control field may also be modified as shown in Table 6. A reserved combination of Multi-TID, Compressed Bitmap, and GCR may be used to indicate that it is a multi-link BAR.

[0266] [Table 6]

[0267] In one method, the BAR Control field defined in 802.11ax is shown in Table 7. A reserved value in BA Type may be used to indicate that this is an ML BAR.

[0268] [Table 7]

[0269] If the combination can indicate a multi-link BAR, the BAR Info field may carry a Multi-links field. This field may indicate the links on which the BA is transmitted. A value of 0 may be used to indicate that the BA can be transmitted over all links. A value of 0 may be used to indicate that the BA can be transmitted over the same link as the BAR.

[0270] The BA frame is defined in 802.11. The underlined fields may be modified to accommodate Multi-Link BA (ML BA).

[0271] [Table 8]

[0272] A reserved value in the BA Control field may be used to indicate this is an ML BA. When this field is set to indicate an ML BA, the BA Information field may carry a Per Link Info field. Each Per Link Info field may carry a LinkID field, the corresponding Ack type, and BA information.

[0273] In one case, there may be a Multi-Link Multi-STA BA (ML MU BA) procedure that enables acknowledgment aggregation from multiple STAs and multiple links.

[0274] The STAs and APs may exchange their multi-link multi-STA acknowledgment capabilities using management / control frames such as probe request, probe response, beacon, association, and / or reassociation frames.

[0275] 10 is a diagram of an example procedure for multi-link multi-STA acknowledgment. In this example, multiple STAs (e.g., STA 1001, STA 1002, STA 1003) may transmit UL frames to an AP (e.g., AP 1000) over one or more links (e.g., 1010 and 1020). An ML MU BA procedure may be defined to aggregate acknowledgment transmissions from the AP to one or more STAs over one or more links.

[0276] An AP 1000 with ML MU acknowledgment capability may schedule UL transmissions to ML MU acknowledgment-enabled STAs (e.g., STAs 1001 and 1002) by transmitting one or more ML MU trigger frames 1011 on an available link 1010. In one example, ML MU trigger frame transmissions over multiple links may be synchronized. The AP 1000 may sense and acquire the channel and transmit ML MU trigger frames simultaneously. In one example, the ML MU trigger frames may be transmitted asynchronously over each available link immediately prior to the triggered UL PPDU. In the embodiment shown in FIG. 10, the AP 1000 may sense the channel on both link 1010 and link 1020. Link 1010 may be available first, and the AP 1000 may transmit an ML MU trigger frame 1011 to trigger transmissions from STAs 1001 and 1002. Later, link 1020 may be available and the AP may send an ML MU trigger frame 1021 to trigger transmissions from STA 1001 and STA 1003. In the ML MU trigger frame, the AP may indicate one or more pieces of information.

[0277] One example of the information to be indicated may be whether multi-link multi-STA aggregate acknowledgment is supported. For example, one field may indicate that the trigger frame is an ML MU Trigger and that ML MU acknowledgment can be expected.

[0278] One example of the information shown may be a linked list of ML MU BAs. This list may include links that can acknowledge aggregated ML MU BAs. STAs that transmitted on a link may expect to receive ML MU BAs on the same or different links.

[0279] One example of the information indicated may be the sequence_space subfield, which may indicate whether the same sequence space can be used for multiple links. In cases where multiple sequence spaces can be used for multiple links, a link index may be used along with the sequence number to assemble the packet.

[0280] One example of the indicated information may be a Buffer_size subfield. This subfield may be used for buffer size negotiation between the transmitting STA(s) and the receiving STA(s). In one method, the receiving STA (which may be, for example, an AP in an uplink transmission) may determine the intended per-STA buffer size across all links and notify the STAs in the ML MU trigger frame. The AP may signal the buffer size in a common field in the trigger frame, which may be a value commonly used by all STAs. Alternatively, the AP may signal the buffer size in a STA-specific field in the trigger frame, which may be different for each STA. In one method, the receiving STA (e.g., an AP in an uplink transmission) may determine the intended per-STA buffer size for each link and notify the STAs in the ML MU trigger frame. The AP may signal the buffer size in a common field in the trigger frame, which may be a value commonly used by all STAs for each link. Alternatively, the AP may signal the buffer size in a STA-specific field in the trigger frame, which may be different for each STA for each link. Alternatively, the buffer information may be carried in management frames such as association request / response, beacon frames, and probe request / response frames.

[0281] After detecting the ML MU trigger frame(s), the desired STA may prepare for UL transmission on the link. The UL packet size may be limited by the buffer size allowed by the AP. The STA may expect an acknowledgment based on the signaling in the ML MU trigger frame. For example, if ML MU BA is supported, the STA may expect an aggregate ML MU BA frame transmitted from one of the operational links.

[0282] The ML MU trigger frame may be defined as a trigger type. For example, the Trigger Type field located in the CommonInfo field may be modified to have a value indicating the ML MU trigger frame as shown in Table 0.

[0283] [Table 9]

[0284] The Trigger Dependent User Information field, located in the User Info field in the trigger frame, may contain one or more of the following information: per-user buffer size across all links; per-user buffer size per link; operational link list; and / or acknowledgement transmission link. The acknowledgement transmission link field may be used to indicate the link on which the acknowledgement can be transmitted. Also, the address field in the ML MU trigger frame may be modified. For example, the transmitter address may be the address of a virtual AP, which represents an AP on multiple links.

[0285] Although the features and elements of the present invention have been described in preferred embodiments in specific combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements of the present invention.

[0286] Although the solutions described herein take into account 802.11 specific protocols, it will be appreciated that the solutions described herein are not limited to this scenario and are applicable to other wireless systems.

[0287] Although SIFS is used to indicate various interframe spacings in the design and procedure examples, any other interframe spacing such as RIFS, AIFS, DIFS, or any other agreed time interval may be applied in the same solution.

[0288] Although four RBs per triggered TXOP are shown as examples in some figures, the actual number of utilized RBs / channels / bandwidth may vary.

[0289] As disclosed herein, there may be systems, methods, and devices that enable a multi-link wireless local area network (WLAN). One or more non-AP base station (STA) multi-link devices (MLDs) and one or more access point (AP) MLDs may establish multi-link associations with each other, thereby establishing a multi-link connection that enables improved and more efficient wireless communication.

[0290] While features and elements have been described above in particular combinations, those skilled in the art will recognize that each feature or element may be used alone or in any combination with the other features and elements. In addition, 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 electrical signals (transmitted over 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 may be used in association with software to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method implemented in a non-access point (non-AP) multi-link device (MLD), comprising: Sending a request to an access point (AP) MLD via a first link, the request including an element related to multi-link operation, the element including a virtual identifier, the virtual identifier being a media access control address; receiving a response to the request from the AP MLD, the response including a single association identifier associated with each of a plurality of links of the multi-link operation with the non-AP MLD, the association identifier being the same for the plurality of links of the multi-link operation with the non-AP MLD; communicating with the AP MLD using multi-link operation based on the association identifier; A method comprising:

2. The method of claim 1 , wherein the virtual identifier comprises an identifier of the non-AP MLD.

3. 2. The method of claim 1, wherein there is a physical layer and logical entity in the non-AP MLD and AP MLD for each link of the plurality of links in the multi-link operation.

4. 2. The method of claim 1, wherein the response includes a beacon, the beacon including a multilink element indicating multilink capabilities of one or more APs belonging to the AP MLD.

5. 2. The method of claim 1, wherein the non-AP MLD includes multiple stations.

6. 10. The method of claim 1, further comprising receiving channel information regarding the multilink operation.

7. 2. The method of claim 1, wherein the AP MLD includes a plurality of APs, and the AP MLD and the plurality of APs are discovered based on the request including the association identifiers associated with the plurality of links of the multi-link operation.

8. A non-access point (AP) multi-link device (MLD), comprising: a processor operably connected to the transceiver wherein the processor: Sending a request via the transceiver to an access point (AP) MLD via a first link, the request including elements related to multi-link operation, the elements including a virtual identifier, the virtual identifier being a media access control address; receiving, via the transceiver, a response to the request from the AP MLD, the response including a single association identifier associated with each of a plurality of links of the multi-link operation with the non-AP MLD, the association identifier being the same for the plurality of links of the multi-link operation with the non-AP MLD; Communicating with the AP MLD via the transceiver using multi-link operation based on the association identifier. The non-AP MLD is configured as follows.

9. 9. The non-AP MLD of claim 8, wherein there is a physical layer and logical entity in the non-AP MLD and AP MLD for each link of the plurality of links in the multi-link operation.

10. The non-AP MLD of claim 8 , wherein the response includes a beacon, the beacon including a multilink element indicating multilink capabilities of one or more APs belonging to the AP MLD.

11. The non-AP MLD of claim 8 , wherein the processor is further configured to receive, via the transceiver, channel information related to the multilink operation.

12. The non-AP MLD of claim 8 , wherein the non-AP MLD includes a plurality of stations.

13. 9. The non-AP MLD of claim 8, wherein the AP MLD includes a plurality of APs, and the AP MLD and the plurality of APs are discovered based on the request including the association identifiers associated with the plurality of links of the multi-link operation.

14. The non-AP MLD of claim 8 , wherein the virtual identifier includes an identifier of the non-AP MLD.

Images