RU2816579C2 - Methods of implementing wireless local area networks (wlan) with multiple communication lines - Google Patents

Abstract

FIELD: wireless communication technologies.

SUBSTANCE: multi-line device (MLD) without an access point (non-AP) performs detection of an access point (AP) based on a message received from the MLD AP, wherein the message contains a beacon or a response to a request from the MLD without an AP. Message contains an association identifier associated with multiple communication lines for MLD without an AP operation with multiple communication lines. MLD without access point (non-AP) exchanges information with MLD AP using operation on multiple communication lines based on association identifier.

EFFECT: high throughput and improved efficiency of wireless communication, which solves the problem of improving quality of service, which is relevant for a wide range of wireless users.

16 cl, 16 dwg, 9 tbl

Description

Cross reference to related application

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 incorporated herein by reference.

Prerequisites for creating the invention

As wireless communication technologies evolve, new use cases are emerging for wireless LANs. To address the challenges presented by these new use cases, there is now a need to make more efficient use of the spectrum on which these wireless technologies operate, especially in 802.11 systems.

Summary of the invention

As described herein, systems, methods, and devices may exist for implementing multi-link wireless local area networks (WLANs). For one or more stations (STAs) and one or more access point (AP) devices, there may be a multi-link pairing procedure between one or more devices, thereby creating a multi-link connection that allows for improved and more efficient wireless communication. There may be a channel feedback protocol with multiple links to balance the load and optimize performance. There may be a procedure for adjusting the mode of operation with multiple communication lines. To facilitate multi-link communications, one or more multi-link architectures and addressing protocols may exist. In addition, there may be a protocol for assigning a frame number for multiple communication links. In addition, there may be an acknowledgment procedure for transmissions over multiple communication lines.

Brief description of graphic materials

A more detailed explanation is contained in the following description, given by way of example, in conjunction with the accompanying drawings, in which like reference numerals in the figures designate like elements:

in fig. 1A is a system diagram illustrating an example of a communication system in which one or more of the described embodiments may be implemented;

in fig. 1B is a system diagram illustrating an example of a wireless transmit/receive unit (WTRU) that may be used in the communication system illustrated in FIG. 1A, in accordance with an embodiment;

in fig. 1C is a system diagram illustrating an example of a radio access network (RAN) and an example of a core network (CN) that may be used in the communication system illustrated in FIG. 1A, in accordance with an embodiment;

in fig. 1D is a system diagram illustrating an additional example of a RAN and an additional example of a CN that may be used in the communication system illustrated in FIG. 1A, in accordance with an embodiment;

in fig. 1E is a system diagram illustrating an example of a communication system in which one or more of the described embodiments may be implemented;

in fig. 2 is a flowchart illustrating an example of a discovery and association procedure for multiple communication links;

in fig. 3A is a diagram illustrating an example of an 802.11 architecture;

in fig. 3B is a diagram illustrating an example of a multi-link architecture;

in fig. 3C is a diagram illustrating an example of a General Link (GLK) architecture with multiple links;

in fig. 4 is a diagram illustrating an example of the most significant bit (MSB) of a fragment number (FN) field as an indication of re-fragmentation in a block acknowledgment request (BAR) of a MAC protocol data unit (MPDU);

in fig. 5 is a diagram illustrating an example of the output of the current pairwise transition key (PTK);

in fig. 6 is a diagram illustrating an example of a nonce field in CCMP;

in fig. 7 is a diagram illustrating an example of a nonce field in the GCMP protocol;

in fig. 8 is a diagram illustrating an example of a delayed block acknowledgment procedure for multiple links;

in fig. 9 is a diagram illustrating an example of an immediate block acknowledgment procedure for multiple links; And

in fig. 10 is a diagram illustrating an example of an acknowledgment procedure for a multiple STA with multiple links.

Detailed description

In fig. 1A is a diagram illustrating an example of a communications system 100 in which one or more of the described embodiments may be implemented. The communication system 100 may be a multiple access system from which a plurality of wireless communication users receive content such as voice, data, video, messaging, broadcast, and the like. The communications system 100 may be configured to provide multiple wireless users with access to such content by sharing system resources, including wireless bandwidth. For example, communication systems 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), Orthogonal Frequency Division Multiplexing (OFDMA), Single Carrier FDMA (SC-FDMA), Redundant Discrete Fourier Transform Extended OFDM with Synchro Burst (ZT-UW-DFT-S-OFDM), OFDM with Synchro Burst (UW-OFDM), OFDM with resource block filtering, filter bank with multiple carriers (FBMC), etc.

As shown in FIG. 1A, communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, radio access network (RAN) 104, core network (CN) 106, public switched telephone network (PSTN) 108, network 110 Internet and other networks 112, although it should be understood that the described embodiments contemplate any number of WTRUs, base stations (eg, access point station (AP STA)), networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or interact in a wireless communications environment. For example, WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive radio signals and may be equivalent to or include a user equipment (UE), a mobile station (STA), a fixed or mobile subscriber unit, a module, pager, cell phone, personal digital assistant (PDA), smartphone, STA, laptop, netbook, personal computer, wireless sensor, Mi-Fi hotspot or device, Internet of Things (IoT) device, watch or other wearable device, wearable head-mounted display (HMD), vehicle, unmanned radio-controlled vehicle, medical device and installations (for example, used in remote surgery), industrial device and installations (for example, robotic and/or other wireless devices operating in industrial and/or automated technological chain), a device related to consumer electronics, a device operating in a commercial and/or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE. As noted herein, a WTRU may be interchangeably referred to as an STA, and an STA may be interchangeably referred to as a WTRU; as described herein, STA and WTRU may be equivalent and/or mean the same thing. In addition, as described herein, various examples are possible that refer to a station (STA), and it is contemplated that these STAs may be both AP STAs and non-AP STAs. AP STA). In addition, each STA and/or WTRU may be a multiple link device (MLD), and may be interchangeably referred to as an STA MLD, a WTRU MLD, an AP MLD, or the like.

Communication systems 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 interact with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as CN 106, the Internet 110 and/or other networks 112. As an example, base stations 114a, 114b may be a base transceiver station (BTS), NodeB, eNode B (eNB), Home Node B, Home eNode B, a next generation NodeB such as a gNode B (gNB), new radio network NodeB (NR), point controller, access point (AP), wireless router, etc. Although each of the base stations 114a, 114b is shown as a separate element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of a RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), radio network controller (RNC), repeater nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless service in a specific geographic area, which may be relatively fixed or which may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one scenario, base station 114a may include three transceivers (eg, one for each cell sector). In one scenario, multiple input multiple output (MIMO) technology may be used at base station 114a and multiple transceivers may be deployed for each cell sector. For example, beamforming can be used to transmit and/or receive signals in desired spatial directions.

Base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication system (e.g., for transmitting signals in the radio frequency (RF), microwave, spectrum centimeter waves, micrometer wave spectrum, infrared (IR), ultraviolet (UV) spectrum, visible light spectrum, etc.). Air interface 116 may be established using any suitable radio access technology (RAT).

More specifically, as stated above, the communication system 100 may be a multiple access system, and one or more channel access schemes may be used, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and WTRU 102a, 102b, 102c may implement a radio technology such as a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) network, in which a radio interface 116 may be installed using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or enhanced HSPA (HSPA+). The HSPA protocol may include High Speed Downlink (DL) Packet Access (HSDPA) and/or High Speed Uplink (UL) Packet Access (HSUPA).

In one scenario, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as an enhanced UMTS Terrestrial Radio Access (E-UTRA) network that may establish air interface 116 using the Long Term Evolution (LTE) standard, and /or LTE-Advanced (LTE-A), and/or LTE-Advanced Pro (LTE-A Pro).

In one scenario, base station 114a and WTRU 102a, 102b, 102c may implement a radio technology such as a new radio access (NR) technology that is capable of establishing air interface 116 using NR.

In one scenario, multiple radio access technologies may be implemented in base station 114a and WTRU 102a, 102b, 102c. For example, together, base station 114a and WTRU 102a, 102b, 102c may implement LTE and NR radio access technologies, for example, using dual connectivity (DC) principles. Thus, the radio interface used by the WTRU 102a, 102b, 102c may be characterized by the use of multiple types of radio access technologies and/or transmissions sent to/from base stations of multiple types (eg, eNB and gNB).

In other scenarios, base station 114a and WTRU 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., microwave broadband technology) band (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) , development of the GSM standard with increased data transfer rates (EDGE), GSM EDGE (GERAN), etc.

Base station 114b shown in FIG. 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may use any suitable RAT to facilitate wireless communications in a localized area, such as a business, a residence, vehicle, educational institution, industrial facility, air corridor (for example, for use by unmanned radio-controlled aerial vehicles), roadway, etc. In one scenario, a radio technology such as IEEE 802.11 may be implemented in base station 114b and WTRU 102c, 102d to create a wireless local area network (WLAN). In one scenario, a radio technology such as IEEE 802.15 may be implemented in base station 114b and WTRU 102c, 102d to create a wireless personal area network (WPAN). In yet another scenario, a cell-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) may be used to create a picocell or femtocell in base station 114b and WTRU 102c, 102d. ). As shown in FIG. 1A, base station 114b may have a direct connection to Internet 110. Thus, base station 114b may not need to access Internet 110 via CN 106.

The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and/or voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different performance requirements, latency requirements, fault tolerance requirements, reliability requirements, data rate requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, location-based mobile services, prepaid calling, Internet connectivity, video distribution, and the like. and/or high-level security features such as user authentication are implemented. Although in FIG. 1A is not shown, it should be understood that RAN 104 and/or CN 106 may directly or indirectly communicate with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which may use NR radio technology, CN 106 may also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-radio technology. UTRA or Wi-Fi.

CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, 102d to provide access to PSTN 108, Internet 110, and/or other networks 112. PSTN 108 may include circuit-switched telephone networks that provide traditional telephone services (POTS). 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/Internet protocol suite. IP. Networks 112 may include wired and/or wireless communications networks that are owned and/or operated by other service providers. For example, networks 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

In fig. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, WTRU 102 may include, but are not limited to, processor 118, transceiver 120, transmit/receive element 122, speaker/microphone 124, keyboard 126, display/touchpad 128, non-removable storage 130, removable storage 132, source 134 power supply, global positioning system (GPS) chipset 136, and/or other peripheral devices 138. It should be understood that the WTRU 102 may include any subcombination of the above elements and still be consistent with the embodiment.

Processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors coupled to a DSP core, a controller, a microcontroller, application specific integrated circuits (ASICs), field programmable gates. matrices (FPGA), integrated circuit (IC) of any other type, state machine, etc. The processor 118 may perform signal encoding, data processing, power control, I/O processing, and/or any other functionality required by the WTRU 102 to operate in a wireless communication environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although FIG. 1B, while processor 118 and transceiver 120 are shown as separate components, it should be understood that processor 118 and transceiver 120 may be formed as a single unit and integrated into an electronic unit or chip.

Transmit/receive element 122 may be configured to transmit signals to or receive signals from a base station (eg, base station 114a) over air interface 116. For example, transmit/receive element 122 may be an antenna configured to transmit and/or reception of RF signals. In one scenario, transmitter/receiver element 122 may be an emitter/detector configured to transmit and/or receive, for example, signals in the IR, UV, or visible light spectrum. In another scenario, transmit/receive element 122 may be configured to transmit and receive signals in both the radio frequency and light spectrum. It should be understood that the transmitter/receiver element 122 may be configured to transmit and/or receive any combination of radio signals.

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

Transceiver 120 may be configured to modulate signals transmitted by transmitter/receiver element 122 as well as demodulate signals received by transmitter/receiver element 122. As noted above, WTRU 102 may have multi-mode capabilities. Thus, transceiver 120 may include a plurality of transceivers that enable WTRU 102 to communicate over multiple RATs, such as NR and IEEE 802.11, for example.

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

Processor 118 may receive power from power supply 134 and may be configured to manage power and/or distribute power to other components in WTRU 102. Power supply 134 may be any suitable device for supplying power to WTRU 102. For example, power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCad), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

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) relative to the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive the information location information over radio interface 116 from a base station (eg, base stations 114a, 114b) and/or determine its location based on the timing of signals received from two or more adjacent base stations. It should be understood that the WTRU 102 may obtain location information through any suitable location method and still be consistent with the embodiment.

Processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless communication capabilities. For example, peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a wireless headset, a Bluetooth® module, frequency modulation (FM) radio, digital music player, multimedia player, video game module, Internet browser, virtual reality (VR) and/or augmented reality (AR) device, activity tracker, etc. Peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a Hall sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; geographic position sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

WTRU 102 may include a full-duplex radio device in which transmission and reception of some or all of the signals (eg, associated with specific subframes for both UL (eg, transmit) and DL (eg, receive)) may be shared and /or simultaneously. A full-duplex radio device may include an interference control unit to reduce and/or substantially eliminate self-interference using either hardware (e.g., an inductor) or signal processing via a processor (e.g., a separate processor (not shown) or processor 118) . In one scenario, WTRU 102 may include a half-duplex radio for transmitting and receiving some or all signals (eg, associated with specific subframes for both UL (eg, transmit) and DL (eg, receive)).

In fig. 1C is a system diagram illustrating RAN 104 and CN 106 in accordance with one or more embodiments. As noted above, RAN 104 may use E-UTRA radio technology to communicate with WTRUs 102a, 102b, 102c over air interface 116. RAN 104 may also communicate with CN 106.

The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it should be understood that the RAN 104 may include any number of eNode-Bs and still be consistent with the embodiment. Each eNode-B 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c over air interface 116. In one scenario, the eNode B 160a, 160b, 160c may implement MIMO technology. Thus, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and/or receive radio signals from WTRU 102a.

Each eNode-B 160a, 160b, 160c may be associated with a specific cell (not shown) and may be configured to make radio resource management decisions, handover decisions, UL and/or DL user scheduling, and the like. As shown in FIG. 1C, eNode-B 160a, 160b, 160c can communicate with each other via the X2 interface.

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

The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a management node. For example, MME 162 may be responsible for authenticating users of WTRUs 102a, 102b, 102c, channel activation/deactivation, selecting a specific serving gateway during initial connection of WTRUs 102a, 102b, 102c, and the like. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM and/or WCDMA.

The SGW 164 may be connected to each eNode B 160a, 160b, 160c in the RAN 104 via the S1 interface. SGW 164 may essentially route and forward user data packets to and from WTRUs 102a, 102b, 102c. SGW 164 may perform other functions, such as user plane binding during handover between eNode B base stations, triggering paging when DL data is available to WTRU 102a, 102b, 102c, managing and storing context of WTRU 102a, 102b, 102c, etc. .

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

CN 106 can facilitate data exchange with other networks. For example, CN 106 may provide WTRU 102a, 102b, 102c access to circuit switched networks, such as PSTN 108, to facilitate communication between WTRU 102a, 102b, 102c and traditional landline communications devices. For example, CN 106 may include or communicate with an IP gateway (eg, an IP multimedia subsystem (IMS) server), with the gateway acting as an interface between CN 106 and PSTN 108. Additionally, CN 106 may provide the WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks that are owned and/or provided for use by other service providers.

Although the WTRU is described in FIG. 1A-1E as a wireless terminal, it is contemplated that in certain exemplary embodiments, wired communications interfaces to a communications network may be used with such a terminal (eg, temporarily or permanently).

In fig. 1D is a system diagram illustrating RAN 104 and CN 106 in accordance with an embodiment. As noted above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c over air interface 116. RAN 104 may also communicate with CN 106.

RAN 104 may include gNBs 180a, 180b, 180c, although it should be understood that RAN 104 may include any number of gNBs and still be consistent with an embodiment. Each gNB 180a, 180b, 180c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c over air interface 116. In one scenario, MIMO technology may be implemented on the gNB 180a, 180b, 180c. For example, gNBs 180a, 108b may use beamforming to transmit signals to and/or receive signals from gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, may use multiple antennas to transmit radio signals to and/or receive radio signals from WTRU 102a. In one scenario, carrier aggregation technology may be implemented on the gNB 180a, 180b, 180c. For example, gNB 180a may transmit multiple carrier components (not shown) to WTRU 102a. A subset of these carrier components may be in unlicensed spectrum, while the remaining carrier components may be in licensed spectrum. In one scenario, gNB 180a, 180b, 180c may implement coordinated multipoint transmission (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

The WTRUs 102a, 102b, 102c may communicate with the gNB 180a, 180b, 180c using transfers associated with a scalable numerical value. For example, OFDM symbol spacing and/or OFDM subcarrier spacing may differ for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNB 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable durations (eg, containing varying numbers of OFDM symbols and/or having constant varying absolute time durations).

The gNBs 180a, 180b, 180c may be configured to communicate with the WTRU 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In a standalone configuration, the WTRU 102a, 102b, 102c can communicate with the gNB 180a, 180b, 180c without simultaneously accessing other RANs (eg, such as eNode-B 160a, 160b, 160c). In a standalone configuration, the WTRU 102a, 102b, 102c may use one or more gNBs 180a, 180b, 180c as a mobility anchor point. In a standalone configuration, WTRU 102a, 102b, 102c can communicate with gNB 180a, 180b, 180c using unlicensed band signals. In a non-standalone configuration, the WTRU 102a, 102b, 102c can communicate/establish a connection with the gNB 180a, 180b, 180c and simultaneously communicate/establish a connection with another RAN such as the eNode-B 160a, 160b, 160c. For example, the WTRU 102a, 102b, 102c may implement dual connection (DC) principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In a non-standalone configuration, eNode-B 160a, 160b, 160c may act as a mobility anchor for WTRU 102a, 102b, 102c, and gNB 180a, 180b, 180c may provide additional coverage and/or capacity to serve WTRU 102a, 102b, 102c .

Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to make radio resource management decisions, handover decisions, UL and/or DL user scheduling, network slicing support, DC, interaction between NR and E-UTRA, routing user plane data to user plane functional (UPF) block 184a, 184b, routing control plane information to access and mobility management functional block (AMF) 182a, 182b, and the like. As shown in FIG. 1D, gNB 180a, 180b, 180c can communicate with each other via the Xn interface.

CN 106 shown in FIG. 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 optionally a data network (DN) 185a, 185b ). Although the above elements are shown as part of CN 106, it should be understood that any of these elements may be owned and/or controlled by an entity other than the CN operator.

The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a management node. For example, AMF 182a, 182b may be responsible for authenticating users of WTRU 102a, 102b, 102c, supporting network slicing (eg, handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, registering area management, termination non-access layer signaling (NAS), mobility management, etc. Network slicing may be used at AMF 182a, 182b to configure CN support for WTRUs 102a, 102b, 102c based on the types of services used by WTRUs 102a, 102b, 102c. For example, different network segments may be established for different use cases, such as services based on access to Enhanced Reliability Low Latency Communications (URLLC), services based on access to enhanced mobile broadband (eMBB), services to access MTC, etc. AMF 182a, 182b may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies such as LTE, LTE-A, LTE-A Pro, and/or access technologies other than 3GPP , such as Wi-Fi.

SMF 183a, 183b can be connected to AMF 182a, 182b in CN 106 via interface N11. SMF 183a, 183b can also be connected to UPF 184a, 184b in CN 106 via interface N4. The SMFs 183a, 183b can select and control the UPFs 184a, 184b, and configure the routing of traffic using the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as UE IP address management and allocation, PDU session management, policy enforcement and QoS management, provision of DL data notifications, and the like. The PDU session type may be IP based, non-IP based, Ethernet based, etc.

The UPFs 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRU 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate data exchange between WTRU 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as packet routing and forwarding, user plane policy enforcement, multi-channel PDU session support, user plane QoS processing, DL packet buffering, mobility binding, and the like.

CN 106 can facilitate data exchange with other networks. For example, CN 106 may include or communicate with an IP gateway (eg, an IP multimedia subsystem (IMS) server), with the gateway acting as an interface between CN 106 and PSTN 108. In addition, CN 106 may provide the WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks that are owned and/or provided for use by other service providers. In one scenario, WTRUs 102a, 102b, 102c may be connected to local DN 185a, 185b by UPF 184a, 184b over the N3 interface to UPF 184a, 184b and the N6 interface between UPF 184a, 184b and DN 185a, 185b.

Taking into account FIG. 1A-1E and corresponding descriptions for FIGS. 1A-1E, one or more or all of the functions described herein in connection with one or more of: WTRU 102a-d, base stations 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a–c, AMF 182a–b, UPF 184a–b, SMF 183a–b, DN 185a–b, AP 190a–b and/or any other device(s) described (s) herein may be implemented by one or more emulation devices (not shown). Emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and/or to simulate network and/or WTRU functionality.

Emulation devices may be configured to implement 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 functions or all functions, where they are fully or partially implemented and/or deployed as part of a wired and/or wireless communications network to test other devices in the communications network. One or more emulation devices may perform one or more functions or all functions and are temporarily implemented/deployed as part of a wired and/or wireless communications network. The emulation device may be directly connected to another device for testing purposes and/or performing tests using wireless radio communication.

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 communications network. For example, emulation devices can be used in a test scenario in a test laboratory and/or in a non-deployed (eg, test) wired and/or wireless communications network to conduct testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may use direct RF connections and/or wireless communications via RF circuitry (which may, for example, include one or more antennas) to transmit and/or receive data.

Additionally/alternatively, one or more of the functions described herein in relation to one or more of: STA 102a-d, AP 190a-b and/or any other device(s) described s) in this document, such as STAs with AP and STAs without AP, may represent 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 multiple link device (MLD); An MLD may be called an AP despite having more than one logical AP. In another example, there may be two logical STAs in one physical package (e.g., the MLD of a smartphone); a physical enclosure may be called an STA despite containing more than one logical STA. A physical frame or MLD may contain one or more logical entities of one or more devices, such as one frame containing two logical STAs and two logical APs. As described herein, MLD can be and is interchangeable with AP MLD and/or non-AP MLD.

Additionally/alternatively, the name “channels” may be used interchangeably with the name “links” as described herein.

In some examples, another network 112 of FIG. 1A may be a wireless local area network (WLAN), such as defined in the IEEE 802.11 standard. In fig. 1E is a diagram illustrating an example of a communication system (eg, WLAN).

Basic Service Set (BSS) infrastructure mode WLANs 191a and 191b may each have an access point (AP) 190a and 190b, respectively, for BSSs 191a and 191b, and one or more WTRUs 102a-e (eg, STAs) associated with APs 190a, 190b . As described herein, a given BSS may be referred to as a network and may refer to communications that occur locally. APs 190a, 190b may have access to or interface with a distribution system (DS) or other type of wired/wireless network that carries traffic to and/or from the BSS (not shown). Traffic to the WTRU originating from outside the BSS (eg, 191a, 191b) may arrive through the AP (eg, 190a, 190b) and may be delivered to the WTRU. Traffic originating from WTRUs 190c-e to recipients outside BSS 191a may be forwarded to AP 190a for delivery to the appropriate recipients. Traffic between WTRUs 190c-e within BSS 191a may be sent through AP 190a, for example, if source WTRU 102c can route traffic to AP 190a and AP 190a can deliver traffic to destination STA 190d. Traffic between STAs (eg, 190c-e) within a BSS (eg, 191a) can be treated as and/or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between (eg, directly between) a source WTRU and a destination WTRU using forward link communication (DLS). In some cases, DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS).

In some cases, a WLAN that uses Independent BSS (IBSS) mode may not have an AP, and STAs (eg, each STA) within an IBSS or using an IBSS may communicate directly with each other. In this document, IBSS mode may sometimes be referred to as "dynamic" communication mode.

When using the 802.11ac infrastructure operating mode or similar operating mode, the AP may transmit a beacon over a fixed channel, such as a primary channel. The primary channel can have a fixed width (eg 20 MHz bandwidth) or a dynamically set width. The primary channel may be a BSS operating channel and may be used by multiple STAs to establish a connection with the AP. In some situations, carrier sense multiple access with collision avoidance (CSMA/CA) can be implemented, such as in 802.11 systems. The STAs (eg, each STA), including the AP, can detect the primary channel for the CSMA/CA. If a particular STA has performed primary channel recognition/detection and/or determined it to be busy, then that particular STA may terminate communication. One STA (eg, only one station) can transmit at any given time in a given BSS.

To implement high throughput (HT) STA communication, a 40 MHz channel can be used, for example by combining a primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz channel.

Ultra High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and/or 160 MHz channel widths. 40 MHz and/or 80 MHz channels can be formed by combining continuous 20 MHz channels. A 160 MHz channel can be formed by combining 8 continuous 20 MHz channels or by combining two non-continuous 80 MHz channels, which can be called an 80 + 80 configuration. For an 80 + 80 configuration, the data after encoding the channel can pass through a segment analyzer, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) and time domain processing can be performed separately on a per-stream basis. Streams can be mapped to two 80 MHz channels and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the above operation for the 80+80 configuration can be inverted, and the combined data can be sent to the media access control (MAC) device.

The 802.11af and 802.11ah protocols support operating modes at frequencies up to 1 GHz. In 802.11af and 802.11ah, channel bandwidths and carriers are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television unused portion of the spectrum (TVWS), while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths with using spectrum other than TVWS. In some situations, 802.11ah can support metered control/machine-to-machine communications (MTC), such as machine-to-machine communications (MTC) devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (eg, only supporting) certain and/or limited bandwidths. MTC devices may include a battery having a battery life that exceeds a threshold value (eg, to provide very long battery life).

WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, may include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the largest total operating bandwidth supported by all STAs in the BSS. The primary channel bandwidth may be set and/or limited by an STA from among all STAs operating in the BSS that supports the lowest bandwidth operating mode. In the 802.11ah example, the primary channel could be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz , 16 MHz and/or operating modes with other channel bandwidths. Carrier detection and/or network allocation vector (NAV) parameters may depend on the state of the primary channel. If the primary channel is busy, for example, due to an STA (eg, which only supports 1 MHz mode of operation) transmitting to the AP, all available frequency bands may be considered occupied, even if most of the available frequency bands remain idle.

In the United States, the available frequency bands that can be used by 802.11ah range from 902 MHz to 928 MHz. Available frequency bands in Korea are from 917.5 MHz to 923.5 MHz. Available frequency bands in Japan are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz depending on the country code.

In general, High Efficiency WLAN (HEW) can solve the quality of service problem that is relevant to a wide range of wireless users in many use cases, including high-density user scenarios in the 2.4 GHz, 5 GHz and 6 GHz bands. HEW may include new use cases that support dense AP and STA deployment modes, as well as associated radio resource management (RRM) technologies. Potential use cases for HEW may include high-density user scenarios (e.g., train stations, stadium events, enterprise/retail communications environments, etc.), may eliminate increased dependence on video/data delivery and wireless services communications for medical installations. HEW networks can be implemented in the 802.11ax standard.

Possible applications for HEW may include new use cases such as, but not limited to, data delivery during stadium events, high-density user scenarios such as train stations, enterprise/retail communications environments, and information , associated with the increased dependence of medical institutions on the delivery of video materials and wireless communications.

In addition, the 802.11ax standard can provide a solution to traffic problems for various scenarios that have short packets. Such scenarios include: Virtual office; TPC confirmation; Confirmation of streaming video transmission; Devices/controllers (mice, keyboards, game pads, etc.); Access - trial request/response; Network selection - test requests, ANQP (request-response protocol); and/or Network Management—Management Frames.

Also with respect to 802.11ax, there may be multi-user (MU) features that include uplink and downlink orthogonal frequency division multiple access (UL and DL OFDMA), as well as uplink and downlink multiple-input multiple-output system. communications (UL and DL MU-MIMO). Additionally, there may be UL random access multiplexing mechanisms for various purposes, which may also be included in the 802.11ax standard.

The 802.11 Extremely High Throughput (EHT) standard can match 802.11ax. EHT can provide increased peak throughput and improve the efficiency of 802.11 networks. EHT may be included in the 802.11be standard. One use case for the 802.11be standard may include applications that require high throughput and low latency, such as: Video-over-WLAN; Augmented reality (AR); and/or Virtual Reality (VR). EHT and 802.11be networks may involve one or more of the following features that achieve the goal of increased throughput and improved efficiency, such as: Multiple APs; Multiple bands/lines; Bandwidth 320 MHz; 16 spatial streams; HARQ; Full duplex (in time and frequency domain); AP Coordination; Semi-orthogonal multiple access (SOMA); and/or new projects to access the 6 GHz channel.

For multi-link operation of 802.11be, there may be a high-level MAC architecture that allows for multi-link operation. There may also be duplication detection and replay detection on multiple communication lines. There may also be various multi-band/link modes that may provide performance gains when operating over multiple bands/links.

Typically, achieving improvements in 802.11 networks may require solving several problems, such as: associating multiple links with multiple access points, dynamic feedback for load balancing and interference elimination; regulation of the Tx/RX operating mode with multiple communication lines; multi-link architecture (eg, non-AP multi-link device architecture, multi-link MAC architecture, 802.11ak multi-link MAC design and architecture); frame number assignment (eg, acknowledgment for fragmented packets with multiple links, packet number assignment, fragmentation with multiple STAs/APs); and/or multi-link acknowledgment.

With respect to the problem of associating multiple links with multiple access points, both APs and STAs may be multilink devices. Additionally, multiple APs may exist in multi-AP sets, and the STAs and APs may need to be aware of each other's capabilities and presets and perform appropriate association procedures to achieve optimal performance and properly configure multi-link modes.

In one approach to solve the problem described above, there may be an efficient discovery and association procedure to provide optimal performance for multi-link operation. A multilink AP, which may be a member of a set of multiple APs, may advertise one or more of its multilink capabilities and multilink operating parameters in its beacon, short beacons, fast initial link setup detection frames communications (FILS) and unicast or broadcast probe responses, such as: multi-link functionality element; element of working with multiple communication lines; element with real-time functionality; and/or a real-time element.

The multilink functionality element may contain one or more of the following parameters for the multilink functionality supported by a given AP: number of lanes; number of channels; mode with multiple communication lines; maximum (max) number of simultaneously supported channels or communication lines per device; Max. supported channel width for each device; protected mode; and/or link aggregation mode.

The number of lanes parameter may indicate the number of lanes that a transmitting AP or a set of transmitting multiple APs supports. This may be specified using a bitmap to indicate one or more bands, including the sub-1 GHz band, the 2.4 GHz band, the 5 GHz band, the 3.5 GHz band, and the 6 GHz band.

The number of channels parameter can be used to indicate the number of channels or links that a transmitting AP or a set of transmitting multiple APs are capable of supporting for one or more supported bands.

The multi-link mode parameter may indicate one or more modes in which multi-link operation can be supported. This option may include independent operation on links, link aggregation, load balancing, dynamic link selection, dynamic AP selection, etc.

The maximum number of simultaneous channels supported on a device parameter may specify the maximum number of simultaneous channels supported in a multi-link device or multi-link STA. For example, this parameter could be associated with individual channels or 20 MHz bandwidth channels.

The maximum supported channel width per device parameter can specify the maximum channel width that can be supported (for example, 80 MHz, 160 MHz, 240 MHz, 320 MHz, etc.).

The protected mode parameter may indicate whether protection should be provided on each link in each device, or protection should be provided on the master/control/association channel, or should be provided once for the master AP and applied to all links that can be used in conjunction with the virtual AP ID.

The link aggregation mode parameter may indicate whether the link aggregation should be continuous or non-continuous. In another example, this parameter can be set for each supported band to indicate whether link aggregation in that band should be continuous or non-continuous.

The multilink operation element may indicate current multilink operation parameters, such as: active bands; active channels; main channel/binding channel/association/control channel; Virtual AP ID; BSS color with multiple communication lines; protected mode; and/or current multi-link channel sets.

The active bands parameter may indicate that the current active bands are being used for multi-link operation by a transmitting AP or a set of multiple APs. This may be specified using a bitmap to indicate one or more bands, including the sub-1 GHz band, the 2.4 GHz band, the 5 GHz band, the 3.5 GHz band, and the 6 GHz band.

The active channels parameter may indicate active channels that are used to operate multiple communication lines. In one example, a bitmap is used to indicate the active channels used to operate multiple communication lines. In another example, a bitmap is used for each active band to indicate the active channels used to operate the plurality of links in each band. In another example, 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 contain one or more values for channel width, channel number, channel working class, etc.

The main channel/binding channel/association/control channel parameter may specify the main channel or binding channel, association channel and/or control channels. Such a channel may be used by the STA to perform association or change of control channel, or as a default channel when involved in multi-link operation.

The virtual AP identifier parameter specifies the identifier of the virtual AP for which the multi-AP set is represented. This may be a BSSID or a MAC address, which may be the identifier of the AP that operates on the binding channel or association channel, or may be the MAC address identifier for a higher layer service access point (SAP) connected to the DS.

The multi-link BSS color parameter identifies the multi-link AP device. The BSS color may be the same for links associated with the same multilink AP if the multilink AP cannot perform independent TX/RX MAC operation on different links. The color of the multi-link BSS may be different for links associated with the same multi-link AP if the multi-link AP can perform independent TX/RX MAC operation on those links. One or more multilink BSS colors may be provided for different links associated with the same multilink AP device, and sensitivity levels for other MLDs may be included for these multilink BSSs to allow adjustment their CCA levels upon receiving one of these transmissions over multiple links and determining whether the medium is idle or busy, and allowing determination of whether spatial reuse should be implemented.

The protected mode setting determines the current protection mode. For example, protection may be provided on each link of each device, or protection must be provided on the master/control/association channel, or must be provided once per master AP and applied to all links that may be shared with the identifier. virtual AP.

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

The real-time functionality element may contain functions to specify real-time traffic capabilities, such as the following parameters: latency, jitter; traffic characteristics (specifications); number of simultaneous threads; and/or the number of simultaneous real-time traffic channels.

The delay parameter sets the max. and/or min. the latency that an AP or a set of multiple APs is capable of providing.

The jitter parameter specifies the max. and/or min. the latency that an AP or a set of multiple APs is capable of providing.

The traffic specification parameter specifies the traffic characteristics that an AP or a set of multiple APs are capable of providing.

The number of simultaneous flows parameter indicates the number of simultaneous real-time traffic flows that an AP or set of multiple APs can support.

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.

The real-time element can set the current parameters of real-time traffic flows, such as: latency, jitter, traffic characteristics, additional number of flows; number of simultaneous traffic channels in real time; and/or the current set of real-time traffic channels.

The delay parameter sets the current max. and/or min. the latency that an AP or a set of multiple APs is capable of providing.

The jitter parameter sets the current max. and/or min. the latency that an AP or a set of multiple APs is capable of providing.

The traffic characteristic parameter specifies the traffic characteristic for any additional real-time traffic that the AP or set of multiple APs is capable of providing, such as priority, data rates, or the like.

The additional number of simultaneous flows parameter indicates the number of additional streams of simultaneous real-time traffic that the AP or set of multiple APs is currently capable of supporting.

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.

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

A multilink device, which may include one or more multilink STAs, may advertise one or more of its multilink capabilities, real-time capabilities, and multilink and line requests. real-time communications in one or more of the following elements in their probe requests, association requests: a multi-link functionality element; multi-link request element; element of real-time functionality; and/or real-time request element.

The multilink functionality element may contain one or more parameters for the multilink functionality that is supported by a given STA, such as: number of lanes, number of channels, multilink mode, maximum (max) number of simultaneously supported channels, and/or aggregation mode channels.

The number of lanes parameter indicates the number of lanes that are supported by the sending STA or device. This may be specified using a bitmap to indicate one or more bands, including the sub-1 GHz band, the 2.4 GHz band, the 5 GHz band, the 3.5 GHz band, and the 6 GHz band.

The number of channels parameter can be used to indicate the number of channels that the transmitting STA is capable of supporting for one or more supported bands.

The multi-link mode parameter specifies one or more modes in which multi-link operation can be supported. This option may include independent operation on links, link aggregation, load balancing, dynamic link selection, dynamic AP selection, or the like.

The maximum number of simultaneously supported channels parameter specifies the maximum number of simultaneously supported channels. For example, this parameter could be associated with individual channels or 20 MHz bandwidth channels.

The maximum supported channel width parameter specifies the maximum channel width that can be supported, for example, 80 MHz, 160 MHz, 240 MHz, 320 MHz, or the like.

The link aggregation mode parameter specifies whether the link aggregation should be continuous or non-continuous. In another example, this parameter can be set for each supported band to indicate whether link aggregation in that band should be continuous or non-continuous.

The multilink request element may indicate a request for multilink operations, such as the following parameters: requested bands, requested channels, virtual STA identifier, and/or requested multilink channel sets.

The Requested Bands parameter defines the requested active bands that are used for multilink operations. This may be specified using a bitmap to indicate one or more bands, including the sub-1 GHz band, the 2.4 GHz band, the 5 GHz band, the 3.5 GHz band, and the 6 GHz band.

The requested channels parameter may indicate the requested channels for multi-link operation. In one example, a bitmap is used to indicate the requested channels used to operate on multiple links. In another example, a bitmap is used for each requested band to indicate the requested channels used to operate the plurality of links in each band. In another example, a list of fields may be used to describe one or more requested channels as multilink channels. Each of the fields may contain one or more values of channel width, channel number, channel operating class, or the like.

The virtual STA identifier parameter specifies the identifier of the virtual STA for which the multilink device is represented. This may be a MAC address, which may be the identifier of the STA that operates on the binding channel or association channel, or may be the identifier of the MAC address for the higher layer SAP connected to the DS.

The Requested Multilink Channel Sets parameter may contain one or more multilink channel sets that the STA can use as a fixed channel set for multilink operation.

The real-time functionality element may contain functions to specify real-time traffic capabilities, such as latency, jitter, and/or the number of simultaneous real-time traffic channels.

The delay parameter sets the max. and/or min. the latency that the STA or device is capable of providing.

The jitter parameter specifies the max. and/or min. the latency that the STA or device is capable of providing.

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.

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

The delay parameter specifies the requested max. and/or min. delay.

The jitter parameter specifies the requested max. and/or min. delay.

The traffic characteristics parameter specifies the traffic characteristics of the requested real-time traffic flow, such as priority, data rates, etc.

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

The requested number of simultaneous real-time traffic channels parameter indicates the requested number of parallel channels that can be used to support a single real-time traffic stream.

The Requested Real-Time Traffic Channel Set parameter indicates a requested set of simultaneous channels that can be used to support real-time traffic flows.

In one embodiment, there may be a procedure for discovering and associating multiple APs with multiple communication links. A multilink AP, which may be an element of a multiple AP set, may advertise one or more of its multilink capabilities, a multilink element, a real-time functionality element, and/or a real-time functionality element. time of one or more APs in a multiple AP set in one or more of its beacon elements, short beacons, FILS discovery frames, and unicast or broadcast probe requests.

The multilink AP may advertise the supported bands and the supported channel in the supported bands, as well as the supported multilink mode and the supported link aggregation mode, which may be continuous or non-continuous. In addition, it can also notify the maximum number of channels per multi-link device and the maximum channel bandwidth per channel. In addition, it may also advertise support for protected mode, which may include configuring security on a per-link basis or configuring security once by the master AP, and such protection would apply to all links associated with the device. multiple communication lines without AP.

The multi-link AP may advertise the currently active bands and channels used for multi-link operation. It may also indicate one or more sets of multilink channels over which the STA may request use for its multilink operation. In addition, it can also announce the master/association/control channel through which control signals are transmitted and association can be performed for any non-AP devices. In addition, it may advertise one or more virtual AP identifiers that a non-AP multilink device should use to transmit to an AP or a set of multi-APs. It may report one or more multilink BSS colors, as well as sensitivity levels associated with one or more multilink BSS colors when determining that. whether the channel is busy or idle, or whether spatial reuse should be implemented.

A multi-link AP may advertise its capabilities to support real-time traffic, including the maximum and minimum latency or jitter that the AP is capable of supporting, and/or the maximum amount of real-time traffic or the number of real-time traffic streams. which she is able to support. It can also advertise the maximum number of simultaneous channels it supports for multi-line devices.

A multi-link AP can advertise its traffic performance parameters in real time, including the maximum and minimum latency or jitter that the AP or set of multiple APs (MAP) is currently capable of providing, and/or how much additional real-time traffic or the number of real-time traffic streams they are capable of supporting. It can also report the current set of simultaneous traffic channels in use in real time.

Non-AP multilink devices, which may contain one or more non-AP STAs, may advertise their one or more multilink functionality, multilink operation requests, real-time capabilities, and/or online operation request. real time in one or more elements in its probe request frames or association request frames.

A non-AP multilink device may advertise the supported bands and the supported channel in the supported bands, as well as the supported multilink mode and the supported channel aggregation mode, which may be continuous or non-continuous. It can also provide information about the maximum number of channels for multi-link operation and the maximum channel bandwidth per channel. In addition, it may also advertise support for protected mode, which may include configuring security on a per-link basis or configuring security once by the master AP, and such protection would apply to all links associated with the device. multiple communication lines without AP.

A non-AP multilink device may specify requested bands and channels to be used for multilink operation. It may also indicate one or more sets of multilink channels requested for use in its multilink operation. In addition, it may advertise one or more virtual STAs that a multilink AP device should use to communicate to non-AP multilink devices.

A non-AP multi-link device may advertise its ability to support real-time traffic, including the maximum and minimum latency or jitter that a multi-link device (MLD) can support and/or the maximum amount of traffic in the mode. real-time or the number of real-time traffic streams it can support. It can also advertise the maximum number of simultaneous channels for real-time traffic that it supports.

A non-AP multi-link device can advertise its traffic request in real time, including the maximum and minimum latency or jitter values that the multi-link device (MLD) is requesting and/or how much traffic is in real time. time or the number of real-time traffic streams requested. It may also indicate a request to use a set of simultaneous real-time traffic channels.

A non-AP multilink device may discover a multilink AP or MAP by monitoring discovery channels or any channels for beacons, short beacons, FILS discovery frames, or probe responses, or it may send probe request frames, which may include itself an element of functionality of multiple communication lines and/or an element of real-time functionality. It may also include a multilink request element and a real-time traffic request element for indicating its request for multilink operation or real-time traffic requested. A non-AP multilink STA may switch to the main/association/control channel if it has received such information from FILS discovery frames or other types of frames and transmit a probe request frame or monitor a beacon, short beacon, or probe response frames. . In addition, it may transmit probe request frames on the channel on which it received the FILS discovery frame of the corresponding multilink AP or MAP.

Multilink APs or MAP elements may receive a probe request and may respond with unicast or broadcast responses or beacons, which may include a multilink functionality element, a multilink functionality element, a real-time functionality element, a multilink functionality element, real-time to communicate its multi-link and real-time capabilities and operating parameters for its multi-link and real-time operation. The MLD and MAP may not respond if the probe request contains parameters for a real-time traffic request or a multilink request that the MLD or MAP cannot support.

If a non-AP multilink device detects a suitable multilink AP or MAP by checking received beacons, short beacons, FILS detection frames, and/or probe responses, it may follow a supported protected mode to establish protection with the multilink AP. or MAP. For example, the MLD may transmit an authentication frame request indicating that it is establishing multi-link security containing a master AP address or a virtual AP identifier. The receiving multilink AP or MAP element may send an authentication request to the master AP if it is not the master AP or the AP represents a virtual AP identifier. The master AP or virtual AP may establish authentication and keys for each link in a multilink channel set. In another example, the authentication and keys may be the same for links in a multilink channel set that may be associated with a virtual AP identifier and a virtual STA identifier. In another example, authentication and keys may be specified for a communication link over which an authentication request/response exchange occurs. Authentication and keys on the remainder of the multilink channel set can be established when the multilink mode is set (on each link or on the main/binding channel/association channel) after successful association. In addition, the master AP can perform authentication for all AP elements within the MAP. In another example, authentication and keys may be established for the link between the master AP and the MLD or between the responding slave AP and the MLD on the link over which the authentication request/response is made. Authentication and keys on the remainder of the multilink channel set and MAP can be established when the multilink mode is set (i.e. on each link or on the main/binding channel/association channel) after successful execution association.

A non-AP multilink device may send an association request to a multilink AP or MAP, which may include a virtual AP identifier, to request association with the AP or MAP. The association request may include a request for multilink operating parameters such as bandwidth, channel set, and channel being requested, as well as the real-time traffic characteristics and parameters to be supported. The multilink AP or the master AP in the MAP may evaluate the request and determine whether the specified request can be supported. It may respond with an association response indicating to the STA the assigned channel set, the assigned band, the assigned channel aggregation mode, and the multilink mode. In one embodiment, the association response is sent only to the channel on which the association request was received. The association response may indicate one or more channels and channel widths on one or more bands, as well as the BSSID and colors of a plurality of links on which the STA should associate on the specified band and the specified channel.

The association response may include a single association identifier (AID) that is associated with the non-AP multilink STA. The AID may be an identifier assigned to an AP during association for a non-AP STA. The AID may be the same for all links operating on the entire multilink channel set, and it may be associated with a virtual AP identifier and for a virtual STA identifier. In one example, the AID may be specific to the STA ID and may be associated with the BSSID of the AP that is operating on the link over which the association request/response exchange occurred. There may be additional AIDs assigned to the STA ID associated with the same non-AP multilink STA that operates on other links of the same multilink channel set.

In fig. 2 shows an example of the detection, association and operation procedure for multiple communication lines. At step 201, a multi-link non-AP device (eg, one or more logical STAs or WTRUs) may transmit a probe request that includes information about functionality for the multi-link device of the multi-link non-AP device. Information about the multi-link functionality of a non-AP multi-link device may be contained in a probe request element or sub-element. The probe request may be sent to one or more AP devices with multiple communication lines (logical and/or physical). At step 202, one or more multilink APs may transmit a probe response in response to a probe request indicative of multilink functionality. The probe response may contain information regarding the capabilities of one or more multi-link APs. This information may also be contained in the beacon. The beacon may have one or more multilink functionality elements and/or subelements that contain this information. This information may include functionality for multiple links of one or more multi-link APs and/or operating parameters of one or more multi-link APs.

At step 203, the non-AP multilink device may initiate multilink association via an association channel based on information from one or more multilink APs. In one case, such association may be performed if a non-AP multilink device detects at least one suitable multilink AP from one or more multilink APs based on the multilink AP information. At step 204, a multilink device without an AP, as part of or subsequent to an association, may negotiate multilink operating parameters for multiple links on a single link. At step 205, the non-AP multilink device may perform multilink operations as agreed upon (eg, during association).

In another example similar to FIG. 2, there may be a method implemented by a wireless transmit/receive unit (WTRU) multi-link device (MLD) (eg, a non-AP STA) for performing multi-link communications. The MLD WTRU may send a probe request to an access point (AP) MLD (eg, an STA AP), which probe request may include an indication of functionality for multiple links of the WTRU MLD. The WTRU MLD system may receive a response to a probe request from an MLD AP, wherein the response includes MLD AP information and the MLD AP information may include an indication of a plurality of MLD AP capabilities and parameters for a plurality of MLD AP communications. The MLD WTRU may then initiate association with the MLD AP using the MLD AP information. Once an MLD is associated, the WTRU can communicate over multiple links with the MLD AP or the MLD of a multiple AP. For each link of a plurality of links, both the WTRU MLD and the AP MLD may have a logical entity (eg, a physical layer). Both the WTRU MLD and the AP MLD may have multiple MAC layers, one to interwork with the upper layers (eg, the upper MAC) and one to interact with each of the physical entity layers (eg, the lower layer MAC). In one or more examples, the response may be a beacon, wherein the beacon includes an element of functionality. In one or more examples, the functionality element may include MLD AP information. In one or more examples, initiation may further include negotiating multilink operating parameters for the MLD AP based on the MLD AP information. In one or more examples, the negotiation may occur over a single communication link.

Regarding the problem of dynamic feedback for load balancing and interference control, generally, load balancing may be a multi-link application, and in order to optimally implement load balancing, APs and STAs need to be notified of the real-time load as well as interference on each of the available channels.

To solve the above problem, there may be effective monitoring and feedback mechanisms for APs and STAs to exchange status information regarding channel properties and interference. A multi-link AP may periodically schedule probes on all channels for the STAs to perform channel measurements. Such probing can be accomplished by transmitting short packets such as missing data packet (NDP) frames. In one example, said probing may also be conducted using conventional packets such as beacons, short beacons, or short FILS detection frames.

A multi-link device may support a time synchronization function (TSF) timer on all of its links.

A multi-link AP may advertise in its beacon, short beacons, FILS discovery frames, or other frames the schedule of these probing frames. For example, a multi-link AP device may include offsets for beacons or short beacons or FILS discovery frames. The offset can be done using the same TSF timer or using a separate TSF timer on the channel, or can be done relative to the current beacon target time (TBTT) or FILS detection frame target time on the current channel.

A non-AP multilink device may periodically measure the channel using an offset or schedule for a probe frame or a FILS detection frame or other type of received frames. If the device performs channel measurements, it can provide feedback to APs with multiple links. Feedback can be initiated by a multi-link AP using a trigger frame.

For example, a multilink AP may send an NFRP frame, triggering an NDP feedback report for multilink feedback. The NFRP may include the starting channel number and the number of channels over which the feedback should travel. In another example, the NFRP may include bitmaps for the communication lines over which the feedback must travel. A non-AP multilink device may send an NDP feedback report using a plurality of symbols, with each symbol representing a link-specific feedback bit corresponding to a request included in the NFRP frame. It can also send an NDP report to different Receiver Units (RUs). For example, a bit associated with a particular RU may represent a feedback report for a particular link or channel requested by the NFRP frame.

In another example, a multilink AP may request multilink feedback in the EHT control headers as part of the PHY or MAC header. The EHT control header requesting multilink feedback may include a starting channel number and the number of channels over which the feedback should travel. In another example, such a request may include a bitmap for the communication lines over which the feedback should travel. A multilink device without an AP may send a multilink feedback report to the EHT control field in the MAC or PHY header in a serial frame sent to the multilink AP.

In addition, the multilink AP may include a link activity indicator element in its beacon, short beacon, or FILS detection frames. The link activity indicator may include details of activity on each link of a multi-link channel set. In one example, the link activity indicator may be represented in the form of a bitmap. If the association of a bit with a link is indicated as "0", it means that this link can be considered heavy with traffic, while "1" can mean that traffic on this link can be light and additional traffic can be added to it . In another example, more bits may be associated with each link in a set of multiple links, for example, two bits may be used to indicate the level of activity on 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 heavy traffic on that link. Non-AP multilink STAs can use the received link activity indicator to determine if they need to move to another link to achieve better performance. The choice can be based both on the probing results and on the communication link activity indicator. It should be noted that the values presented herein are examples only, and any value may be used as long as it is indicative of performing the same function as described herein; for example, the values may be set randomly, randomly, algorithmically, ID-based, sequential, preconfigured, real-time determined, or the like.

Such a link activity indicator may also be included in MAC headers, such as the EHT a-control field in the MAC or PHY headers. The inclusion of such a link activity indicator can be considered as a recommendation for receiving STAs to switch to one or more recommended links, such as light traffic links. The STA decision may also be based on channel quality sounding results, as described previously.

A multi-link feedback request or response may also be accomplished using newly developed frames such as control frames; control frames such as multilink feedback request frames or response frames.

The multi-link feedback request or response may be conducted on the control channel/binding channel/association channel or on all channels. A multi-link feedback request or response for any other channels may be conducted over any link on any channel.

With respect to the problem of adjusting the TX/RX mode of operation with multiple communication lines, a WLAN device can operate in different modes for transmission and reception depending on current applications and power levels.

To solve the above problem, there may be a protocol that allows the TX and RX operating modes of the STAs and APs to be adjusted so as to maintain efficient and power-saving operation. The multilink STA may initiate a change in TX and RX data transmission mode by sending an OMC change request to the multilink AP. The request can be addressed to the master AP or virtual AP, or to a single AP element within a MAP. It can be transmitted on the main channel/binding channel/control channel or on any communication link. However, the request frame may be sent over a link that will function after the multilink operating mode has changed. The multilink mode change request may also be sent as part of the EHT control header in the MAC or PHY header. A multi-link STA may include one or more bitmaps to indicate requested changes to operate the links on different channels. A single bitmap may be used for multiple active lanes, or one or more bitmaps may be used for each supported lane. A "0" for a particular link or link means that the specified link or link is on request or remains inactive. A "1" for a particular link or link may indicate that the specified link or link is requesting activation or remains active. In another example, a channel set number may be used to indicate a change request to a new multi-link channel set. In yet another example, a multilink device without an AP may request the number of links to be active, while exactly the active link or channel may be determined by the multilink AP. A separate bitmap can be used to request simultaneous links/channels in real time. In one example, a bitmap may be included for all MAP elements to indicate a request to switch to another AP element within the MAP or to switch to another link on the same or a different AP element within the MAP.

A request to change the multi-link operating mode may be triggered by changing the number of traffic flows, the number of active real-time traffic flows, the power level of the device, the level of interference on one or more links, and/or the traffic saturation on one or more links.

The AP MAP element may forward the request to the master AP. The multilink AP or master AP may respond (ie, it may occur through the AP element from which the request was received) with a multilink mode change response frame. The response may be directed to the identity of the virtual STA or the STA that submitted the request. It can be transmitted on the main channel/binding channel/control channel or on any communication link. However, a response frame may be sent over a link that will function after the multilink operating mode has changed. The Multilink Mode Change Response frame may also be sent as part of the EHT control header in the MAC or PHY header. A multilink AP or master AP may include one or more bitmaps to indicate assigned links or channels. A single bitmap may be used for multiple active lanes, or one or more bitmaps may be used for each supported lane. A "0" for a particular link or link means that the specified link or link is not assigned or remains inactive. A "1" for a particular link or channel may indicate that the specified link or link is assigned to a multi-link STA or remains active. In another example, a channel set number may be used to indicate the assignment of a new multilink channel set to a multilink STA. In yet another example, a multi-link device without an AP is assigned a number of links that are active. A separate bitmap can be used to assign simultaneous lines/channels in real time. In one example, a bitmap may be included for all MAP elements to indicate assignments for switching to another AP element in the MAP or switching to another link in the same or a different AP element in the MAP.

A multilink AP or a master AP may initiate a multilink mode change by sending an OMC change request to the non-AP multilink device (eg, an STA/WTRU). The request may be addressed to the identifier of a virtual STA or a non-AP STA operating on this link. It can be transmitted on the main channel/binding channel/control channel or on any communication link. However, the request frame may be sent over a link that will function after the multilink operating mode has changed. The multilink mode change request may also be sent as part of the EHT control header in the MAC or PHY header. The multi-link AP may include one or more bitmaps to indicate requested changes to operate the links on different channels. A single bitmap may be used for multiple active lanes, or one or more bitmaps may be used for each supported lane. A "0" for a particular link or link means that the specified link or link is on request or remains inactive. A "1" for a particular link or link may indicate that the specified link or link is requesting activation or remains active. In another example, a channel set number may be used to indicate a change request to a new multi-link channel set. In yet another example, a multi-link device AP requests a number of communications links to be active. A separate bitmap can be used to request simultaneous links/channels in real time. In one example, a bitmap may be included for all MAP elements to indicate a request to switch to another AP element within the MAP or to switch to another link on the same or a different AP element within the MAP.

A multi-link operation mode change request may be triggered by changing the number of traffic flows, the number of active real-time traffic flows, the power level of the devices, the level of interference on one or more links, and/or the traffic saturation on one or more links.

The multilink STA may respond with a response frame to a change in multilink operating mode. The response may be directed to the ID of the virtual AP or the AP that sent the request. It can be transmitted on the main channel/binding channel/control channel or on any communication link. However, a response frame may be sent over a link that will function after the multilink operating mode has changed. The Multilink Mode Change Response frame may also be sent as part of the EHT control header in the MAC or PHY header. In one example, a multilink response frame sent by a non-AP multilink STA may simply represent an acknowledgment or rejection of the request by the master AP, or the identity of the virtual AP, or the AP that sent the request.

Multilink devices can begin using a new multilink operating mode only if it is acknowledged by the multilink AP and STAs.

Regarding the issue of multi-link device architecture without an AP, both APs and STAs can be multi-link devices. In addition, there may be multiple APs in multiple AP sets (eg, that are not associated with a multilink AP device) in which data flows need to be monitored, and to which STAs/links packets are transmitted. This problem can be solved by using an efficient multi-line device architecture without AP, and an addressing protocol that ensures reliable communication.

In one example, a non-AP multilink STA device may be represented by a virtual STA identifier, which may be indicated by the device in its probe request, association request, or other type of control or monitoring frames. The virtual STA ID can be used on all links to identify a multi-link device without an AP. A non-AP multilink STA operating on any link or channel can filter and receive packets that are addressed to the virtual STA ID as well as the MAC address of the STA operating on that link or channel. A multi-link STA or non-AP device may be assigned a single AID that is associated with a virtual STA ID and can be identified as such on all links.

In one example, a multi-link AP device may be represented by a virtual AP identifier, which may be indicated by the device in probe responses, association responses, beacons, or short beacons, or FILS discovery frames, or in other type of management or control frames. A virtual AP identifier can be used on all links to identify a multi-link AP device. A multi-link AP device operating on any link or channel can filter and receive packets that are addressed to the virtual AP ID as well as the MAC address of the AP operating on that link or channel. A multi-link AP may be assigned a single AID that is associated with a virtual AP ID and can be identified as such on all links by all AP elements within the MAP.

In one example, all multilink AP devices belonging to the same multiple AP may be represented by a virtual AP identifier, which may be indicated by one or more devices in probe responses, association responses, beacons, or short beacons, or frames. FILS detection, or in other types of management or control frames. A virtual AP identifier can be used on all links to identify multi-link APs in a multi-AP set. Any multi-link AP device in a multi-AP set operating on any link or channel can filter and receive packets that are addressed to the virtual AP ID and/or MAC address of its AP or all APs operating on that link or channel. In one example, a multi-link STA associated with a set of multiple APs may be assigned a single AID that is associated with a virtual AP identifier and can be identified as such on all links by all APs within the MAP. In one example, a multi-link STA may be assigned an AID that has two parts—one part that is common to all links, and a specific link part that can identify the link or AP operating on that link.

The packet that is transmitted to the multilink STA device may include a virtual STA identifier. In one example, a frame sent to a multilink STA device may have a destination address (DA) or receive address (RA) configured to the virtual STA identifier. In one example, a packet sent to a multi-link STA device may have an RA address configured to the MAC address of the STA operating on that link or channel, and a DA address configured to the virtual STA ID. The BSSID can be configured to be the ID of the virtual AP or the BSSID of the transmitting AP operating on that link. In one example, a multi-link STA may be assigned an AID that has two or three parts—one part that is common to all links and all APs in the MAP, and a special link part that can identify the link. or an AP operating on that link, and a third part that can identify a particular AP element.

A multi-link STA may respond to, for example, a Traffic Indication Map (TIM) indication or a Missing Data Packet (NDP) feedback report poll, or any other AID-based schemes if one of the following situations may occur:

The specified AID may be equal to the AID assigned to the multi-link STA.

The specified AID may be equal to the common part of the AID, and the frame retrieved specifies the virtual AP ID.

The specified AID may be equal to a combination of the general portion of the assigned AID as well as the link-specific portion of the assigned AID, and the extracted frame may indicate a virtual AP identifier or BSSID that is specific to the AP operating on the corresponding link, or such extracted frame is received on corresponding communication line.

The specified AID may correspond to a combination of the general portion of the assigned AID as well as the link-specific portion of the assigned AID, and the retrieved frame may indicate a virtual AP identifier or BSSID that is specific to the AP operating on the corresponding link, or such retrieved frame is received on the corresponding link, and/or such retrieved frame indicates a virtual AP identifier or BSSID that is specific to the AP element within the MAP.

A packet, such as a data packet, that is transmitted by a multilink STA may include a virtual STA identifier that identifies the multilink STA without an AP. In one example, a frame, such as a data frame, that is transmitted to a multilink STA device may have an Address 3 field or an Address 4 field configured to the virtual STA identifier. The MAC header or PHY header of the frame may also include an indication that it is a multilink packet and may carry a virtual STA identifier. In one example, a packet transmitted to a multi-link STA may have an RA address or Address 1 field configured to the MAC address of the STA operating on that link or channel, and an Address 3 field configured to the virtual STA ID. The Address 2 field can be configured to be the virtual AP ID or the BSSID of the transmitting AP operating on that link. Additionally, the Address 3 field can be configured to be the virtual AP ID. In an alternative or additional embodiment, the Color BSS field in the PHY header may be configured to be a multilink BSS color or a multilink AP BSS color or a multilink AP BSS color to indicate that the packet being transmitted is a multilink addressable packet. link PPDU, or multiple AP PPDU with multiple links, or multiple AP PPDU. The STA may filter and adjust the NAV based on the multi-link BSS color, the multi-AP BSS color, or the multi-link multi-AP BSS color.

The packet that is transmitted to the multilink STA device may include a virtual STA identifier. In one example, a frame transmitted to a multilink STA device may have a DA address, or RA address, or Address 1 configured to the virtual STA identifier. In one example, a packet sent to a multilink STA device may have an RA address or Address 1 configured to the MAC address of the STA operating on that link or channel, and a DA address configured to the virtual STA ID. The BSSID or Address 2 field can be configured to be the virtual AP ID or the BSSID of the transmitting AP operating on that link. A packet that is sent to a multilink STA may contain in the Address 2 field the BSSID or MAC address of the AP transmitting on that link or in the BS of the multilink AP, and contain a virtual AP ID in the Address 3 field. A packet that is specifically targeting a multi-link STA device operating on a specific link can be identified by including the STA's MAC address (eg, in the RA address field or Address 1 field). The source address in the downlink packet may be configured to the virtual AP ID if the frame is initiated by the master AP. The source address field can be configured to the MAC address of the AP operating on that link, as long as it is link-specific and not initiated by the master AP.

The packet that is transmitted to the multilink AP device may include a virtual AP identifier. In one example, a frame sent to a multilink AP device may have a DA address, or RA address, or Address 1 field configured to the virtual AP identifier. In one example, a packet sent to a multilink AP may have an RA or Address 1 field configured to the MAC address of the AP operating on that link or channel, and a DA or Address 3 address field configured to the virtual ID. AP. The BSSID or Address 3 field can be configured to be the virtual AP ID or the BSSID of the AP operating on that link. The TA Address or Address 2 field may be configured to be the virtual STA ID of the sending non-AP STA. A packet that is specifically targeted at an AP of a multi-link AP operating on a particular link can be identified by including the AP's MAC address, for example, in the RA address field. The source address in the uplink packet may be configured to the virtual AP identifier if the specified frame is intended to be routed to the master AP or DS. The source address field can be configured to the MAC address of the AP operating on that link, as long as it is link-specific and not intended to be sent to the master AP or DS.

In another example, the To DS and From DS fields may both be set to 1 so that Address 4 may be used by the EHT STA to recognize that the transmitted packet is a multilink packet. In a multilink packet for a non-AP STA, Address 1 can be configured to the MAC ID of the receiving STA on that link or channel, Address 2 can be configured to the virtual AP STA or the MAC address of the sending AP on that link or channel, Address 4 can be configured to be a virtual AP ID, and Address 3 can be configured to be a virtual STA ID. In a multilink burst for an AP, Address 1 may be configured to be the MAC ID of the receiving AP on that link or channel, Address 2 may be configured to be the virtual STA ID or MAC address of the sending STA on that link or channel, Address 3 may be configured to the virtual AP ID, and Address 4 can be configured to the virtual STA ID.

When a receiving STA or AP receiving a multilink packet, which may be indicated by an indication in the PHY or MAC header, and which may be one specific bit or by the "To DS" or "From DS" bits, then the receiving STA or APs may interpret the address fields as described above.

Regarding the issue of multi-link MAC architecture, if multi-link devices have multiple SAPs for lower level MACs and a single MAC SAP going to/from the DS, then more design decisions may be required to ensure proper operation of the multiple links. facilitating the described architecture.

In fig. 3A is a diagram illustrating an example of a legacy 802.11 MAC architecture. In fig. 3B is a diagram illustrating an example of a multi-link MAC architecture. Fig. 3C is an example of a multi-link GLK MAC architecture. For all figs. 3A, 3B and 3C, similar numbering will correspond to similar elements.

In fig. 3A, the existing 802.11 architecture and the 802 architecture in general have several concepts regarding protocol objects, peers, layers, services, and clients. Within these concepts, there are techniques for dynamically stacking protocol objects. In the example shown, STA 310 may access via wireless medium 304 a single link 307 to AP 320A. Each object can have unmanaged (U) and managed (C) ports. Typically, the data flow is shown through various layers as it moves to and from the STA 310A to/from the AP 320A and from/to the DS 336. To the extent appropriate, the legacy configuration may have a single MAC 312 and PHY 313 for the STA 310A, and similarly, AP 320A may have a single MAC 322 and PHY 323.

According to FIG. 3A, to implement a multi-link approach (e.g., link 307A, 307B, and 307C), there may be multiple lower layer SAP MACs underneath a higher layer SAP MAC that collectively act as MAC functional layer devices for the multi-link scenario. as shown in Fig. 3B. The introduction of this additional layer (eg, lower MACs) may provide a new/improved and/or additional set of peers, layer features, and services to their clients. Accordingly, to solve the above problems, a set of SAP MAC peers may exist as described herein.

In an AP, such as the multi-link AP 320B, there may be an upper SAP MAC (e.g., upper MAC SAP 312U), which may be between the DS (e.g., 335 and 336 in aggregate), or with IEEE-802.1x layer 321. which may be directly below the DS, and multiple single SAP 322LC, 322LB, 322LA MAC links, each with its own PHY layer (e.g. PHY 1 323A, PHY 2 323B, PHY 3 323C), essentially creating separate logical APs for each communication link (eg, communication links 307A, 307B and 307C). To the DS, this top MAC SAP may appear to be a standard 802.11 SAP, providing all 802.11 intended services to the DS, and said DS may likewise provide all existing intended 802.11 services to that top MAC SAP. In addition to the services currently defined, there may be additional services described in this document that may be provided by the upper MAC SAP.

In a non-AP STA, such as a multi-link STA 310B, there may be a top MAC peer SAP 312U, which may also be located below the LLC layer or below the 802.1X layer 311, and above a plurality of SAPs 312LA, 312LB and 312LC MACs with single link (for example, again, each of which has its own PHY level: PHY 1 313A, PHY 2 313B, PHY 3 313C).

The MAC services provided by the upper MAC layer (eg, 312U and/or 322U) may include all the services provided by any legacy 802.11 MAC service and may also provide additional services to optimize frame transmission over multiple single 802.11 links. These additional services may include optional A-MAC service data unit (MSDU) aggregation/deaggregation capability, optional fragmentation/defragmentation capability, sequence number assignment services, deferred queuing and PS routing services, packet number assignment, and other services. as described herein.

Regarding the issue of multi-link design and 802.11ak MAC architecture, in some situations 802.11ak can replace DS (eg 335 and 336) with a direct connection to an 802.1 switch (eg 340) that controls the flow of data over the 802.11 link . In fig. 3C is a diagram illustrating an example of a General Link (GLK) architecture with multiple links (eg, 802.11ak). As explained in FIG. 3B, to handle multi-link scenarios, the multi-link architecture may introduce an additional SAP MAC layer; how this impacts the way 802.11ak operates and the requirements for the upper MAC SAPs that transform/manage data flows to/from the lower MAC SAPs may require consideration when considering how to approach this issue. In particular, there may be a multi-link channel feedback procedure for load balancing and optimal interference control, as described herein.

The role of the upper MAC SAP (eg, 311 and 321) in the 802.11ak MAC architecture shown in FIG. 3C may be similar and/or similar to the non-802.11ak MAC architecture shown in FIG. 3B. The upper MAC may provide an SAP MAC that provides the functionality and services of the legacy SAP 802.11 MAC for GLK links. As shown in FIG. 3C, there may be two possible forward links 351 and 352 that extend across the entire architecture - they may be independent links and both do not need to be present. Link 351 is shown as a link connecting two LLC sublayers (eg, 341B to 341D), while link 352 is shown as a link connecting two 802.1Q MAC relay entities (eg, 341A to 341C). Both of these may be peer links 351 and 352, may use multiple 802.11 MAC/PHY links (eg, 307A, 307B, 307C, etc.) to provide a wireless interconnect portion of the link.

Regarding the issue of acknowledging fragmented packets over multiple links, in a multi-link environment of a multiple AP, each packet sent by a particular AP over a particular link may be fragmented into multiple fragments. If an acknowledgment (eg, BA) needs to be sent over another link, which may be associated with another AP, the receiving AP may not have information about the number of fragments transmitted. It may be necessary to develop an acknowledgment protocol to ensure accurate acknowledgment of fragmented transmissions. For example, in the current ACK and block acknowledgment for an 11ax MAC Protocol Data Unit (MPDU) with fragmentation level 1~3, when received by another AP, there is no way to convey how many fragments are in the MPDU and whether all fragments are received. Additionally, there is a need to address the scenario where fragments are lost, such as a protocol for APs to report retransmission of lost fragments.

In one scenario, there may be fragmented packet acknowledgment for multiple links, which may include methods for processing MSDUs, and these methods may also be applicable to MMPDUs when they describe the MSDU. For demonstration purposes, this scenario can assume that there are many uncorrelated APs, and each of them can transmit MPDUs from the same traffic identifier (TID) to the same non-AP STA. APs can operate on different channels or in different bands. MSDUs directed to non-AP STAs may be received at each transmitting AP from the centralized entity. The centralized entity may maintain a source information panel for the TID to perform retransmission of the reported missing MPDU based on status indications from transmitting APs that receive the Block ACK (BA) acknowledgment bitmap or ACKs sent from non-AP STAs. As described herein, this centralized entity may be referred to as an anchor AP. For STAs without an AP, different forwarding APs may appear that have the same or different MAC addresses. In the case of different MAC addresses for different transmitting APs, a non-AP STA may interpret the sequence number of MPDUs from different APs as belonging to the same sequence number space.

The anchor AP may maintain a record of which MSDUn is sent to which AP (ie, the sending AP of the specified MSDUn). At the same time, if the anchor AP needs to reduce latency and/or improve the reliability of MSDUn, there may be more than one AP transmitting MSDUn.

The status indication may be generated from the AP transmitting MSDUn to the anchor AP. The indication may identify the transfer success/failure status of MSDUn (fragment). The indication may indicate that the sending MSDUn AP is no longer buffering MSDUn for transmission due to acknowledgment or (repeated) MSDUn failure(s). The status indication may be generated by an AP that is not the AP sending the MSDUn, but the indicated AP generates the indication based on the BA bitmap received from the non-AP STA. The state indication may include a re-fragmentation indication, described below, to identify the bitmap from different fragmentation events (eg, fragmentation is performed differently across different fragmentation events). The state indication when generated by the sending AP may include the fragmentation indicators described below so that the anchor AP can instruct another sending AP to perform identical MSDUn fragmentations.

To identify the MSDUn (fragment) and to reset the buffered MSDUn (fragment) at the sending AP, a reset indication may be generated from the anchor AP to the sending MSDUn AP. This indication may be generated by the anchor AP because it has received an MSDUn acknowledgment (from another AP), or because the anchor AP needs to retransmit an MSDUn (fragment) from another AP that is not the current sending MSDUn AP.

Timer x can be started on the anchor AP when it transmits MSDUn to the sending AP. After the timer expires, the anchor AP may send a reset command to the sending MSDUn AP to reset the buffered MSDUn (fragment).

Timer x can be started on both the anchor AP and the MSDUn transmitting AP when the anchor AP transmits MSDUn to the transmitting AP. After timer x expires, the sending AP can flush the buffered MSDUn (fragments) without a reset command from the anchor AP.

Within the duration of timer x, the sending MSDUn AP may not flush the buffered MSDUn unless it has received an indication to reset MSDUn from the anchor AP.

Each transmitting AP may have an independent CSMA/CA and may retransmit multiple times. When a status indication identifying a missing MSDUn (fragment) is received from APy, but such MSDUn has previously been transmitted to APx for transmission, the anchor AP may wait for time x to expire before initiating retransmission of the MSDUn (fragment), with timer x starting when MSDUn is transmitted in APx. In an alternative embodiment, the anchor AP may wait for a status indication from the APx indicating a reset of MSDUn before it initiates retransmission of the MSDUn (fragment).

In one scenario, fragmentation may not be allowed. In this scenario, the same MSDUn may be transmitted by different APs. When configuring block acknowledgment (ACK) negotiation, the source (AP) can send an add block acknowledgment (ADDBA) request frame indicating no fragmentation by setting the No-fragmentation field to 1 in the ADDBA extension element. For TIDs without block acknowledgment negotiation, MSDU fragmentation may not be enabled at the transmitter. In an alternative embodiment, the retransmission of the MSDU may not be fragmented. Based on More Fragments=0 and Fragment Number FN=0, the non-AP STA correctly accepts MSDU retransmission and can reject previously received MSDU fragments.

In one scenario, a retransmission/duplicate transmission may be authorized to be sent from the same AP. In this method, MSDU fragmentation can be resolved. In one case, all MSDUs from the same TID to the same non-AP STA may be routed to the same AP for transmission. In this case, a source information panel may be maintained for the TID of the sending/referring AP.

When the anchor AP receives a status indication indicating missing MSDUns or MSDUn fragment(s), it may send a retransmission indication to the previous AP transmitting the MSDUn identifying the specified MSDUn(s). The status indication may be generated by an AP that is not the sending AP of MSDUn. An identical fragment of the original transmission is retransmitted from the same transmitting AP.

In one scenario, missing pieces can be identified. In 11ax dynamic fragmentation there can be 3 levels. At layers 1 or 2, there can be at most 1 fragment of the same MSDU in a PSDU. In Layer 1 or Layer 2 acknowledgment methods, the success/failure state of each fragment may not be identified because the source explicitly knows the state of the transmitted fragment, which corresponds to the state of the MPDU reported in the acknowledgment.

In an uncorrelated multiple AP environment, if a Layer 1 or 2 mechanism is used, and if an MSDUn status indication is received from an AP that is not the originating MSDUn AP, the anchor AP may be unable to identify the missing fragment and the overall MSDUn pass/fail status may be based on on such an instruction. Only the sending MSDUn AP can know how to interpret the acknowledgment. To resolve this situation, an acknowledgment similar to a layer 3 bitmap (eg, k bits per MSDU) can be used.

In 802.11ax Layer 3 acknowledgment, the bit corresponding to the received fragment in the bitmap is set to 1, otherwise the bit is set to 0. With this mechanism, when a status indication is received from an AP that is not the sending AP MSUn, the binding AP is not will be able to identify the missing fragment and overall MSDUn success/failure status based on such an indication, since the binding AP has no knowledge of how many fragments the transmitting AP sent for the specified MPDU. For example, if the maximum fragments allowed per MSDU are k=4, then the bitmap for MSDN=1110, then the binding AP will have no information whether the specified MSDUn has 3 fragments and whether all of them are accepted, or whether the MSDUn has 4 fragments. and the first 3 were accepted.

To solve the above problem, the generation of the bitmap when the receiver receives the last fragment or the only fragment can be reconsidered. The bit positions for the same MPDU subsequent to the last fragment bit position can be set to 1. For example, in Table 1, k could be 4.

Table 1

Bitmap for MSDUn Number of MSUDun fragments Example of Binding AP/Host AP Bitmap Interpretation 1110 4 ^4th fragment not accepted 0011 3 or 4 ^1st and ^2nd fragments not accepted 1100 3 or 4 FN>=2 ( ^3rd and possibly ^4th fragments) not accepted 1111 1, 2, 3 or 4 All fragments accepted

In this method, the binding AP may know whether to generate a retransmission indication for the AP transmitting MSDUn. If such an indication is generated, the missing FN may be identified either explicitly (eg, FN=0, FN=1 on line 0011) or implicitly (eg, FN>=2 on line 1100) to the sending AP.

In one case, identical fragmentation may exist across multiple APs. Multiple transmitting MSDUn APs may use identical fragmentation. In the state indication, the sending AP may provide fragment pointers to the binding AP, which may contain the starting octet/length of each fragment and the number of fragments. The anchor AP may designate an additional MSDUn transmitting AP or may designate a new MSDUn transmitting AP to replace the current transmitting AP. The destination may contain fragment pointers. In this case, the retransmission from the other (i.e., new) transmitting AP may only contain the missing fragment not delivered by the original (i.e., old) transmitting AP. In an alternative embodiment, fragment pointers may be passed directly from the original MSDUn transmitting AP to the new/additional MSDUn transmitting AP.

In one case, when MSUDuns are sent to the sending AP, fragment pointers are determined by the anchor AP and are specified for each sending MSDUn AP. In this case, the transmission of fragments can occur simultaneously/independently from all transmitting MSDUn APs. The BA bitmap can be understood by all transmitting MSDUn APs to independently perform retransmission.

In one case, re-fragmentation and/or other fragmentation may exist in the new/additional transmitting AP. The designated new/additional MSDUn transmitting AP may not need the fragment pointer information from the original/old transmitting AP. An additional/new transmitting MPDUn AP may implement different fragmentation. Each transmitting AP may include an indication of refragmentation or a block acknowledgment request (BAR) in the MPDU, either explicitly or implicitly.

An implicit indication of refragmentation may be based on the MAC address of the sending APs if different sending APs have different MAC addresses. Fragments of the same MPDUn from different TAs may require the allocation of separate buffers for reassembly into non-AP STAs. The RA in the ACK/BA can identify which fragment of the transmitting AP acknowledges the non-AP STA.

An explicit indication of re-fragmentation may be included in the MPDU, BAR and BA. The indication may be a number, in which a higher/lower value may indicate more recent MSDUn fragmentation/transfer.

If a non-AP STA receives an MPDU that represents a fragment of MSDUn, it may do one or more things: it may maintain different reassembly buffers for MSDUn for each refragmentation indication, and/or it may only maintain a reassembly buffer for the most recent MSUDn re-fragmentation indications, where fragment(s) with older fragmentation indication(s) may be discarded.

A BA sent from a non-AP STA may include a corresponding re-fragmentation indication that is mapped to the MPDU re-fragmentation indication that it acknowledges.

In an alternative embodiment, the channel/band or AP identified without using the MAC address from which the MPDU is received, or to which the BA is sent, may serve as an implicit indication of re-fragmentation. For example, for a non-AP STA, the same MPDU received from different APs or on different channels is not guaranteed to have identical fragmentation and may be independently reassembled.

In one case, an indication of refragmentation may exist in the MPDU or BAR, as shown in the illustration of FIG. 4. As shown, the sequence control field of the MPDU may contain a fragment number (FN) 402 (eg, B0-B3) and a sequence number (SN) 403 (eg, B4-B15). The most significant bits (MSBs) of the FN field 402 may be used to indicate refragmentation, as shown by the shaded bits 404. For example, if a maximum of 4 fragments are allowed per MSDU, then the 2 MSBs of the FN field (eg, B2 and B3) may be used as an indication of re-fragmentation. The re-fragmentation indication may be increased/decreased for each new/additional MSDUn transmitting AP. The value of this indication can be assigned to the anchor AP. For example, in the initial transmission from the transmitting APx, the MSDU is fragmented into 3 fragments. 2 MSB (eg B2 and B3) FN fields can be set as 00, while 2 LSB can be set as 00~10 for FN=0~2. When retransmitted from the transmitting APy, the MSDU may be fragmented into 2 fragments. The 2 MSBs of the FN field can be set as 01, and the 2 LSBs can be set as 00~01 for FN=0~1. The recipient may not use fragments from another refragmentation indication to reassemble the MSDU. In the above example, the receiver may discard buffered fragments from the refragmentation indication =00 and SN (sequence number) =n that cannot be collected in MSDUn when it receives an MPDU with a newer refragmentation indication =01 and SN=n .

In one case, there may be an indication of re-fragmentation in the Block Ack. Reserved bits in the BA control field or reserved values in the TID_INFO, FN subfield, Per AID TID Info subfield, or a combination of these reserved fields/values may be used to convey a refragmentation indication value. The value may not be the same as the refragmentation indication value in the corresponding MPDU or BAR, but the value sent in the MPDU/BAR and the value sent in the BA can have a 1 to 1 mapping so that the AP (bindings) can correctly interpret the reception status of the specified refragmentation example.

Regarding the issue of packet number (PN) assignment, in a multi-AP, multi-link environment, each packet sent by a particular AP may need to be assigned a packet number to be used for encryption algorithms. In general, the packet number should not be repeated if different APs use the same key. A rephrased question might be how to design packet assignment protocols to ensure that packet numbers are not repeated by APs in the same set of multiple APs that share the same keys.

In one case, each AP may use different keys. If different forwarding APs emerge to have different MAC addresses for non-AP STAs, then reusing existing transition key (TK) generation can generate different TKs for each forwarding AP. This can avoid the assignment of the same PN from different APs transmitting different MPDUs to non-AP STAs.

The MAC addresses of the transmitting APs may be provided to the requesting device (eg, non-AP STA) during the 4-way handshake. For example, the addresses may be specified in the first message from the authenticator (eg, AP) to the supplicant device (eg, STA).

Alternatively, an additional input may be added to the pseudo-random function (PRF) that corresponds to the index (i) of the transmitting AP. In fig. Figure 5 shows a diagram of an example of PTK formation. In this example, the index i corresponding to the transmitting AP can be combined with the current parameter B PRF-Length(K,A,B), for example where B=Min(AA,SPA)||Max(AA,SPA)||Min (ANonce,SNonce)||Max(ANonce,SNonce)|| i, which can be used to derive the pairwise transient key TK (PTK) 503 of the transmitting AP from the pairwise master key (PMK) 501. In this alternative, the authenticator can specify the maximum number of PTKs to be deduced, (i.e., the range of i) before deriving the key . The anchor AP can then designate the transmitting AP corresponding to index i. PTK 503 can be used to determine EAPOL-Key 504, EAPOL-Key 505 and temporary key 506. PTK 503 is the union of EAPOL-Key 504, EAPOL-Key 505 and temporary key 506. EAPOL-key 504 is used to ensure authenticity of data origin in 4-way handshake and group key handshake messages, EAPOL-key 505 is used to ensure data confidentiality in 4-way handshake and group key handshake messages. The temporary key 506 is used to protect individually addressed communication between the AP and the STA outside of the 4-way handshake and in group key handshake messages.

In some cases, the same key may be used for each AP. Some scripts may not allow fragmentation or may use fragmentation in a specific way. For example, fragmentation may not be allowed in the sending MSDUn AP. Alternatively, techniques related to fragmentation across multiple STAs/APs as described herein may be used such that there is no need to fragment the MSDU on the AP transmitting the MSDUn. In either scenario, the anchor AP can assign a packet number (PN) when there is a 1 to 1 mapping of MSDU to MPDU.

In one scenario, there may be a partition of the PN space based on the maximum number of transmitting APs. PN assignment can be hierarchical. The binding AP may determine a subset of bits based on the maximum number of transmitting APs, while each transmitting AP may independently assign the remaining bits. For example, if there are 4 transmitting APs, the anchor AP may assign 2 MSB PN 00~11 to each of the APs. Each AP then independently generates an LSB for the PN. In this example, 3 PNs are generated using the same transmitting AP MSDU, in which the MSDUn is fragmented into 3 MPDUs. 3 PNs share 2 MSBs and different LSBs. PNs generated in different transmitting APs may have different 2 MSBs but the same LSBs.

In one scenario, the PN space may be partitioned based on the maximum number of fragments. The PN may be generated at the anchor AP at intervals equal to the maximum number of fragments allowed for non-AP STAs. For example, the maximum number of fragments allowed is 4, and when the anchor AP sends MSDUn to the sending APx, it may also have a PNx where PNx%4=0 (PNx Mod4 is zero). The actual PN carried in the MPDU is then PNn+FN, where FN is the fragmentation number of the MSDUn fragment. When an anchor AP transmits an MSDU to an additional transmitting APy MSDUn, a new PN=PNy may be generated for the same MSDUn where PNy%4=0.

In one scenario, a change to the nonce may exist without partitioning the PN space. In this alternative, the nonce field values can be split into separate sets. The Nonce field of another security protocol may be shown in FIG. 6 and fig. 7. In FIG. 6 is a diagram of an example Nonce field in CBC-MAC Protocol (CCMP) counter mode, which may include Nonce flags 611, the MAC address of the STA identified by A2 612 and/or PN 613. Each octet of 601 bits may represent 8 bits, and the 611 Nonce flags (e.g. O1) may represent 4 621 priority bits (e.g. B0-B3), 1 622 control bit (e.g. B4), 1 623 - PN1 bit (e.g. B5) and/or 2 zero 624 (for example, B6 and B7). In fig. 7 is a diagram of an example Galois/Counter Mode Protocol (GCMP) Nonce field, which may include A2 711 and PN 712.

The PN may be assigned to the transmitting AP, where the PN is independently generated by each transmitting AP without sharing the number space. If another transmitting AP has a different MAC address, then the uniqueness of the Nonce is guaranteed. If another transmitting AP has the same MAC address (A2), then the non-AP STA and the transmitting AP can be based on the index of the transmitting AP, which can be mapped to the PPDU channel/band. For example, A2 can be used to construct Nonce = original A2 + AP index.

The PN may be assigned to the anchor AP, where the PN is generated by the anchor AP without taking into account the number of fragments created at the sending AP (eg, increased by 1 for each MSDU). To retransmit the MSDU to another sending AP, a new PN may be generated. The non-AP STA and the transmitting AP can be based on the FN to modify the A2 field (eg, A2 can be used to construct Nonce=original A2 + FN).

Regarding fragmentation across multiple STAs/APs, current fragmentation designs to improve the balance of data flow across available links, improve latency, and improve reliability may not be sufficient. A rephrased question might be how to design more efficient fragmentation in other parts of the multi-link MAC architecture.

In one case, fragmentation may exist across multiple STAs/APs. The upper MAC layer can control data flows to and from the lower MAC layer SAPs, and, if so, the upper MAC layer peer can also control data flows to and from the lower MAC layer SAPs below. Flow control may include packet fragmentation, packet aggregation, multi-packet encoding/decoding, packet duplication, packet retransmission, fragment retransmission, fragmentation of aggregated packets for retransmission, acknowledgment control, block acknowledgment control, HARQ control, data management functions . This functionality can be used to: improve the balance of data flow across available communication lines (for example, each communication line can be controlled to provide a data rate appropriate to the communication line conditions and wireless load on the channel); increasing the effective data flow rate (i.e. increasing productivity); reducing latency; and/or improving transmission reliability (eg, fragmentation may involve some redundancy).

In one scenario, there may be an improvement in data flow balance. The upper layer MAC can be informed of the throughput and latency of all individual lower layer MACs, which are managed based on performance, and additional WLAN radio measurements can be made available for each upper layer MAC individually. This information can be used by the upper layer MAC to balance data flows on each of the available links, optimizing the overall performance of a multi-link link (eg, a live link arranged by combining multiple links). The upper MAC layer may optimize the link based on one specific metric or a combination of multiple metrics, such as data rate, signal latency, reliability, or any other performance metric. This can be done dynamically, based on real-time or near real-time link information, or based on averaged performance over a longer period, or any other combination of link management performance metrics (e.g. individual load for communication line).

In one scenario, the effective data flow can be increased. Efficient data flow through a multi-link link can combine the capacity of individual links to create an effective bandwidth much greater than that of any single link. Modern 802.11 broadband links rely on wideband channels (eg, 80, 160 MHz) to provide high throughput. However, these broadband links sometimes have problems with a narrow bandwidth of traffic (eg 20 MHz) part of the shared traffic of their broadband link, which can result in packet loss or packet delay as different MAC techniques (eg in headers) are used to achieve sharing narrowband and broadband channels. Channel aggregation across multiple links should not be dependent on these techniques because multiple channels can be aggregated to provide broadband capacity without requiring all channels to be transparent for transmission at the same time. In addition, multiple links may provide 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 their effective channel bandwidth and therefore throughput, which should be higher than the 20, 40, 60, 80 or 160 MHz currently allowed. For example, the effective channel bandwidth may include two 20 MHz channels in the 2.4 GHz band, three 80 MHz channels in the 5 GHz band, and an 80 MHz channel and a 40 MHz channel in the 6 GHz band, resulting in an effective bandwidth of 400 MHz. In addition to the ability to combine these channel resources into significant effective bandwidth, each channel can be optimized for performance based on the radio characteristics of the link and the availability of the link; This ensures that the entire network is optimized while maintaining required performance targets.

In one scenario, reduced latency may exist. The MAC, as described herein, can also optimize overall link performance in terms of signal delay. Because the 802.11 standard uses contention-based channel access, access to any given resource can be delayed by a resource in use. If data transmission is forced to be based on a single transmission link, the transmission delay depends on the collision resolution mechanism of the single link. However, when using multiple communication links, channel contention resolution may be distributed across multiple channels, with each channel having its own contention resolution mechanism. This distribution over multiple channels can have the effect of reducing latency since data can be transmitted on any of the channels. The next packet can be transmitted on any of the channels that is available next, etc., which statistically reduces the transmission delay.

In one scenario, there may be increased reliability. The upper MAC layer also optimizes the performance of the entire communication link in terms of reliability. This can be achieved by sending redundant packets over multiple links and combining the received packets into a MAC. Also, the packet may be encrypted such that part of the packet is sent over multiple links, and then the encrypted received packets are combined to improve the reliability of the multilink channel.

Regarding the issue of multi-link acknowledgment, a WLAN device may operate over different communications links when transmitting. Acknowledgments or aggregated acknowledgments of previous transmissions over multiple links can be used to reduce signaling overhead and provide a more flexible, low-latency feedback mechanism. To solve this problem, there may be detailed procedures for coordinating data transmission and multilink acknowledgments, such as a multilink acknowledgment procedure.

In multi-link communications, an STA that is capable of operating on more than one link (ie, a multi-link capable STA) may communicate with another STA that is capable of operating on more than one link. As described herein, a communication link may refer to a band or a channel. In one architecture, a multi-link capable STA may have a unique MAC address on multiple links. Transmissions over multiple links may have the same sequence number space, so that the receiver may be able to sequence packets received from different links. In one example, data transmission and acknowledgment may occur over different communication links. Or data transmissions may be carried out over N links, while acknowledgment may be sent over M links.

The STA and AP may exchange acknowledgments over multiple links using control/control frames such as probe request, probe response, beacon, associate, and/or reassociate frames.

In one case, there may be a delayed acknowledgment (ACK) of a block over multiple links. To provide multi-link acknowledgment, there is a need for a modified approach to block negotiation and acknowledgment procedures. In fig. 8 is a diagram of an example of a delayed block acknowledgment procedure.

As shown in FIG. 8, a first STA, such as STA 801, may begin negotiating a block acknowledgment with a second STA, such as STA 802. STA 801 may request a channel on link 810 and, at step 811, transmit to STA 802 an add block acknowledgment (ADDBA) request frame. over multiple communication lines (ML). In the ML request frame, ADDBA Req STA 801 may include multi-link negotiation, sequence_space, TID setting, buffer_size, and/or other related information as described herein.

The buffer_size parameter is a subfield that can be used to negotiate a buffer size between the sending STA and the receiving STA. In one method, the transmitting STA and the receiving STA may negotiate a buffer size for each link. The link index may be used for this negotiation. STAs may maintain a buffer for each link. Each link can have a different buffer size. In one method, the transmitting STA and the receiving STA may negotiate a total buffer size for all available operating links. STAs can maintain a buffer for all links.

The sequence_space parameter is a subfield that can indicate whether the same sequence space can be used for multiple links. In case multiple sequence spaces can be used for multiple links, the link index along with the sequence number can be used to assemble packets.

The multi-link negotiation subfield may be one or more pieces of information such as: acknowledgement_link; ACK_in_different_link; aggregation of ACK/BA across multiple lines cross_link_fragmentation; and/or operating_link.

The acknowledgement_link subfield may indicate over which link the acknowledgment may be sent. One method may use a link bitmap. For example, if the receiving STA can operate on N links, then the bitmap can contain N bits. Each bit may indicate whether the corresponding communication link can be used to transmit acknowledgment(s). In one method, link indices may be carried explicitly to indicate the corresponding link(s) that may be used to transmit the acknowledgment. A special link identifier may be used to indicate that all links may be used.

ACK_in_different_link is a subfield that may indicate an acknowledgment that may be sent on a link other than the data link. In one method, if notified, STA2 may be allowed to transmit a block acknowledgment over a link that may be available before other links.

Multi-link ACK/BA aggregation is a subfield that may indicate whether multi-link ACK/BA aggregation is enabled. Here, the aggregated ACK/BA may be a procedure that allows the ACK/BA sent on link k to indicate data transmission on link (L ₁ ... L _M ).

The Cross_link_fragmentation parameter is a subfield that can indicate whether a fragmented MSDU can be carried across multiple links.

Operating_links is a subfield that may indicate operating links for the transmitting STA. Alternatively, this subfield may be used to negotiate operating links between transmitting STAs and receiving STAs. For example, a transmitting STA may include its operating lines in this subfield in an ADDBA request frame. A set of operating communication lines may be designated S_tx. The receiving STA may select in S_tx the links that the receiving STA is capable of operating and enter them in the Operating_links subfield when the receiving STA sends back an ADDBA response frame.

As shown in FIG. 8, STA 802 may respond to STA 801 with block acknowledgment negotiation. In particular, STA 802 may transmit an ADDBA response frame over multiple links (ML) to STA 802 at step 812. In the ML_ADDBA request frame, STA 801 may include one or more pieces of information. In the ML_ADDBA response frame, the STA 802 can indicate its settings. Upon receiving the response, the STA 801 may adjust its BA transmission procedures accordingly.

The above exchange of ADDBA request/response frames may occur over other link(s) (eg, link 820). The exchange may also occur differently in some aspects. In one case, STA 801 may request channels on all links and transmit an ADDBA request frame simultaneously on all links. In one case, STA 801 may perform independent EDMA/CA over multiple links, where STA 801 may transmit immediately upon a link request. In some cases, an ADDBA request/response frame may be defined using one of the following: ADDBA request/response frames may be duplicated over multiple links, with each frame containing information about multiple links; and/or multi-link ADDBA request/response frames may be different, where each frame may carry general multi-link information and link-specific information.

After exchanging the ADDBA request/response, STA 801 may transmit data frames on communication link 810 and communication link 820 (eg, 813, 814, 823, 824). Transmissions may correspond to settings negotiated in ADDBA request/response frames (eg, 811, 812, 821, 822).

After transmitting the data frames, the STA 801 may transmit a BA request frame 815. In this frame, STA 801 may indicate whether an immediate or deferred BA is being requested. STA 801 may also indicate whether a multilink BA or an aggregated multilink BA may be requested. In the example shown in FIG. 8, a deferred BA may be requested.

STA 802 may respond with an acknowledgment frame 816 after receiving a BA request frame, where an ACK frame 816 acknowledges the recently received BA request frame 815.

Based on the ADDBA negotiation, STA 802 may prepare to transmit a BA on one or more links (eg, 810 and/or 820). Typically, the ACK/BA may include acknowledgments for MPDUs from multiple links/APs and/or acknowledgment of QoS data frames with two or more TIDs using the BA. If multilink aggregation is agreed upon, the STA 802 may transmit the multilink aggregated BA 817; Note that the BA for one link (eg, 810) and/or all links (eg, aggregated 810 and 820) may be transmitted on another link (eg, 820). For example, see BA 817 sent over link 820 at step 832. All examples and functions described using link 810 may also occur via link 820, and vice versa.

Note for FIG. 8 that although only two STAs are explicitly shown, there may be four logical STAs (e.g., one for each end of a link), where each link may correspond to its own link between the two logical STAs and where in each physical unit/package An STA (eg, each STA 810 and STA 820) has a plurality of logical STAs.

In one case, there may be a procedure for immediately acknowledging a block over multiple links, as shown in FIG. 9, different from the example in FIG. 8, which shows the BA request. To provide multi-link acknowledgment, there may be a change in the block negotiation and acknowledgment procedure. As shown, exchange of ADDBA request/response frames over multiple links (eg, 911, 912, 921, 922) may occur on one or more links as described herein (eg, 910 and 920). After an ADDBA request/response exchange (eg, 911, 912, 921, 922), STA 901 may transmit data frames (eg, 913, 914, 923, 924) on link 910 and link 920. Transmissions may follow settings negotiated in ADDBA request/response frames (for example, 911, 912, 921, 922).

After transmitting the data frames, STA 901 may transmit a BA request frame (eg, 925) over one of the links (eg, 920). In this frame, STA 901 may indicate whether an immediate or deferred BA is being requested. STA 901 may also indicate whether a multi-link BA or an aggregated multi-link BA may be requested. In one case, the BA may be transmitted over the same link as the BAR. In one case, STA 901 may transmit a BAR over link 920, and this indirectly indicates that BA transmission should also be performed over link 920. In our example, an immediate aggregated multi-link BA 926 is requested.

STA 902 may prepare an aggregated multi-link BA and transmit it (eg, 926) over the link over which the BAR was sent.

Similarly for Fig. 8, although only two STAs are explicitly shown, there may be four logical STAs (e.g., one for each end of a link), where each link may correspond to its own link between the two logical STAs, and where in each physical block/frame an STA (eg, in each STA 910 and STA 920) there are multiple logical STAs.

In one case, there may be an acknowledgment (ACK) of a multilink block across the main link. The main link may be predefined and negotiated by the AP and associated STAs. Simplified frame exchange with ADDBA request/response may be used. In this frame exchange, the STAs may negotiate what may be allowed by the BAs with multiple links. BAR and BA frames may be transmitted over the main link. The main link procedure/negotiation may be similar to other negotiations/procedures described in this document.

In one case, BA frames with multiple communication links may exist. In the above procedures related to FIGS. 8 and 9, reference is made to STAs, which may be non-AP STAs and/or AP STAs. In the above procedures related to FIGS. 8 and 9, some frames may need to be modified. For example, a multilink BA functionality element and/or a multilink ADDBA request and a multilink ADDBA response may be defined as an action frame. Table 2 may define an ADDBA request/response action frame format with multiple communication lines. The underlined fields in Table 2 are subject to change. Italic fields may be modified or reinterpreted to accommodate multiple link attributes as described herein.

Table 2. Action field of the modified ADDBA ML request/response frame

The block acknowledgment action field values can be changed in Table 3. Two new fields can be added, ADDBA ML Request and ADDBA ML Response:

Table 3. Modified block action fields

The block acknowledgment parameter set field can be modified in Table 4. A new link field, Links, with x bits has been added. In one method, the Links field may indicate communication links for both data and acknowledgment transmission. In one method, the Links field may have two subfields. One subfield may be dedicated to data links and another to acknowledgment links.

Table 4. Modified block confirmation parameter set field

The Block Ack Timeout Value field can indicate the timeout value for BAs on all links. In one example, a block acknowledgment delay value may be transmitted for each link.

The block acknowledgment start sequence control may be a sequence number space used for all links, and this field may indicate the start sequence for frames across all links. In one example, multiple sequence number spaces are used for multiple links, and this field may indicate a start sequence for each link.

Table 5 shows an example of including a block acknowledgment request (BAR) frame. The underlined fields can be modified to implement multiple link BAR (ML BAR).

Table 5. Modified Block Acknowledgment Request Frame

The BAR Control field can also be modified as shown in Table 6. A reserved combination of Multi-TID, Compressed Bitmap and GCR can be used to indicate the presence of a multi-link BAR.

Table 6. Modified block confirmation request control field

In one method, the BAR Management field defined in the 802.11ax standard is shown in Table 7. A reserved value in the BA type can be used to indicate that it represents an ML BAR.

Table 7. Modified 802.11ax BAR Control field

If the combination may indicate a BAR with multiple links, the BAR Info field may have a Multi-links field. This field may indicate the communication link for BA transmission. The value may be used to indicate that the BA can be transmitted across all communication links. The value may be used to indicate that the BA can be transmitted on the same link as the BAR.

The BA frame is defined in the 802.11 standard. The underlined fields may be modified to implement multiple link BA (ML BA).

Table 8. Modified block acknowledgment frame

A reserved value in the BA Control field can be used to indicate that this is an ML BA. Once this field is set to indicate the ML BA, the BA Information field may have Per Link Info fields. Each Per Link Info field may contain a Link ID field and corresponding confirmation type and BA information.

In one case, there may be block acknowledgment procedures in a multiple STA with multiple links (ML MU BA) that provide aggregation of acknowledgments from multiple STAs and multiple links.

The STAs and APs may exchange multi-STA multi-link acknowledgments using control/control frames such as probe request, probe response, beacon, associate and/or reassociation frames.

In fig. 10 is a diagram illustrating an example of an acknowledgment procedure for a multiple STA with multiple links. In this example, a plurality of STAs (eg, STA 1001, STA 1002, STA 1003) may transmit UL frames to an AP (eg, AP 1000) over one or more links (eg, 1010 and 1020). An ML MU BA procedure may be defined to aggregate acknowledgment transmissions from an AP to one or more STAs over one or more links.

An AP 1000 with ML MU acknowledgment functionality may schedule UL transmissions for STAs with ML MU acknowledgment functionality (eg, STAs 1001 and 1002) by transmitting one or more ML MU Trigger frames 1011 on an available link 1010. In one case, transmission of an ML MU Trigger frame over multiple communication links may be synchronized. The AP 1000 can detect and query channels and simultaneously transmit ML MU Trigger frames. In one case, the MU ML Trigger frame may be transmitted on each available link asynchronously, immediately before the UL activated PPDU. In the example shown in FIG. 10, AP 1000 may detect a channel on both communication link 1010 and communication link 1020. Communication link 1010 may be available first, and AP 1000 may transmit ML MU Trigger frame 1011 to initiate transmission from STA 1001 and STA 1002. Communication link 1020 may then be available, and AP may transmit ML MU Trigger frame 1021 to initiate transmission from STA 1001 and STA 1003. In a Trigger ML MU frame, the AP may indicate one or more pieces of information.

One example of this information is whether aggregated acknowledgment of multiple STAs with multiple links can be supported. For example, one field may indicate that the start frame is an ML MU Trigger and ML MU acknowledgments may be expected.

One example of such information may be a list of communication lines for the ML MU BA. This list may include communication lines over which the aggregated ML MU BA can be performed. STAs transmitting on a specified link may wait to receive an ML MU BA on the same or a different link.

One example of this information may be a sequence_space subfield. This subfield may indicate whether the same sequence space can be used for multiple links. In case multiple sequence spaces can be used for multiple links, the link index along with the sequence number can be used to assemble packets.

One example of this information may be a Buffer_size subfield. This subfield may be used to negotiate a buffer size between the sending STA and the receiving STA. In one method, a receiving STA (eg, which may be an uplink AP) may determine a buffer size for each intended STA across all links and inform the STA in the MU Trigger ML frame. The AP may specify a buffer size in a common field of the trigger frame, which may be a value commonly used by all STAs. Alternatively, the AP may specify a buffer size in a field of a particular STA in the trigger frame, which may differ between STAs. In one method, a receiving STA (eg, an uplink AP) may determine a buffer size for each intended STA on each link and inform the STA in the MU Trigger ML frame. The AP may specify a common buffer size field in the trigger frame, which may be a value commonly used by all STAs on a single link. Alternatively, the AP may specify a buffer size in a field of a specific STA in the trigger frame, which may differ for individual links in different STAs. Alternatively, the buffer information may be carried in control frames such as an association request/response, a beacon frame, a probe request/response frame, and the like.

Upon detection of the MU Trigger ML gene frame(s), the desired STA can prepare UL transmission over the link. The UL packet size may be limited by the buffer size allowed by the AP. The STA may expect the acknowledgment to be based on the data in the ML MU Trigger frame. For example, if ML MU BA is supported, the STA may wait for an aggregated ML MU BA frame transmitted from one of the operating links.

Frame Trigger ML MU can be defined as a trigger type. For example, the Trigger Type field located in the Common Info field may be modified to have the value of indicating a Trigger ML MU frame, as shown in Table 9.

Table 9

Trigger Type subfield value Trigger frame option 0 Base 1 BF Report Polling (BFRP) 2 MU-BAR 3 MU-RTS 4 Buffer Status Report Polling (BSRP) 5 GCR MU-BAR 6 Bandwidth Query Report Polling (BQRP) 7 NDP Feedback Report Survey (NFRP) 8 Trigger ML MU 9-15 Reserved

The Trigger Dependent User Information field, located in the User Info field of the trigger frame, may contain one or more of the following information: the size of the buffer per user among all links; buffer size per user per communication line; list of working communication lines; and/or a communication link for transmitting an acknowledgment. The acknowledgment link field may be used to indicate the communication link over which the acknowledgment may be sent. Also, the address field in the ML MU Trigger frame can be modified. For example, the transmitter address may be the address of a virtual AP, where the virtual AP represents an AP on a plurality of links.

Although the features and elements of the present invention are described in preferred embodiments in certain 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.

Although the solutions described in this document relate to specific 802.11 protocols, it should be understood that the solutions described in this document are not limited to this scenario and are also applicable to other wireless systems.

Although example designs and procedures use SIFS to indicate various interframe intervals, the same solutions may use any other interframe intervals, such as RIFS, AIFS, DIFS, or other negotiated time intervals.

Although some graphics show four RBs per initiated TXOP as an example, the actual number of RBs/channels/bandwidths used may vary.

As described herein, systems, methods, and devices may exist for implementing multi-link wireless local area networks (WLANs). One or more multilink stations (STAs) devices (MLDs) without an AP, and one or more access point (AP) MLDs can establish a multilink association with each other, thereby creating a multilink connection that provides improved and more efficient wireless communications.

Although the features and elements are described above in specific combinations, one skilled in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic 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), register, cache memory, semiconductor storage devices, magnetic media such as internal hard drives and removable drives, magneto-optical media and optical media such as CD-ROMs and digital versatile discs (DVDs). The processor, in combination with software, may be used to implement an RF transceiver for use in a WTRU, UE, terminal, base station, RNC, and/or any host computer.

Claims (23)

1. A communication method implemented by a multi-link device (MLD) without an access point (non-AP), which method includes: detecting an access point (AP) based on a message received from the MLD AP, wherein the message contains a beacon or response to a request from the non-AP MLD, wherein the message contains an association identifier associated with the plurality of links for operating the non-AP MLD with the plurality of links; And exchanging information with the MLD AP using multi-link operation based on the association identifier. 2. The method of claim 1, wherein the message contains an MLD identifier without an AP, the identifier comprising a medium access control address. 3. The method of claim 1, wherein there is a physical layer and a logical entity in the non-AP MLD and the AP MLD for each link of the plurality of links in multi-link operation. 4. The method of claim 1, wherein the response comprises a beacon, wherein said beacon includes a multi-link element that indicates the multi-link capability of one or more APs associated with the MLD AP. 5. The method of claim 1, wherein the non-AP MLD includes a plurality of stations. 6. The method according to claim 1, further including receiving channel information for operation with multiple communication lines. 7. The method of claim 1, wherein the MLD AP comprises a plurality of APs, and wherein the MLD AP and the plurality of APs are detected based on a message containing an association identifier associated with the plurality of multiline operating lines. 8. Method according to claim 1, including: sending a multi-line operation request to the MLD AP via the first communication link, the request including a non-AP MLD identifier, said identifier being a media access control address; And receiving a message on the first line in response to a request. 9. A multi-line communication device (MLD) without an access point (AP), wherein said MLD without an AP comprises a processor operatively coupled to the transceiver and configured to: detecting an access point (AP) based on a message received from the MLD AP, wherein the message contains a beacon or response to a request from the non-AP MLD, wherein the message contains an association identifier associated with the plurality of links for operating the non-AP MLD with the plurality of links; communicating via the transceiver with the MLD AP using multi-link operation based on the association identifier. 10. The non-AP MLD of claim 9, wherein there is a physical layer and a logical entity in the non-AP MLD and the AP MLD for each link of the plurality of links for operating the plurality of links. 11. The non-AP MLD of claim 9, wherein the response comprises a beacon, wherein said beacon includes a multi-link element that indicates the multi-link capability of one or more APs associated with the MLD AP. 12. The AP-less MLD of claim 9, wherein the processor is configured to receive channel information for multi-link operation via the transceiver. 13. The non-AP MLD of claim 9, wherein the non-AP MLD includes a plurality of stations. 14. The non-AP MLD of claim 9, wherein the MLD AP includes a plurality of APs, and wherein the MLD AP and the plurality of APs are discoverable based on a message containing an association identifier associated with the plurality of multiline operating lines. 15. The non-AP MLD of claim 9, wherein the message contains an identifier of the non-AP MLD, the identifier comprising a medium access control address. 16. MLD without AP according to claim 9, in which the processor is configured to: sending, by the transceiver, a multilink operation request to the MLD AP via a first communication link, the request including a non-AP MLD identifier, said identifier being a media access control address; And receiving via the transceiver on the first line a message in response to the request.