Method for artificial intelligence machine learning (AIML) media access control (MAC) and other operation management in wireless local area network (WLAN)

Abstract

A method performed by a station (STA) may include receiving a first artificial intelligence / machine learning (AIML) media access control (MAC) element from an access point (AP), the first AIML MAC element including information indicating that the AP supports AIML operation, the first AIML MAC element including at least one of an AIML MAC restriction field and an AIML MAC parameter field. Further, the STA may transmit a second AIML MAC element to the AP, the second AIML MAC element including information indicating that the AP supports the AIML operation, the second AIML MAC element including at least one of an AIML MAC restriction field and an AIML MAC parameter field.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 63 / 488,298, filed March 3, 2023, and U.S. Provisional Application No. 63 / 463,408, filed May 2, 2023; the contents of all of which are incorporated herein by reference. Summary of the Invention

[0002] A method performed by a station (STA) may include: receiving a first artificial intelligence / machine learning (AIML) media access control (MAC) element from an access point (AP), the first AIML MAC element including information indicating that the AP supports AIML operations, the first AIML MAC element including at least one of an AIML MAC restriction field and an AIML MAC parameter field. In addition, the STA may send a second AIML MAC element to the AP, the second AIML MAC element including information indicating that the AP supports AIML operations, the second AIML MAC element including at least one of an AIML MAC restriction field and an AIML MAC parameter field.

[0003] The AIML MAC Restriction field may include at least one of a Carrier Sense subfield, a Spatial Reuse subfield, a Submit to NAV subfield, a Backoff subfield, and a Service Period (SP) Only subfield. The Carrier Sense subfield may indicate whether the AIML-based channel access algorithm uses carrier sensing to access the channel. The Spatial Reuse subfield may indicate whether the AIML-based channel access algorithm uses spatial reuse to access the channel. The Submit to NAV subfield may indicate whether the AIML-based channel access algorithm must obey NAV. The Backoff subfield may indicate whether the AIML-based channel access algorithm must follow backup rules. The SP Only subfield may indicate whether the AIML-based channel access algorithm is allowed only in specific SPs.

[0004] The AIML MAC Restriction field may include at least one of a priority subfield, a contention window parameter subfield, a minimum wait time subfield, a backoff parameter subfield, and an AIML model sharing parameter subfield. The priority subfield may indicate the priority of a service accessing a channel using an AIML-based MAC algorithm. The contention window parameter subfield may indicate one or more parameters for a service accessing an AIML-based channel. The backoff parameter subfield may specify one or more parameters that the AIML-based channel access algorithm must comply with when a collision occurs or a transmission fails. The AIML model sharing parameter subfield may specify one or more parameters for sharing an AIML model in a downlink or uplink. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0006] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;

[0007] FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in Figure 1A according to an embodiment; FIG. 1A

[0008] FIG. 1C is a system diagram illustrating an example wireless access network (RAN) and an example core network (CN) that can be used within the communications system 100 shown in Figure 1A according to an embodiment; FIG. 1A

[0009] FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that can be used within the communications system 100 shown in Figure 1A according to an embodiment; FIG. 1A

[0010] FIG. 2 is an example design of an artificial intelligence machine learning (AIML) medium access control (MAC) element;

[0011] FIG. 3 is an example format of an AIML MAC restriction field;

[0012] FIG. 4 is an example format of an AIML MAC parameters field;

[0013] FIG. 5 is an example format of a modified station (STA) information field of an extremely high throughput (EHT) null data packet announcement (NDPA) frame; and

[0014] FIG. 6 is an example format of an enhanced STA information field in an EHT NDP announcement frame;

[0015] FIG. 7 is an example format of an enhanced STA information field in an EHT NDP announcement frame;

[0016] FIG. 8 is a first example format of a modified EHT MIMO control field format;

[0017] FIG. 9 is a second example format of a modified EHT MIMO control field format;

[0018] ​​​FIG. 10 is an example of a non-TB sounding sequence with enhanced MIMO control field;

[0019] FIG. 11 is an example of an adaptive sounding protocol; and

[0020] FIG. 12 is an example format of a modified STA info field of an EHT NDPA frame. DETAILED DESCRIPTION

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

[0022] As FIG. 1AAs shown, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which can be referred to as a station (STA), can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environments), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0024] The base stations 114a can be part of the RAN 104, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrums. A cell can provide wireless service to a particular geographic area that can be relatively fixed, or can vary as users in the cell move throughout the network. The cell can also be divided into cell sectors, each of which can be associated with a base station. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In one embodiment, the base station 114a can employ multiple-input multiple-output (MIMO) techniques, and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0025] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

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

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

[0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.

[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

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

[0032] The RAN 104 can be in communication with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ NR radio technology, the CN 106 can also be in communication with another RAN (not shown) employing 5G, GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0033] ​CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice telephony. The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 or a different RAT.

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

[0035] FIG. 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B shown, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0036] The processor 118 can 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While FIG. 1B The processor 118 and the transceiver 120 are depicted as separate components, but can be integrated together in an electronic package or chip.

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

[0038] Although the transmit / receive element 122 is depicted in the WTRU 102 FIG. 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to enable the WTRU 102 to transmit and receive wireless signals over the air interface 116.

[0039] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

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

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

[0042] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or

[0043] The processor 118 can further couple to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands- free headset, a Bluetooth® The peripheral 138 can include a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, an electronic game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral 138 can include one or more sensors. The sensors can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor; a geo-location sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a posture sensor, a biometric sensor, a humidity sensor, etc.

[0044] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals (e.g., some or all signals associated with particular subframes for both the UL (e.g., for transmission) and the DL (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or substantially eliminate self-interference and / or cross- interference due to concurrent transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals (e.g., some or all signals associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)) can be concurrent but not simultaneous.

[0045] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

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

[0047] Each of eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. FIG. 1C

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

[0049] MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

[0052] ​The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can facilitate communications with other networks 112. Other networks 112 can include other wired or wireless networks that are owned and / or operated by other service providers. In

[0053] Although WTRUs are described in FIGS. 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such terminals can use, e.g., temporarily or permanently, wired communication interfaces with the communication network.

[0054] In representative embodiments, the other network 112 can be a WLAN.

[0055] A WLAN in an infrastructure Basic Service Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and can be delivered to the STAs by the AP. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations depending on the traffic. For example, traffic to other STAs in the BSS can be directed to the AP to be delivered to the other STAs. Traffic to other devices on the DS or other networks can be sent to the AP to be delivered to the other devices. Traffic from a STA in the BSS to a destination in the BSS can be sent directly to the destination by the source

[0056] When using an 802.11 ac infrastructure mode of operation or similar, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems, with collision avoidance. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If a particular STA senses / detects the primary channel and / or determines that the primary channel is busy, the particular STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

[0057] High Throughput (HT) STAs can use 40 MHz wide channels, for example, by combining the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0058] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can be parsed into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described 80+80 configuration operations can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0059] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.1 lac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metering type control / machine type communications (MTC), such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support (e.g., only support) for certain and / or limited bandwidths. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0060] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11η, 802.1 lac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA of all STAs operating in the BSS that supports the minimum bandwidth mode of operation. In the example of 802.11ah, for a STA (e.g., a MTC type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide, even though other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth modes of operation. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (only supporting a 1 MHz mode of operation) transmitting to the AP, all available frequency bands can be considered busy, even though most of the available frequency bands remain idle.

[0061] In the United States, the available frequency bands that 802.11ah can use are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available to 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0062] FIG. 1Dis a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

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

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

[0065] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c without also accessing other RANs, such as eNode-Bs 160a, 160b, 160c. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize signal transmission and reception over an unlicensed frequency band with gNBs 180a, 180b, 180c. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate / be connected with the gNBs 180a, 180b, 180c, while also communicating / being connected with another RAN, such as eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c can implement DC principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as the WTRUs' 102a, 102b, 102c mobility anchor point, and the gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to the WTRUs 102a, 102b, 102c serving as service WTRUs 102a, 102b, 102c.

[0066] Each of the gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking with E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b, and the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. FIG. 1D

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

[0068] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and can serve as the control node. For example, the AMF 182a, 182b can be responsible for authenticating the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the WTRU 102a, 102b, 102c registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b can utilize network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service plans the WTRUs 102a, 102b, 102c have subscribed to. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b can provide the control plane functionality to manage the WTRU 102a, 102b, 102c

[0069] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 106 by an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating IP address

[0070] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0071] The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface between the UPF 184a, 184b and the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0072] In view of FIGS. 1A-1D And FIGS. 1A-1D one or more or all of the functions described herein with reference to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices can be used to test other devices and / or to simulate a network and / or WTRU functionality.

[0073] A simulation device can be designed to implement one or more tests of one or more other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can directly couple to another device and / or can use over-the-air wireless communications to perform testing, for purposes of testing.

[0074] One or more simulation devices can perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in testing labs and / or non-deployed (e.g., testing) wired and / or wireless communication networks to implement test scenarios in order to test one or more components. The one or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communications via RF circuitry (e.g., which can include one or more antennas).

[0075] A wireless local area network (WLAN) in Infrastructure Basic Service Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or connectivity to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and be passed to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS can also be sent through the AP, where the source STA sends traffic to the AP and the AP delivers the traffic to the destination STA. Such traffic between STAs within a BSS is also known as peer-to-peer (P2P) traffic. Such P2P traffic can also be sent directly between source and destination STAs without using the AP. Such direct communication between source and destination STAs can occur, for example, when the STAs are in range of each other's wireless communication range and the required direct link setup (DLS) or tunneled DLS (TDLS) has been established. The WLAN can also have an independent BSS (IBSS) mode in which there is no AP and STAs communicate directly with each other.

[0076] Using the 802.11ac infrastructure mode of operation, the AP can transmit beacons on a fixed channel, typically the primary channel. This channel can be 20 MHz wide and is the operating channel of the BSS. This channel is also used by STAs to establish a connection with the AP. The basic channel access mechanism in 802.11 systems is carrier sense multiple access with collision avoidance (CSMA / CA). In this mode of operation, each STA, including the AP, senses the primary channel. If the channel is detected to be busy, the STA can back off. Thus, in a given BSS, only one STA can transmit at any given time.

[0077] In 802.11η, high throughput (HT) STAs can also use 40 MHz wide channels for communication. This can be achieved by combining the primary 20 MHz channel with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.

[0078] In 802.11ac, very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. The 40 MHz and 80 MHz channels can be formed by combining adjacent 20 MHz channels similar to 802.11η described above. The 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which can also be referred to as 80+80 configuration. For the 80+80 configuration, the channel coded data can be passed through a segment parser that splits the data into two streams. The IFFT and time domain processing is done on each stream, respectively. The streams can then be mapped on to two channels and the data is transmitted. At the receiving end, the mechanism is reversed and the combined data can be sent to the MAC.

[0079] 802.11af and 802.11ah support sub-1 GHz modes of operation. For these specifications, the channel operating bandwidths and carriers are reduced relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. One use case for 802.11ah is to support meter type control (MTC) devices in a macro coverage area. MTC devices can have limited capabilities, including support for only a limited bandwidth, but also include a requirement for very long battery life.

[0080] WLAN systems that support multiple channels and channel widths, such as 802.11η, 802.1 lac, 802.1 laf, and 802.1 lah, can include a channel designated as the primary channel. The bandwidth of the primary channel can, but does not necessarily, equal the maximum common operating bandwidth supported by all STAs in the BSS. Thus, the bandwidth of the primary channel is limited by the STA of all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.1 lah, if there is a STA (e.g., a MTC type of device) that only supports a 1 MHz mode, the primary channel can be 1 MHz wide, even though other STAs in the AP and BSS can support 2 MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes. All carrier sensing and NAV settings depend on the status of the primary channel (i.e., if the primary channel is busy, e.g., due to a STA that only supports a 1 MHz operating mode transmitting to the AP, then the entire available frequency band is considered busy, even though a large portion of it remains idle and available).

[0081] In the United States, the available frequency band that 802.1 lah can use ranges from 902 MHz to 928 MHz. In Korea, the range is from 917.5 MHz to 923.5 MHz; and in Japan, the range is from 916.5 MHz to 927.5 MHz. The total bandwidth available to 802.1 lah is 6 MHz to 26 MHz, depending on the country code.

[0082] Machine learning can be defined as a computer program that learns from experience "E" and a performance measure "P" on some class of tasks "T" in that its performance (measured by "P") on tasks in "T" improves with experience "E".

[0083] There are many different kinds of machine learning. Depending on the nature of the task "T" that the system will learn, the nature of the performance measure P that can be used to evaluate the system, and the nature of the training signals or experience "E" given to it.

[0084] Depending on the nature of the learning "signals" or "responses" available to the learning system, machine learning implementations can be divided into three main categories: (1) supervised learning; (2) unsupervised learning; (3) reinforcement learning.

[0085] In supervised learning, an algorithm can learn from example data and associated target responses (which can be by numerical or string labels such as classes or labels) in order to later predict the correct response when faced with new examples under the class of supervised learning. This approach is similar to how a human learns under the supervision of a teacher. The teacher provides good examples for the student to memorize, and then the student derives general rules from these specific examples.

[0086] In unsupervised learning, an algorithm can learn from examples that do not have any associated responses, leaving it to the algorithm to determine the data patterns itself. This type of algorithm can reorganize the data into something else, such as new features that can represent a class or a new series of unrelated values. They can help provide humans with insights into the meaning of the data and provide new useful inputs for supervised machine learning algorithms.

[0087] In reinforcement learning, a system or agent can have to learn how to interact with its environment. This can be encoded by a policy a = π(x) that specifies which action to take in response to each possible input x (derived from the state of the environment). Unlike supervised learning, the system can not be told which action to take is the best (i.e., which output to produce for a given input). Instead, the system can receive a signal of occasional rewards (or penalties) in response to the actions it takes. This is similar to learning from a critic who occasionally thumbs up or thumbs down, as opposed to learning from a teacher who tells you what to do at each step.

[0088] Federated learning is a machine learning setting whose goal is to train a high-quality centralized model while the training data is still distributed across a large number of clients, each of which has an unreliable and relatively slow network connection. Learning algorithms considered for this setting are on each round. Each client independently computes an update to the current model based on its local data and transmits this update to a central server where the client-side updates are aggregated to compute a new global update. A typical client in this setting is a mobile phone, and communication efficiency is paramount. Federated learning can enable mobile phones to collaboratively learn a shared predictive model while keeping all the training data on the device, decoupling the ability to do machine learning from the need to store data in the cloud. The training data is kept locally on the user’s mobile device, and the device is used as a node that performs computations on its local data in order to update the global model.

[0089] A simple implementation of federated learning can require each client to send back the full model (or the full model update) to the server on each round. For large models, this step is likely to become a bottleneck for federated learning due to a number of factors. One factor is the asymmetric nature of internet connection speeds: the uplink is typically much slower than the downlink. Thus, in federated learning, there are a number of ways to reduce the cost of uplink communication (from the client to the server). In structured updates, updates from limited stepsize can be learned, and they can be parameterized using a smaller number of variables. In sketched updates, the full model can be updated and then compressed before being sent to the server.

[0090] IEEE 3652.1 provides a blueprint for cross-organizational data usage and model building while meeting applicable privacy, security, and regulatory requirements. IEEE 3652.1 defines an architectural framework and application guide for federated machine learning, including: (1) description and definition of federated learning; (2) types of federated learning and applicable application scenarios for each type; (3) performance evaluation of federated learning; and (4) related regulatory requirements.

[0091] By adjusting parameters and selecting reward actions, the AIML algorithm can be used to optimize the operation of media access control in WLANs. An AP managing its own BSS can need to provide means to control the media access in its BSS and in the vicinity, and should have a certain level of control over the AIML-based MAC operation of STAs associated with it. In addition, the AP can also need to manage the AIML-based MAC operation in its own BSS to ensure fairness of channel access between STAs that are legacy devices and STAs that are AIML capable. Thus, one problem is how to provide an efficient MAC procedure for APs and STAs in order to effectively manage the AIML-based MAC operation within the network.

[0092] Another problem relates to compressed CSI feedback and fast determination of CSI reporting schemes. As the number of transmit / receive antennas increases, especially when an AP can need probe feedback from STAs associated with other APs in a multi-AP scenario, an efficient CSI compression scheme is desired, e.g., with reduced overhead due to reduced number of feedback bits with minimal packet error rate loss. To facilitate CSI feedback reporting, a new type of efficient CSI feedback reporting needs to be developed, especially when there are multiple CSI feedback reporting format candidates. In addition, when multiple CSI feedback reporting formats are available, including AIML enabled or non-AIML enabled CSI feedback reporting, the AP needs to determine the criteria and communicate with neighboring APs and associated STAs so that they can use the same criteria and quickly decide which type of CSI feedback format can be used to optimize performance.

[0093] Another problem is how to provide efficient management procedures for coordination of multi-link devices (MLDs) and multiple multi-link devices (MMLDs) and AIML-based MAC operations. MLDs and MMLDs can be deployed in 802.11be networks and beyond. MLDs and MMLDs can provide new methods of coordinated operations and AIML-based MAC operations. These coordinated operations and AIML-based MAC operations can need to be efficiently managed.

[0094] An AP or AP MLD can provide support for AIML-based MAC operations in a BSS or one or more of the BSSs of its affiliated APs.

[0095] An AP can indicate that it supports AIML operations by setting a bit (e.g., AIML MAC capability bit) in one or more capability elements, such as a HT Capabilities element, a VHT Capabilities element, a HE Capabilities element, an EHT Capabilities element, a UHR Capabilities element, or an Extended Capabilities element. If the AIML MAC capability bit is set to 1, it can imply that the same AP can include an AIML MAC element in frames it transmits, such as a beacon frame, an AIML beacon frame, a short beacon frame, a FILS discovery frame, or other types of frames, such as an AIML announcement frame. In addition, a short beacon, an A-Beacon, or other frames can also contain the AIML MAC capability bit.

[0096] In another example, an AP can indicate that it supports AIML MAC operations by including an AIML MAC element in frames it transmits, such as a beacon frame, an AIML beacon frame, a short beacon frame, a FILS discovery frame, or other types of frames, such as an AIML announcement frame. In yet another example, an AP can indicate that it supports AIML MAC operations of transmitting AIML related frames, such as an AIML announcement frame or an AIML beacon.

[0097] An AP affiliated to an AP MLD can indicate that it, one or more of the affiliated APs in the MLD, or all of the affiliated APs included in the AP MLD support AIML MAC operations by setting a bit (e.g., AIML MAC capability bit) in one of the capability elements, such as a HT Capabilities element, a VHT Capabilities element, a HE Capabilities element, an EHT Capabilities element, a Multi-Link element, a UHR Capabilities element, or an Extended Capabilities element. If the AIML MAC capability bit is set to 1, it can imply that the same AP or other APs affiliated to the AP MLD can include an AIML MAC element in frames it transmits, such as a beacon frame, an AIML beacon frame, a short beacon frame, a FILS discovery frame, or other types of frames, such as an AIML announcement frame. In addition, a short beacon, an A-Beacon, or other frames can also contain the AIML MAC capability bit.

[0098] In another example, an AP affiliated to an AP MLD can indicate that it or the AP MLD supports AIML MAC operations by including an AIML MAC element in frames it transmits, such as a beacon frame, an AIML beacon frame, a short beacon frame, a FILS discovery frame, or other types of frames, such as an AIML announcement frame. In yet another example, an AP affiliated to an AP MLD can indicate that it or the AP MLD supports AIML MAC operations by transmitting AIML related frames, such as an AIML announcement frame or an AIML beacon.

[0099] FIG. 2An example design of an AIML MAC element 200 is shown. The AIML MAC element can include an element ID field 202, a length field 204, an element ID extension field 206, an AIML MAC operation control field 208, an AIML MAC restriction field 210, and an AIML MAC parameter field 212. The combination of the element ID field 202 and the element ID extension field 206 can indicate that the element is an AIML MAC element. The length field 204 can indicate the length of the AIML MAC element 200.

[0100] The AIML MAC operation control field can indicate an AIML-based media access control (MAC) operation status and can have one of the following values: disabled, suspended, enabled, registered enabled, enabled and AP-distributed model only, enabled and AP-distributed model or STA’s own model, or enabled and AP-distributed model or STA’s own model with restrictions.

[0101] The disabled value can indicate that the AIML-based MAC operation is disabled and all STAs or non-AP MLDs can be allowed to use only non-AIML-based media access operation. The suspended value can indicate that the AIML-based MAC operation is suspended and all STAs or non-AP MLDs can switch to non-AIML-based MAC operation. The STAs or non-AP MLDs can keep their AIML models or continue to refine their AIML models. The enabled value can indicate that the AIML-based MAC operation is enabled and can allow STAs or non-AP MLDs to use the AIML-based MAC operation. The STAs or non-AP MLDs can be allowed to use their own AIML MAC model, with or without restrictions, or use an AIML model distributed by an AP or AP MLD.

[0102] The registered enabled value can indicate that the AIML-based MAC operation is enabled only for STAs or non-AP MLDs that have requested or registered with the AP or AP MLD their intent to use the AIML-based MAC operation and the AP or AP MLD has acknowledged or approved the request or registration. In one example, a STA can need to request or register with the AP to use a specific AIML model or data collection or model delivery method, which can be identified by a model I or function-based ID or model delivery identification, and the AP can need to acknowledge or approve the request or registration for one or more AIML models identified by the model or function-based ID or data collection or model delivery method.

[0103] A value of enabled and AP-distributed models only can indicate that AIML-based MAC operations are enabled, and STAs or non-AP MLDs can be allowed to use AIML-based MAC operations, but can only be allowed to use AIML models distributed by an AP or AP MLD.

[0104] A value of enabled and AP-distributed models or STA own models can indicate that AIML-based MAC operations are enabled, and STAs or non-AP MLDs can be allowed to use AIML-based MAC operations. STAs or non-AP MLDs can be allowed to use AIML model(s) distributed by an AP or AP MLD, or use their own AIML models.

[0105] A value of enabled and AP-distributed models or STA own models with restrictions can indicate that AIML-based MAC operations are enabled, and STAs or non-AP MLDs can be allowed to use AIML-based MAC operations, but can use AIML model(s) distributed by an AP or AP MLD, or use their own AIML models, subject to restrictions indicated by an AP or AP MLD.

[0106] The AIML MAC operation control field can be implemented using one subfield or multiple subfields or a bitmap or a combination of subfields to indicate one or more values or combinations thereof, as shown above.

[0107] FIG. 3 An example design of the AIML MAC restriction field (e.g., FIG. 2 The AIML MAC restriction field 210 in FIG. 2) is shown. The AIML MAC restriction field can include information needed to control AIML-based MAC operations, and can include one or more of the following subfields: (1) a carrier sensing subfield 302; (2) a spatial reuse subfield 304; (3) a subject to NAV subfield 306; (4) a backoff subfield 308; and / or (5) a service period (SP) only subfield 310.

[0108] The carrier sensing subfield 302 can indicate whether AIML-based channel access can use carrier sensing to access the medium. Detailed indication can include whether a STA needs to perform signal detection or energy detection for carrier sensing to ensure that the medium is idle before it is allowed to access the medium, and the minimum detection level required for each scheme. This can also include whether a time slot can be used for AIML-based channel access (e.g., whether AIML-based channel access can only occur at the boundary of a time slot).

[0109] The spatial reuse subfield 304 can indicate whether the AIML-based channel access algorithm can use spatial reuse to access the medium, e.g., using OBSS-PD, PSR, SRG-OBSS-PD, or other types of spatial reuse. The indication can also include a minimum required energy detection threshold or a measured signal detection threshold for each spatial reuse scheme.

[0110] The NAV compliance subfield 306 can indicate whether the AIML-based channel access algorithm can comply with the NAV. For example, one indication can be that the AIML-based channel access must comply with the NAV. For example, if any received frames set the NAV, the NAV compliance 306 subfield can indicate to the STA that it must comply with the NAV and cannot transmit during the NAV period.

[0111] The backoff subfield 308 can indicate whether the AIML-based channel access algorithm must follow a backoff rule, e.g., when a collision occurs, or when a transmission fails, the AIML-based channel access can double or extend its contention window size.

[0112] The only-in-SP subfield 310 can indicate whether the AIML-based channel access is allowed only in certain SPs, e.g., AIML TWT, AIML SP, or other intervals, which can be reserved specifically for STAs with AIML capability. The STA can need to perform non-AIML-based channel access during other intervals or periods to provide better coexistence with legacy and non-AIML capable devices.

[0113] FIG. 4 An example design of the AIML MAC parameters field is shown. The AIML MAC parameters field can include information needed to control the AIML-based MAC operation and can include one or more of the following subfields: (1) a priority subfield 402; (2) a contention window (CW) parameter subfield 404; (3) a minimum wait time subfield 406; (4) a backoff parameter subfield 408; and / or (5) an AIML model sharing parameter subfield 410.

[0114] The priority subfield 402 can indicate the priority used by the traffic using the AIML-based MAC algorithm to access the channel. For example, the traffic using the AIML-based channel access algorithm can be considered to be one or more of the following access categories (ACs): AC_VI, AC_VO, AC_BE, AC_BK, or AC_AIML, such as a particular access category for traffic using the AIML-based algorithm to access the channel. The priority can also imply that the parameters associated with the AC (which can be advertised in frames such as beacons), such as CWmin, CWmax, etc., should be used.

[0115] The CW parameter subfield 404 can indicate parameters that should be used for traffic using AIML-based channel access, such as AIML_CWmin, AIML_CWmax.

[0116] The minimum wait time subfield 406b can specify the minimum time a STA using an AIML-based channel access algorithm must wait until it can determine that the channel is idle. Some values can include DIFS, PIFS, SIFS, or a period specified in ms, ns, TUs, or slots.

[0117] The backoff parameter subfield 408 can specify parameters that an AIML-based channel access algorithm must adhere to when a collision occurs or a transmission is unsuccessful. The specified behavior can include doubling the CW size, with a maximum of CWmax; or maintaining the current contention window size, or expanding or reducing the contention window size with another parameter N, where N can be a fraction or an integer.

[0118] The AIML model sharing parameter subfield 410 can specify parameters that can be used to share an AIML model in DL or UL. For example, for the case where an AP or MLD can share an AIML model, the field can include the content ID and / or the broadcast MAC address of the STA / AP that is broadcasting the AIML model to be shared. The field can also include the frequency / time of such broadcast of the AIML model. In another example, for the case where a STA or non-AP MLD can share an AIML model in UL or P2P, it can include the HLP (Higher Layer Protocol) header that the STA or non-AP MLD should use to broadcast or transmit its shared AIML model.

[0119] Any field, subfield, or portion of the AIML MAC element or combination thereof can be constructed using existing or new elements or fields, subfields, or data, control, management frames, action frames, or other types of portions of PHY and MAC headers without ACK.

[0120] In one embodiment, a STA can receive a first AIML MAC element from an AP. The first AIML MAC element can include information indicating that the AP supports AIML operation and includes at least one of an AIML MAC restriction field and an AIML MAC parameter field. Further, the STA can transmit a second AIML MAC element to the AP. The second AIML MAC element can include information indicating that the AP supports AIML operation and includes at least one of a second AIML MAC restriction field and a second AIML MAC parameter field.

[0121] The AIML MAC restriction field can include at least one of a carrier sense subfield, a spatial reuse subfield, a defer to NAV subfield, a backoff subfield, and a service period (SP) only subfield. The AIML MAC restriction field includes at least one of a priority subfield, a contention window parameter subfield, a minimum wait time subfield, a backoff parameter subfield, and an AIML model sharing parameter subfield.

[0122] The AIML MAC operation manager can include the following:

[0123] An AP or an AP MLD affiliated AP can include an AIML MAC element in any frame it transmits, such as a beacon, a short beacon, an AIML beacon, a probe response frame, or an AIML announcement frame, or can transmit an AIML beacon or an AIML announcement frame or other type of AIML specific frame to indicate that it or the AP MLD it is affiliated with supports AIML operation.

[0124] A STA or a STA affiliated with a non-AP MLD can include an AIML MAC element in any frame it transmits to an AP, such as a probe request, an association request, an AIML request frame, to indicate that it or the non-AP MLD it is affiliated with supports AIML operation.

[0125] An AP or an AP MLD affiliated AP can indicate the exact mode of operation of the AIML based MAC operation it or the AP MLD supports. It can also indicate whether only AIML models distributed by the AP are allowed to be used or whether STAs or non-AP MLDs can use their own models, with or without restrictions, e.g., for AIML based media access. It can also indicate whether STAs or non-AP MLDs have to register or request with the AP in order to be able to start AIML based MAC operation. For example, a STA can need to request or register with the AP to use a specific AIML model or data collection or model delivery method, which can be identified by a model I or function based ID or model delivery identification, the AP can need to confirm or approve the request or registration for one or more AIML models identified by a model or function based ID or data collection or model delivery method.

[0126] An AP affiliated with an AP MLD can include an AIML MAC element in a report STA profile of another AP affiliated with the same AP MLD, e.g., in a multi-link element. Such as a basic multi-link element or an AIML multi-link element. The AP can include an indication in a reduced neighbor report that a neighbor AP is capable of supporting AIML based MAC operation.

[0127] A STA or non-AP STA can follow the indication of the AP to request or start an AIML-based MAC operation supported by the AP or AP MLD. It can request an AIML model from the AP or use its own model, with or without restrictions, indicated by the AP or AP MLD. A STA or non-AP STA can obtain a shared AIML-based MAC model using an AIML model sharing parameter, e.g., by receiving an EBCS stream with an indicated content ID. A STA can need to request or register with the AP to use a specific AIML model or data collection or model delivery method, which can be identified by a model I or function-based ID or model delivery identification. An AP can need to confirm or approve a request or registration of one or more AIML models identified by a model or function-based ID, data collection or model delivery method.

[0128] For example, an AP or an AP attached to an AP MLD can reject an (re)association request from a STA or non-AP MLD using the reason code “Not conformant to AIML MAC operation” if it finds that the STA or non-AP MLD does not have the appropriate AIML operation capabilities or parameters.

[0129] For example, an AP or an AP attached to an AP MLD can disassociate a STA or non-AP MLD using the reason code “Not conformant to AIML MAC operation” if it finds that the STA or non-AP MLD is conducting an AIML MAC operation that does not follow the regulations and indications of the AP or AP MLD.

[0130] For example, an AP or an AP attached to an AP MLD can reject an association request of a STA or non-AP MLD using the reason code “Not conformant to AIML MAC operation” if it finds that the STA or non-AP MLD does not have the capabilities to support the desired AIML MAC operation.

[0131] An AP or an AP attached to an AP MLD can send a frame with an AIML MAC element or any part of an AIML MAC element to change the mode of an AIML-based MAC operation. For example, an AP or an AP attached to an AP MLD can disable, suspend or enable an AIML-based MAC operation. It can change the AIML MAC operation mode, e.g., to only allow AP-distributed AIML models, or to allow a STA’s own model with restrictions, or to change any restriction parameters of an AIML MAC operation. Such a frame can be an AIML operation mode change frame. Any such change in an AIML MAC operation can be characterized as a critical update and can be reported by another AP attached to the same AP MLD in any multi-link element.

[0132] If it has received an AIML operation mode change, e.g., in an AIML element, a STA or a STA affiliated to a non-AP MLD can change its AIML-based MAC operation. It can stop AIML-based MAC operation and discard its AIML model according to the received AIML operation mode change announcement. It can suspend all or one or more AIML-based operations according to the received AIML operation mode change announcement, but can keep and continuously refine its AIML model. It can enable AIML-based MAC operation according to the received AIML operation mode change announcement, from which it can request an AIML model from the AP or an AP affiliated to an AP MLD.

[0133] A STA or a STA affiliated to a non-AP MLD can adapt to the limitations of AIML-based MAC operation announced by an AP or an AP affiliated to an AP MLD, e.g., by obeying the rules of carrier sensing, spatial reuse, respecting the NAV and backoff rules, or performing AIML-based MAC operation only in certain SPs such as AIML TWT or other AIML intervals.

[0134] A STA or a STA affiliated to a non-AP MLD can adapt to the parameters of AIML-based MAC operation announced by an AP or an AP affiliated to an AP MLD, e.g., by adapting the priority, CW parameter, minimum wait time, backoff parameter.

[0135] A STA or a STA affiliated to a non-AP MLD that is required or expected to share its own model with an AP or an AP MLD or other peer entity can use the HLP information shared by the AP or the AP MLD to construct a UL EBCS frame to share its own AIML model.

[0136] The methods and behaviors described in other clauses of this embodiment can be extended beyond the BSS (AP) and MLD described above. These techniques can be applied to ESS, MMLD, or an entire wireless local area network (WLAN). The analysis and management of measurements from these non-AP STAs, APs, MLDs, MMLDs, and other entities in the WLAN may require a WLAN-level AIML management entity within the WLAN, or be provided by AIML resources based on cloud or edge-based services. The management entity may receive reports from other entities, or receive summary reports compiled by one entity using input from other entities (for example, an MLD will compile all measurement data from its affiliated APs and non-AP STAs and then send this compiled information to the management entity). The management entity can use these measurements and measurement reports to analyze and evaluate the network to generate management recommendations for network entities, or it can actively manage network entities. The management entity can provide management recommendations or controls to distribute or share channels, subchannels, time, space, codes, or other resources to various network entities, as described in this embodiment.

[0137] An example of one type of management control that can be provided at the WLAN level is AP bandwidth and frequency band allocation for optimal WLAN performance. A management entity can use measurement data to allocate bandwidth and channels to each AP in the WLAN to maximize throughput and minimize interference between other APs and non-AP STAs in the WLAN, while also considering interference from entities not in the WLAN.

[0138] In another embodiment, the AP can indicate to the non-AP STA whether it requires all the information in the compressed beamforming report. In one example, the AP can request In another example, the AP may request only In this case, the non-AP STA will only feedback The quantized index of the angle ψ is used, while for the angle ψ, the AP shall use a predetermined value. In either of these instances, the non-AP STA may or may not support AIML-based CSI reporting.

[0139] To indicate such a request, the AP may use additional bits in the STA Information field of the Null Data Packet Announcement (NDPA) frame. FIG. 5 A modified STA Information field format of an EHT NDPA frame is depicted. In this example, the STA Information field may have an additional subfield labeled Partial BF Feedback.

[0140] The partial BF feedback subfield of the modified STA info field format of the EHT NDPA frame can be defined as shown in Table 1 below: Table 1 - Partial BF feedback subfield encoding.

[0141] In the EHT MIMO control field, the partial BF feedback subfield can also be used by non-AP STAs to indicate that the beamforming feedback report contains quantized indices of both the angle and the angle quantized indices of the angle only.

[0142] In the case that the angle information is not included in the feedback report, the angle is given a fixed value that is known to both the beamformer (e.g., AP) and the beamformee (e.g., non-AP STA). For SU feedback with N_c = 2, the fixed value can be as follows:

[0143] If N r × N c = 8 x 2, then 21 = 0.25π, ψ 31 = 0.19π, ψ 41 = 0.15π, ψ 51 = 0.13π, ψ 61 = 0.12π, ψ 71 = 0.11π, ψ 81 = 0.10π, ψ 32 = 0.26π, ψ 42 = 0.19π, ψ 52 = 0.16π, ψ 62 = 0.13π, ψ 72 = 0.12π, ψ 82 = 0.11π.

[0144] If N r × N c = 7 x 2, then 21 = 0.25π, ψ 31 = 0.19π, ψ 41 = 0.15π, ψ 51 = 0.13π, ψ 61 = 0.12π, ψ 71 = 0.11π, ψ 32 = 0.26π, ψ 42 = 0.19π, ψ 22 = 0.16π, ψ 62 = 0.13π, ψ 72 = 0.12π.

[0145] If N r x N c = 6 x 2, then ψ 21 = 0.25π, ψ 31 = 0.19π, ψ 41 = 0.15π, ψ 51 = 0.13π, ψ 61 = 0.12π, ψ 32 = 0.26π, ψ 42 = 0.19π, ψ 52 = 0.16π, ψ 62 = 0.13π.

[0146] If N r x N c = 5 x 2, then ψ 21 = 0.25π, ψ 31 = 0.19π, ψ 41 = 0.15π, ψ 51 = 0.13π, ψ 32 = 0.26π, ψ 42 = 0.19π, ψ 52 = 0.16π.

[0147] If N r x N c = 4 x 2, then ψ 21 = 0.25π, ψ 31 = 0.19π, ψ 41 = 0.15π, ψ 32 = 0.26π, ψ 42 = 0.19π.

[0148] If N r x N c = 3 x 2, then

[0149] If N r x N c = 2 x 2, then ψ 21 = 0.25π.

[0150] In one embodiment, the number of bits for ψ feedback can be minimized (e.g., the number of bits for ψ feedback can be 0 (ψ need not be reported), or 1 or 2, etc.). For example, when the number of bits for ψ feedback is equal to 1, both the AP and the non-AP STA(s) can store the same 25% tile and 50% tile ψ values. For example, if the bits for ψ feedback are set to 0, it indicates that the 25% tile ψ values are fed back; if the bits for ψ feedback are set to [1], it indicates that the 50% tile ψ values are fed back. In the case of 2 bits for ψ feedback, if the number of bits for ψ feedback is equal to 2, both the AP and the non-AP STA(s) can store the same 25% tile, 50% tile, 75% tile, 90% tile values. For example, if the bits for ψ feedback are set to [0 0], it indicates that the 25% tile ψ values are reported; if the bits for ψ feedback are set to [0 1], it indicates that the 50% tile ψ values are reported; if the bits for ψ feedback are set to 10, it indicates that the 75% tile ψ values are reported; if the bits for ψ feedback are set to [1 1], it indicates that the 90% tile ψ values are reported. Note that the above is one example of indicating that the AP and the non-AP STA can share the same set of ψ values corresponding to the feedback bits indication. There can be other mappings between the representation of the bits for ψ feedback and the meaning of the ψ values.

[0151] In addition, the number of bits for ψ feedback can be dynamically changed. The AP can indicate the number of bits for ψ feedback in the EHT NDP Announcement frame with the enhanced STA information field.

[0152] FIG. 6 An example format of the enhanced STA information field 600 in the EHT NDP Announcement frame is shown. The enhanced STA information field 600 can include one or more of the following subfields: AID 11 subfield 602, partial BW information subfield 604, reserved subfield 606, NC index subfield 608, feedback type and Ng subfield 610, disambiguation subfield 612, codebook size subfield 614, and number of bits for ψ feedback subfield 616.

[0153] The number of bits for ψ feedback subfield 616 can contain N bits. For example, if N = 1, then in one example, [0] indicates that no ψ feedback is needed, and 1 indicates that ψ feedback is included. In this case, the number of bits for ψ feedback follows the requirements defined in the feedback type and Ng subfield 610. If N = 2, then in one example, [1 1] indicates that no ψ feedback is needed, [0 1] indicates 1 bit for ψ feedback, [1 0] indicates 2 bits for ψ feedback, and [0 0] indicates the value for legacy devices. The feedback type and Ng subfield 620 can indicate the number of bits needed for φ and ψ feedback, respectively. The number of bits for ψ feedback subfield 616 can override the requirements for the number of bits for ψ feedback indicated in the feedback type and Ng subfield 610, and the target STA addressed in the AID 11 subfield 602 can follow the requirements indicated in the number of bits for ψ feedback subfield.

[0154] FIG. 7 Another example format of the enhanced STA info field 700 in an EHT NDP announcement frame is shown, which includes an enhanced feedback type and Ng subfield. As shown, the enhanced STA info field can include one or more of the following subfields: an AID 11 subfield 702, a partial BW info subfield 704, a reserved subfield 706, an Nc index subfield 708, a feedback type and Ng subfield 710, an ambiguity resolution subfield 712, a codebook size subfield 714, an enhanced feedback type and Ng subfield 716. FIG. 7

[0155] The enhanced feedback type and Ng subfield 716 can be combined with the feedback type and Ng subfield 710 to indicate the requirements for the number of bits for φ and ψ feedback. The enhanced feedback type and Ng subfield 716 can contain N bits. Table 2 below provides an exemplary encoding for the feedback type and Ng subfield 710, the codebook size subfield 714, and the enhanced feedback type and Ng subfield 716 for EHT TB sounding when the enhanced feedback type and Ng contains 1 bit (i.e., N = 1): Table 2 - Exemplary encoding for the feedback type and Ng subfield, the codebook size subfield, and the enhanced feedback type and Ng subfield for EHT TB sounding 1 bit.

[0156] In FIG. 6 and FIG. 7 In the example shown, N can be greater than 1, which means that there can be more variations for the number of bits for ψ feedback. Additionally or alternatively, the AP can indicate partial feedback requirements (e.g., ψ feedback requirements) as shown above in the UH NDP announcement frame or other NDP announcement frames.

[0157] ​In one embodiment, N bits in the EHT MIMO Control field can be used to indicate how many bits are used for ψ feedback. Alternatively or additionally, the N bits used to indicate the number of bits for ψ feedback can be included in the UHR MIMO Control field or other control field included in the CSI feedback report.

[0158] FIG. 8 An example format 800 of a modified EHT MIMO Control field is shown, which includes a number of bits for ψ feedback subfield 812. As FIG. 8 shown, the modified EHT MIMO Control field 800 can include one or more of the following subfields: Nc index subfield 802, Nc index subfield 804, BW 806 subfield, grouping subfield 808, feedback type subfield 810, number of bits for ψ feedback subfield 812, remaining feedback segment subfield 814, first feedback segment subfield 816, partial BW information subfield 818, sounding dialog token number subfield 820, and codebook information subfield 822.

[0159] The number of bits for ψ feedback subfield 812 subfield can include N bits. For example, if N = 1 (e.g., the number of bits for ψ feedback subfield is set to 1), it can indicate that ψ feedback is not included, otherwise, ψ feedback is included (i.e., the number of bits and format for ψ follows the feedback type and codebook information subfields).

[0160] FIG. 9 Another example format of a modified EHT MIMO Control field 900 is shown, which includes an enhanced codebook information subfield 912. As FIG. 9 shown, the modified EHT MIMO Control field 900 can include one or more of the following subfields: Nc index subfield 902, Nc index subfield 904, BW 906 subfield, grouping subfield 908, feedback type subfield 910, enhanced codebook information subfield 912, remaining feedback segment subfield 914, first feedback segment subfield 916, partial BW information subfield 918, sounding dialog token number subfield 920, and codebook information subfield 922.

[0161] The codebook information subfield 922 and the enhanced codebook information subfield 912 can be combined to indicate the size of the codebook entry. For example, if the enhanced codebook information subfield 912 includes 1 bit (i.e., N = 1), if the feedback type subfield indicates SU: if the codebook information subfield is set to 0 and the enhanced codebook information subfield is set to 1, it represents 4 bits for φ and 0 bits for ψ; and if the codebook information subfield is set to 1 and the enhanced codebook information subfield is set to 1, it represents 6 bits for φ and 0 bits for ψ.

[0162] For example, in case the enhanced codebook information subfield contains 1 bit (i.e., N = 1), if the feedback type subfield indicates MU: if the codebook information subfield is set to 0, and the enhanced codebook information subfield is set to 1, it represents 7 bits for φ and 0 bits for ψ; and if the codebook information subfield is set to 1 and the enhanced codebook information subfield is set to 1, it represents 9 bits for φ and 0 bits for ψ.

[0163] In FIG. 8 and FIG. 9 , N can be greater than 1, which means there can be more kinds of bit numbers for ψ feedback.

[0164] In one embodiment, the sounding protocol can include multiple sounding sequences with different resolutions of ψ feedback. In a non-TB sounding protocol, the beamforming receiver can determine the resolution of ψ feedback (i.e., the number of bits used for ψ feedback). The beamforming receiver can decide to only use the enhanced EHT MIMO control field to report Φ.

[0165] FIG. 10 An exemplary non-TB sounding protocol using the enhanced EHT MIMO control field (e.g., any of the formats depicted in FIG. 8 and FIG. 9 ) is shown. The AP 1002 can send an NDP announcement frame 1010 to STA1 1004, followed by an NDP 1012. Then, STA1 1004 can send an EHT compressed beamforming / CQI with enhanced MIMO control field to the AP 1002. The EHT compressed beamforming / CQI with enhanced MIMO control field can indicate a partial CSI feedback format (e.g., including only Φ and not reporting ψ). In one embodiment, the AP 1002 can request additional Φ feedback after receiving Φ and ψ feedback from different STAs. Alternatively, the AP 1002 can independently request feedback from any STA.

[0166] FIG. 11An example adaptive sounding protocol is shown, which includes a legacy non-TB sounding sequence between AP 1102 and STA1 1104. AP 1102 and STA2 1104 and a modified TB sounding sequence, which has an enhanced STA information field in the EHT NDP Announcement frame and an enhanced MIMO control field in the EHT compressed beamforming / CQI report. In this example, the AP 1102 sends a legacy EHT NDP Announcement frame to STA1 1104, followed by an NDP, and STA1 sends an EHT compressed beamforming report upon receiving the EHT NDP Announcement frame and the NDP from the AP. Similarly, the AP sends a legacy EHT NDP Announcement frame to STA2, followed by an NDP, and STA2 sends an EHT compressed beamforming report upon receiving the EHT NDP Announcement frame and the NDP from the AP. To obtain the most recent channel state and save overhead, the AP can send another EHT NDP Announcement frame including enhanced STA information addressed to STA1 and STA2, which can request only Φ feedback without ψ feedback (or a smaller number of bits for ψ feedback), e.g., using the format of FIG. 6 and FIG. 7 The NDP Announcement frame is followed by an NDP and a trigger frame, which are separated by a SIFS. Upon receiving the trigger frame, STA1 and STA2 can follow the instructions defined in the enhanced information field in the EHT Announcement frame and accordingly send a compressed beamforming report with an enhanced MIMO control field, which indicates only Φ feedback without ψ feedback (or a smaller number of bits for ψ feedback). The format of the enhanced MIMO control field can use the format given in FIG. 8 and FIG. 9

[0167] Although different numbers of bits for feedback are discussed here, all of the above algorithms, formats, or procedures can be adapted for different numbers of bits for φ feedback. For example, the enhanced MIMO control field, the enhanced STA information field in the EHT NDP Announcement frame, the non-TB sounding protocol with the enhanced MIMO control field, the adaptive sounding protocol can be adapted for cases where a variable number of bits are used for φ feedback.

[0168] In another embodiment, the AP can request a non-AP STA to feedback the value of a key performance indicator (KPI) that measures the quality of the AIML-based CSI report with respect to the actual channel quality. The KPI under consideration can be implementation-dependent (e.g., generalized cosine similarity, effective SINR, etc.).

[0169] To indicate such a request, the AP can use additional bits in the STA information field of the NDPA frame. FIG. 12 ​A modified STA Info field format of the EHT NDPA frame is depicted. In this example, the STA Info field has an additional subfield labeled KPI.

[0170] The KPI subfield can be defined as shown in Table 3 below: KPI Description 0 KPI is not requested in beamforming feedback report. 1 KPI is requested in beamforming feedback report. Table 3 - KPI subfield encoding.

[0171] In the EHT MIMO Control field, the non-AP STA can also use the KPI subfield to indicate whether the beamforming feedback report contains information related to KPI. If the STA indicates that the beamforming feedback report contains information related to KPI, the modified EHT Compressed Beamforming / CQI frame Action field can include KPIs for multiple purposes, e.g., used as an optimization function or objective, used as a classification criterion for the AIML CSI compression scheme, used as a feature fed into the AIML model, used as an evaluation parameter for candidate CSI compression algorithms, etc., in the AIML or non-AIML CSI compression algorithm. Table 3 gives an example of the modified EHT Compressed Beamforming / CQI frame Action field format. In this example, KPIs that can be used in the selection of the CSI compression algorithm are included in the modified EHT Compressed Beamforming / CQI frame Action field. Table 4 below provides an example of the modified EHT Compressed Beamforming / CQI frame Action field: Step Meaning … … 7 KPI (e.g., for selection of CSI compression algorithm) Table 4 - Modified EHT Compressed Beamforming / CQI frame Action field.

[0172] In one embodiment, the AP can indicate KPIs to the non-AP STAs or neighboring APs. The KPIs can be included in the EHT Variant User Info field of the Trigger frame, which is used for the triggered sounding, or in the STA Info field of the EHT NDPA frame. Alternatively, the KPIs can be contained in any control or management frame. The KPIs can be negotiated among STAs. For example, to unify the AIML CSI compression model, the AP or non-AP STAs can need to have agreed KPIs to generate the AIML CSI compression model. Table 5 gives an example encoding of the KPI bits. In this example, 2 bits are used to represent different KPIs. The 2 bits can be included in the above-mentioned control or management frames. Table 5 - Example encoding of KPI bits.

[0173] In one embodiment, all AIML parameters for CSI compression (e.g., classification or compression criteria, classification methods, etc., in the training phase and / or testing phase) can be included in the management frames / control frames sent from non-APs or APs or among APs.

[0174] In an embodiment, a STA can indicate its support of partial feedback by setting a bit (e.g., partial feedback bit) in one or more capability elements, such as HT Capabilities element, VHT Capabilities element, HE Capabilities element, EHT Capabilities element, UHR Capabilities element, or Extended Capabilities element. The partial feedback bit can be included in a PHY Capabilities Info field, such as a PHY Capabilities Info field, an EHT PHY Capabilities Info field, a UHR PHY Capabilities Info field, or other PHY Capabilities Info field. Setting the partial feedback bit to 1 can imply that the same STA can support partial feedback report, e.g., only Φ feedback report or only Ψ feedback report, or use a smaller number of bits to represent Φ or Ψ (e.g., 1 bit to represent Φ or Ψ).

[0175] In an embodiment, a STA can indicate its support of reporting or indicating intermediate KPIs by setting a bit, e.g., intermediate KPI support bit, in one or more capability elements, such as HT Capabilities element, VHT Capabilities element, HE Capabilities element, EHT Capabilities element, UHR Capabilities element, or Extended Capabilities element. The bit can be included in a PHY Capabilities Info field or / and a MAC Capabilities Info field, such as HE PHY Capabilities Info field or / and HE MAC Capabilities Info field, EHT PHY Capabilities Info field or / and EHT MAC Capabilities Info field, UHR PHY Capabilities Info field or / and UHR MAC Capabilities Info field, or other PHY Capabilities Info field or / and other MAC Capabilities Info field. Setting the intermediate KPI support bit to 1 can imply that the same STA can support indicating intermediate KPIs or using the indicated intermediate KPIs in compressed CSI process, e.g., AIML-enabled CSI compression.

[0176] Although features and elements are described in particular combinations in preferred embodiments, each feature or element can be used alone or in various combinations with or without other features and elements dependent on the preferred embodiment.

[0177] Although the solutions described herein consider 802.11 specific protocols, it should be understood that the solutions described herein are not limited to such scenarios and are applicable to other wireless systems as well.

[0178] Although SIFS is used in examples of designs and procedures to indicate various interframe spaces, all other interframe spaces, such as RIFS, AIFS, DIFS, or other agreed time intervals, can be applied in the same solutions.

[0179] Although four RBs per triggered TXOP are shown as an example in some figures, the actual number of RBs / channels / bandwidth utilized can vary.

[0180] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in combination with others dependent upon the circumstances. The methods described herein can be implemented in a computer program, software, or firmware incorporated 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, readonly memory (ROM), random-access memory (RAM), register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs, and digital versatile disks (DVDs). A processor in association with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a station (STA), the method comprising: A first artificial intelligence / machine learning (AIML) media access control (MAC) element is received from an access point (AP), the first AIML MAC element including information indicating that the AP supports AIML operations, the first AIML MAC element including at least one of a first AIMLMAC restriction field and a first AIMLMAC parameter field.

2. The method according to claim 1, further comprising: A second AIML MAC element is sent to the AP, where the second AIML MAC element includes information indicating that the AP supports AIML operation, and the second AIML MAC element includes at least one of a second AIML MAC restriction field and a first AIML MAC parameter field.

3. The method according to claim 1, wherein The first AIML MAC restriction field includes at least one of a carrier sensing subfield, a spatial reuse subfield, a obey NAV subfield, a backoff subfield, and a service period (SP) only subfield.

4. The method according to claim 3, wherein: The Carrier Sense subfield indicates whether AIML-based channel access uses carrier sensing to access the channel.

5. The method according to claim 3, wherein The spatial reuse subfield indicates whether the AIML-based channel access algorithm uses spatial reuse to access the channel.

6. The method according to claim 3, wherein: The Submit to NAV subfield indicates whether the AIML-based channel access algorithm must obey NAV.

7. The method according to claim 3, wherein: The backoff subfield indicates whether the AIML-based channel access algorithm must follow the backup rule.

8. The method according to claim 3, wherein: The Only in SP subfield indicates whether the AIML-based channel access algorithm is allowed only in a specific SP.

9. The method according to claim 1, wherein The first AIML MAC restriction field includes at least one of a priority subfield, a contention window parameter subfield, a minimum waiting time subfield, a backoff parameter subfield, and an AIML model sharing parameter subfield.

10. The method according to claim 9, wherein: The priority subfield indicates the priority used by services accessing the channel using an AIML-based MAC algorithm.

11. The method according to claim 9, wherein The contention window parameter subfield indicates one or more parameters for a service using an AIML-based channel access.

12. The method according to claim 9, wherein The backoff parameter subfield specifies one or more parameters that the AIML-based channel access algorithm must obey when a collision occurs or when a transmission fails.

13. The method according to claim 9, wherein: The AIML model sharing parameter subfield specifies one or more parameters for sharing an AIML model in a downlink or uplink.

14. A station (STA), comprising: transceiver; as well as processor; wherein the transceiver and processor are configured to: A first artificial intelligence / machine learning (AIML) MAC element is received from an access point (AP), the first AIML MAC element including information indicating that the AP supports AIML operations, the first AIML MAC element including at least one of a first AIML MAC restriction field and a first AIML MAC parameter field.

15. The STA according to claim 14, further comprising: A second AIML MAC element is sent to the AP, where the second AIML MAC element includes information indicating that the AP supports AIML operation, and the second AIML MAC element includes at least one of a second AIML MAC restriction field and a second AIML MAC parameter field.

16. The STA according to claim 14, wherein: The first AIML MAC restriction field includes at least one of a carrier sensing subfield, a spatial reuse subfield, a obey NAV subfield, a backoff subfield, and a service period (SP) only subfield.

17. The STA according to claim 16, wherein: The Carrier Sense subfield indicates whether AIML-based channel access uses carrier sensing to access the channel.

18. The STA according to claim 16, wherein: The spatial reuse subfield indicates whether the AIML-based channel access algorithm uses spatial reuse to access the channel.

19. The STA according to claim 16, wherein: The Submit to NAV subfield indicates whether the AIML-based channel access algorithm must obey NAV.

20. The STA according to claim 16, wherein: The backoff subfield indicates whether the AIML-based channel access algorithm must follow the backup rule.

21. The STA according to claim 16, wherein: The Only in SP subfield indicates whether the AIML-based channel access algorithm is allowed only in a specific SP.

22. The STA according to claim 14, wherein: The first AIML MAC restriction field includes at least one of a priority subfield, a contention window parameter subfield, a minimum waiting time subfield, a backoff parameter subfield, and an AIML model sharing parameter subfield.

23. The STA according to claim 22, wherein: The priority subfield indicates the priority used by services accessing the channel using an AIML-based MAC algorithm.

24. The STA according to claim 22, wherein: The contention window parameter subfield indicates one or more parameters for a service using an AIML-based channel access.

25. The STA according to claim 22, wherein: The backoff parameter subfield specifies one or more parameters that the AIML-based channel access algorithm must obey when a collision occurs or when a transmission fails.

26. The STA according to claim 22, wherein: The AIML model sharing parameter subfield specifies one or more parameters for sharing an AIML model in a downlink or uplink.

Images