Method and apparatus for using transfer learning for channel state information enhancement

Abstract

Methods and apparatus are provided for utilizing transfer learning of one wireless transmit / receive unit (WTRU) to benefit another WTRU. A method may include a WTRU receiving AI / ML model configuration information indicating one or more AI / ML models available from a network node, profiles associated with the AI / ML models, and a training convergence threshold. Based at least on the one or more profiles, the WTRU determines that the one or more AI / ML models are not suitable for use by the WTRU, and sends first information indicating that the one or more AI / ML models are not suitable for the WTRU and / or the WTRU will train a local AI / ML model. The method may then include training the local AI / ML model according to a convergence threshold; receiving a request for migrating AI / ML model parameters; and sending an indication of AI / ML model parameters associated with the trained local AI / ML model to the network node.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Application No. 63 / 335,287, filed on April 27, 2022. The contents of that earlier filed application are incorporated herein by reference in their entirety. Technical Field

[0002] The present disclosure relates generally to the field of wireless communication networks.For example, one or more embodiments disclosed herein may relate to methods, apparatuses, systems, and / or processes for utilizing learning of one wireless transmit / receive unit (WTRU) to benefit another WTRU. Summary of the invention

[0003] Certain embodiments described herein may provide methods, apparatus, systems, and / or processes for utilizing transfer learning of one wireless transmit / receive unit (WTRU) to benefit another WTRU. Embodiments may relate to a method that may include: a WTRU receiving AI / ML model configuration information indicating one or more AI / ML models available from a network node, profiles associated with the AI / ML models (e.g., a corresponding profile associated with each of the AI / ML models), and a training convergence threshold. Based at least on the one or more profiles, the WTRU determines that the one or more AI / ML models are not suitable for use by the WTRU and sends first information indicating that the one or more AI / ML models are not suitable for the WTRU and / or that the WTRU will train a local AI / ML model. The method may then include: training a local AI / ML model according to a convergence threshold; receiving a request to migrate AI / ML model parameters; and sending an indication of AI / ML model parameters associated with the trained local AI / ML model to the network node.

[0004] Embodiments may relate to an apparatus comprising a circuit, the circuit comprising any of a processor, a memory, a receiver, and / or a transmitter. The circuit may be configured to: receive AI / ML model configuration information indicating one or more AI / ML models available from a network node, a profile associated with the AI / ML model, and a training convergence threshold. Based at least on the one or more profiles, the circuit may be configured to: determine that the one or more AI / ML models are not suitable for use by the WTRU; and send first information indicating that the one or more AI / ML models are not suitable for the WTRU and / or that the WTRU will train a local AI / ML model. The circuit may be configured to: train a local AI / ML model according to a convergence threshold; receive a request to migrate AI / ML model parameters; and send an indication of AI / ML model parameters associated with the trained local AI / ML model to the network node. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding can be obtained from the following detailed description given as an example in conjunction with the accompanying drawings. Like the detailed description, the figures in such drawings are exemplary. Thus, the figures and detailed description should not be considered limiting, and other equally effective examples are possible and desirable. In addition, like reference numerals ("reference") in the various figures ("Figures") indicate similar elements, and wherein: Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented; Figure 1B is a diagram illustrating an embodiment of the Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system illustrated in; Figure 1C is a diagram illustrating an embodiment of the Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system illustrated in FIG. Figure 1D is a diagram illustrating an embodiment of the Figure 1A A system diagram of a further example RAN and a further example CN used within the communication system illustrated in FIG. Figure 2 is a diagram illustrating an example of configuration for CSI report settings, resource settings, and links; Figure 3 is a diagram illustrating codebook-based precoding utilizing feedback information; Figure 4 is a signal flow diagram of a method and apparatus for model migration from an artificial intelligence / machine learning (AI / ML or AIML) model trainer according to an embodiment; Figure 5A is a signal flow diagram of a method and apparatus for model migration from an AI / ML model user according to an embodiment; and Figure 5B is a signal flow diagram of a method and apparatus for migrating from / to a UL and / or DL ​​model of one or more UEs according to an embodiment; and Figure 6 is a flow chart of a method according to an embodiment. DETAILED DESCRIPTION

[0006] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other examples, well-known methods, processes, components, and circuits have not yet been described in detail to avoid blurring the following description. Further, embodiments and examples not specifically described herein can be practiced in place of or in conjunction with embodiments and other examples described herein, disclosed, or otherwise explicitly, implicitly, and / or inherently provided (collectively referred to as "provided").

[0007] Although various embodiments are described and / or claimed herein in which devices, systems, equipment, etc. and / or any elements thereof implement operations, processes, algorithms, functions, etc. and / or any portions thereof, it should be understood that any embodiments described and / or claimed herein specify that any device, system, equipment, etc. and / or any elements thereof are configured to implement any operation, process, algorithm, function, etc. and / or any portion thereof.

[0008] The methods, devices, and systems provided herein are well suited for communications involving both wired and wireless networks. Wired networks are well known. Figures 1A-1D To provide an overview of various types of wireless devices and infrastructure, wherein various elements of the network can utilize the methods, apparatuses, and systems provided herein, perform the methods, apparatuses, and systems provided herein, are arranged according to the methods, apparatuses, and systems provided herein, and / or are adapted and / or configured for the methods, apparatuses, and systems provided herein.

[0009] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (such as voice, data, video, messaging, broadcast, etc.) to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-sOFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0010] like Figure 1AAs shown in FIG, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, 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 device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain context), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0011] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is 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 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a home Node B, a home eNode B, a gNB, an NR NodeB, a site controller, an access point (AP), a wireless router, and the like. Although 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.

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

[0013] 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, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

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

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

[0016] 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 New Radio (NR).

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

[0018] 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), etc.

[0019] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, 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 one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In 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 a femtocell. Figure 1A As shown in FIG, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not be required to access Internet 110 via CN 106 / 115.

[0020] The RAN 104 / 113 may communicate with the CN 106 / 115, 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc. and / or perform advanced security functions, such as user authentication. Although Figure 1A Not shown, but it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0022] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and the base station 114b, which may employ an IEEE 802 radio technology.

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

[0024] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0026] Although the transmit / receive element 122 is Figure 1B 102 as a single element, but 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.

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

[0028] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. 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 a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, or 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).

[0029] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to 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, etc.

[0030] 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. The WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations in addition to or in lieu of the information from the GPS chipset 136. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

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

[0032] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference via hardware (e.g., choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for both uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0033] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with 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.

[0034] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although 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.

[0035] 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 uplink (UL) and / or downlink (DL), etc. Figure 1C As shown in FIG. , the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

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

[0037] 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, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

[0040] 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 be in communication with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] Although the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use (eg, temporarily or permanently) a wired communications interface with a communications network.

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

[0043] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a 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 into the BSS and / or carries traffic out of the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and may be delivered to the STA. Traffic from a STA to a destination outside the BSS may be sent to the AP so as to be delivered to the corresponding destination. 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 traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer traffic. Peer traffic may be sent between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0044] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each 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.

[0045] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0046] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels or by combining two non-continuous 80MHz channels (which can be referred to as 80+80 configurations). For the 80+80 configuration, after channel coding, the data can be passed through a segment parser, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be done separately on each stream. The stream can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0047] The operation mode below 1 GHz is supported by 802.11af and 802.11ah. The channel operation bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operation bandwidth and carrier used in 802.11n and 802.11ac. 802.11af supports 5MHz bandwidth, 10MHz bandwidth and 20MHz bandwidth in the TV white space (TVWS) spectrum, and 802.11ah supports 1MHz bandwidth, 2MHz bandwidth, 4MHz bandwidth, 8MHz bandwidth and 16MHz bandwidth using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument type control / machine type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries whose battery life is above a threshold (e.g., to maintain a very long battery life).

[0048] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports a 1MHz operating mode) transmitting to the AP, the entire available band may be considered busy, even if most of the band is still idle and may be available.

[0049] In the United States, the available frequency band that 802.11ah can use is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0050] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0051] The RAN 113 may include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 113 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, the gNBs 180a, 180b 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 one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

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

[0053] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as, for example, the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to the gNBs 180a, 180b, 180c while also communicating / connecting to another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

[0054] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink (UL) and / or downlink (DL), support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. As shown in FIG. Figure 1D As shown in , gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0055] Figure 1DThe CN 115 shown in FIG. 1 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. Although each of the foregoing elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by entities other than the CN operator.

[0056] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRU 102a, 102b, 102c based on the type of service utilized by the WTRU 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 machine type communication (MTC) access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies, such as WiFi.

[0057] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0058] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the 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 184a, 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 downlink packets, providing mobility anchoring, etc.

[0059] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local data network (DN) 185a, 185b through the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0060] Given that Figures 1A to 1D as well as Figures 1A to 1D , one or more or all of the functions described herein with respect to one or more of the following items may be performed by one or more simulation devices (not shown) to perform one or more or all of the functions described herein with respect to one or more of the following items: WTRU102a-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. The simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0062] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as a part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or in a non-deployed (e.g., test) wired and / or wireless communication network to achieve the test of one or more components. The one or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication carried out via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0063] Certain example embodiments may relate to channel state information reporting. Channel state information (CSI) which may include at least one of: a channel quality index (CQI), a rank indicator (RI), a precoding matrix index (PMI), an L1 channel measurement result (e.g., RSRP (such as L1-RSRP) or SINR), a CSI-RS resource indicator (CRI), an SS / PBCH block resource indicator (SSBRI), a layer indicator (LI), and / or any other measurement quantity measured by the WTRU from a configured reference signal (e.g., a CSI-RS or a SS / PBCH block or any other reference signal). More particularly, one or more embodiments disclosed herein may relate to methods, apparatus, systems, and / or processes for utilizing transfer learning to achieve channel state information (CSI) feedback enhancements such as overhead reduction, improved accuracy, and prediction.

[0064] Some example embodiments may provide a CSI reporting framework. The WTRU may be configured to report CSI via an uplink control channel on a physical uplink control channel (PUCCH) or as requested by the gNB for an uplink physical shared channel (UL PUSCH) grant. Depending on the configuration, the CSI-RS may cover the full bandwidth of a bandwidth part (BWP) or only a small portion thereof. Within the CSI-RS bandwidth, the CSI-RS may be configured in each physical resource block (PRB) or every other PRB. In the time domain, the CSI-RS resources may be configured periodically, semi-persistently, or aperiodically. Semi-persistent CSI-RS is similar to periodic CSI-RS, except that: the resource may be activated (deactivated) by a MAC control element (CE); and the WTRU reports the relevant measurement results only when the resource is activated. For aperiodic CSI-RS, the WTRU is triggered by a request in the DCI (downlink control information) to report the measured CSI-RS on the PUSCH. Periodic reports are carried on the PUCCH, while semi-persistent reports may be carried on the PUCCH or PUSCH. The reported CSI may be used by the scheduler in allocating optimal resource blocks, determining the precoding matrix, beams and / or transmission mode, and selecting an appropriate modulation and coding scheme (MCS), possibly based on the time-frequency selectivity of the channel. The reliability, accuracy, and timeliness of WTRU CSI reporting may be critical to meeting Ultra-Reliable and Low-Latency Communication (URLLC) service requirements.

[0065] The WTRU may be configured with a CSI configuration, which may include one or more CSI reporting settings, resource settings, and / or a link between one or more CSI reporting settings and one or more resource settings. The linking may be achieved, for example, by providing a pointer to the resource configuration within the CSI reporting setting. Figure 2 Examples of configuration for CSI reporting settings, resource settings, and linking are shown.

[0066] In the CSI configuration, one or more of the following configuration parameters may be provided: N≥1 CSI report settings 211; M≥1 resource settings 213; and CSI measurement settings 215, which link the N CSI report settings 211 with the M resource settings 213. The CSI report settings 211 may include at least one of the following: time domain behavior (e.g., aperiodic or periodic / semi-persistent); frequency granularity, at least for PMI and CQI; CSI report type (e.g., PMI, CQI, RI, CRI, etc.); and if PMI is reported, PMI type (Type I or II) and codebook configuration. The resource settings 213 may include at least one of the following: time domain behavior (e.g., aperiodic or periodic / semi-persistent); RS type (e.g., for channel measurement results or interference measurement results); and S≥1 resource sets, and each resource set may contain K resources, where K is a preconfigurable integer. The CSI measurement settings 215 may include a linked pair of at least one of the following: a CSI reporting setting; a resource setting; and for CQI, a reference transmission scheme setting. For CSI reporting for component carriers, one or more of the following frequency granularities may be supported: wideband CSI, partial-band CSI, and / or sub-band CSI.

[0067] Certain example embodiments may involve codebook based precoding. Figure 3 The basic concept of codebook-based precoding using feedback information is shown. The feedback information may include: a precoding matrix index (PMI), which may be referred to as Figure 3 The codeword index in the codebook shown in .

[0068] like Figure 3 As shown in , the codebook includes a set of precoding vectors / matrices for each rank and multiple antenna ports, and each precoding vector / matrix has its own index so that the receiver can inform the transmitter of the preferred precoding vector / matrix index. Codebook-based precoding may suffer from performance degradation due to its unlimited number of precoding vectors / matrices compared to precoding not based on the codebook. However, the main advantage of codebook-based precoding is the possibility of lower control signaling / feedback overhead. Table 1 shows an example of a codebook for 2Tx: 2Tx downlink codebook Table 1

[0069] Some example embodiments may include CSI processing criteria. A CSI processing unit (CPU) may be referred to as a minimum CSI processing unit, and a WTRU may support one or more CPUs (e.g., N CPUs). A WTRU with N CPUs may estimate N CSI feedback calculations in parallel, where N may be the WTRU capability. If a WTRU is requested to estimate more than N CSI feedbacks simultaneously, the WTRU may perform only the N highest priority CSI feedbacks, and the remaining may not be estimated.

[0070] The start and end of the CPU process can be determined based on the CSI report type (e.g., aperiodic, periodic, semi-persistent) as follows. For aperiodic CSI reporting, the CPU is occupied starting from the first OFDM symbol after the PDCCH trigger until the last OFDM symbol of the PUSCH carrying the CSI report. For periodic and semi-persistent CSI reporting, the CPU is occupied starting from the first OFDM symbol of one or more associated measurement resources (no earlier than the CSI reference resource) until the last OFDM symbol of the CSI report.

[0071] The number of occupied CPUs may differ based on the CSI measurement result type (e.g., beam-based or non-beam-based), as follows. For non-beam-related reports, K CPUs are occupied when there are K CSI-RS resources in the CSI-RS resource set for channel measurement. For beam-related reports (e.g., "cri-RSRP" (CSI-RS resource indicator - reference signal received power), "ssb (synchronization signal block) - index-RSRP", or "none"), one CPU is occupied regardless of the number of CSI-RS resources in the CSI-RS resource set for channel measurement due to lower CSI calculation complexity. It should be noted that "none" is used for P3 operation or non-periodic tracking reference signal (TRS) transmission. For non-periodic CSI reporting with a single CSI-RS resource, one CPU is occupied. For CSI reporting K CSI-RS resources, K CPUs are occupied because the WTRU needs to perform CSI measurement for each CSI-RS resource.

[0072] When the number of unoccupied CPUs (N u ) is less than the required number of CPUs reported for CSI (N r ), the following WTRU behavior may be used. In case of UCI on PUSCH without data / HARQ (Hybrid Automatic Repeat Request), the WTRU may discard N_r–N_u CSI reports based on priority. In other cases, the WTRU may report dummy information in Nr–Nu CSI reports based on priority to avoid rate matching treatment of PUSCH.

[0073] Artificial intelligence can be broadly defined as the behavior exhibited by a machine. Such behavior can, for example, mimic cognitive functions to sense, reason, adapt, and act.

[0074] Machine learning may refer to a type of algorithm that solves problems based on learning through experience ("data") without being explicitly programmed ("a configured set of rules"). Machine learning may be considered a subset of AI. Different machine learning paradigms may be imagined based on the nature of the data or feedback available to the learning algorithm. For example, a supervised learning scheme may involve learning a function that maps inputs to outputs based on labeled training examples, where each training example may be a pair consisting of an input and a corresponding output. For example, an unsupervised learning scheme may involve detecting patterns in data that do not have pre-existing labels. For example, a reinforcement learning scheme may involve executing a sequence of actions in an environment to maximize a cumulative reward. In some embodiments, it is possible to apply a machine learning algorithm using a combination or interpolation of the above-mentioned schemes. For example, a semi-supervised learning scheme may use a combination of a small amount of labeled data with a large amount of unlabeled data during training. In this regard, semi-supervised learning falls between unsupervised learning (without labeled training data) and supervised learning (with only labeled training data).

[0075] Deep learning refers to a class of machine learning algorithms that use artificial neural networks (specifically, deep neural networks (DNNs)) that are loosely inspired from biological systems. DNNs are a special class of machine learning models inspired by the human brain, in which the input is multiple linear transformations and nonlinear activation functions passed. DNNs typically include multiple layers, each of which includes a linear transformation and a given nonlinear activation function. DNNs can be trained using training data via a backpropagation algorithm. Recently, DNNs have shown prior art performance in a variety of fields (e.g., speech, vision, natural language, etc.) and for various machine learning settings (such as supervised, unsupervised, and semi-supervised). The term "AIML-based method / processing" may refer to the implementation of behavior and / or compliance with requirements through data-based learning without explicit configuration of a sequence of steps or actions. This approach can enable learning of complex behaviors that may be difficult to specify and / or implement using traditional methods.

[0076] Machine-to-machine AI / ML transfer learning and inference systems connected together via 5G (and 5G+) networks are promising tools for addressing scenarios where the availability of large data sets may not be practical due to the cost of the data collection process and the highly dynamic behavior of the system. Sharing of knowledge among diverse learning algorithms can reduce the size of the required data set and improve learning accuracy and rate. However, there are implementation challenges to efficiently and seamlessly deploying and using transfer learning to achieve any gains. One such challenge is that there are no performance metrics to measure the success of transfer learning from the source system to the target system. In addition, the required bandwidth, security, and privacy levels of the knowledge being migrated, as well as the convergence time to complete training at the source and the latency to complete the migration from the source WTRU to the target WTRU may be difficult to determine.

[0077] In the present disclosure, it is assumed that there are multiple AI / ML systems available in a low latency, high reliability, and high bandwidth system enabled for machine-to-machine interaction (e.g., via a sidechain interface). The interaction may also be via a network (i.e., using a Uu link). The framework is compatible with the proposed description from 3GPP TR 22.874 [7], whereby AI / ML systems may continuously exchange and share AI / ML model layers in a distributed and / or federated network as determined by the system in response to changes in events, conditions, or emergency situations to improve some or all of the ML system prediction accuracy. These systems may optimize AI / ML inference latency by executing different layers on various AI / ML networked systems.

[0078] There are two main types of ML model processing / training, namely: (1) using non-real-time training; and (2) using real-time training. AI / ML models may be trained and optimized based on a specific set of input training data, using extensive computing resources, utilizing very large data sets and parameters to achieve the highest possible accuracy in the performance of the ML model. Training is typically done offline over a long period of time, and the resulting trained model may serve as a baseline / general model that the WTRU may take and further train / fine-tune using its local data.

[0079] The WTRU may use real-time data for online training of partial or complete AI / ML models. The WTRU may use local data to retrain / improve / fine-tune the ML model it receives from the network. The use of real-time training is also applicable for applications where different types of ML systems are connected to exchange partial or complete AI / ML model data or parameters to improve prediction accuracy. The WTRU may continuously improve their local ML models based on data collected from the environment by the WTRU or other sensors. The WTRU may periodically upload the improved model data / parameters to a larger cloud-based network where further processing occurs to further improve the complete ML model.

[0080] Certain example embodiments may be configured to use transfer learning for enhanced channel state information processing. An AI / ML capable WTRU (also referred to interchangeably in this disclosure as an ML capable WTRU, ML encoder / decoder, ML capable channel estimation decoder, or simply WTRU) is a WTRU configured with one or more artificial intelligence (AI) / machine learning (ML) models, which are also referred to interchangeably in this disclosure as ML models, ML encoder / decoders, CSI models, CSI derivation models, CSI prediction models, CHEST models, CSI model estimators and / or predictors and / or derivers, etc. Throughout this document, the (model) lifecycle management phase / process may refer to any one or more of the following: model training / retraining / fine-tuning, model performance monitoring, model selection / activation / deactivation / switching / fallback to legacy, model inference, etc. An AI / ML capable WTRU may be an anchor WTRU and / or a collaborative WTRU. An AI / ML capable WTRU may transition from an anchor WTRU role to a collaborative WTRU role, or vice versa.

[0081] An anchor WTRU in the context of the present disclosure (interchangeably referred to as a model trainer WTRU or master WTRU) refers to an AI / ML-capable WTRU involved in performing one or more of the following: partial or complete training / retraining of an AI / ML model; receiving configuration on training parameters of the AI / ML model (e.g., performance thresholds that determine the quality of training to ensure maintenance of QoS when using the ML model) from the network; sending the trained model / trained model parameters to the network in an uplink; hosting an application function (e.g., an AI / ML application) from which a request for training / retraining may be received; sending information related to the training to the network and / or a cooperating WTRU; and / or sending the trained model / trained model parameters to (one or more) cooperating WTRUs via a sidechain interface.

[0082] A collaborative WTRU in the context of the present disclosure (interchangeably referred to as a model user WTRU or auxiliary WTRU or member WTRU) refers to an AI / ML capable WTRU involved in performing one or more of the following: partial or complete training / retraining of an AI / ML model; receiving configuration on training parameters of the AI / ML model (e.g., performance thresholds that determine the quality of training to ensure maintenance of QoS when using the ML model) from the network; receiving trained models / trained model parameters in the downlink from the network and / or directly from the anchor WTRU via a sidechain interface; sending information related to the training / fine-tuning of the model to the network and / or the anchor WTRU.

[0083] A collaboration group (interchangeably referred to as a collaboration WTRU group or WTRU group) may include one or more WTRUs, wherein a WTRU transmitting or sending an AI / ML-capable model and / or AI / ML model parameters (e.g., in uplink) may be referred to as an anchor WTRU, and a WTRU receiving a trained AI / ML-capable model and / or model parameters (e.g., in downlink) may be referred to as a collaboration WTRU and / or member WTRU. A WTRU may change role from an anchor WTRU to a collaboration / member WTRU, and / or vice versa.

[0084] A ML capable WTRU is configured with a first set of ML model(s) which may include one or more ML models for CSI derivation / channel estimation / prediction. The models may be among a subset of models pre-approved by the network. The model(s) may have been implemented by the WTRU vendor or pre-downloaded from the network (from the serving gNB or possibly from another gNB), or the models may be among a list of pre-defined models as per the standard.

[0085] The model(s) configured at the WTRU may be trained periodically, semi-periodically, or when triggered by a request from the network or other triggers from the WTRU (e.g., channel measurements). The models may have a model ID that may uniquely identify them, assigned by the WTRU and indicated to the network, or vice versa. The model(s) may also have additional descriptive information labeling them (such as model type, e.g., recurrent neural network (RNN), deep neural network (DNN), convolutional neural network (CNN), etc.).

[0086] In one example, the WTRU may train one of the ML models it is configured with until the model meets a threshold for a performance metric, which may be set by the network to ensure a certain quality for the output of the ML model. The WTRU may then report the completion of the training of its ML model to the network and send the ML model (parameters) in the uplink upon network request.

[0087] In another example, the WTRU may assess the validity / suitability of each model in the first set of models with which it is configured and may determine that none of the (one or more) models with which it is configured matches its requirements and the WTRU may determine that it requires model migration (e.g., in the downlink).

[0088] A second set of ML models may exist at the network. These ML models may be specified in the standard, implemented by the network operator, or pre-downloaded from a server. The models may be gNB specific, or the same set of models may be shared among different gNBs. The second list of models present at the network / gNB may have been trained by WTRU(s) other than the WTRU with which the ML models will be shared / used, possibly in a similar environment (e.g., similar propagation delay) to the environment in which the models will be shared / used.

[0089] In an example, the gNB may send a list of one or more trained models to the WTRU (e.g., via a broadcast in a system information block (SIB)). The models may have model IDs that uniquely identify them, assigned by the WTRU that trained them, or assigned by the network.

[0090] In another example, the WTRU may send assistance information to the network, which may include capability information (e.g., ML model type(s) the WTRU is configured with / compatible with, WTRU antenna configuration, WTRU positioning / location information, bandwidth portion the WTRU is configured with, etc.). The network may perform initial filtering and send an indication with a list of trained ML models (e.g., model IDs) available at the network corresponding to the WTRU's capabilities in response to the assistance information sent by the WTRU.

[0091] The AIML model may be associated with a model profile. In one embodiment, the WTRU may be configured with an association between the AI / ML model and the model profile. In another embodiment, the WTRU may determine / update the model profile associated with the AI / ML model, for example based on the results of a training process.

[0092] According to an embodiment, the model profile may include configuration and / or information regarding the number of layers (e.g., N1) that are updated out of the total number of layers (e.g., N). Once the WTRU receives a deep learning model, it may choose to directly use a pre-trained model or retrain the entire or a portion of the received model. After receiving the trained model, the WTRU may establish that the received model is not directly suitable for channel estimation or CSI derivation. Even though the received model may not be suitable for direct deployment, portions of the model may be directly utilized for inference or retraining purposes.

[0093] In accordance with some example embodiments, the WTRU may be configured to perform training and update portions of an AI / ML model based on a model profile determined by the WTRU, for example, the number of layers that remain unchanged (i.e., N-N1) and the number of layers whose weights may be updated due to training (i.e., N1).

[0094] For example, the received deep learning model may have N layers. The low-level features extracted by the first N1 layers may be directly applicable to the WTRU and may not require retraining, and therefore, the weights of these layers may be kept "frozen" for the training process. The remaining N-N1 layers may require retraining by the WTRU, and these weights may be updated based on data available locally at the WTRU during the fine-tuning or retraining process at the WTRU.

[0095] The selection of parameter N1, which indicates how many layers can be directly utilized by the WTRU and how many layers will require retraining, may be determined by the WTRU based on channel characteristics calculated at the WTRU using reference symbols (e.g., CSI-RS, DMRS, etc.). The WTRU may provide parameter N1 to the gNB.

[0096] Alternatively, the channel characteristics calculated at the WTRU may also be indicated to the gNB, which may then decide that only a portion of the model (e.g., the first N1 layers) may be useful to the WTRU and may transmit only that portion of the model (e.g., the first N1 layers) to the WTRU.

[0097] According to certain example embodiments, the WTRU may be configured to migrate portions of the AIML model based on a model profile determined by the WTRU, such as the number of layers (ie, N1) that differ from a baseline model of N layers.

[0098] Once training at the WTRU is complete, the WTRU may transmit an indication of the completion of training to the gNB. The gNB may initiate a model migration request (i.e., send a request to the WTRU to send the model to the gNB). In this scenario, the WTRU may be required to share the trained model or the trained model parameters and some statistics related to the training data conditions with the gNB. In an example, if the WTRU has used an existing model received from the gNB for the transfer learning process and only a portion of the base model received from the gNB is trained (e.g., the last N-N1 layers) while the other layers (e.g., the first N1 layers) are kept constant or "frozen", then the WTRU may indicate to the gNB that only a portion of the model is to be retrained. The WTRU may share weights corresponding to only the trained layers (e.g., the last N-N1 layers).

[0099] In accordance with some example embodiments, a model profile may include configuration and / or information about a version associated with an AI / ML model. Each AIML model may be associated with a unique version number. For example, the version number may be configured by the gNB, possibly as part of the model profile. For example, the WTRU may be configured to autonomously assign version numbers for the AI / ML model. The WTRU may assign different version numbers to different updates to the same AI / ML model, perhaps after an update due to a training process. In one embodiment, the WTRU may be configured to select a version number within a version number space configured by the gNB. In one embodiment, the WTRU may be configured with a version number format comprising two parts. The first part may carry a WTRU-specific identifier, and the second part may be a model-specific identifier.

[0100] In particular, the gNB may potentially have several different versions of the models received from different WTRUs. Therefore, these models may need to be versioned appropriately, and it is important to capture information about the data conditions under which they were trained and are expected to perform well.

[0101] For many of these deep learning models, the weights associated with the initial layers of the neural network may be the same, since many of these networks may have been trained on the same baseline model. Therefore, as part of model versioning, it may be useful to review the model version number associated with the baseline model and the number of layers that are directly reused from the baseline model ("frozen" layers). Since these "frozen" layers have already been used without retraining and are the same as the baseline model, they may not need to be explicitly stored, and only the retrained layers may need to be saved.

[0102] According to certain example embodiments, a model profile may include configuration and / or information regarding model performance metrics associated with an AI / ML model. Each AIML model may be associated with a performance metric. Some examples of model performance metrics may include, but are not limited to: NMSE (normalized mean square error), cosine similarity, etc. In one example, the WTRU may receive performance metrics for a model from the gNB, perhaps for an AIML model downloaded from the gNB. In another example, the WTRU may be configured to determine performance metrics for an AIML model, perhaps by measuring AIML model performance on a predefined data set and / or a data set collected / observed over a period of time.

[0103] According to an embodiment, the WTRU may be configured with different levels of model profiles, where each level may refer to the amount of information associated with the model profile.

[0104] Different levels of model profiles may be configured to enable the WTRU to trade off between signaling overhead and the level of exposure of model details. For example, the model-specific parameters that may be shared may include model parameters related to the data domain and task that may be shared: for example, model weights, partially labeled data sets, algorithms (e.g., parameters of minimization / optimization functions). When migrating models between a WTRU and a gNB or between WTRUs, for example, different levels of information exchange may be configured.

[0105] Level 1: This is the most basic level of information exchange. This may include at least one of the following: weights associated with the trained model, the version number of the baseline model used (if any), or very basic channel characteristics (e.g., Doppler, delay spread, signal-to-noise ratio (SNR)) under which the model was trained. The model shared at this level may even be a compressed version of the actual model with quantized weights. Model compression and quantization may slightly affect the accuracy of the model.

[0106] Level 2: At this level, a higher degree of information may be provided. In addition to the level 1 information, the WTRU may also share more detailed information about the channel characteristics, or may also share some representative data samples for model training. The models shared at this level may be uncompressed with floating point weights, or may have a lower degree of compression and quantization than level 1.

[0107] Level 3: This is the highest level of information that may be provided by the WTRU. In this level, in addition to the information shared in level 2, the WTRU may also share at least one of the following: a larger number of training samples, the training samples used for training (like the optimizer used, the learning rate, the cost function, the data augmentation method used (if any), the regularization used (if any), etc.). In addition to this, the models shared at this level may be uncompressed and unquantized, or may have a lower degree of compression or quantization than level 2.

[0108] ML model validity relies on some conditions that determine how long and / or under what conditions the ML model is valid, i.e., validity conditions. These conditions may be sent in the uplink along with the model migration performed by the anchor WTRU in the uplink. The WTRU may receive (e.g., in the downlink or from the network / gNB) the conditions on the validity of the model, possibly along with the model itself. Examples of parameters that may determine model validity and may be fully or partially sent / received in the downlink along with the model or in the uplink along with model migration include any one or more of the following: data distribution or data distribution statistics, measurement results (e.g., channel measurement results) used to train the AI / ML model (e.g., channel coherence bandwidth, channel coherence time, Doppler spread, delay spread, SINR, etc.), static information about the AI / ML model, information about model parameters as described above, information about model performance (e.g., thresholds or performance thresholds, history / performance of the model at the WTRU, training frequency of the model at the WTRU).

[0109] The data distribution or data distribution statistics may include a complete data set or a partial data set. It may include (one or more) training data sets and / or (one or more) validation data sets and / or (one or more) test data sets. It may include any type of data set (e.g., numerical, bivariate, multivariate, correlation, etc.).

[0110] The measurement results (e.g., channel measurement results) may include measurement results (e.g., channel coherence bandwidth, channel coherence time, Doppler spread, delay spread, SINR, etc.) used to train the AI / ML model. In one example, the ML model may output (e.g., only output) reasonable estimates for channel estimation / prediction / CSI derivation within a given SNR range. Outside this range, the estimate is outside the error margin (which may be, for example, determined when using CSI-RS to calculate the NMSE between the ML model output and the traditional CSI calculation). The measurement results may include the channel coherence time measured by the anchor WTRU. In one example, the WTRU may determine how fast or slow the channel is changing based on the measurement results of the channel coherence time while the ML model is measured / being measured. The WTRU may report the original channel coherence time value to the network along with sending the model in the uplink, or it may use the channel coherence time to determine a validity period during which the anchor WTRU may assume the model to be valid in the future. Since it is a common metric to characterize the fading characteristics of the channel used in the training of the model, the channel coherence time may be a good measure of how good the model is and / or how long the network / another WTRU may be able to use the ML model. This may be especially true for neighboring WTRUs in similar environments that may experience similar propagation delays and channel conditions.

[0111] Static information about the model (e.g., model size, overhead associated with the model, latency of the model output results) is another example parameter that may be factored into the decision of whether the model is suitable for use. The parameters (e.g., model size, overhead, latency of the model) may be reported as raw metrics. Alternatively, other parameters that implicitly / explicitly provide information may be determined by the WTRU or the network. In one example, the WTRU may report the size of the ML model (e.g., in megabytes, megabits, or kilobytes, etc.). In another example, the WTRU may report the bandwidth required to download the model, which may implicitly inform the network of the model size. In another example, the WTRU may report the size of the ML model (e.g., in megabytes, megabits, or kilobytes, etc.), leaving it to the network to determine the bandwidth required to download the model. In one example, the WTRU may measure the training metrics of the model and report them back to the network (e.g., time to train, number of iterations, amount of data required). In another example, the network may send a request to the anchor WTRU to have it train its ML model. The network may measure the time from sending the request to the time of receiving the trained ML model and determine the total latency of training and sending the model (including model processing / training latency and communication latency on the anchor WTRU's Uu link). Based on the knowledge of the communication latency, the network may determine the training time. The granularity of maintenance / reporting of model parameters may vary. In one example, the WTRU may determine and report to the network the time or number of resources it consumed to train the complete model. In another example, the WTRU may determine and report to the network the time or number of resources it consumed to train some layers of the model and report the number of layers trained along with the training time. In one example, upon receiving a request for model migration from the network, the anchor WTRU may send the model (parameters) to the network. The network may determine the total communication latency of the link based on the knowledge of the round trip time between the WTRU and the gNB.

[0112] In one example, the WTRU may determine the validity of the model based on its performance, such as during a testing phase. In one example, the WTRU may know how well the ML model has performed during a testing phase and may determine the validity of the model based on its performance (e.g., how long the model may be valid).

[0113] In one example, the WTRU may determine the effectiveness of the ML model based on the training frequency of the model. In one example, if the WTRU knows that the ML model has required training / retraining every X seconds on average, it may report to the network the effectiveness of X ms associated with the ML model.

[0114] Whenever the anchor WTRU sends a model in the uplink, it may also send validity information associated with the model. The validity information may be based on the factors listed above (e.g., the channel coherence time measured by the anchor WTRU, the training frequency of the ML model, etc.). In an example, this information may be sent in the form of a validity timer sent with the model, or in the form of a condition (e.g., the ML model may be downloaded only if sufficient bandwidth is available based on the model size), or in the form of an applicability range (e.g., an ML model that is valid for a specific SNR range).

[0115] Whenever the network sends a model to a member WTRU in the downlink, it may also send the associated validity information so that the member WTRU knows how long the model is valid. In one example, a ML model sent in the downlink with a validity timer of, for example, Y ms may inform the member WTRU that the ML model may give an output within an error margin (e.g., NMSE < threshold T) only within Y ms. The member WTRU may determine how long to use the model based on the validity information and what its backup options may be. The member WTRU may apply or start the validity timer when receiving the ML model or when using the ML model for the first time. The WTRU may determine that the model is not valid when the validity timer expires. The validity timer may be defined as the number of time slots or resources or transmission resources / occasions. In one example, the member WTRU may send a request to increase the frequency of the CSI-RS to the gNB after Y ms. In another example, the member WTRU may send a request for another ML model (parameters) to the gNB in ​​the downlink.

[0116] The validity information may also be sent without a model, in the uplink, downlink, and / or on a sidelink interface. In this case, the validity information may serve to provide information about the validity of the AIML model in advance to avoid the overhead of first sending the model and then determining its validity.

[0117] In some examples, there may be an initial exchange of information. For example, to configure a WTRU with a specific AIML model (e.g., CNN, DNN) for channel estimation and prediction, the gNB may require information about the WTRU's capabilities and other information that enables the gNB to configure the WTRU with specific information for the estimation / prediction process (e.g., CNN, DNN, RNN weights).

[0118] The WTRU may send capability information for model assistance (sometimes referred to as model assistance information below), such as the model(s) with which the WTRU may be configured (e.g., DNN, CNN, RNN), the WTRU antenna configuration, the WTRU positioning / location / orientation information, the portion of the WTRU bandwidth on which the WTRU operates, and the WTRU CSI statistics.

[0119] The WTRU may use uplink control information (UCI) to periodically or aperiodically send model assistance information, possibly depending on changes in the observed CSI distribution. The sending of model assistance information may also be event triggered (e.g., a large change in the observed CSI distribution may trigger the WTRU to send / re-send model assistance information).

[0120] The gNB may send data distribution statistics on all AIML models (e.g., CNN, DNN, RNN) available at the gNB, with corresponding (one or more) convergence thresholds. In other words, the gNB may convey information of all available AIML models (e.g., DNN, CNN, RNN) and the parameters for which each AIML model is trained (e.g., channel estimation / prediction error thresholds, convergence rate, etc.). The WTRU may receive a set of information associated with the AIML models available at its gNB. The set of information associated with the AIML models may be received via a dedicated transmission (e.g., PDSCH), via RRC, or via broadcast information (e.g., PBCH, SIB, SSB).

[0121] The gNB may also send CSI-RS samples to the WTRU to observe the channel profile characteristics and select an AIML model specific to the observed channel profile characteristics. The WTRU may be configured with CSI-RS to perform and report channel profile measurements.

[0122] In one example, if the data distribution statistics / model profile of the gNB does not match the observed channel distribution characteristics / model profile at the WTRU, the WTRU may send an indication to the gNB expressing that no match was found and request online training.

[0123] In one example, depending on the AIML model assistance information sent by the WTRU to the gNB, the gNB may select a specific AIML model that is close to or matches the assistance information received by the gNB from the WTRU. The WTRU may receive multiple models and may select an appropriate one based on measurement results or capabilities.

[0124] The gNB may then configure the WTRU with an AIML model that is best suited for the WTRU based on the auxiliary information (e.g., channel conditions), where the WTRU may use the configured model to employ the AIML model and perform channel estimation and prediction.

[0125] In one example, if the WTRU data distribution characteristics / statistics match one of the data distribution models available at the gNB, the WTRU may indicate the AIML match information to the gNB. In response, the gNB may send the AIML model parameters (e.g., model weights) of the relevant model to the WTRU.

[0126] In one example, after the model weights have been downloaded / deployed at the WTRU, the WTRU may choose to update the weights to be fine-tuned based on channel conditions specific to the WTRU.

[0127] The WTRU may be provided with one or more AIML models. The WTRU may receive or download an AIML model from a gNB or another WTRU. The WTRU may determine the AIML model based on training performed by the WTRU or by another network node (e.g., a gNB or another WTRU). The WTRU may determine the model based on a combination of a first model (e.g., possibly obtained from another network node) and training performed by the WTRU. For example, the WTRU may obtain a first / rough AIML model, and the WTRU may improve the model using training. The WTRU may determine the AIML model based on a combination of two or more AIML models.

[0128] The WTRU may determine whether the AIML model is applicable to at least one of its functions. For example, the WTRU may use or require the AIML model to perform at least one of channel estimation, channel prediction, CSI measurement, positioning, beam failure detection / recovery, mobility, radio link monitoring (RLM), or unlicensed channel monitoring / assessment.

[0129] The WTRU may determine whether an AIML model is suitable for use in at least one of the applicable functions. Suitability may be defined as the required performance of the model to implement the applicable function. Suitability may be defined as a set of parameters associated with an AIML model that is applicable to the WTRU or a function of the WTRU. Suitability (or required performance) may be configured per function. Suitability may be determined based on at least one criterion that is implemented. The WTRU may be configured with the at least one criterion.

[0130] The WTRU may determine the suitability of the AIML model based on at least one of: WTRU capabilities, model type, WTRU traffic type, measurement results, comparison with legacy functionality, whether the WTRU is part of the group with which the AIML model is associated, and / or hysteresis information.

[0131] For example, the WTRU capabilities may include at least one of the following: antenna configuration, numerology (e.g., SCS, waveform), number of Tx / Rx chains, whether the WTRU supports frequency division duplex (FDD) / time division duplex (TDD) / cross division duplex (XDD) / full duplex / half duplex, number of panels. The WTRU may determine that the AIML model is appropriate if the AIML model is applicable to at least one of its capabilities.

[0132] Regarding model types, for example, the WTRU may support at least one of the following model types: DNN, Untrained Neural Network (UNN), CNN, RNN, or Autoencoder. If the AIML model uses a model type supported by the WTRU, the WTRU may determine that it is suitable.

[0133] The WTRU may determine that the AIML model is suitable if it is applicable to the WTRU's traffic type. The traffic type may be defined as or may include at least one of: periodic / aperiodic, burst start / end / duration, reliability, latency, throughput.

[0134] Regarding measurement results, for example, the WTRU may be configured with resources on which to perform at least one measurement result. The WTRU may compare the at least one measurement result with at least one threshold. The at least one threshold may be configurable. If the at least one measurement result is greater than or less than the at least one threshold, the WTRU may determine that the model is appropriate. The model may be associated with at least one measurement result threshold. The WTRU function may be associated with at least one measurement result threshold. The measurement results may include and / or relate to at least one of the following: position, speed and / or mobility direction; L1 or L3 measurement results, such as reference signal received power (RSRP), received signal strength indicator (RSSI), reference signal received quality (RSRQ), signal to interference and noise ratio (SINR), channel occupancy (CO), rank indicator (RI), channel quality index (CQI), precoding matrix indicator (PMI), layer indicator (LI); interference measurement results; Doppler, Doppler spread, delay spread, number of multipaths; coherence time, coherence bandwidth ; beam direction, beam width, set of beams (e.g., elements in a set of cardinality of a set); energy detection; successful channel access attempt rate (e.g., the WTRU may maintain a number or percentage of successful listen-before-talk (LBT) attempts over a period of time. The period of time may be dynamically determined (e.g., a sliding window)); NACK rate (e.g., the WTRU may maintain a measurement of the number or percentage of NACKs over a period of time. The period of time may be dynamically determined (e.g., a sliding window)); path loss; whether the path is line-of-sight or non-line-of-sight; throughput; BLER; and / or latency.

[0135] With respect to comparison of execution to conventional functions, for example, the WTRU may compare the performance of the AIML model on a function to the expected performance using a baseline (e.g., non-AIML) method to perform the function. The WTRU may determine an error event rate based on the use of the AIML model. An error event may be determined when the difference between the output of the AIML model and the baseline method is greater than or less than a threshold. If the error event rate is greater than or less than the threshold, the WTRU may determine the suitability of the AIML model. If the difference between the output of the AIML model and the baseline model is greater than or less than a threshold, the WTRU may determine the suitability of the AIML model.

[0136] In one example, the WTRU may determine the suitability of the AIML model based on whether the WTRU is part of a group with which the AIML model is associated. For example, the AIML model may be associated with a group of the WTRU, and whether the WTRU is part of the group may enable the WTRU to determine whether the AIML model is suitable.

[0137] With respect to hysteresis, for example, the WTRU may determine whether an AIML model is suitable according to whether the WTRU has recently determined that the AIML model is not suitable. For example, if the WTRU determines that the AIML model is not suitable, it may not reuse or retest the model for suitability within a certain time period (e.g., fixed, predetermined, variable). This may ensure that the WTRU does not repeatedly ping-pong between models.

[0138] When the WTRU determines that the model is not suitable, it may send an indication to the gNB or another WTRU. When the WTRU determines that the model is not suitable, the WTRU may request a new model, an update to the model, and / or resources to retrain the model or train a new model.

[0139] Certain embodiments may include a trigger for verifying model suitability. For example, before using an AIML model, the WTRU may determine whether the model is suitable, where suitability may be as described herein. The WTRU may receive a command from a gNB or another WTRU to verify whether the AIML model is suitable for at least one WTRU function. When the WTRU receives at least one new AIML model, it may determine to test the AIML model for suitability.

[0140] In another embodiment, the WTRU may be triggered to check or recheck the suitability of the AIML model according to at least one of the following: time period (for example, the WTRU may be configured with periodic moments to check the suitability of the AIML model. In another example, a semi-persistent moment may be used to trigger the WTRU to check the suitability of the AIML model); configuration, activation and / or deactivation of a cell; changes in channel conditions (for example, where the channel conditions may include at least one of the following: Doppler, Doppler spread, delay spread, line of sight (LOS) to non-line of sight (NLOS), NLOS to LOS, path loss, coherence time, coherence bandwidth, channel type); changes in L1 or L3 measurements (for example, if RSRP, RSRQ, SINR, RSSI, CO, RI, CQI, PMI, LI at least one change is more than a threshold, the WTRU can be triggered to check the suitability of the AIML model); when the set of best sub-bands changes; change of radio resource control (RRC) state (idle, connected, inactive); discontinuous reception (DRX) configuration or change of DRX configuration; RRC configuration (reconfiguration); PHY (e.g., DCI) or MAC layer (e.g., MACCE) indication; change of BWP (e.g., if the WTRU changes the BWP due to timer expiration, the WTRU can check the suitability of the AIML model); change of beam or beam pair (e.g., when the set of best beams changes, the WTRU can check the suitability of the AIML model); detection of beam failure; change of transmission mode; RLM / RLF (radio link failure); change of position (e.g., translation or orientation).For example, if the location changes by more than a threshold, the WTRU may be triggered to check the AIML model suitability); a change in traffic type (for example, if the priority of the traffic changes, the WTRU may be triggered to check the AIML model suitability); a change in buffer status (for example, if the buffer status is above or below a threshold, the WTRU may be triggered to check the AIML model suitability); when triggered to transmit a scheduling request (SR) or an uplink reference signal (UL RS) (e.g., sounding reference signal (SRS)) or configuration grant (CG) transmission; when the difference between the performance of the AIML model and the performance of the baseline method is greater than or less than a threshold; the difference between the historical value and the ML model output becomes greater than or less than a threshold; when the WTRU determines that the model needs to be retrained or improved; HARQ-ACK (hybrid automatic repeat request) results or block error rate (BLER) (e.g., when the NACK rate exceeds a threshold or when the BLER is less than or greater than a threshold, the WTRU can be triggered to verify the suitability of the AIML model); traffic performance (e.g., when at least one of throughput, reliability, and latency is greater than or less than a threshold, the WTRU can be triggered to verify the suitability of the AIML model); reception of a new or updated AIML model; reception of a sidelink (SL) broadcast or DL ​​broadcast of a new or updated model; AIML fault detection (e.g., when a fault occurs in the AIML model, the WTRU can determine the event and count the event. The fault can be determined in a manner similar to the triggers discussed in this document (e.g., based on comparison with a baseline model). If the failure count exceeds a configurable value, the WTRU may declare an AIML failure detection or may be triggered to verify the AIML model suitability. When the failure timer expires, the failure count may be reset. When a failure event is determined, the failure timer may be restarted. In another embodiment, the WTRU may start a timer when N (e.g., N consecutive) failure events are determined (where N may be configurable). If the WTRU does not determine M success events and the timer is running, the WTRU may declare an AIML failure detection or the WTRU may be triggered to verify the AIML model suitability); when the WTRU is configured with or receives model retraining resources (e.g., the WTRU may be configured with periodic bursts of model retraining resources. Before using the resources to retrain the AIML model, the WTRU may verify the suitability of the model. If the model is deemed suitable or inappropriate, the WTRU may (e.g., may only) retrain the model); when the WTRU changes the WTRU group (e.g., the WTRU may be assigned to or determine a WTRU group. Such a group may share models.When the WTRU changes groups, the WTRU may be triggered to verify the suitability of the AIML model); when there is a change in the source of the AIML model (for example, the AIML model may be trained by a first node (WTRU or gNB) and may be updated by a second node (WTRU or gNB). When the training or retraining node associated with the model changes, the WTRU may be triggered to verify the suitability of the AIML model); and / or when training a new AIML model is completed (for example, when training of a first AIML model or a second AIML model is completed, the WTRU may verify the suitability of the first AIML model).

[0141] The triggers, their parameters and / or thresholds for checking the suitability of the AIML model may depend on whether the WTRU has trained and shared the model or whether the model is trained at another node (WTRU or gNB) and shared with the WTRU. For example, the WTRU may be configured with a first set of triggers or thresholds associated with a model trained and shared by the WTRU and a second set of triggers and thresholds associated with a model trained elsewhere and shared with the WTRU. In another embodiment, each model may be configured with a set of triggers or thresholds. In yet another embodiment, the set of triggers or thresholds may depend on the functionality for which AIML can be used.

[0142] The triggers discussed above may be reused as triggers for the WTRU to request a new model, updates to the model, and / or resources to retrain the model or train a new model.

[0143] Certain embodiments may provide triggers for training and / or retraining. The WTRU may perform channel measurements, such as channel coherence time, channel coherence bandwidth, SNR, Doppler spread, etc. Changes in the measured channel conditions may trigger the WTRU to assess the performance of the ML model.

[0144] In an exemplary scenario, if the WTRU measures a change in the channel coherence time, it may send an indication to the gNB reporting the change. The WTRU may be configured to report the channel coherence time periodically and / or when prompted by the gNB (e.g., via DCI) and / or when the channel coherence time exceeds a corresponding preconfigured threshold. Any change or changes beyond a preconfigured threshold in the channel coherence time may cause the WTRU to trigger training / retraining of the ML model.

[0145] A decrease in the channel coherence time may indicate a change in the channel from a slow fading to a fast fading channel. Thus, the WTRU may determine to retrain the model after a decrease in the channel coherence time is greater than a threshold, which may be configured by the WTRU or the network. The updated training frequency may apply within a predetermined time window or indefinitely until another event is triggered, for example, until the WTRU detects / measures an increase in the channel coherence time.

[0146] In another exemplary scenario, a small value of the coherence time (i.e., below a preconfigured threshold set by the WTRU or the gNB) may indicate a fast fading channel, thereby implicitly indicating to the WTRU that additional metric (e.g., SNR) measurements may be required. The WTRU may report the additional measurements to the gNB independently or by including them as part of the CSI feedback report (e.g., CQI, SNR, etc.).

[0147] The ACK / NACK statistics measured by the WTRU may indicate the performance of the ML-based CHEST or CSI derivation model. For example, if the WTRU sends several consecutive NACKs to the gNB, the gNB may send a request to the WTRU to re-evaluate the performance of the CSIML model. The number of consecutive NACKs that will trigger the training / retraining of the ML model may be configured by the gNB. The gNB may send a request for training / retraining of the ML model at the WTRU. In one example, the WTRU may measure and track the ACK / NACK statistics within a time window. If the number / percentage of NACK responses recorded within the window exceeds a preconfigured threshold, the WTRU may re-evaluate the performance of the ML model, for example, by calculation of NMSE or cosine similarity.

[0148] Whenever the WTRU completes training of the CSIML model, it may start a counter / timer. The expiration of the counter / timer may trigger the WTRU to retrain the model. The length of the time set by the timer may be measured / recorded in any of the following units: time slot, symbol duration, SFN, and seconds / milliseconds. The counter may be measured in number of symbols. The length of the timer / counter may be preconfigured by the WTRU and indicated to the gNB, or vice versa. The gNB may send a message to the WTRU requesting a change in the length of the counter / timer. In an exemplary scenario, the gNB may register poor uplink channel conditions from the CSI report from the WTRU. The gNB may send a request to reduce the length of the timer / counter to the WTRU to trigger training / retraining of the ML model.

[0149] In case the calculation of the error exceeds a preconfigured threshold as described below in Section 4.7, the WTRU may trigger retraining of the ML model. For example, if NMSE > threshold T1 and / or if cosine similarity < threshold T2, the WTRU may trigger training / retraining of the ML model. The network may also have thresholds corresponding to performance metrics of the ML-capable WTRU. In an example, if the WTRU reports the calculated NMSE and / or cosine similarity to the gNB and the error performance metric is below the corresponding threshold at the gNB, the gNB may send an indication to the WTRU to trigger training / retraining of the CSIML model.

[0150] In one example, the WTRU may be configured to report the channel coherence time to the gNB periodically or when prompted by the gNB via an indication sent to the WTRU (e.g., in a DCI). There may also be a semi-periodic configuration whereby the WTRU reports the channel coherence time to the gNB at a periodicity set by the gNB and when prompted by the gNB and / or when the WTRU measures a large change in the channel coherence time. In one example, there may be a configuration of a channel coherence time threshold at the WTRU. Exceeding the channel coherence time threshold may trigger the WTRU to report the coherence time to the gNB and / or train / retrain the ML model at the WTRU. Similarly, thresholds for other channel measurement results may also be configured. In one example, the WTRU may trigger training / retraining of the channel estimation model if the SNR measured by the WTRU is below a corresponding preconfigured threshold and / or the BLER is above a corresponding preconfigured threshold.

[0151] In an example, the WTRU may receive an explicit request for training from the network. With knowledge of the state of the ML models of other ML-capable WTRUs in the vicinity, the network may determine that a particular WTRU may need to improve / retrain its ML model before sending it in the uplink. An exemplary scenario may be when the WTRU is the only WTRU with an ML model that can be trained in a strict time window with minimal RS overhead compared to the ML models of (one or more) neighboring WTRUs that may require more CSI-RS to train and / or may take longer to train.

[0152] In an example, the WTRU may receive a request for training / retraining directly from a neighboring WTRU via a sidechain interface. The WTRU may have received an indication that it has been selected by the network as a basis for transfer learning, which may have been accompanied by the WTRU ID(s) of the neighboring WTRU(s) that are likely to request model migration. The WTRU may receive a request for model migration, which may be preceded by a request for training / improvement of an ML model.

[0153] The WTRU may use the legacy channel estimation (CHEST) or CSI reporting framework as a reference for evaluating the output of the ML model and / or calibrating / recalibrating the neural network. The WTRU may calculate the difference / discrepancy / error between the output of the CSI estimation model and the result of the legacy CHEST or CSI reporting framework. The difference / discrepancy / error may be calculated by: (i) NMSE and / or (ii) cosine similarity.

[0154] The normalized mean square error (NMSE) may be used as a performance measure of the ML model, whereby the accuracy of the ML model may be inversely proportional to the NMSE value calculated at the WTRU. The WTRU may quantify the normalized MSE (NMSE) as shown in the following equation: Where H: CSI channel matrix from traditional channel estimation; the output of the ML-enabled decoder; and E: Expectation (statistical mean).

[0155] The cosine similarity measures the similarity between the reference channel matrix and the output of the ML decoder. The WTRU may calculate the cosine similarity p as shown in the following equation: in the reconstructed channel vector at the nth subcarrier at the output of the ML decoder; and N c : The number of subcarriers (or frequency domain samples of the channel matrix).

[0156] NMSE or cosine similarity is used to quantify the reconstruction performance. The quantized result of the difference / discrepancy / error that may be calculated by the WTRU is evaluated against a preconfigured threshold. In an exemplary scenario, if the NMSE calculated by the WTRU < threshold T1, the WTRU may report to the gNB that the performance of the ML channel estimator is sufficient and the WTRU may not trigger a remeasurement / recalculation of the NMSE, for example within a certain time period.

[0157] Similarly, if the cosine similarity p calculated by the WTRU in an example is above a preconfigured threshold, the WTRU may report to the gNB that the performance of the CSI model estimator / predictor / derivative is good or valid or suitable, and the WTRU may not trigger a recalculation of p for a certain subcarrier within a certain time period. Conversely, if the cosine similarity p calculated by the WTRU is below a certain threshold, the WTRU may report the value of the cosine similarity to the gNB, and the gNB may send a request for retraining of the model (or the WTRU may trigger a remeasurement of the cosine similarity). The above-mentioned thresholds may be preconfigured by the WTRU and indicated to / approved by the gNB. Alternatively, the thresholds may be configured by the gNB and shared with the WTRU during initial configuration (e.g., during RRC).

[0158] The WTRU may perform additional channel measurements, such as channel coherence time, channel coherence bandwidth, SNR, Doppler spread, etc. A change in the measured channel conditions may trigger a change in the thresholds. In an example, if the WTRU measures a decrease in the channel coherence time, it may report the change to the gNB. The gNB may trigger a change in the preconfigured threshold(s) to accommodate dynamic changes in channel conditions.

[0159] The WTRU may be configured with multiple thresholds (e.g., T1, T2, T3, ..., TN) by the gNB for measurements of one or more performance metrics. For example, the gNB may configure one or more thresholds that, when exceeded, may trigger the WTRU to compute the NMSE between the legacy channel estimate and the output of the ML decoder. Each threshold may be associated with a specific parameter, and the WTRU may decide which threshold to use depending on its measurements of the parameter. In one example, one threshold (e.g., T1) may correspond to a certain SNR range, such that if the SNR is outside of that range, the WTRU may have to use a different threshold (e.g., T2) corresponding to the new measured SNR. An error / difference / difference (e.g., NMSE or cosine similarity) exceeding a final threshold TN may trigger the WTRU to retrain the ML model.

[0160] The WTRU may be configured with a first set of reference signals (e.g., CSI-RS) on which to perform channel estimation and calculate CSI estimates. The configuration of the first set of reference signals for calculating CSI estimates may be high density and short periodicity, or it may be the same configuration for a WTRU without ML capabilities. After calculation of the error (e.g., NMSE or cosine similarity), the WTRU may request a change in the periodicity and / or density of the configuration of the reference signals, possibly due to the value of the error. In one example, a large error may trigger the anchor WTRU to train / retrain its model. This may be the case in particular if the anchor WTRU has knowledge that none of the trained ML models available at the network at that given time match its requirements (e.g., based on data distribution statistics). In another example, a large error calculated by a member WTRU may trigger the member WTRU to request model migration in the downlink.

[0161] The result of the determination of the CSI estimation error may be training / retraining of the AIML model and / or redetermination of the model suitability based on any of the parameters discussed above and / or a request for model parameter migration from the gNB.

[0162] Certain embodiments may provide a process for model upload (e.g., a model in the UL). For example, a ML-capable WTRU may be configured with a first set of ML models for channel estimation / prediction / CSI compression. The (one or more) ML models may already be implemented / loaded in the WTRU. Alternatively, the ML models in the first set of models may be downloaded from the gNB, for example after the WTRU reports the WTRU capability information to the gNB. The ML model may have an associated unique identifier (model ID), a model profile (e.g., the model profile may describe configuration information, number of layers), model parameters (including input and output sizes), and data distribution statistics.

[0163] In certain embodiments, the WTRU may report assistance information and / or capabilities of a first set of ML models. For example, the WTRU reports to the gNB the capabilities of the ML models it is configured with (e.g., in the first set of models); the WTRU may also report assistance information related to the configured first set of ML models. For example, the WTRU may report assistance information to enable the gNB to determine an anchor WTRU for model migration and / or update its second set of models.

[0164] The auxiliary information for the configured ML models in the first set of models may include one or more of the following: model type (e.g., RNN, DNN, CNN, etc.), model ID, model profile, model parameters including model size, data distribution statistics (e.g., of the data on which the model was trained), WTRU antenna configuration, WTRU positioning / location information, and / or metrics for model performance (e.g., NMSE).

[0165] The WTRU may report assistance information to the gNB when it detects a change in operating conditions, for example: when the WTRU detects a change in channel statistics relative to the statistics of the model training data set (e.g., this may include changes in Doppler spread, delay spread, angular spread, SNR, etc.), when the WTRU detects a significant change in its position and / or orientation, and / or when the BWP changes.

[0166] In accordance with some embodiments, the WTRU may receive information related to a second set of ML models available at the gNB. For example, the WTRU receives an indication of an ML model in the second set of models available at the gNB. The WTRU may receive the indication, for example, after it reports auxiliary information and / or capabilities of the first set of ML models. In another example, the indication may be broadcast in a SIB.

[0167] The indication on the second set of ML models available at the gNB may include one or more of: model type (e.g., RNN, DNN, CNN), model ID, model profile, model parameters including model size, data distribution statistics (e.g., of the data on which the model was trained) (which may include Doppler spread, delay spread, SNR, channel coherence time, etc.), number of RX antennas and / or a metric for model performance (e.g., NMSE), and a threshold for model convergence.

[0168] In some embodiments, the WTRU may use the configured CSI-RS transmissions to measure channel statistics (e.g., to evaluate model suitability). For example, the WTRU may use the configured CSI-RS transmissions to perform traditional channel estimation and determine channel statistics such as Doppler spread, delay spread, SNR, channel coherence time, etc.

[0169] The WTRU may compare the measured channel conditions with data distribution statistics for the ML models in the second set of models received from the gNB, for example, to determine whether any of the ML models in the second set of models may be used for the current channel conditions.

[0170] The WTRU may determine that no ML model from the second set of models meets its requirements, for example when the measured channel statistics do not match any of the model profiles in the second set of models, or when parameters (e.g., the number of WTRU antennas) do not match.

[0171] When the WTRU determines that no ML model from the second set of models meets its requirements, the WTRU may send an indication to the gNB that no ML model meets. The WTRU may implicitly indicate to the gNB that it will train its ML model. In another example, the WTRU may explicitly signal to the gNB that it is entering a model training state.

[0172] The WTRU may report specific failure conditions to the gNB, for example, the current measured SNR is outside the range of all ML models in the second set.

[0173] When the WTRU enters the model training state, the WTRU updates the weights of the ML model, for example using CSI-RS transmissions for online training. The WTRU may calculate the error (e.g., NMSE or cosine similarity) between the ML-based CSI estimate and the traditional CSI estimate. When the error is greater than a configured threshold, the WTRU may continue online training (e.g., run additional iterations).

[0174] When the error becomes smaller than a configured threshold, the WTRU may indicate the completion of the ML model parameter update to the gNB. The WTRU may also report auxiliary information, such as channel statistics measured during model retraining.

[0175] When the WTRU determines an applicable ML model from the second set of models, the WTRU may indicate information related to the preferred model to the gNB. The indication may include one or more of: model ID, model type (e.g., RNN, DNN, CNN), model profile, model size, and / or data distribution statistics.

[0176] The WTRU may send a request to the gNB to download a preferred ML model from the second set.

[0177] Certain embodiments may include a WTRU trigger for migrating and / or uploading an ML model. For example, when the WTRU retrains its model and the error becomes less than a configured threshold, the WTRU may indicate the completion of the ML model parameter update to the gNB. The WTRU may also report auxiliary information, such as channel statistics measured during model retraining. The WTRU may request an UL grant to migrate its trained model to the gNB.

[0178] In one example, the WTRU may receive an ML model parameter request from the gNB, for example, after the retraining of the model reported by the WTRU is complete. Upon receiving the ML model parameter request from the gNB, the WTRU may migrate the model parameters to the gNB. The WTRU may also report auxiliary information for the trained model, such as channel conditions (Doppler, delay spread, angular spread, SNR, etc.).

[0179] The gNB may select the WTRU as an anchor for transfer learning, for example, when it determines that the WTRU has a trained model (e.g., the best trained model in a cluster of neighboring WTRUs sharing similar channel conditions). When selected as an anchor WTRU for transfer learning, the WTRU may receive a configuration indication from the gNB that it is selected as the basis for transfer learning (i.e., it is designated as the anchor WTRU for the group of WTRUs). The WTRU may freeze updates to the first few layers of the model. The WTRU may also expect to receive a model migration request directly from another WTRU, for example, in the UL on Uu or via a sidelink.

[0180] The following is an example embodiment of a process for training and sharing an ML model according to the principles discussed herein.

[0181] Figure 4 is a signal flow diagram illustrating an example process for migrating a model from a model trainer or anchor WTRU to a user WTRU (eg, model migration in the UL) according to an embodiment.Initially, an ML-capable WTRU is configured with a first set of ML models for channel estimation.

[0182] The model may have been implemented by the WTRU vendor, pre-downloaded from the network (possibly from a different gNB than the one the WTRU is now associated with), or pre-defined in the standard.

[0183] At 411, the WTRU sends model assistance information to the gNB. The model assistance information may include WTRU capability information, and may include, for example, any of: the model type(s) with which the WTRU is configured, the WTRU antenna configuration, the WTRU positioning / location information, and / or the bandwidth portion.

[0184] Next, at 413, the WTRU receives an indication of the ML models (e.g., model ID) available at the gNB and the corresponding profile associated with each channel model as a response to the WTRU assistance indication 411 or broadcast in the SIB. The indication of each ML model may include any of the following: performance metrics, threshold T; data distribution statistics (e.g., Doppler, SINR); and model parameters (e.g., size, delay, RS overhead).

[0185] At 415, the WTRU receives CSI-RS from the gNB that is required to compute a channel estimate. Then, at 416, the WTRU uses the CSI-RS to compute a channel estimate using a conventional channel estimation process. The WTRU may also measure other channel conditions (e.g., Doppler, SINR).

[0186] If, based on the capabilities or radio conditions in the model-based profile, e.g., the WTRU determines that no available trained model parameters match its requirements (e.g., the profile of the model at the gNB does not match the channel conditions just measured), then the WTRU may send an indication 417 to the gNB that no current ML model meets its requirements, thereby implicitly indicating to the gNB that it will train its ML model. In one embodiment, the WTRU may include a failing condition (e.g., the SINR measured by the WTRU is not within the range of SINRs of any of the models available at the gNB). Alternatively (not shown), the indication to enter the training phase may be explicit.

[0187] Next, at 418, the WTRU computes the weights of the ML model and updates the model accordingly. The computation of the weights may be based on historical data (if available) and may be periodic at a period set by the gNB. Alternatively, the computation of the weights may be event-triggered. The WTRU may update the weights based on CSI-RS transmissions for online training.

[0188] At 418, the WTRU then uses the updated ML model to obtain an ML-based CSI estimate. Additionally, it computes an error e (e.g., NMSE) based on the difference between the CSI estimate output by the ML model and the CSI estimate computed using the conventional method from 416. The error may be computed periodically, semi-periodically, or triggered by the gNB.

[0189] If e > T, then the WTRU runs additional iterations to achieve convergence.

[0190] If e < T, then the WTRU reports, at 419, the completion of the ML model parameter computation and support information to the gNB, the support information including data (statistics) on the channel conditions on which the model was trained.

[0191] Next, the WTRU may receive an ML model parameter transfer request 421 from the gNB. In response, at 423, the WTRU may transfer the ML model parameters to the gNB.

[0192] Finally, the WTRU may receive, at 425, an indication from the gNB that it has been selected as the basis for transfer learning (the designated anchor WTRU), such that the WTRU may expect a model transfer request directly from another WTRU via SL.

[0193] Figure 5A is a signal flow diagram illustrating an example process for migrating a model from a model user or member WTRU to a network node or anchor WTRU (e.g., model migration in DL). Initially, in this example, the ML-capable WTRU is configured with one or more ML models to perform channel estimation.

[0194] At 511, the WTRU sends auxiliary information to the gNB, which may include any one or more of the following: a list of the (one or more) models (i.e., model IDs) that the WTRU is configured with; antenna configuration; WTRU positioning / location information; and BWP.

[0195] Next, at 513, in response to the WTRU auxiliary indication 511 or as a broadcast in the SIB, the WTRU receives an indication of the ML models (e.g., model IDs) available at the gNB and the corresponding profiles associated with each CHEST model. The indication of each ML model may include any one of the following: performance metrics, a threshold T for each ML model; data distribution statistics associated with each model (e.g., Doppler range, SINR); and model parameters (e.g., size, latency, RS overhead).

[0196] At 515, the WTRU receives the CSI-RS required to compute the channel estimate from the gNB. Then at 516, the WTRU uses the current ML model to obtain an ML-based CSI estimate and calculates an error e (e.g., NMSE) based on the difference between the CSI estimate using the ML model and the CSI estimate using a traditional method. If e < T, then the WTRU determines that it does not require an ML model update and no action is required. If on the other hand e > T, then the WTRU determines that it requires an ML model update, the WTRU selects the model whose data distribution most closely matches its environmental parameters (e.g., SINR, Doppler), and at 517, the WTRU sends an ML model update request to the gNB (with the model ID).

[0197] At 519, the WTRU receives the ML model update from the gNB. At 520, the WTRU may use its local data (e.g., CSI parameters based on CSI-RS calculated by the WTRU periodically / semi-periodically) to fine-tune the weights of the ML model.

[0198] Figure 5B is a signal flow diagram depicting a method and apparatus for UL and / or DL model migration to / from one or more UEs according to an example embodiment. As Figure 5BAs illustrated in the example of , the method may involve UL model migration between a UE (UE A) and a network node (eg, gNB). In addition, Figure 5B An example may involve DL model migration between a network node (e.g., gNB) and UE B. Figure 5B As shown in the example of , UE A may receive information indicating one or more model profiles and / or data distribution statistics of available models (e.g., data distribution statistics associated with each of the available models) from a network node (e.g., a gNB) at 530. In this example, UE A may determine that no available model matches the requirements of UE A, for example based on the data distribution statistics and / or model profiles, and as discussed elsewhere herein. At 532, UE A may send an indication to the network node (e.g., a gNB) indicating that no currently available model meets the requirements of UE A. At 534, UE A may receive configuration information indicating information for training a local AI / ML model. For example, in addition to other information or parameters, the configuration information may include a convergence threshold T that may be used by UE A to determine when the local AI / ML model achieves the performance requirement. In this example, UE A may then train the local AI / ML model, for example until the error associated with the trained local AI / ML model converges to less than the convergence threshold T. At 536, UE A may send an indication to the network node (e.g., a gNB) confirming that convergence of the local AI / ML model has been achieved. At 538, UE A may receive a request to migrate ML model parameters, e.g., in a DCI. At 540, UE A may send information indicating ML model (e.g., Model A) parameters and supporting information, e.g., via PUCCH / PUSCH. The network node (e.g., gNB) may then add the AI / ML model information (e.g., Model A) received from UE A to a list of AI / ML models at the network (e.g., at the gNB).

[0199] like Figure 5BAs further illustrated in the example of , certain embodiments may include DL model migration between a network node (e.g., a gNB) and a UE (UEB). For example, as shown at 542, a network node (e.g., a gNB) may send information indicating one or more model profiles and / or data distribution statistics of available models (e.g., data distribution statistics associated with each of the available models) to UE B. In this example, UE B may determine a model (e.g., Model A) that matches the requirements of UE B based on the received information. Model A may be a trained version received from UE A at a network node (e.g., a gNB), or a modified and / or fine-tuned and / or trained and / or retrained and / or processed and / or pre-processed version of Model A received from UE A. At 544, UE B may send a request to the network node for AI / ML model parameters associated with a model (e.g., Model A) that matches the requirements of UE B. At 546, the network node may migrate the requested ML model parameters to UE B. Then, in this example, UE B may fine-tune the model weights (eg, weights received as part of the model parameters) based on local data (eg, CSI parameters calculated from the CSI-RS).

[0200] Figure 6 is an example flow chart illustrating an example method for migration, assessment, and / or training of AIML model(s) according to some embodiments. Figure 6 The example methods and accompanying disclosures herein may be viewed as a summary or synthesis of the various disclosures discussed above. For ease and simplicity of description, the architecture of the communication system 100 (FIG. 1) may be referred to to describe Figure 6 However, different architectures can also be used to implement Figure 6 According to some embodiments, Figure 6 The method may be implemented by a WTRU (such as WTRU 102). For example, executing Figure 6 The WTRU of the example method may be, for example, an anchor WTRU, a master WTRU, or a model trainer WTRU.

[0201] like Figure 6As illustrated in the example of , the method may include: at 605, receiving AI / ML model configuration information from a network node (e.g., a base station or gNB). For example, the received model configuration information may indicate any of the following: one or more AI / ML models available from the network node; a profile associated with each corresponding AI / ML model of the one or more AI / ML models (e.g., each of the AI / ML models may have a corresponding profile associated with it), and / or an AI / ML model training convergence threshold. For example, the AI / ML model profile (e.g., each of the profiles) may include any of the following: data distribution statistics and / or model parameters associated with the AI / ML model. In addition, the AI / ML model profile may include additional information as discussed elsewhere herein. According to some embodiments, the configuration information may optionally include a trigger or command for determining whether the one or more AI / ML models are suitable for use in at least one function at the WTRU.

[0202] In some examples (not shown), the method may include: the WTRU transmitting assistance information to the network node. For example, the assistance information may indicate any one or more of the following: capability information including the model type with which the WTRU is configured, antenna configuration information for the WTRU, and / or location information for the WTRU.

[0203] exist Figure 6 In an example, the method may include: at 610, determining that the one or more AI / ML models are not suitable for use by the WTRU. For example, the determination 610 may be based at least on the (one or more) profiles associated with the corresponding AI / ML models. Additionally or alternatively, in some embodiments, determining 610 that the one or more AI / ML models are not suitable may be based on, but not limited to, the measured radio conditions and any one or more of the following: the AI / ML model profile, the configured performance threshold, and / or the capabilities of the WTRU. It should be noted that the determination 610 may be based on further parameters as discussed elsewhere herein. In some examples, the determination 610 may include: comparing at least one measurement result performed by the WTRU with the configured performance threshold; and based on the comparison, determining that the one or more AI / ML models are not suitable.

[0204] like Figure 6As shown in the example of , the method may include: at 615, sending first information to the network node. The first information may indicate any of the following: the one or more AI / ML models are not suitable for the WTRU and / or the WTRU will train a local AI / ML model. In some embodiments, the first information may include an indication of a condition associated with the AI / ML model profile that is determined by the WTRU to be failed. For example, the failure of the condition may cause the WTRU to determine that the associated AI / ML model is not suitable for use by the WTRU. As an example, the failed condition may include, but is not limited to: the signal to interference plus noise ratio (SINR) measured by the WTRU is not within the range of SINRs of any of the models available from the network node. Other examples of conditions are discussed elsewhere herein. In some examples, the indication of the condition may be a reason code for indicating that the AI / ML model is not suitable for use by the WTRU. In various embodiments, the local AI / ML model may be a model that is stored and / or located at the WTRU and can be used for lifecycle management stages (such as training, retraining, fine-tuning, inference, etc.).

[0205] refer to Figure 6 In an example, the method may include: at 620, training the local AI / ML model according to a convergence threshold. According to some embodiments, training 620 the local AI / ML model according to the convergence threshold may include: determining an error based on an output of the local AI / ML model and a measured channel condition. Under the condition that the error is greater than the convergence threshold, training 620 may include: performing additional iterations of training to achieve convergence of the local AI / ML model. When the error is less than the convergence threshold, the method may include: reporting completion of the training of the local AI / ML model to the network node.

[0206] exist Figure 6 In an example of , the method may include: at 625, receiving second information from the network node indicating a request to migrate AI / ML model parameters. Figure 6 As shown in the example of , the method may include: at 630, sending third information indicating AI / ML model parameters associated with the trained local AI / ML model to the network node. As an example, the model parameters may include any one or more of the following: channel measurement results associated with the training AI / ML model, static information associated with the AI / ML model, performance information associated with the AI / ML model; and / or training frequency associated with the AI / ML model. According to some embodiments, the sending 630 of the third information may further include: sending channel data distribution statistics associated with the training AI / ML model parameters.

[0207] According to certain example embodiments, any of the one or more AI / ML models and / or local AI / ML models are configured to perform CSI estimation. However, in various embodiments, the (one or more) AI / ML models may be configured to perform other functions associated with the WTRU, as discussed elsewhere herein.

[0208] The system and method for processing data according to a representative embodiment can be executed by one or more processors that execute a sequence of instructions contained in a memory device. Such instructions can be read into the memory device from other computer-readable media (such as, (one or more) auxiliary data storage devices). The execution of the sequence of instructions contained in the memory device causes the processor to operate, for example, as described above. In an alternative embodiment, hard-wired circuits can be used instead of software instructions or in combination with software instructions to implement the present invention. Such software can be run on a processor contained in a robot-assisted / device (RAA) and / or remotely in another mobile device. In the latter case, data can be transmitted between the RAA or other mobile devices containing sensors and a remote device containing a processor via wires or wirelessly, and the processor runs software that performs scale estimation and compensation as described above. According to other representative embodiments, some of the processing described above with respect to localization can be performed in a device containing a sensor / camera, and the remainder of the processing can be performed in a second device after receiving partially processed data from a device containing a sensor / camera.

[0209] Although features and elements are provided in specific combinations above, it will be appreciated by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in the present application, which are intended to be illustrations of various aspects. Without departing from its spirit and scope, many modifications and variations can be made, which will be obvious to those skilled in the art. The elements, actions or instructions used in the specification of the present application should not be understood as being essential or indispensable to the present invention unless so explicitly specified. In addition to those listed herein, from the above description, the functionally equivalent methods and devices within the scope of the present disclosure will be obvious to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the items of the appended claims and the full scope of the equivalents enjoyed by such claims. It should be understood that the present disclosure is not limited to a particular method or system.

[0210] For simplicity, the above embodiments are discussed with respect to the terminology and structure of infrared-enabled devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0211] It should also be understood that the terms used herein are used only to describe specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "imagery" may mean any of a snapshot, a single image, and / or a plurality of images displayed on a time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a wirelessly-enabled and / or wiredly-enabled device (e.g., shareable via a mobile phone) configured with, among other things, some or all of the structure and functionality of a WTRU; (iii) a wirelessly-enabled and / or wiredly-enabled device configured with less than all of the structure and functionality of a WTRU; (iv) and the like. This document is about Figures 1A to 1D Details of an example WTRU are provided that may represent any WTRU described herein. As another example, various disclosed embodiments are described above and below herein as utilizing a head mounted display. Those skilled in the art will appreciate that devices other than a head mounted display may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to flow information to provide an adapted reality experience.

[0212] In addition, the method provided herein can be implemented in a computer program, software or firmware incorporated into a computer-readable medium for execution by a computer or processor. The example of a computer-readable medium includes an electronic signal (transmitted by a wired or wireless connection) and a computer-readable storage medium. The example of a computer-readable storage medium includes, but is not limited to, a read-only memory (ROM), a random access memory (RAM), a register, a cache memory, a semiconductor memory device, a magnetic medium (such as an internal hard disk and a removable disk), a magnetic-optical medium and an optical medium (such as a CD-ROM disk and a digital versatile disk (DVD)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, a UE, a terminal, a base station, a RNC, a MME, an EPC, an AMF or any host computer.

[0213] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered to limit the scope of the appended claims. For example, the embodiments provided herein include handheld devices that can include or be used with any suitable voltage source (such as, batteries, etc.) to provide any suitable voltage.

[0214] In addition, in the embodiments provided above, processing platforms, computing systems, controllers and other devices including processors are mentioned. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as "being executed", "being executed by a computer" or "being executed by a CPU".

[0215] Those of ordinary skill in the art will appreciate that actions and symbolically represented operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which can cause the resulting transformation or reduction of electrical signals, and maintain the data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU, as well as other processing of signals. The memory location where the data bits are maintained is a physical location with specific electrical, magnetic, optical or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs can support the provided methods.

[0216] The data bits may also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system that can be read by a CPU. The computer-readable medium may include cooperating or interconnected computer-readable media that reside exclusively on a processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the memories mentioned above, and other platforms and memories may support the provided methods.

[0217] In an illustrative embodiment, any operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0218] There is little distinction between hardware and software implementations of aspects of the system. The use of hardware or software is typically (but not always, as the choice between hardware and software may become important in certain contexts) a design choice that represents a cost versus efficiency tradeoff. There may be a variety of vehicles by which the processes and / or systems and / or other technologies (e.g., hardware, software, and / or firmware) described herein may be implemented, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, the implementer may select a vehicle that is primarily hardware and / or firmware. If flexibility is most important, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0219] The above detailed description has been described various embodiments of the device and / or process by using block diagrams, flow charts and / or examples. Since such block diagrams, flow charts and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a variety of hardware, software, firmware or almost any combination thereof. In one embodiment, several parts of the subject matter described herein can be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in whole or in part in an integrated circuit as one or more computer programs running on one or more computers (e.g., implemented as one or more programs running on one or more computer systems), implemented as one or more programs running on one or more processors (e.g., implemented as one or more programs running on one or more microprocessors), implemented as firmware or almost any combination thereof, and in view of the present disclosure, designing circuits and / or writing code for software and / or firmware will be well within the skills of those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a variety of forms of program products, and that the illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually implement the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.; and transmission-type media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0220] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and then use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into data processing systems via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can typically include one or more of the following: a system unit housing, a video display device, a memory (such as, volatile and non-volatile memory), a processor (such as, a microprocessor and a digital signal processor), a computing entity (such as, an operating system, a driver, a graphical user interface, and an application), one or more interactive devices (such as, a touchpad or screen) and / or a control system including a feedback loop and a control motor (e.g., a feedback for sensing position and / or speed, a control motor for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those components typically found in data computing / communication and / or network computing / communication systems.

[0221] The subject matter described herein sometimes illustrates different components that are included in or connected to different other components.It should be understood that this depicted architecture is only an example, and in fact, many other architectures that realize the same function can be realized.In the sense of concept, any arrangement of components that realize the same function is effectively "associated" so that the desired function can be realized.Therefore, any two components that are combined to realize a specific function herein can be regarded as "associated" with each other so that the desired function is realized, regardless of the architecture or intermediate components.Similarly, any two components so associated can also be regarded as "operably connected" or "operably coupled" to each other to realize the desired function, and any two components that can be so associated can also be regarded as "operably coupled" to each other to realize the desired function.Specific examples of operably coupling include but are not limited to components that can be physically paired and / or physically interacted and / or components that can be wirelessly interacted and / or wirelessly interacted and / or components that can interact logically and / or components that can interact logically.

[0222] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. For purposes of clarity, various singular / plural permutations may be expressly set forth herein.

[0223] Those skilled in the art will understand that, in general, the terms used herein and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "comprising" should be interpreted as "including but not limited to", etc.). Those skilled in the art will further understand that if a specific number of an introduced claim recitation is intended, such intent will be expressly recorded in the claim, and if no such recording is made, such intent does not exist. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be understood to imply that the introduction of a claim recitation by the indefinite article "a" or "an" will include any particular claim of such introduced claim recitation limited to embodiments including only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. In addition, even if specific numbers of introduced claim recitations are explicitly recited, those skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited numbers (e.g., the unmodified recitation of "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, generally speaking, such construction is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.). In those instances where a convention similar to “at least one of A, B, or C, etc.” is used, generally speaking, such construction is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.).Those skilled in the art will further understand that, whether in the specification, claims or drawings, almost any alternative words and / or phrases presenting two or more replaceable terms should be understood to consider the possibility of including one of the terms, any one of the two terms or all of the two terms. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B". Further, as used herein, the term "any of..." followed by a list of multiple items and / or multiple categories of items is intended to include "any one", "any combination", "any multiple" and / or "any combination of multiple" in the items and / or categories, either alone or in combination with other items and / or other categories of items. In addition, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. Moreover, as used herein, the term "multiple" is intended to be synonymous with "plurality".

[0224] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0225] As will be understood by those skilled in the art, for any and all purposes, such as, in providing a written description, all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily identified as fully describing the same range and enabling the same range to be decomposed into at least equal half, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range discussed herein can be easily decomposed into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "up to", "at least", "greater than", "less than", etc. include the recorded numbers, and refer to the ranges that can be subsequently decomposed into sub-ranges as discussed above. Finally, as will be understood by those skilled in the art, the range includes each individual member. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2 or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4 or 5 units, and the like.

[0226] Furthermore, the claims should not be read as limited to the order or elements provided unless so stated. In addition, the use of the term "means for..." in any claim is intended to invoke or “means-plus-function” claim format, and any claim without the term “means for…” is not intended to be so.

[0227] By way of example, suitable processors include 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, an application specific integrated circuit (ASIC), an application specific standard product (ASSP); a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine.

[0228] The WTRU may be used in conjunction with modules implemented in hardware and / or software including software defined radio (SDR) and other components such as a camera, a video camera module, a video phone, a speaker phone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, a Bluetooth module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0229] Although various embodiments have been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0230] Furthermore, although the invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

[0231] References The following references may have been mentioned above and are incorporated herein by reference in their entirety.

[0232] [1]3GPP TS 38.214, "Physical layer procedures for data", v16.0.0 [2]3GPP TS 38.213, "Physical layer procedures for control", v16.0.0 [3]3GPP TS 38.212, "Multiplexing and channel coding", v16.0.0 [4]3GPP TS 38.211,“Physical Channels and Modulation”,v16.0.0 [5]3GPP TS 38.331,“Radio Resource Control(RRC)protocolspecification”,v16.0.0 [6]3GPP TS 38.321,“MediumAccess Control(MAC)protocol specification”,v16.0.0 [7]3GPP TR 22.874,“Study on traffic characteristics and performancerequirements for AI / ML model transfer in 5GS”,Rel-18,v18.2.0。

Claims

1. A wireless transmit / receive unit (WTRU), comprising: A circuit, including any one of a processor, a memory, a transmitter and a receiver, configured to: receiving, from a network node, artificial intelligence / machine learning (AI / ML) model configuration information indicating: one or more AI / ML models available from the network node, a profile associated with each respective AI / ML model of the one or more AI / ML models, and an AI / ML model training convergence threshold; determining, based at least on the one or more profiles, that the one or more AI / ML models are not suitable for use by the WTRU; sending first information to the network node indicating any of: the one or more AI / ML models are not suitable for the WTRU; and the WTRU is to train a local AI / ML model; training the local AI / ML model according to the convergence threshold; receiving second information from the network node indicating a request to migrate AI / ML model parameters; as well as Third information indicative of AI / ML model parameters associated with the trained local AI / ML model is sent to the network node.

2. The WTRU of claim 1, wherein the profile comprises any of: data distribution statistics and model parameters associated with the AI / ML model.

3. The WTRU of claim 2, wherein the model parameters include any of: Channel measurements associated with the AI / ML model; Static information associated with the AI / ML model; performance information associated with the AI / ML model; and The training frequency associated with the AI / ML model.

4. The WTRU of at least one of claims 1 to 3, wherein the circuit is configured to determine that the one or more AI / ML models are not suitable based on measured radio conditions and any one of: the profile, the configured performance threshold, and the capabilities of the WTRU.

5. The WTRU of claim 4, wherein the circuit is configured to: comparing at least one measurement performed by the WTRU to a configured performance threshold; and Based on the comparison, it is further determined that the one or more AI / ML models are not suitable.

6. The WTRU of at least one of claims 1 to 5, wherein to train the local AI / ML model according to the convergence threshold, the circuit is configured to: determining an error based on an output of the local AI / ML model and a measured channel condition; Under the condition that the error is greater than the convergence threshold, performing additional iterations of the training to achieve convergence of the local AI / ML model; Under the condition that the error is less than the convergence threshold, the completion of the training of the local AI / ML model is reported to the network node.

7. The WTRU of at least one of claims 1 to 6, wherein the first information includes an indication of a condition associated with the profile that was determined by the WTRU to be failed.

8. The WTRU of claim 7, wherein the condition that is not met comprises: A signal to interference plus noise ratio (SINR) measured by the WTRU is not within a range of SINRs of any of the AI / ML models available from the network node.

9. The WTRU of at least one of claims 1 to 8, wherein the WTRU is configured to transmit assistance information to the network node.

10. The WTRU of claim 9, wherein the auxiliary information indicates any one of: capability information including the type of AI / ML model with which the WTRU is configured, antenna configuration information for the WTRU, and location information for the WTRU.

11. The WTRU of at least one of claims 1 to 10, wherein the configuration information comprises a trigger or command for determining whether the one or more AI / ML models are suitable for use in at least one function at the WTRU.

12. The WTRU of at least one of claims 1 to 11, wherein any one of the one or more AI / ML models and the local AI / ML model are configured to perform any one of channel state information (CSI) estimation or CSI prediction.

13. The WTRU of at least one of claims 1 to 12, wherein the local AI / ML model comprises a model for a lifecycle management phase stored at the WTRU.

14. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving, from a network node, AI / ML model configuration information indicating: one or more AI / ML models available from the network node, a profile associated with each respective AI / ML model of the one or more AI / ML models, and an AI / ML model training convergence threshold; determining, based at least on the one or more profiles, that the one or more AI / ML models are not suitable for use by the WTRU; sending first information to the network node indicating any of: the one or more AI / ML models are not suitable for the WTRU; and the WTRU is to train a local AI / ML model; training the local AI / ML model according to the convergence threshold; receiving second information from the network node indicating a request to migrate AI / ML model parameters; as well as Third information indicative of AI / ML model parameters associated with the trained local AI / ML model is sent to the network node.

15. The method of claim 14, wherein the profile comprises any of: data distribution statistics and model parameters associated with the AI / ML model.

16. The method of claim 15, wherein the model parameters include any one of the following: Channel measurements associated with the AI / ML model; Static information associated with the AI / ML model; performance information associated with the AI / ML model; and The training frequency associated with the AI / ML model.

17. The method of at least one of claims 14 to 16, wherein determining that the one or more AI / ML models are unsuitable is based on measured radio conditions and any one of: the profile, a configured performance threshold, and capabilities of the WTRU.

18. The method of claim 17, comprising: comparing at least one measurement performed by the WTRU to a configured performance threshold; as well as Based on the comparison, it is further determined that the one or more AI / ML models are not suitable.

19. The method of at least one of claims 14 to 18, wherein training the local AI / ML model according to the convergence threshold comprises: determining an error based on an output of the local AI / ML model and a measured channel condition; Under the condition that the error is greater than the convergence threshold, performing additional iterations of the training to achieve convergence of the local AI / ML model; Under the condition that the error is less than the convergence threshold, the completion of the training of the local AI / ML model is reported to the network node.

20. The method of at least one of claims 14 to 19, wherein the first information includes an indication of a condition associated with the profile that was determined by the WTRU to be failed.

21. The method of claim 20, wherein the failed condition comprises: A signal to interference plus noise ratio (SINR) measured by the WTRU is not within a range of SINRs of any of the AI / ML models available from the network node.

22. The method according to at least one of claims 14 to 21, comprising: Assistance information is transmitted to the network node.

23. The method of claim 22, wherein the auxiliary information indicates any one of: capability information including the type of AI / ML model with which the WTRU is configured, antenna configuration information for the WTRU, and location information for the WTRU.

24. The method of at least one of claims 14 to 23, wherein the configuration information comprises a trigger or command for determining whether the one or more AI / ML models are suitable for use in at least one function at the WTRU.

25. The method of at least one of claims 14 to 24, wherein any one of the one or more AI / ML models and the local AI / ML model are configured to: perform any one of channel state information (CSI) estimation or CSI prediction.

26. The method of at least one of claims 14 to 25, wherein the local AI / ML model comprises a model for a lifecycle management phase stored at the WTRU.

Images