EP4677946A1 - Methods for artificial intelligence machine learning (aiml) medium access control (mac) and other operation management in wireless local area networks (wlan) - Google Patents

Abstract

A method performed by a station (STA) may comprise: receiving, from an access point (AP), a first artificial intelligence/machine learning (AIML) medium access control (MAC) element, 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 restrictions field and an AIML MAC parameters field. Further, the STA may transmit to the AP, a second AIML MAC element, 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 restrictions field and an AIML MAC parameters field.

Description

METHODS FOR ARTIFICIAL INTELLIGENCE MACHINE LEARNING (AIML) MEDIUM ACCESS CONTROL (MAC) AND OTHER OPERATION MANAGEMENT IN WIRELESS LOCAL AREA NETWORKS (WLAN) CROSS REFERENCE TO RELATED APPLICATION [0001] This application claims the benefit of U.S. Provisional Application No.63/488,298 filed March 03, 2023; and U.S. Provisional Application No.63/463,408 filed May 2, 2023; the contents of all which are incorporated herein by reference. SUMMARY [0002] A method performed by a station (STA) may comprise: receiving, from an access point (AP), a first artificial intelligence/machine learning (AIML) medium access control (MAC) element, 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 restrictions field and an AIML MAC parameters field. Further, the STA may transmit to the AP, a second AIML MAC element, 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 restrictions field and an AIML MAC parameters field. [0003] The AIML MAC restrictions field may include at least one of a Carrier Sensing subfield, a Spatial Reuse subfield, an Obey NAV subfield, a Backoff subfield, and an Only in Service Period (SP) subfield. The Carrier Sensing subfield may indicate whether an AIML-based channel access uses carrier sensing to access a channel. The Spatial Reuse subfield may indicate whether an AIML-based channel access algorithm uses spatial reuse to access a channel. The Obey NAV subfield may indicate whether an AIML-based channel access algorithm must obey NAV. The Backoff subfield may indicate whether an AIML-based channel access algorithm must follow backup rules. The Only in SP subfield may indicate whether an AIML-based channel access algorithm is only allowed in specific SPs [0004] The AIML MAC Restrictions field may include at least one of a Priority subfield, a Contention Window Parameters subfield, a Minimum Wait Time subfield, a Backoff Parameters subfield, and an AIML Model Sharing Parameters subfield. The priority subfield may indicate a priority used for traffic that is accessing a channel using a AIML-based MAC algorithm. The Contention Window Parameters subfield may indicate one or more parameters used for traffic that uses AIML-based channel access. The Backoff Parameters subfield may specify one or more parameters that an AIML-based channel access algorithm must obey when a collision occurs or when a transmission fails. The AIML Model Sharing Parameters subfield may specify one or more parameters to be used to share the AIML model in downlink or uplink. - 1 - 8376423.1 BRIEF DESCRIPTION OF THE DRAWINGS [0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein: [0006] FIG.1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented; [0007] FIG.1B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG.1A according to an embodiment; [0008] FIG.1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG.1A according to an embodiment; [0009] FIG.1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG.1A according to an embodiment; [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 a AIML MAC restriction field; [0012] FIG.4 is an example format of a AIML MAC parameters field; [0013] FIG.5 is an example format of a modified station (STA) info field of the extremely high throughput (EHT) null data packet announcement (NDPA) frame; and [0014] FIG.6 is an example format of an enhanced STA Info field in an EHT NDP announcement frame; [0015] FIG.7 is an example format of an enhanced STA Info 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 an 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 the EHT NDPA frame. DETAILED DESCRIPTION [0021] FIG.1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division - 2 - 8376423.1 multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like. [0022] As shown in FIG.1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, 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 may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include 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 and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE. [0023] The communications systems 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly 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 may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, 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 may include any number of interconnected base stations and/or network elements. [0024] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one - 3 - 8376423.1 embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions. [0025] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT). [0026] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (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 may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro). [0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using NR. [0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB). [0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may 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, CDMA20001X, 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] The base station 114b in FIG.1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity 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 - 4 - 8376423.1 use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may 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 in FIG.1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106. [0032] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may 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 may 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, it will be appreciated that the RAN 104 and/or the CN 106 may 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 may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. [0033] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may 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 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG.1A may be configured to communicate with the base station 114a, which may employ a cellular- based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology. [0035] FIG.1B is a system diagram illustrating an example WTRU 102. As shown in FIG.1B, the WTRU 102 may 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 - 5 - 8376423.1 source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. [0036] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG.1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip. [0037] The transmit/receive element 122 may 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 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals. [0038] Although the transmit/receive element 122 is depicted in FIG.1B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116. [0039] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may 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 may be coupled to, and may 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 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may 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 may include random-access - 6 - 8376423.1 memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information 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 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry 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 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. [0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like. [0044] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)). - 7 - 8376423.1 [0045] FIG.1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106. [0046] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may 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 may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. [0047] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG.1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface. [0048] The CN 106 shown in FIG.1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator. [0049] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA. [0050] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring 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] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. [0052] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP - 8 - 8376423.1 multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. [0053] Although the WTRU is described in FIGS.1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network. [0054] In representative embodiments, the other network 112 may be a WLAN. [0055] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have 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 may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication. [0056] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS. [0057] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of 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 may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non- - 9 - 8376423.1 contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC). [0059] Sub 1 GHz modes of operation are supported by 802.11af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control/Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life). [0060] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle. [0061] In the United States, the available frequency bands, which may be used by 802.11ah, 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 for 802.11ah is 6 MHz to 26 MHz depending on the country code. [0062] FIG.1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106. - 10 - 8376423.1 [0063] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may 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 may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may 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 may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c). [0064] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time). [0065] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c. [0066] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and - 11 - 8376423.1 Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG.1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface. [0067] The CN 106 shown in FIG.1D may include at least one AMF 182a, 182b, at least one UPF 184a,184b, at least one Session Management Function (SMF) 183a, 183b, and 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 may be owned and/or operated by an entity other than the CN operator. [0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi. [0069] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like. [0070] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may 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 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may 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 - 12 - 8376423.1 may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b. [0072] In view of FIGs.1A-1D, and the corresponding description of FIGs.1A-1D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions. [0073] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the 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. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or performing testing using over-the-air wireless communications. [0074] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data. [0075] A wireless local area network (WLAN) in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in and out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations. Traffic between STAs within the BSS may 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 may be peer-to-peer traffic. Such peer-to-peer traffic may also be sent directly between the source and destination STAs with a direct link setup (DLS) using an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode has no AP, and/or STAs, communicating directly with each other. This mode of communication is referred to as an “ad-hoc” mode of communication. - 13 - 8376423.1 [0076] Using the 802.11ac infrastructure mode of operation, the AP may transmit a beacon on a fixed channel, usually the primary channel. This channel may be 20 MHz wide, and is the operating channel of the BSS. This channel is also used by the STAs to establish a connection with the AP. The fundamental channel access mechanism in an 802.11 system is Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). In this mode of operation, every STA, including the AP, will sense the primary channel. If the channel is detected to be busy, the STA may back off. Therefore, only one STA may transmit at any given time in a given BSS. [0077] In 802.11n, High Throughput (HT) STAs may also use a 40 MHz wide channel for communication. This may 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 may support 20MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. The 40 MHz, and 80 MHz, channels may be formed by combining contiguous 20 MHz channels similar to 802.11n described above. A160 MHz channel may be formed either by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, this may also be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that divides it into two streams. IFFT, and time domain, processing are done on each stream separately. The streams may then be mapped on to the two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data may be sent to the MAC. [0079] Sub 1 GHz modes of operation are supported by 802.11af, and 802.11ah. For these specifications the channel operating bandwidths, and carriers, are reduced relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, 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 support for Meter Type Control (MTC) devices in a macro coverage area. MTC devices may have limited capabilities including only support for limited bandwidths, but also include a requirement for a very long battery life. [0080] WLAN systems which support multiple channels, and channel widths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, may include a channel that is designated as the primary channel. The primary channel may, but not necessarily, have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel is therefore limited by the STA, of all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide if there are STAs (e.g. MTC type devices) that only support a 1 MHz mode even if the AP, and other STAs in the BSS, may support a 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, for example, due to a STA supporting only a 1 MHz operating mode is transmitting to the AP, then the entire available frequency bands are considered busy even though majority of it stays idle and available). - 14 - 8376423.1 [0081] In the United States, the available frequency bands which may be used by 802.11ah range from 902 MHz to 928 MHz. In Korea the range is from 917.5 MHz to 923.5 MHz; and in Japan, is the range is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code. [0082] Machine learning may be defined as a computer program that learns from experience “E” with respect to some class of tasks “T”, and performance measure “P”, if its performance at tasks in “T”, as measured by “P”, improves with experience “E”. [0083] There are many different kinds of machine learning. Depending on the nature of the task “T” the system will learn, the nature of the performance measure P may be used to evaluate the system, and the nature of the training signal or experience “E” given it. [0084] Machine learning implementations may be classified into three major categories, depending on the nature of the learning “signal” or “response” available to a learning system: (1) supervised learning; (2) unsupervised learning; and (3) reinforcement learning. [0085] In supervised learning, an algorithm may learn from example data and associated target responses that can consist of numeric values or string labels, such as classes or tags, in order to later predict the correct response when posed with new examples comes under the category of Supervised learning. This approach is similar to human learning under the supervision of a teacher. The teacher provides good examples for the student to memorize, and the student then derives general rules from these specific examples. [0086] In unsupervised learning, an algorithm may learn from examples without any associated response, leaving it to the algorithm to determine the data patterns on its own. This type of algorithm may restructure the data into something else, such as new features that may represent a class or a new series of un-correlated values. They may be useful in providing humans with insights into the meaning of data and new useful inputs to supervised machine learning algorithms. [0087] In reinforcement learning, the system or agent may have to learn how to interact with its environment. This may be encoded by means of a policy a=π(x), which specifies which action to take in response to each possible input x (derived from the environment state). The difference from supervised learning is that the system may not told which action is the best one to take (i.e., which output to produce for a given input). Instead, the system may receive an occasional reward (or punishment) signal in response to the actions that it takes. This is similar to learning with a critic, who gives an occasional thumbs up or thumbs down, as opposed to learning with a teacher, who tells you what to do at each step. [0088] Federated learning is a machine learning setting where the goal is to train a high-quality centralized model while training data remains distributed over a large number of clients each with unreliable and relatively slow network connection. The learning algorithms considered for this setting are on each round. Each client independently computes an update to the current model based on its location data, and communicates this update to a central server, where the client-side updates are aggregated to compute a new global update. The - 15 - 8376423.1 typical clients in this setting are mobile phones, and communication efficiency is of utmost importance. Federated learning may enable mobile phones to collaboratively learn a shared prediction model while keeping all the training data on device, decoupling the ability to do machine learning from the need to store the data in the cloud. The training data is kept locally on users’ mobile devices, and the devices are used as nodes performing computation on their local data in order to update a global model. [0089] A naïve implementation of the federated learning may require each client to send a full model (or a full model update) back to the server in each round. For large models, this step is likely to be the bottleneck of federated learning due to multiple factors. One factor is the asymmetric property of internet connection speeds: the uplink is typically much slower than downlink. Therefore, there are many ways to reduce the uplink communication (from the client to the server) cost in federated learning. In structured updates, an update from a restricted pace may be learned and it can be parametrized using a smaller number of variables. In sketched updates, a full model may be updated and is then compressed before sending to the server. [0090] IEEE 3652.1 provides a blueprint for data usage and model building across organizations while meeting applicable privacy, security and regulatory requirements. IEEE 3652.1 defines the architectural framework and application guidelines for federated machine learning, including: (1) description and definition of federated learning; ( 2) the types of federated learning and the application scenarios to which each type applies; (3) performance evaluation of federated learning; and (4) associated regulatory requirements. [0091] AIML algorithms may be used to optimize the operations for medium access control in WLAN, by adjusting parameters and choosing the reward actions. An AP managing its own BSS may need to provide means to control medium access in its BSS as well as in the vicinity and should have certain level of controls of the AIML-based MAC operations of STAs that are associated with it. In addition, an AP may also need to manage AIML-based MAC operations in its own BSS to ensure fairness of channel access among STAs that are legacy devices and STAs that are AIML capable. Accordingly, one problem is how to provide efficient MAC procedures for APs and STAs for effective management of AIML-based MAC operations within a network. [0092] Another problem relates to compressed CSI feedback and fast determination of CSI report scheme. When the number of transmitting/receiving antennas increase, especially when an AP may require the sounding feedback from STAs associated with other APs in multi-AP scenario, an effective CSI compression scheme is desired, e.g., reduced overhead with minimum loss of packet error rate due to the reduced number of feedback bits. To facilitate the CSI feedback report, there is need to develop an efficient new type of CSI feedback report, especially when there are multiple CSI feedback report format candidates. Furthermore, when multiple CSI feedback report formats are available, including AIML enabled or non-AIML enabled CSI feedback reports, there is a need for the AP to determine a criterion and communicate with neighboring APs and associated STAs such that they can use the same criterion and make a fast decision on what type of CSI feedback format may be used to optimize the performance. - 16 - 8376423.1 [0093] Another problem is how to provide an efficient management procedure for multi-link devices (MLDs) and multiple multi-link devices (MMLDs) based coordination and AIML-based MAC operations. MLDs and MMLDs may be deployed in 802.11be networks and beyond. MLDs and MMLDs may provide a new way to coordinate operations as well as AIML-based MAC operations. These coordinated operations and AIML-based MAC operations may need to be efficiently managed. [0094] An AP or AP MLD may provide support for AIML-based MAC operations in its BSS or in the BSS of one or more of its affiliated APs. [0095] An AP may indicate that it supports AIML operation by setting a bit, (e.g., the AIML MAC Capable bit), in one or more Capability element(s), such as HT Capability element, VHT Capability element, HE Capability element, EHT Capability element, UHR Capability element, or extended capability element. If the AIML MAC Capable bit is set to 1, it may imply that the same AP may include an AIML MAC element in frames that it transmits, such as beacon frame, AIML beacon frames, short beacon frames, FILS discovery frame, or other type of frames such as AIML announcement frames. In addition, a short beacon, A-Beacon or other frames may also contain the AIML MAC Capable bit. [0096] In another example, an AP may indicate that it supports AIML MAC operation by including an AIML MAC element in frames that it transmits, such as beacon frame, AIML Beacon frames, short beacon frames, FILS discovery frame, or other type of frames such as AIML announcement frames. In yet another example, an AP may indicate that it supports AIML MAC operation transmitting AIML related frames such as AIML announcement frames or AIML beacons. [0097] An AP that is affiliated with an AP MLD may indicate that it, one or more affiliated APs in the MLD, or all the affiliated APs included in the AP MLD supports AIML MAC operation by setting a bit (e.g., the AIML MAC Capable bit, in one of the Capability elements, such as HT Capability element, VHT Capability element, HE Capability element, EHT Capability element, Multi-link element, UHR Capabilities element or extended capability element. If the AIML MAC Capable bit is set to 1, it may imply that the same AP or other APs affiliated with the AP MLD, may include an AIML MAC element in frames that it transmits, such as beacon frame, AIML Beacon frames, short beacon frames, FILS discovery frame, or other type of frames such as AIML announcement frames. In addition, a short beacon, A-Beacon, or other frames may also contain the AIML MAC Capable bit. [0098] In another example, an AP that is affiliated with an AP MLD may indicate that it or the AP MLD supports AIML MAC operation by including an AIML MAC element in frames that it transmits, such as beacon frame, AIML Beacon frames, short beacon frames, FILS discovery frame, or other type of frames such as AIML announcement frames. In yet another example, an AP that is affiliated with an AP MLD may indicate that it or the AP MLD supports AIML MAC operation by transmitting AIML related frames such as AIML announcement frames or AIML beacons. - 17 - 8376423.1 [0099] FIG.2 illustrates an is an example design of an AIML MAC element 200. The AIML MAC element may include an Element ID field 202, Length field 204, Element ID Extension field 206, AIML MAC Operation Control field 208, AIML MAC Restrictions field 210, and AIML MAC Parameters field 212. The combination of the Element ID field 202 and Element ID Extension field 206 may indicate that the element is an AIML MAC element. The Length field 204 may indicate the length of the AIML MAC element 200. [0100] The AIML MAC operation control field may indicate the AIML-based medium access control (MAC) operation status and may have one of following values: disabled, paused, enabled, enabled with registration, enabled and AP distributed model only, enabled and AP distributed model or STA own model, or enabled and AP distributed model or STA own model with restrictions. [0101] A disabled value may indicate that AIML-based MAC operations are disabled and all STAs or non- AP MLD may only be allowed to use non-AIML-based medium access operations. A paused value may indicate that AIML-based MAC operations are paused and all STAs or non-AP MLDs may switch to non-AIML-based MAC operations. The STA or non-AP MLD may maintain their AIML models or continue to refine their AIML models. An enabled value may indicate that AIML-based MAC operations are enabled and STAs or non-AP MLDs may be allowed to use AIML-based MAC operations. The STAs or non-AP MLDs may be allowed to use their own AIML MAC models with or without restrictions or use AIML models distributed by the AP or AP MLD. [0102] An enabled with registration value may indicate that AIML-based MAC operations are enabled only for STAs or non-AP MLDs that have requested or registered with the AP or AP MLD that they intent to use AIML-based MAC operations and the AP or AP MLD has acknowledged or approved the request or registration. In one example, a STA may need to request or register with the AP to use a particular AIML model or data collection or model delivery method, which may be identified by a Model I or functionality based ID or model delivery identification, An AP may need to acknowledge or approve the request or registration for one or more AIML models identified by a Model or functionality-based ID, or data collection or model delivery method. [0103] A value of enabled and AP distributed model only may indicate that AIML-based MAC operations are enabled and STAs or non-AP MLDs may be allowed to use AIML-based MAC operations but may be only allowed to use the AIML model(s) distributed by the AP or AP MLD. [0104] A value of enabled and AP distributed model or STA own model may indicate that AIML-based MAC operations are enabled and STAs or non-AP MLDs may be allowed to use AIML-based MAC operations. The STAs or non-AP MLDs may be allowed to use the AIML model(s) distributed by the AP or AP MLD or use their own AIML models. [0105] A value of enabled and AP distributed model or STA own model with restrictions may indicate that AIML-based MAC operations are enabled and STAs or non-AP MLDs may be allowed to use AIML-based MAC operations but may use the AIML model(s) distributed by the AP or AP MLD or use their own AIML models subject to restrictions indicated by the AP or AP MLD. - 18 - 8376423.1 [0106] AIML MAC operation control field may be implemented using one subfield or multiple subfields or combinations of bitmaps or subfields to indicate one or more values or combinations thereof as indicated above. [0107] FIG.3 illustrates an example design of an AIML MAC Restriction field (e.g., AIML MAC Restrictions field 210 in FIG.2). The AIML MAC Restriction field may include information needed to control the AIML-based MAC operation, and may include one or more of the following subfields: (1) Carrier Sensing subfield 302; (2) Spatial Reuse subfield 304; (3) Obey NAV subfield 306; (4) Backoff subfield 308; and/or (5) Only in Service Periods (SP) subfield 310. [0108] The Carrier Sensing subfield 302 may indicate whether the AIML-based channel access may use carrier sensing to access the medium. A detailed indication may include whether a STA may need to perform signal detection or energy detection to conduct carrier sensing to assure that the medium is idle before it is allowed to access the medium as well as required minimum detection levels for each scheme. This may also include whether slots may be used for AIML-based channel access (e.g., whether AIML-based channel access may only occur at the boundary of a slot). [0109] The Spatial Reuse subfield 304 may indicate whether the AIML-based channel access algorithm may use spatial reuse to access the medium, for example, using OBSS-PD, PSR, SRG OBSS-PD or other type of spatial reuse. This indication may also include minimum required energy detection threshold or measured signal detection threshold for each of the spatial reuse scheme. [0110] The Obey NAV subfield 306 may indicate whether the AIML-based channel access algorithm may obey NAV. For example, one indication may be that AIML-based channel access must obey NAV. For example, if any of the received frames set the NAV, the Obey NAV 306 subfield may indicate to the STA that is must obey the NAV and cannot transmit during the NAV period. [0111] The Backoff subfield 308 may indicate whether the AIML-based channel access algorithm must follow backup rules, for example, when a collision occurred, or when a transmission failed, the AIML-based channel access may double or expand its contention window size. [0112] The Only in SP subfield 310 may indicate whether AIML-based channel access is only allowed in specific SPs, such as AIML TWT, AIML SPs, or other intervals, which may be specifically reserved for AIML- capable STAs. The STAs may need to conduct non-AIML-based channel access during other intervals or periods to provide better co-existence with legacy and non-AIML-capable devices. [0113] FIG.4 illustrates an example design of a AIML MAC parameters field. The AIML MAC restriction field may include information needed to control the AIML-based MAC operation, and may include one or more of the following subfields: (1) Priority subfield 402; (2) Contention Window (CW) Parameters subfield 404; (3) Minimum Wait Time subfield 406; (4) Backoff Parameters subfield 408; and/or (5) AIML Model Sharing Parameters subfield 410. [0114] The Priority subfield 402 may indicate the priority used for traffic that is accessing the channel using AIML-based MAC algorithm. For example, the traffic using AIML-based channel access algorithm may be - 19 - 8376423.1 considered as one or more of the following Access Categories (ACs): AC_VI, AC_VO, AC_BE, AC_BK, or AC_AIML, such as a specific access category for traffic accessing the channel using AIML-based algorithm. The priority may also imply that the parameters associated with the AC (which may be advertised in frames such as beacon, etc.) should be used, such as CWmin, CWmax, etc. [0115] The CW Parameters subfield 404 may indicate the parameters that should be used for traffic that uses AIML-based channel access, such as AIML_CWmin, AIML_CWmax. [0116] The Minimum Wait Time subfield 406b may specify the minimum time that a STA using AIML-based channel access algorithm must wait until it may determine the channel to be idle. Some value may include DIFS, PIFS, SIFS or periods that may specified in ms, ns, TUs, or slots. [0117] The Backoff Parameters subfield 408 may specify parameters that the AIML-based channel access algorithm must obey when collision occurs or when a transmission was not successful. Behavior specified may include doubling CW sizes with a maximum value of CWmax; or maintain current contention window sizes, or expanding or reducing the contention window sizes with another parameter N, where N may be a fraction or an integer. [0118] AIML Model Sharing Parameters subfield 410 may specify the parameters that may be used to share the AIML model in DL or UL. For example, for the case where APs or MLDs may share AIML models, this field may include the content ID and/or broadcast MAC address of the STA/AP that are broadcasting the AIML Models to be shared. This field may also include the frequency/time of such broadcasting of AIML models. In another example, for the case where a STA or non-AP MLD may share AIML models in the UL or P2P, it may include the HLP (Higher Level Protocol) headers that the STA or non-AP MLD shall use to broadcast or transmit its shared AIML models. [0119] Any field, subfield or part of the AIML MAC element or combination thereof may be constructed using existing or new element or fields, subfield, or other type of parts of a data, control, management frames, action frames or action frames without ACK, or PHY and MAC headers. [0120] In an embodiment, a STA may receive, from an AP, a first AIML MAC element. The first AIML MAC element may include information indicating that the AP supports AIML operations and include at least one of an AIML MAC restrictions field and an AIML MAC parameters field. Further, the STA may transmit to the AP, a second AIML MAC element. The second AIML MAC element may include information indicating that the AP supports AIML operations and include at least one of a second AIML MAC restrictions field and a second AIML MAC parameters field [0121] The AIML MAC restrictions field may include at least one of a Carrier Sensing subfield, a Spatial Reuse subfield, an Obey NAV subfield, a Backoff subfield, and an Only in Service Period (SP) subfield. The AIML MAC Restrictions field includes at least one of a Priority subfield, a Contention Window Parameters subfield, a Minimum Wait Time subfield, a Backoff Parameters subfield, and an AIML Model Sharing Parameters subfield. - 20 - 8376423.1 [0122] The AIML MAC operation management procedure may include the following: [0123] An AP or an AP affiliated with an AP MLD may include an AIML MAC element in any frames it transmits such as beacon, short beacon, AIML beacon, probe response frames, or AIML announcement frame, or may transmit AIML beacon or AIML announcement frame or other type of AIML specific frames to indicate that it or the AP MLD with which it is associated supports AIML operations. [0124] A STA or a STA affiliated with a non-AP MLD may include an AIML MAC element in any frames it transmits to an AP such as probe request, association request, AIML request frames to indicate that it or the non-AP MLD, with which it is associated with, supports AIML operations. [0125] The AP or AP affiliated with an AP MLD may indicate the exact operation mode for the AIML based MAC operations it or the AP MLD supports. It may also indicate whether only AP distributed AIML models are allowed to be used, or STAs or non-AP MLDs may use their own models, with or without restrictions, for example, for AIML-based medium access. It may also indicate whether a STA or an non-AP MLD must register or request with the AP to be able to start AIML-based MAC operations. For example, a STA may need to request or register with the AP to use a particular AIML model or data collection or model delivery method, which may be identified by a Model I or functionality based ID or model delivery identification, An AP may need to acknowledge or approve the request or registration for one or more AIML models identified by a Model or functionality-based ID, or data collection or model delivery method. [0126] An AP affiliated with an AP MLD may include an AIML MAC element in a reported STA profile for another AP affiliated with the same AP MLD, for example, in a multi-link element. For example the basic multi- link element or AIML multi-link element. An AP may include indication of a neighbor AP is capable of supporting AIML-based MAC operations in the Reduced Neighbor report. [0127] A STA or non-AP STA may follow the directions of the AP to request or start AIML-based MAC operations that the AP or AP MLD supports. It may request the AIML models from the AP, or use its own model, with or without restrictions as indicted by the AP or AP MLD. The STA or non-AP STA may use the AIML Model Sharing Parameters to obtain the shared AIML-based MAC models, for example, by receiving the EBCS streams with the indicated Content ID. A STA may need to request or register with the AP to use a particular AIML model or data collection or model delivery method, which may be identified by a Model I or functionality based ID or model delivery identification. An AP may need to acknowledge or approve the request or registration for one or more AIML models identified by a Model or functionality-based ID, or data collection or model delivery method. [0128] An AP or an AP affiliated with an AP MLD may reject the (re)association request from a STA or non- AP MLD using the reason code “Non-compliant AIML MAC Operations” if, e.g., it discovers that a STA or a non-AP MLD is does not have the appropriate AIML operation capabilities or parameters. - 21 - 8376423.1 [0129] An AP or an AP affiliated with an AP MLD may disassociate a STA or non-AP MLD using the reason code “Non-compliant AIML MAC Operations” if, for example, it discovers that a STA or a non-AP MLD is conducting AIML MAC operations not following the stipulations and directions of the AP or AP MLD. [0130] An AP or an AP affiliated with an AP MLD may reject the association request by a STA or non-AP MLD using the reason code “Non-compliant AIML MAC Operations” if, for example, it discovers that a STA or a non-AP MLD does not have the capabilities of supporting the desired AIML MAC operations. [0131] An AP or an AP affiliated with an AP MLD may transmit a frame with an AIML MAC element or any part of AIML MAC element to change the mode of AIML-based MAC operation. For example, the AP or AP affiliated with an AP MLD may disable, pause, or enable AIML-based MAC operations. It may change the AIML MAC operation mode, for example, to only allow AP Distributed AIML models, or allow STA Own Model with restrictions, or change any of the restrictions parameters for AIML MAC operations. Such a frame may be an AIML Operation Mode Change frame. Any such changes in AIML MAC operations may be characterized as a critical update and may be reported in any multi-link element by another AP affiliated with the same AP MLD. [0132] A STA or a STA affiliated with a non-AP MLD may change its AIML based MAC operation if it has received an AIML operation mode change in for example an AIML element. It may stop AIML-based MAC operations according to the received AIML operation mode change announcement and discard its AIML models. It may pause all or one or more AIML-based operations according to the received AIML operation mode change announcement, but may maintain and keep refining its AIML models. It may enable AIML-based MAC operations according to the received AIML operation mode change announcement, It may request AIML model from the AP or AP affiliated with the AP MLD. [0133] A STA or a STA affiliated with a non-AP MLD may adapt the restrictions for AIML-based MAC operations announced by the AP or AP affiliated with the AP MLD, for example by obeying rules of carrier sensing, spatial reuse, obey NAV and Backoff rules, or only conduct AIML-based MAC operations in certain SPs, such as AIML TWTs or other AIML intervals. [0134] A STA or a STA affiliated with a non-AP MLD may adapt the parameters for AIML-based MAC operations announced by the AP or AP affiliated with the AP MLD, for example by adapting priority, CW parameters, minimum wait time, backoff parameters. [0135] A STA or a STA affiliated with a non-AP MLD that are required or desires to share its own models with the AP or AP MLD or with other peer entities may use the HLP information shared by the AP or AP MLD to construct UL EBCS frames to share its own AIML models. [0136] The methods and behaviors described in the other clauses of this embodiment may be extended beyond the BSSs (APs) and MLDs discussed above. These techniques may be applied to ESSs, MMLDs, or an entire Wireless Local Area Network (WLAN). The analysis of measurements from and management of 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 that are cloud based or edge-based - 22 - 8376423.1 services. The management entity may receive reports from the other entities or receive a summary report compiled by an entity with inputs from other entities (e.g., the MLD will compile all the measurement data from its affiliated APs and non-AP STAs and then send this complied information to the management entity). The management entity may use these measurements and measurement reports to analyze and assess the network to generate management recommendations to the network entities or it may actively manage the network entities. The management entity may provide management recommendations or control to distribute or share channel, subchannel, time, spatial, code, or other resources to the various network entities as described in this embodiment. [0137] An example of one type of management control that could be provided at the WLAN level is that of AP bandwidth and band assignment for optimal WLAN performance, the management entity may use measurement data to assign the bandwidth and channel of each of the APs 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, an AP may indicate, to the non-AP STA, whether or not it requires full information in the compressed beamforming report. In one instance, the AP may request full information of ϕ and ψ angles in the beamforming report, which is the existing approach in compressed beamforming. In another instance, the AP may request only the ϕ angle information in the beamforming report. In such a case, the non- AP STA will feed back only the quantized indices of the ϕ angles, whereas for the ψ angles the AP will use pre-determined values. In either of these instances, the non-AP STA may or may not support the AIML based CSI report. [0139] To indicate such a request, the AP may use an additional bit in the STA Info filed of the null data packet announcement (NDPA) frame. FIG.5 depicts a modified STA info field format of the EHT NDPA frame. In this example, the STA info 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 may be defined as shown in Table 1 below: Partial BF Description Feedback 0 Request quantized indices of ^^ and ^^ in the beamforming feedback report. 1 Request quantized indices of ^^ only in the beamforming feedback report. Table 1 – Partial BF Feedback Subfield Encoding [0141] In the EHT MIMO Control field, the non-AP STA may also use a Partial BF feedback subfield to indicate whether the beamforming feedback report contains quantized indices of both ϕ and ψ angles or the quantized indices of ϕ angles only. - 23 - 8376423.1 [0142] In the instances when the ψ angle information is not included in the feedback report, the ψ angles are given fixed values which are known both to the beamformer (e.g. AP), and the beamformee (e.g., non-AP STA). For SU feedback with N_c=2, the fixed values may be as follows: ^{[0143] If ^^ ^^ × ^^ ^^ = 8 × 2, ^^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 ^^} ^^{^, ^^61 =} _{= = = = = = 0.12 ^^} ^{[0145] If ^^ ^^ × ^^ ^^ = 6 × 2, ^^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 ^^ ^^ × ^^ ^^ = 5 × 2, ^^21 = 0.25 ^^, ^^31 = 0.19 ^^, ^^41 = 0.15 ^^, ^^51 = 0.13 ^^, ^^32 =} _{0.26 ^^, ^^42 = 0.19 ^^, ^^52 = 0.16 ^^} ^{[0147] If ^^} _^^ ^{× ^^} _^^ ^{= 4 × 2, ^^} ₂₁ ^{= 0.25 ^^, ^^} ₃₁ ^{= 0.19 ^^, ^^} ₄₁ ^{= 0.15 ^^, ^^} ₃₂ ^{= 0.26 ^^, ^^} ₄₂ ⁼ _{0.19 ^^} [0148] If ^^ _^^ × ^^ _^^ = 3 × 2, ^^₂₁ = 0.25 ^^, ^^₃₁ = 0.19 ^^, ^^₃₂ = 0.26 ^^ [0149] If ^^ _^^ × ^^ _^^ = 2 × 2, ^^₂₁ = 0.25 ^^ [0150] In one embodiment, the number of bits used for Ψ feedback may be minimized (e.g., the number of bits used for Ψ feedback may be 0) (no need to report Ψ), or 1 or 2, etc. For example, when the number of bits used for Ψ feedback is equal to 1, both the AP and the non-AP STA(s) may store the same 25%-tile and 50%- tile Ψ values. For example, if the bit used for Ψ feedback is set to 0, it represents the 25%-tile Ψ value is fed back; if the bit used for Ψ feedback is set to [1], it represents that the 50%-tile Ψ value is fed back. In the case of 2 bits used for Ψ feedback, if the number of bits used for Ψ feedback is equal to 2, then both the AP and non-AP STA(s) may store the same 25%-tile, 50%-tile, 75%-tile, 90%-tile values. For example, if the bits used for Ψ feedback is set to [00], it represent the 25%-tile Ψ value is reported; if the bits used for Ψ feedback is set to [01], it represents the 50%-tile Ψ value is reported; if the bits used for Ψ feedback is set to 10, it represents the 75%-tile Ψ value is reported; if the bits used for Ψ feedback is set to [11], it represents the 90%-tile Ψ value is reported. Please note that above is one example to indicate the AP and non-AP STAs may share the same set of Ψ values which correspond to the feedback bit representation. There may be other mappings between the representation of bits used for Ψ feedback and the meaning of Ψ values. [0151] Additionally, the number of bits used for Ψ feedback may be dynamically changed. An AP may indicate the number of the bits used for Ψ feedback in the EHT NDP Announcement frame with Enhanced STA Info field. [0152] FIG. 6 illustrates an example format of an Enhanced STA Info field 600 in an EHT NDP announcement frame. The Enhanced STA Info field 600 may include one or more of the following subfields: - 24 - 8376423.1 AID 11 subfield 602, Partial BW Info 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 Used for Ψ Feedback subfield 616. [0153] The Number of Bits Used for Ψ Feedback subfield 616 may contain N bits. For example, if N = 1, then, in one example, [0] represents that no Ψ feedback is required and 1 represents that Ψ feedback is included. In this case the number of bits used for Ψ feedback follows the requirement defined in the Feedback Type And Ng subfield 610. If N = 2, then, in one example, [11] represents that no Ψ feedback is required, [0 1] represents that 1 bit is used for Ψ feedback, [10] represents that 2 bits are used for Ψ feedback, [00] represents the values used for legacy devices. Feedback Type and Ng subfield 620 may indicate the bits required for Φ and Ψ feedbacks respectively. The Number of bits Used for Ψ Feedback subfield 616 may over- write the requirements for the number of bits used for Ψ feedback indicated in the Feedback Type And Ng subfield 610 and the target STA that is addressed in AID11 subfield 602 may follow the requirement indicated in the Number of Bits Used for Ψ Feedback subfield. [0154] FIG.7 illustrates another example format of the Enhanced STA Info field 700 in an EHT NDP Announcement frame, which includes an Enhanced Feedback Type And Ng subfield. As shown in FIG.7, the Enhanced STA Info field may include one or more of the following subfields: AID11 subfield 702, Partial BW Info subfield 704, Reserved subfield 706. Nc Index subfield 708, Feedback Type and Ng subfield 710, Disambiguation subfield 712, Codebook Size subfield 714, Enhanced Feedback Type and Ng subfield 716. [0155] This Enhanced Feedback Type And Ng subfield 716 may be combined with the Feedback Type And Ng subfield 710 to represent the requirement of number of bits used for Φ and Ψ feedback. The Enhanced Feedback Type And Ng subfield 716 may contain N bits. Table 2 below provides exemplary encoding of the Feedback Type And Ng subfield 710, Codebook Size subfield 714 and 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). - 25 - 8376423.1 Feedback Type Codebook Enhanced Feedback Type and Ng Size And Ng (Part 2) Description B25 B26 B28 B29 0 _{0 0 1} ^{SU, Ng = 4, quantization} r_{esolution (Φ, Ψ) = {4,1} 0 0 1 1} ^{SU, Ng = 4, quantization} r_{esolution (Φ, Ψ) = {6,1} 0 1 0 1} ^{SU, Ng = 4, quantization} r_{esolution (Φ, Ψ) = {4,1} 0 1 1 1} ^{SU, Ng = 4, quantization} r_{esolution (Φ, Ψ) = {6,1} 1 0 0 1} ^{MU, Ng = 4, quantization} r_{esolution (Φ, Ψ) = {7,1} 1 0 1 1} ^{SU, Ng = 4, quantization} r_{esolution (Φ, Ψ) = {9,1} 1 1 1 1} ^{SU, Ng = 16, quantization} r_{esolution (Φ, Ψ) = {9,1}} Table 2 - Exemplary Encoding of Feedback Type And Ng subfield, Codebook Size subfield and Enhanced Feedback Type And Ng subfield for EHT TB sounding 1 bit [0156] N in the examples indicated in FIG.6 and FIG.7 may be more than 1, which means there may be more variety of number of bits used for Ψ feedback. Additionally or alternatively the AP may indicate the partial feedback requirement (e.g., Ψ feedback requirement) as illustrated above in the UHR NDP Announcement frame or other NDP Announcement frame. [0157] In one embodiment, N bits in the EHT MIMO Control field may 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 may be included in the UHR MIMO Control field or other Control field which is included in the CSI feedback report. [0158] FIG.8 illustrates an example format of a Modified EHT MIMO Control field.800, which includes a Number of Bits Used for Ψ Feedback subfield 812. As shown in FIG.8, the Modified EHT MIMO Control field 800 may 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 used for Ψ Feedback subfield 812, Remaining Feedback Segments subfield 814, First Feedback Segment subfield 816, Partial BW Info subfield 818, Sounding Dialog Token Number subfield 820, and Codebook Information subfield 822. [0159] Number of Bits Used for Ψ Feedback subfield 812 subfield may include N bits. For example, if N = 1 (e.g., Number of Bits Used for Ψ Feedback subfield is set to 1), it may represents that no Ψ feedback is included, otherwise, Ψ feedback is included (i.e., the format and number of bits used for Ψ follows Feedback Type and Codebook Information subfields). [0160] FIG.9 illustrates another example format of a Modified EHT MIMO Control field 900, which includes an Enhanced Code Information subfield 912. As shown in FIG.9, Modified EHT MIMO Control field 900 may 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 - 26 - 8376423.1 Feedback Segments subfield 914, First Feedback Segment subfield 916, Partial BW Info subfield 918, Sounding Dialog Token Number subfield 920, and Codebook Information subfield 922. [0161] The Codebook Information subfield 922 and Enhanced Codebook Information subfield 912 may be combined to indicate the size of the codebook entries. For example, if the Enhanced Codebook Information subfield 912 includes 1 bit (i.e., N = 1), if the Feedback Type subfield indicates SU: if Codebook Information subfield is set to 0 and Enhanced Codebook Information Subfield is set to 1, it represents 4 bits for Φ and 0 bit for Ψ; and if Codebook Information subfield is set to 1 and Enhanced Codebook Information Subfield is set to 1, it represents 6 bits for Φ and 0 bit for Ψ. [0162] For example, in the case when Enhanced Codebook Information subfield contains 1 bit (i.e., N = 1), if the Feedback Type subfield indicates MU: if Codebook Information subfield is set to 0 and Enhanced Codebook Information Subfield is set to 1, it represents 7 bits for Φ and 0 bit for Ψ; and if Codebook Information subfield is set to 1 and Enhanced Codebook Information Subfield is set to 1, it represents 9 bits for Φ and 0 bit for Ψ. [0163] In FIG.8 and FIG.9, N may be more than 1, which means there may be more variety of number of bits used for Ψ feedback. [0164] In one embodiment, a sounding protocol, may include multiple sounding sequences with different resolutions of Ψ feedback. In the non-TB sounding protocol, the beamformee may determine the resolution of Ψ feedback (i.e., number of bits used for Ψ feedback). The beamformee may decide to report Φ only using Enhanced EHT MIMO control field. [0165] FIG.10 illustrates an exemplary non-TB sounding protocol using Enhanced EHT MIMO control field (e.g. either of the formats depicted in FIG.8 and FIG.9). The AP 1002 may transmit, to STA11004, an NDP announcement frame 1010 followed by NDP 1012. STA11004 may then transmit, to AP 1002, an EHT Compressed Beamforming/CQI with Enhanced MIMO Control field. The EHT Compressed Beamforming/CQI with Enhanced MIMO Control field may indicate the partial CSI feedback format(e.g., only Φ’s are included and no Ψ is reported). In one embodiment, the AP 1002 may request additional Φ feedback after receiving Φ and Ψ feedback from different STAs. Alternatively, the AP 1002 may request Φ feedback from any STA independently. [0166] FIG.11 illustrates an exemplary adaptive sounding protocol, which includes legacy non-TB sounding sequences between AP 1102 and STA11004. AP 1102 and STA21004 respectively and modified TB sounding sequence with an Enhanced STA Info field in EHT NDP announcement frame and an Enhanced MIMO Control field in the EHT Compressed Beamforming/CQI report. In this example, the AP 1102 transmits, to STA11104, a legacy EHT NDP announcement frame followed by an NDP and STA1 transmits the EHT Compressed Beamforming report upon reception of the EHT NDP announcement frame and NDP from the AP. Similarly, the AP transmits to STA2 a legacy EHT NDP announcement frame followed by an NDP and STA2 transmits the EHT Compressed Beamforming report upon reception of the EHT NDP announcement frame and NDP - 27 - 8376423.1 from the AP. In order to obtain the most recent channel status and save the overhead, the AP may transmit another EHT NDP Announcement frame which includes Enhanced STA Info addressed to STA1 and STA2, The Enhanced STA Info (e.g., using the format of FIG.6 and FIG.7) may request Φ feedback only without Ψ feedback (or fewer number bits used for Ψ feedback). The NDP Announcement frame is followed by an NDP and a Trigger frame which are SIFS apart. Upon reception of the Trigger frame, STA1 and STA2 may follow the instruction defined in the Enhanced Info field in the EHT Announcement frame and transmit the compressed beamforming report with Enhanced MIMO Control fields indicating Φ feedback only without Ψ feedback ( or fewer number bits used for Ψ feedback) accordingly. The format of the Enhanced MIMO Control field may use the format given in FIG.8 and FIG.9. [0167] Although different number of bits used for Ψ feedback is discussed here, all algorithms, formats or procedures described above may be applicable to the varying number of bits used for ^^ feedback. For example, the Enhanced MIMO Control field, Enhanced STA Infor field in the EHT NDP Announcement frame, non-TB sounding protocol with Enhanced MIMO Control field, adaptive sounding protocol may be applicable to the case where the varying number of bits are used for ^^ feedback. [0168] In another embodiment, the AP may request the non-AP STA to feed back the value of a key performance indicator (KPI) that measures the quality of the AIML based CSI report against the actual channel quality. The KPI in consideration may be implementation dependent (e.g. generalized cosine similarity, effective SINR, etc.). [0169] To indicate such a request, the AP may use an additional bit in the STA info filed of the NDPA frame. FIG.12 depicts a modified STA info field format of the EHT NDPA frame. In this example, the STA info field has an additional subfield labeled KPI. [0170] The KPI subfield may be defined as shown in Table 3 below: KPI Description 0 KPI not requested in the beamforming feedback report. 1 Request KPI in the beamforming feedback report. Table 3 – KPI Subfield Encoding [0171] In the EHT MIMO control field, the non-AP STA may also use a KPI subfield to indicate whether the beamforming feedback report contains information pertaining to the KPI or not. If the STA indicates that the beamforming feedback report contains information pertaining to the KPI, the modified EHT compressed beamforming/CQI frame action field may include the KPI used for multiple purposes in the AIML or non-AIML CSI compression algorithm, e.g., used as an optimization function or objective, used as a classification criteria of AIML CSI compression scheme, used as a feature that feeds to the AIML model, used as an evaluation parameter of the candidate CSI compression algorithms, etc. Table 3 gives an example of Modified EHT compressed beamforming/CQI frame action field format. In this example, KPI, which may be used in the selection of CSI compression algorithm is included in the modified EHT compressed beamforming/CQI frame - 28 - 8376423.1 action field. Table 4 below provides an example of a modified EHT compressed beamforming/CQI frame action field. Order Meaning … … 7 KPI (e.g., used in the selection of CSI Compression algorithm) Table 4 – Modified EHT Compressed Beamforming/CQI frame Action field [0172] In one embodiment, the AP may indicate the KPI to the non-AP STA or neighboring APs. The KPI may be included in the EHT variant User Info field of the Trigger frame, which is used in the trigger-based sounding, or in the STA Info field of the EHT NDPA frame. Alternatively, this KPI may be included in any control or management frames. KPI may be negotiable between STAs. For example, to unify the AIML CSI compression model, the AP or non-AP STA may need to have an agreed KPI to generate the AIML CSI compression model. Table 5 gives the exemplary encoding of KPI bits. In this example, 2 bits are used to represent different KPIs. These 2 bits may be included in the control or management frames mentioned above. KPI Bits Description 00 Generalized Cosine Similarity (GCS) 01 Squared Generalized Cosine Similarity (SGCS) 1⁰ Error rate, e.g., ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ = ^{^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^} ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^, assuming that one ACK is required for one frame 1¹ _{Goodput, e.g., ^^ ^^ ^^ ^^ ^^ ^^ ^^ =} ^{^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ℎ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^} ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ Table 5 - Exemplary Encoding of KPI Bits [0173] In one embodiment, all AIML parameters used for CSI compression (e.g., classification or compression criteria in training phase and/or testing phase, classification methods, etc.) may be included in the management frame/control frame sent from the non-AP or AP or between APs. [0174] In one embodiment, a STA may indicate that it supports the partial feedback by setting a bit, e.g., the Partial Feedback bit, in one or more Capability element(s), such as HT Capability element, VHT Capability element, HE Capability element, EHT Capability element, UHR Capability element, or extended capability element. This Partial Feedback bit may be included in the PHY Capabilities Information field, e.g., HE PHY Capabilities Information field, EHT PHY Capabilities Information field, UHR PHY Capabilities Information field, or other PHY Capabilities Information field. The Partial Feedback bit is set to 1 may imply that the same STA may support the partial feedback report, e.g., either Φ only feedback report or Ψ only feedback report, or using fewer number of bits to represent Φ or Ψ (e.g.1 bit to present Φ or Ψ). [0175] In one embodiment, a STA may indicate that it supports to report or indicate the intermediate KPI by setting a bit, e.g., the Intermediate KPI Support bit, in one or more Capability element(s), such as HT Capability element, VHT Capability element, HE Capability element, EHT Capability element, UHR Capability element, or extended capability element. This bit may be included in the PHY Capabilities Information field - 29 - 8376423.1 or/and MAC Capabilities Information field, e.g., HE PHY Capabilities Information field or/and HE MAC Capabilities Information field, EHT PHY Capabilities Information field or/and EHT MAC Capabilities Information field, UHR PHY Capabilities Information field or/and UHR MAC Capabilities Information field, or other PHY Capabilities Information field or/and other MAC Capabilities Information field. The Intermediate KPI Support bit is set to 1 may imply that the same STA may support to indicate the intermediate KPI or using the indicated intermediate KPI in the compressed CSI process, e.g., AIML enabled CSI compression. [0176] Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. [0177] Although the solutions described herein consider 802.11 specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well. [0178] Although SIFS is used to indicate various inter frame spacing in the examples of the designs and procedures, all other inter frame spacing such as RIFS, AIFS, DIFS or other agreed time interval could be applied in the same solutions. [0179] Although four RBs per triggered TXOP are shown in some figures as example, the actual number of RBs/channels/bandwidth utilized may 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 any combination with the other features and elements. In addition, the methods described herein may 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, a read only memory (ROM), a random access memory (RAM), a 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-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer. - 30 - 8376423.1

Claims

CLAIMS What is Claimed: 1. A method performed by a station (STA), the method comprising: receiving, from an access point (AP), a first artificial intelligence/machine learning (AIML) medium access control (MAC) element, 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 restrictions field and a first AIML MAC parameters field. 2. The method of claim 1 further comprising: transmitting, to the AP, a second AIML MAC element, the second AIML MAC element including information indicating that the AP supports AIML operations, the second AIML MAC element including at least one of a second AIML MAC restrictions field and a first AIML MAC parameters field. 3. The method of claim 1, wherein the first AIML MAC restrictions field includes at least one of a Carrier Sensing subfield, a Spatial Reuse subfield, an Obey NAV subfield, a Backoff subfield, and an Only in Service Period (SP) subfield. 4. The method of claim 3, wherein the Carrier Sensing subfield indicates whether an AIML-based channel access uses carrier sensing to access a channel. 5. The method of claim 3, wherein the Spatial Reuse subfield indicates whether an AIML-based channel access algorithm uses spatial reuse to access a channel. 6. The method of claim 3, wherein the Obey NAV subfield indicates whether an AIML-based channel access algorithm must obey NAV. 7. The method of claim 3, wherein the Backoff subfield indicates whether an AIML-based channel access algorithm must follow backup rules. 8. The method of claim 3, wherein the Only in SP subfield indicates whether an AIML-based channel access algorithm is only allowed in specific SPs. 9. The method of claim 1, wherein the first AIML MAC Restrictions field includes at least one of a Priority subfield, a Contention Window Parameters subfield, a Minimum Wait Time subfield, a Backoff Parameters subfield, and an AIML Model Sharing Parameters subfield. 10. The method of claim 9, wherein the priority subfield indicates a priority used for traffic that is accessing a channel using a AIML-based MAC algorithm. 11. The method of claim 9, wherein the Contention Window Parameters subfield indicates one or more parameters used for traffic that uses AIML-based channel access. 12. The method of claim 9, wherein the Backoff Parameters subfield specifies one or more parameters that an AIML-based channel access algorithm must obey when a collision occurs or when a transmission fails. 13. The method of claim 9, wherein the AIML Model Sharing Parameters subfield specifies one or more parameters to be used to share the AIML model in downlink or uplink. 14. A station (STA) comprising: - 31 - 8376423.1 a transceiver; and a processor; wherein the transceiver and processor are configured to: receiving, from an access point (AP), a first artificial intelligence/machine learning (AIML) MAC element, 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 restrictions field and a first AIML MAC parameters field. 15. The STA of claim 14 further comprising: transmitting, to the AP, a second AIML MAC element, the second AIML MAC element including information indicating that the AP supports AIML operations, the second AIML MAC element including at least one of a second AIML MAC restrictions field and a second AIML MAC parameters field. 16. The STA of claim 14, wherein the first AIML MAC restrictions field includes at least one of a Carrier Sensing subfield, a Spatial Reuse subfield, an Obey NAV subfield, a Backoff subfield, and an Only in Service Periods (SP) subfield. 17. The STA of claim 16, wherein the Carrier Sensing subfield indicates whether an AIML-based channel access uses carrier sensing to access a channel. 18. The STA of claim 16, wherein the Spatial Reuse subfield indicates whether an AIML-based channel access algorithm uses spatial reuse to access a channel. 19. The STA of claim 16, wherein the Obey NAV subfield indicates whether an AIML-based channel access algorithm must obey NAV. 20. The STA of claim 16, wherein the Backoff subfield indicates whether an AIML-based channel access algorithm must follow backup rules. 21. The STA of claim 16, wherein the Only in SP subfield indicates whether an AIML-based channel access algorithm is only allowed in specific SPs. 22. The STA of claim 14, wherein the first AIML MAC Restrictions field includes at least one of a Priority subfield, a Contention Window Parameters subfield, a Minimum Wait Time subfield, a Backoff Parameters subfield, and an AIML Model Sharing Parameters subfield. 23. The STA of claim 22, wherein the priority subfield indicates a priority used for traffic that is accessing a channel using a AIML-based MAC algorithm. 24. The STA of claim 22, wherein the Contention Window Parameters subfield indicates one or more parameters used for traffic that uses AIML-based channel access. 25. The STA of claim 22, wherein the Backoff Parameters subfield specifies one or more parameters that an AIML-based channel access algorithm must obey when a collision occurs or when a transmission fails. 26. The STA of claim 22, wherein the AIML Model Sharing Parameters subfield specifies one or more parameters to be used to share the AIML model in downlink or uplink. - 32 - 8376423.1