AIML model lifecycle management

Abstract

A wireless transmit / receive unit (WTRU) includes a processor configured to receive configuration information, the configuration information includes information about one or more AIML lifecycle management (LCM) stages associated with an artificial intelligence / machine language (AIML) model and information about a local LCM stage report identification (ID) granularity and a global LCM stage report ID granularity for reporting the one or more AIML LCM stages; sending feedback for the first AIML LCM stage using the local LCM stage report ID granularity; receiving an indication to switch to the global LCM phase report ID granularity; sending an LCM stage report ID granularity switching confirmation message; and sending feedback for the second AIML LCM stage using the global LCM stage report ID granularity.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 410,983, filed on September 28, 2022, and U.S. Provisional Application No. 63 / 456,831, filed on April 4, 2023, the entire contents of which are incorporated herein by reference. Background Art

[0003] A WTRU using an Artificial Intelligence / Machine Language (AIML) model may need to provide feedback on the Artificial Intelligence / Machine Language (AIML) Lifecycle Management (LCM) phases associated with the AIML model (e.g., model training, model switching, model activation / deactivation). Feedback on the LCM phases of an AIML model may provide many different types and layers of data. A WTRU providing feedback on the LCM phases may need to provide data of different granularities for different AIML models in different environments. A WTRU system and method is needed that enables the use of different LCM phase report ID granularities to provide feedback on AIML models at different levels of information. Summary of the invention

[0004] A wireless transmit / receive unit (WTRU) may include a processor. The processor may be configured to receive configuration information including information about one or more AIML lifecycle management (LCM) phases associated with an artificial intelligence / machine language (AIML) model and information about a local LCM phase report identification (ID) granularity and a global LCM phase report ID granularity for reporting the one or more AIML LCM phases, wherein the global LCM phase report ID granularity is configured to utilize a different amount of resources than the local LCM phase report ID granularity. The processor may be further configured to use the local LCM phase report ID granularity to send feedback for a first AIML LCM phase of the AIML model. The processor may be further configured to receive an indication of switching to the global LCM phase report ID granularity for reporting the one or more AIML LCM phases. The processor may be further configured to send an LCM phase report ID granularity switch confirmation message. The processor may be further configured to use the global LCM phase report ID granularity to send feedback for a second AIML LCM phase of the AIML model. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0006] Figure 1Bis an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system.

[0007] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within an illustrated communication system.

[0008] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of a further example RAN and a further example CN for use within the illustrated communication system.

[0009] Figure 2A is a schematic diagram of an example system environment for implementing an artificial intelligence (AI) and / or machine learning (ML) model.

[0010] Figure 2B An example of a neural network is illustrated.

[0011] Figure 2C is a schematic diagram of an example system environment for training and / or implementing an AIML model including a neural network (NN).

[0012] Figure 3 is a process diagram illustrating an example for indicating the granularity of AIML LCM phase report IDs.

[0013] Figure 4 is a flow chart illustrating an example method for implementing AIML LCM phase report ID granularity. DETAILED DESCRIPTION

[0014] 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 through sharing of 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-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0015] like Figure 1A As shown, 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, but it should be understood 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 send 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 environment), 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 WTRU.

[0016] 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 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 Node B, 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 should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0017] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (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 of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

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

[0019] 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, and SC-FDMA, among others. 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 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

[0022] 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 the dual connectivity (DC) principle. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0023] 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, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0024] Figure 1AThe base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0025] The RAN 104 / 113 may be in communication 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 calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text and video, the CN 106 / 115 may be 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 calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1A Although not shown in the figure, 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 that 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) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] 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 communication networks 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.

[0027] 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 illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0028] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, 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 foregoing elements while remaining consistent with an embodiment.

[0029] 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 decoding, 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 is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0031] Although the transmit / receive element 122 Figure 1B 1 as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

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

[0033] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may 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, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0035] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information 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. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0036] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules 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, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

[0037] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (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 for reducing and / or substantially eliminating self-interference via signal processing performed via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

[0039] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-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 evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0040] Each of the evolved Node 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, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0041] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0042] The MME 162 may be connected to each of the evolved Node-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, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. 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.

[0043] The SGW 164 may be connected to each of the evolved Node-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 an inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

[0045] 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 networks and / or wireless networks owned and / or operated by other service providers.

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

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

[0048] 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 to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit 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 point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the destination STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11eDLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. This IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0049] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send 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 / 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 by a particular STA and / or determined to be busy, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0050] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0051] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels 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 (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0052] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0053] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. 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 a STA (which supports the minimum bandwidth operating mode) from 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) 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, because a STA (supporting only the 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

[0054] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

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

[0056] The RAN 113 may include gNBs 180a, 180b, 180c, though 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 send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0057] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. 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 transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0058] 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 while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 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 for serving the WTRUs 102a, 102b, 102c.

[0059] 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 UL and / or 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. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0060] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] 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, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling and mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services 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 mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 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-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0062] 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 WTRU 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.

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

[0064] 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 networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0065] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein for one or more of the following items may be performed by one or more simulation devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182ab, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

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

[0068] The following description is for exemplary purposes and is not intended to limit in any way the applicability of the methods described herein to any wireless technology and / or to other wireless technologies when applicable. The term "network" in this disclosure may refer to one or more gNBs (which in turn may be associated with one or more transmit / receive points (TRPs)), or may refer to any other node in a radio access network.

[0069] The terms "artificial intelligence (AI)", "machine learning (ML)", "deep learning (DL)" and "DNN" are used interchangeably. The methods described herein are exemplified based on learning in a wireless communication system. These methods are not limited to such scenarios, systems and services, and can be applied to any transmission and / or service type.

[0070] Throughout the disclosure, the terms "AIML model," "AIML model," "ML model," and "model" are used interchangeably to refer to an artificial intelligence / machine learning model that emulates logical decisions based on available, collected, and / or requested data.

[0071] AI can be broadly defined as the behavior exhibited by machines that mimic cognitive functions of sensing, reasoning, adapting, and acting. Machine learning can refer to a type of algorithm that solves problems based on learning through experience ("data") without explicit programming (e.g., a configured set of rules). Machine learning can be considered a subset of AI. Different machine learning paradigms can be envisioned based on the nature of the data or feedback available for learning the algorithm. Supervised learning methods can involve learning a function that maps inputs to outputs based on labeled training data, with each training data example consisting of a pair of inputs and corresponding outputs. Unsupervised learning methods can involve detecting patterns in data without any pre-existing labels. For example, a reinforcement learning method can involve performing a series of actions in an environment to maximize a cumulative reward.

[0072] It is possible to apply a machine learning algorithm using a combination of interpolations of the above-mentioned methods. For example, a semi-supervised learning method can use a combination of a small amount of labeled data and a large amount of unlabeled data during training. In this regard, semi-supervised learning falls between unsupervised learning (no labeled training data) and supervised learning (only labeled training data). Deep learning refers to a class of machine learning algorithms using artificial neural networks (DNNs) loosely inspired by biological systems. Deep neural networks (DNNs) are a class of special machine learning models inspired by human brain inspiration, in which the input is linearly transformed and passes through nonlinear activation functions many times. DNNs are generally composed of multiple layers, each layer consisting of a linear transformation and a nonlinear activation function. DNNs can be trained using training data via a back propagation algorithm. Recently, DNNs have been demonstrated in various fields (e.g., speech, vision, natural language, etc.) and for various machine learning settings (including supervision, unsupervised and semi-supervised) The performance of the prior art.

[0073] Figure 2A2 is a schematic diagram of an example system environment 200A for implementing an AIML model 209. The AIML model 209 may be implemented at a WTRU and / or a network. The AIML 209 model may include model data and one or more algorithms and / or functions configured to learn from received input data 207 to train the AIML model 209 and / or generate output 215. The input data 207 may be input in one or more formats, such as an image format, an audio format (e.g., a spectrogram or another audio format), a tensor format (e.g., including a one-dimensional or multi-dimensional array), and / or another data type that can be input into the AIML model 209 algorithm. The input data 207 may be the result of a pre-processing 205 that may be performed on the raw data 203, or the input data 207 may include the raw data 203 itself. The raw data 203 may include image data, text data, audio data, or another information sequence (such as a network information sequence associated with a communication network) and / or other types of data. Preprocessing 205 may include format changes or other types of processing to generate input data 207 in a format for input into an AIML 209 algorithm. Output 215 may be generated by the AIML model 209 algorithm in one or more formats, such as a tensor, a text format (e.g., words, sentences, or other text sequences), a numerical format (e.g., predictions), an audio format, an image format (e.g., including video formats), another data sequence format, and / or another output format.

[0074] The AIML model 209 may be implemented using software and / or hardware as described herein. The AIML model 209 may be stored as computer executable instructions on a computer readable medium that can be accessed by one or more processors for execution as described herein. Example AIML environments and / or libraries include TENSORFLOW, TORCH, PYTORCH, MATLAB, GOOGLE CLOUD AI and AUTOML, AMAZON SAGEMAKER, AZURE MACHINE LEARNING STUDIO, and / or ORACLE MACHINE LEARNING.

[0075] The AIML model 209 may include one or more algorithms configured for unsupervised learning. Unsupervised learning may be implemented using an AIML model 209 algorithm that learns from input data 207 without training for a specific target output. For example, during unsupervised learning, the AIML model 209 algorithm may receive unlabeled data as input data 207 and determine patterns or similarities in the input data 207 without additional intervention (e.g., updating parameters and / or hyperparameters). The AIML model 209 algorithm configured to implement unsupervised learning may include an algorithm configured to identify patterns, groupings, clusters, anomalies and / or similarities or other associations in the input data 207. For example, the AIML model 209 algorithm may implement a hierarchical clustering algorithm, a k-means clustering algorithm, a K-nearest neighbor (K-NN) algorithm, an anomaly detection algorithm, a principal component analysis algorithm, and / or a priori algorithms. The AIML model 209 algorithm configured for unsupervised learning may be implemented on a single device or distributed across multiple devices such that the output 215 or portions thereof may be aggregated at one or more devices for further processing and / or implemented in other downstream algorithms or processes, as may be further described herein.

[0076] The AIML model 209 may include one or more algorithms configured for supervised learning. The AIML model 209 algorithm trained during the training process may be used to implement supervised learning to determine a predictive model using known results. The AIML model 209 algorithm may be characterized by parameters and / or hyperparameters that may be trained during the training process. These parameters may include values ​​derived during the training process. These parameters may include weights, coefficients, and / or biases. The AIML model 209 may also include hyperparameters. Hyperparameters may include values ​​for controlling the learning process. Hyperparameters may include learning rate, number of epochs, batch size, number of layers, number of nodes in each layer, number of kernels (e.g., CNN), step size (e.g., CNN), kernel size in pooling layers (e.g., CNN), and / or other hyperparameters. The AIML model may use certain parameters and hyperparameters interchangeably.

[0077] The AIML model 209 can be trained during supervised learning by inputting training data into the AIML model 209 algorithm and adjusting parameters and / or hyperparameters toward a known target output 215 while minimizing the loss or error in the output 215 generated by the AIML 209 algorithm. The raw data 203 may include or may be divided into training data, validation data, and / or test data for training, validation, and / or testing the AIML model 209 algorithm during supervised learning, respectively. The training data, validation data, and / or test data may be preprocessed from the raw data 103 for input into the AIML model 209 algorithm. During supervised learning, the training data may be labeled before being input into the AIML model 209. The training data may be labeled to teach the AIML model 209 algorithm to learn from the labeled data and test the accuracy of the AIML model 209 implemented on the unlabeled input data 207 during the production / specific implementation of the AIML model 209 algorithm or a similar AIML model 209 algorithm using similar parameters and / or hyperparameters. The training data may be used to fit the AIML model 209 parameters using an optimization function, such as a loss function or an error function. The trained or fitted AIML model 209 may receive validation data as input to evaluate the model fit to the training data set while tuning the hyperparameters of the AIML model 209. The AIML model 209 may receive test data to evaluate the final model fit to the training data set and estimate the AIML model 209 performance. One or more of training, validation, and / or testing may be performed during supervised learning for different types of AIML models 209.

[0078] Supervised learning can be implemented for various types of AIML model 209 algorithms, including algorithms that implement linear regression, logistic regression, neural network (NN), decision tree, Bayesian logic, random forest and / or support vector machine (SVM). NN and deep NN (DNN) are popular examples of algorithms used in AIML models that can be trained using supervised learning. However, AIML model 209 can implement one or more NN-based and / or non-NN-based algorithms. Various examples of NN may include perceptrons, multilayer perceptrons (MLP), feedforward NNs, fully connected NNs, convolutional neural networks (CNNs), recursive NNs (RNNs), long short-term memory (LSTM) NNs and / or residual NNs (ResNets). A perceptron is a NN that includes a function that multiplies its input by a learned weight coefficient to generate an output value. A feedforward NN is a NN that receives input at one or more nodes of an input layer and moves information in the direction of one or more nodes of an output layer through one or more hidden layers. In a feedforward NN, one or more nodes of a given layer may be connected to one or more nodes of another layer. A fully connected NN is a NN that includes an input layer, one or more hidden layers, and an output layer. In a fully connected NN, every node in one layer is connected to every node in another layer of the NN.

[0079] MLP is a feed-forward NN of the fully connected class. CNN is a NN with one or more convolutional layers configured to perform convolution. Various types of NNs may have elements including one or more CNNs or convolutional layers, such as generative adversarial networks (GANs). GANs may include conditional GANs (CGANs), cycle-consistent GANs (CycleGANs), StyleGANs, DiscoGANs, and / or IsGANs. GANs may include a generator submodel and a discriminator submodel. The generator submodel may be configured to receive input data and pass true and independently generated data to the discriminator submodel. The discriminator submodel may be configured to receive true and independently generated data from the generator, discriminate the true and independently generated data, and provide feedback to the generator submodel during training to improve the generator submodel's function in independently generating outputs based on received inputs. For example, GAN is a popular model for generating data types or data sequences such as image data, audio data, and / or text. RNNs are inherently recursive NNs in that nodes include feedback connections and internal hidden states (e.g., memories) that allow outputs from nodes in the NN to affect subsequent inputs to the same node. LSTM NNs may be similar to RNNs in that nodes have feedback connections and internal hidden states (e.g., memories). However, LSTM NNs may include additional gates to allow the LSTM NN to learn long-term dependencies between data sequences.

[0080] ResNet is a NN that may include skip connections to skip one or more layers of the NN. The autoencoder may be a form of AIML 109 that may be implemented for supervised learning so that parameters and / or hyperparameters may be updated during the training process. The parameters and / or hyperparameters may be associated with the encoder portion and / or the decoder portion of the autoencoder. The NN may include one or more attention layers or functions to enhance or focus on some portions of the input data while reducing or weakening other portions.

[0081] Different types of NNs and / or layers may be implemented to process different types of data and / or produce different types of outputs. For example, a NN may include one or more convolutional layers (e.g., for a CNN or GAN) that may be padded for processing images and / or audio data (e.g., spectrograms). Each convolutional layer may vary according to various convolutional layer parameters or hyperparameters, such as kernel size (e.g., the field of view of the convolution), step size (e.g., the step size of the kernel when traversing the image), padding (e.g., for processing image boundaries), and / or input and output sizes. The processed image may include one or more dimensions (e.g., a row of pixels or a two-dimensional array of pixels). Pixels may be represented according to one or more values ​​(e.g., one or more integer values ​​representing color and / or intensity) that may be received by the convolutional layer. A kernel, which may also be referred to as a convolution matrix or mask, may be a matrix for extracting and / or transforming features from received input data. Kernels may be used for blurring, sharpening, edge detection, etc. Example kernel sizes may include matrices of 3×3, 5×5, 10×10, etc. (e.g., in pixels of a 2D image). The stride may be a parameter identifying the amount by which the kernel moves over the image data. An example default stride has a size of 1 or 2 within the matrix (e.g., in pixels of a 2D image). Padding may include the amount of data added to the boundaries of the image data as the kernel processes the boundaries of the image data (e.g., in pixels of a 2D image). The kernel may move over the input image data (e.g., according to the stride length) and perform a dot product with an overlapping input region to obtain an activation value for the region. The output of each convolutional layer may be provided to the next layer of the NN, or as an output of the NN itself (e.g., image data, feature maps, etc.) with convolution-based updated features.

[0082] The NN may include similar types of layers (e.g., convolutional layers, feed-forward layers, fully connected layers, etc.), and / or include similar or different configurations for each layer (e.g., size, number of nodes, etc.). The NN may also or alternatively include one or more layers of a NN of a different type or subset, which may be interconnected for training and / or implementation as described herein. For example, a NN may include both convolutional layers and feed-forward or fully connected layers.

[0083] Figure 2BAn example of a neural network 200B is illustrated. The purpose of training can be to use input 207a as training data and / or to adjust Figure 2B One or more weights (e.g., which may be referred to as neuron weights and / or link weights) indicated as w and x in the training data such that the output 215 from the neural network 200B approaches the desired target value associated with the input 207a values ​​for the training data. For example, the neural network may include three layers (e.g., Figure 2B ). During training, for a given input, the difference between the output value and the expected value may be calculated and / or the difference may be used to update one or more weights in the neural network. For example, if the difference between the output and the expected value is observed to be significant (e.g., large), one or more changes in one or more weights may be expected to be relatively significant (e.g., large). A small difference (e.g., between the output and the expected value) may include one or more changes in one or more weights being relatively small. For example, the input 207a may be a reference signal parameter for positioning, and / or the output 215 may be an estimated position. The expected value may be position information acquired by a highly accurate global navigation satellite system (GNSS).

[0084] Once the neural network 200B completes its training, the difference between the output 215 value and the expected value may be below a threshold. The neural network 200B may be applied or implemented after training for positioning by feeding the input data 207a and / or by estimating or predicting the output 215 as the expected result of the associated input 207a. For example, the output 215 may be an estimated position and / or location of the WTRU.

[0085] Training the neural network 200B may include identifying one or more of: inputs to the neural network, expected outputs associated with the inputs, and / or actual outputs from the neural network that are compared to target values.

[0086] For example, a neural network model may be characterized by one or more parameters and / or hyperparameters, which may include: the number of weights and / or the number of layers in the neural network.

[0087] As used herein, the term "deep learning" may refer to a class of machine learning algorithms that employ artificial neural networks (e.g., deep neural networks (DNNs)) that are loosely inspired by biological systems and / or include at least one hidden layer. DNNs may be a special class of machine learning models inspired by the human brain, in which inputs are linearly transformed and / or passed through a nonlinear activation function one or more times (e.g., multiple times). DNNs may include one or more (e.g., multiple) layers, in which one or more (e.g., each) layer includes a linear transformation and / or a given nonlinear activation function. DNNs may be trained using training data via a back-propagation algorithm. Recently, DNNs have demonstrated state-of-the-art performance in various fields (e.g., speech, vision, natural language, etc.) and / or for various machine learning settings (e.g., supervised, unsupervised, and / or semi-supervised).

[0088] Figure 2C 200B. 200B is a schematic diagram of an example system environment 200C for training and implementing an AIML model including NN 200B. However, other types of AIML models (e.g., including NN models and / or non-NN models) may be similarly trained and / or implemented. NN 200B may be trained and / or implemented on one or more devices to determine and / or update parameters and / or hyperparameters 217 of NN 200B. Raw data 203a may be generated from one or more sources. For example, raw data 203a may include image data, text data, audio data, or another information sequence (such as a network information sequence associated with a communication network) and / or other types of data. Raw data 203a may be preprocessed at 205a to generate training data 207a. The preprocessing may include formatting or other types of processing / (pre) filtering of the changes so as to generate training data 207a in a format for input into NN 200Ba.

[0089] NN 200B may include one or more layers 211. The configuration of NN 200B and / or layer 211 may be based on parameters and / or hyperparameters 217. As described herein, parameters may include weights, coefficients, and / or biases for nodes or functions in layer 211. Hyperparameters may include learning rate, number of epochs, batch size, number of layers, number of nodes in each layer, number of kernels (e.g., CNN), step size (e.g., CNN), kernel size in pooling layer (e.g., CNN), and / or other hyperparameters. As described herein, NN 109a may include a feedforward NN, a fully connected NN, a CNN, a GAN, an RNN, a ResNet, and / or one or more other types of NNs. NN 200B may include one or more different types of NNs or layers for different types of NNs. For example, NN 109a may include one or more separate layers having one or more configurations.

[0090] During the training process, training data 207a may be input into NN 200B and may be used to learn parameters and / or tune hyperparameters 217. Training may be performed by initializing parameters and / or hyperparameters of NN 200B, generating and / or accessing training data 207a, inputting training data 207a into NN 200B, calculating the error or loss from the output of NN 200B to the target output 215a via loss function 213 (e.g., using gradient descent and / or associated back propagation), and / or updating parameters and / or hyperparameters 217.

[0091] The loss function 213 may be implemented using a back-propagation based gradient update and / or gradient descent technique, such as stochastic gradient descent (SGD), synchronous SGD, asynchronous SGD, batch gradient descent, and / or mini-batch gradient descent. For example, examples of loss functions or error functions may include functions for determining squared error loss, mean squared error (MSE) loss, mean absolute error loss, mean absolute percentage error loss, mean squared logarithmic error loss, pixel-based loss, pixel-by-pixel loss, cross entropy loss, logarithmic loss, and / or benchmark-based loss. The loss function may be implemented based on one or more quality metrics such as a signal-to-noise ratio (SNR) metric or another signal or image quality metric.

[0092] The optimizer may be implemented with the loss function 213. The optimizer may be an algorithm or function configured to adapt properties of the NN 200B, such as learning rate and / or weights, to improve the accuracy of the NN 200B and / or reduce loss or error. The optimizer may be implemented to update parameters and / or hyperparameters 217 of the NN 200B.

[0093] The training process may be iterated to update parameters and / or hyperparameters 217 until an end condition is achieved. The end condition may be met when the output of NN 200B is within a predefined threshold of the target output 215a.

[0094] After the training process is completed, the trained NN 200B or its parts may be stored for implementation by one or more devices. The trained NN 200B or its parts may be implemented in other downstream algorithms or processes, as may be further described herein. The trained NN 200B or its parts may be implemented on the same device that performs the training. The trained NN 200B or its parts may be sent or otherwise provided to another device for implementation. For example, NN 209b, 209c may include one or more parts of the trained NN 200B. NN 209b and NN 209c may receive input data 207b, 207c and generate corresponding outputs 215b, 215c. The outputs 215b, 215c can be generated in one or more formats, such as tensors, text formats (e.g., words, sentences, or another text sequence), numerical formats (e.g., predictions), audio formats, image formats (e.g., including video formats), another data sequence format, and / or another output format. The outputs 215b, 215c may be aggregated at one or more devices for further processing and / or implementation in other downstream algorithms or processes, as may be further described herein.

[0095] Alternatively or additionally, after the training process is completed, the trained parameters and / or tuned hyperparameters 217 or portions thereof may be stored for implementation by one or more devices. The trained parameters and / or tuned hyperparameters 217 or portions thereof may be implemented in other downstream algorithms or processes, as may be further described herein. The trained parameters and / or tuned hyperparameters 217 or portions thereof may be implemented on the same device that performs the training. The trained parameters and / or tuned hyperparameters 217 or portions thereof may be sent or otherwise provided to another device for implementation. For example, based on the trained parameters and / or tuned hyperparameters 217 being sent or otherwise provided to another one or more devices that can implement NN 209b, 209c. For example, NN 209b, 209c may be constructed at another device based on the trained parameters and / or tuned hyperparameters 217 or portions thereof. NN 209b and NN 209c may be configured according to parameters / hyperparameters 217 or portions thereof to receive respective input data 207b, 207c and generate respective outputs 215b, 215c. Outputs 215b, 215c may be generated in one or more formats, such as tensors, text formats (e.g., words, sentences, or another text sequence), numerical formats (e.g., predictions), audio formats, image formats (e.g., including video formats), another data sequence format, and / or another output format. Outputs 215b, 215c may be aggregated at one or more devices for further processing and / or implementation in other downstream algorithms or processes, as may be further described herein.

[0096] The AIML models and / or algorithms described herein may be implemented on one or more devices. For example, AIML 209 may be implemented in whole or in part on one or more devices, such as one or more WTRUs, base stations, and / or other network entities, such as network servers. Example networks in which AIML may be distributed may include a federated network. A federated network may include a group of dispersed devices, each of which includes AIML. Figure 2C As shown, AIML model 209b and AIML model 209c may be distributed on separate devices. Figure 2C Two models are shown (e.g., AIML model 209b and AIML model 209c), but any number of models may be implemented across any number of devices. The AIML models may be implemented for collaborative learning, where the AIML models are trained across multiple devices. In another example, the AIML models may be trained at a centralized location or device, and one or more portions of the AIML models or trained parameters and / or tuned hyperparameters may be distributed to decentralized locations. For example, updated parameters or hyperparameters may be transmitted to one or more devices to update and / or implement the AIML models thereon.

[0097] The WTRU may be configured to perform an AIML model registration process. The AIML model registration process may include one or more capabilities. For example, the AIML model registration process may include the WTRU reporting its AIML capabilities, including support for different RAN functions for AIML models that the WTRU can support, the number of supported AIML models, AIML processing capabilities, etc. In another example, the AIML model registration process may include AIML model identity assignment or AIML model ID space configuration, where the WTRU and / or NW can unambiguously address the AIML model during activation / deactivation, performance monitoring, training, etc. For example, the AIML model registration process may include AIML model verification, where the WTRU can verify the integrity, compatibility and / or applicability of the AIML model.

[0098] The registration procedure may involve the exchange of one or more messages between the WTRU and the gNB. The registration procedure may be performed during the RRC connection establishment procedure (e.g., reusing the RRC connection establishment message). The registration procedure may be performed during the RRC reconfiguration procedure (e.g., reusing the RRC reconfiguration message). Different parts of the registration procedure may be performed based on signaling at different protocol layers (e.g., WTRU capability transmission via RRC messages and model activation / deactivation using MAC CE).

[0099] As a result of the model registration process, the WTRU may be configured with an AIML model registration context. The model registration context may be a means of addressing, verifying, configuring, controlling, tracking, and managing the lifecycle management (LCM) phase of the AIML model. The LCM phase of an AIML model may include model training, model monitoring, model switching, and model activation / deactivation.

[0100] The WTRU may be configured for AIML model capability exchange. The WTRU may determine the suitability of the AIML model through capability exchange, which can be performed in a semi-static manner (e.g., during RRC configuration or reconfiguration) or before the model transfer at any time when the node (WTRU and / or gNB) requests the model. The model capability exchange may include any one or more of the following: WTRU capabilities, model type, number of models, WTRU service type, measurements, comparison with traditional functions, information about the expected KPIs (performance, latency, FLOPs) of the ML model, additional information about the input to the model, inference-related capabilities (e.g., FLOPs-floating point operations) and training-related capabilities (e.g., FLOPs-floating point operations), AIML hardware-specific information, and including model switching delay. The WTRU and NW are able to negotiate the optimal configuration for the coexistence of AIML inference for multiple RAN functions.

[0101] The WTRU capabilities may include, for example, antenna configuration, parameter set (e.g., SCS, waveform), number of Tx / Rx chains, whether the WTRU supports FDD / TDD / XDD / full duplex / half duplex, and / or number of panels. The WTRU may determine whether the AIML model is suitable for performing at least one of its capabilities.

[0102] The WTRU may support at least one model type including DNN, UNN, CNN, RNN, transformer and / or autoencoder. If the AIML model uses a model type supported by the WTRU, the WTRU may determine whether the AIML model is suitable. The WTRU may indicate the types of layers and activation functions supported. The WTRU may indicate the different model formats supported (e.g., ONNX - Open Neural Network Exchange, etc.).

[0103] The WTRU may be configured with multiple AIML models. The model may be developed offline by the WTRU vendor. The WTRU may support different AIML models for different RAN functions. For example, the AIML model may support RAN functions such as CSI feedback compression / prediction, beam prediction, and positioning. The WTRU may support more than one AIML model for each RAN function. Each AIML model may be optimized for a specific operating context of the RAN function. The specific operating context in this document may refer to different scenarios and / or configurations associated with the RAN function. The WTRU may indicate the maximum number of models it can support as part of its capabilities. For example, the maximum number of models that the WTRU can support may vary with the model size and is limited by the storage / memory size at the WTRU.

[0104] If the AIML model is applicable to the WTRU's service type, the WTRU may determine whether the AIML model is appropriate. The service type may be defined as or include at least one of periodicity / aperiodicity, burst start / end / duration, reliability, latency, throughput, etc.

[0105] The WTRU may indicate its capabilities based on the supported measurements, including the measurement type, measurement frequency, and supported measurement bandwidth. Such measurements may be used as input to the AIML model. Such measurements may be used to monitor the performance of the AIML model. For example, the WTRU may be configured with resources on which to perform at least one measurement. The WTRU may compare at least one measurement with at least one threshold. At least one threshold may be configurable. If at least one measurement 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 threshold. The WTRU function may be associated with at least one measurement threshold. For example, the measurement may include at least one of the following items: position, speed, mobility direction, L1 or L3 measurement (such as L1-RSRP, RSSI, RSRQ, SINR, CO, RI, CQI, PMI, LI), interference measurement, Doppler, Doppler spread, delay spread, number of multipaths, coherence time, coherence bandwidth, beam direction, beam width, beam set, path loss, determination of whether the path is line of sight or non-line of sight, throughput, BLER and / or delay.

[0106] The WTRU may compare the performance of the AIML model on a function with the expected performance of performing the function using a baseline (e.g., non-AIML) method. The WTRU may determine the error event rate due to 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.

[0107] The WTRU may be configured to determine the suitability of an ML model based on the number and / or type and / or size of inputs to the ML model. For example, during a training process using local data, an ML model may require more reference signals (e.g., CSI-RS resources) and / or higher frequency reference signals than the WTRU is able to support. For example, an AIML model may require inputs of larger size (e.g., more fine-grained multi-bit location information) than another ML model that may require single-bit location indications. The WTRU may be configured to determine the suitability of an ML model based on RS configurations supported for inference. The WTRU may be configured to determine the suitability of an ML model based on indications of different capabilities of the inputs for model training and model inference.

[0108] The WTRU may be configured to determine the suitability of the ML model based on capabilities, which may include computational complexity, inference latency, storage required for the model, and / or other inference-related capabilities. In addition, the WTRU may be configured to determine the suitability of the ML model based on how many inference instances can be run in parallel.

[0109] The WTRU may be configured to determine the suitability of an ML model based on capabilities, which may include computational complexity, training latency, storage required for the model, frequency of model updates, and other training-related capabilities.

[0110] The WTRU may be configured to determine the suitability of the ML model based on how many training instances can be run in parallel. The WTRU may be configured to determine the suitability of the ML model based on the extent to which inference and training can coexist and function together in the WTRU at any given time.

[0111] The WTRU may be configured to determine the suitability of the ML model based on the WTRU and NW being able to negotiate the best configuration for coexistence of AIML inference for multiple RAN functions. For example, the gNB may indicate the function / corresponding ML model to the WTRU for prioritization in the presence of multiple ML models performing different functions.

[0112] The WTRU may be configured to determine the suitability of the ML model based on the type of hardware environment, AIML execution environment, memory availability, and other hardware specific information. Such configuration may be abstracted and may be indicated as a scaling factor compared to a predefined reference model.

[0113] The WTRU may be configured to determine the suitability of an ML model based on a model switching delay (e.g., the time it takes to switch inference from one model to another). The model switching delay may vary with the AIML size, supported RAN functions, etc.

[0114] The WTRU may be configured for AIML model validation. For example, the WTRU may be configured to perform model validation before using the model for inference and / or training. Model validation may be part of the registration process.

[0115] The WTRU may perform model validation. For example, the WTRU may be configured to validate whether a one-sided AIML model is ready for inference and / or training.

[0116] The WTRU and gNB may jointly perform model validation. For example, the WTRU and gNB may jointly perform model validation via a signaling exchange to verify that the models at the WTRU and gNB are ready. Model validation may involve one or more of completeness, compatibility, and / or interoperability.

[0117] The WTRU may be configured by the network (NW) with an AIML model that requires integrity checking. The WTRU may be configured to check the integrity of the received AIML model. For example, the WTRU may be configured to calculate a checksum on the AIML model parameters using a pre-configured hash function. The WTRU may compare the checksum with the relevant checksum of the AIML model. If the checksum does not match, the WTRU may indicate an integrity failure to the network.

[0118] The WTRU may be configured by the network with an AIML model that requires a compatibility check. The WTRU may be configured to verify whether it can use the AIML model configured by the network. The WTRU may indicate to the network whether the configured AIML model can be used for inference and / or training at the WTRU. For example, the WTRU may be configured to perform a compatibility check on the configured model, including whether the WTRU supports the configured AIML model format, whether the configured AIML model exceeds the WTRU capabilities and / or whether the configured AIML model can be compiled into the WTRU-specific target execution environment.

[0119] The WTRU may be configured to verify that the AIML model used by the WTRU is able to interoperate with the gNB. The WTRU may be configured with an AIML model that works jointly with a gNB model (e.g., in a CSI compression use case). For example, the WTRU may be configured to verify that the encoder model at the WTRU is able to interoperate with the decoder model at the gNB model so that the gNB can reconstruct the CSI feedback transmitted by the WTRU.

[0120] The WTRU may be configured for AIML model identifier assignment. The WTRU may be configured with one or more rules and / or configurations associated with the AIML model identifier. The WTRU may be configured for AIML model identifier assignment during the AIML model registration process. If the model validation is successful, the WTRU may be configured for AIML model identifier assignment. The WTRU may be configured for AIML model identifier assignment for the AIML model for which the model validation is successful. The WTRU may receive an explicit identifier for the AIML model. The WTRU may receive a configuration of rules to determine the identifier of the AIML model within a pre-configured identifier space. The registration process may create an addressable assignment for the AIML model at the WTRU. The registration process may create an addressable assignment for the AIML model configured for future use based on the gNB.

[0121] The WTRU may be configured with an AIML model identification that is partially implicitly or explicitly associated with one or more of: an identification of the NW vendor, an identification of the WTRU vendor, an identification of the cell, an identification of the operator; an identification of the gNB, CU or any other RAN node or CN node; an identification of the logical area; the architecture of the model; the hyperparameters of the model; an identification based on a reference to a previously used ML model between the WTRU and the gNB; the security context of the WTRU; an identification associated with the training data and / or test data used to train the model; a model identification associated with the model structure or model parameters (including learned parameters); an identification associated with a RAN function or use case; an identification associated with a model training instance; and an identification associated with a scenario and / or configuration.

[0122] The NW provider's identifier may be a logical identifier defined in the operator's identifier space.

[0123] The identifier of the NW provider may be a globally unique ID.

[0124] The cell identifier may be unique within a preconfigured logical area. The cell identifier may be a globally unique identifier. For example, the cell identifier may be a mobile network code (MNC).

[0125] The operator's identification may include one or more of a Mobile Country Code (MCC), MNC, etc.

[0126] The identification of the logical area may include, for example, a RAN area, a tracking area, etc.

[0127] The architecture of the model may include, for example, RNN, CNN, DNN, autoencoder, GAN, transformer, etc.

[0128] Hyperparameters of a model may include, for example, the number of layers, activation functions, learning rates, etc.

[0129] The identities associated with RAN functions or use cases may include, for example, different logical identifiers that may be assigned to CSI feedback, beam management, positioning, mobility management, etc.

[0130] The identification associated with a model training instance may include, for example, a version ID or a variation thereof.

[0131] Identification associated with a scenario and / or configuration may include, for example, a channel model, a bandwidth configuration, and the like.

[0132] The model ID structure may include model ID levels and / or granularities, each level and / or granularity defining a different type and / or degree of information and requiring a different amount of resources. The model ID structure may include model ID levels, where the first level may carry basic information and other levels add additional information. For example, level 1 (e.g., first granularity) may include necessary, basic and / or required information for a model version ID required to identify the model, which may be assigned by the gNB and / or WTRU. Models may be assigned within the model ID space configured by the gNB and / or after a handshake with the gNB. For example, other levels may include levels 2, 3...N (e.g., second...Nth granularity), where any additional information that is part of the model ID to identify the model is included in one or more of these levels or granularities. The additional information may be optional or mandatory. The additional information may correspond to any one or more of a RAN function / sub-function, a use case, a scenario, a configuration, a training, and a layer group within the corresponding model. The additional information may correspond to one or more AIML LCM stages associated with the AIML model.

[0133] The AIML model ID may include information about the model identification or a portion thereof and the association between the model (or a portion thereof) and one or more other models (or a portion thereof). The mapping of functions to models may be one-to-one, many-to-one, and one-to-many. In a one-to-one mapping, the mapping of functions to models may be one-to-one. In a one-to-one mapping, the version model ID assigned to a model corresponds to a function executed by the model. A function executed by a model may be incorporated into the model version ID.

[0134] A mapping table at the gNB may assign unique IDs to different functions. For example, CSI prediction may correspond to ID#1, beam prediction may correspond to ID#2, and so on. The gNB may share the mapping table with the WTRU (e.g., semi-statically in RRC configuration / reconfiguration). A model function may correspond to a field in the model version ID. A node (e.g., the WTRU or gNB where the model currently resides) may share a model version ID that explicitly indicates the function performed by the model. The model function corresponding to the lookup table may be indicated by a node (e.g., the WTRU or gNB where the model currently resides) other than the model version ID (e.g., the function may not be incorporated into the model version ID). Additionally or alternatively, in a one-to-one, any training / retraining of the model or a portion thereof may update the model version ID or a portion thereof.

[0135] In one-to-many, a single model identity can be applied to more than one model, for example, in a federated learning scenario.

[0136] In many-to-one (e.g., different identifications for different layers / layer groups), the model ID may include, for example, [model ID][layer group 1 ID][layer group 2 ID]. In many-to-one, layer grouping may be based on a function (e.g., beam prediction vs. beam blocking prediction) or configuration.

[0137] In one or more cases, the model ID may be associated with a binary model that may be compiled and optimized for specific WTRU hardware. In one or more other cases, the model ID may be associated with a model structure and / or parameters. For example, the model structure and / or parameters may be defined in a proprietary format. In another example, the model structure and / or parameters may be defined in a standardized format (e.g., 3GPP or an open format such as ONNX). In one or more cases, the model ID may be associated with a logical model. For example, the logical model may be the functionality of the model. For example, the logical model may refer to the input and output relationships of the model. In another example, the logical model may refer to a data set used to train the model. In another example, the logical model may refer to a training instance or result. In another example, the logical model may refer to a model pairing between an encoder and a decoder of a bilateral model.

[0138] The model version ID may or may not include configuration and / or information about the number of layers (e.g., N1) that are updated from the total number of layers (e.g., N). Information about layers (e.g., the number of layers, the group of layers that perform a function, the number of functions performed by the model, or a portion thereof) may not necessarily form part of the model version ID. For example, information about layers may be sent with the model (e.g., as part of a model configuration file).

[0139] Information about the layers may be incorporated into the version ID. For example, the WTRU may be configured to perform training and update a portion of the AIML model (e.g., the number of layers that are unchanged / frozen (i.e., N-N1) and the number of layers whose weights can be updated as a result of training (i.e., N1)). For example, the received AIML model may have N layers. The low-level features extracted by the first (N-N1) layers may be directly applicable to the WTRU and may not require retraining, and the weights of these layers may remain frozen for the training process. The remaining N1 layers may need to be retrained by the WTRU, and these weights may be updated based on data locally available at the WTRU during a fine-tuning or retraining process at the WTRU. The selection of parameters indicating how many layers can be directly utilized by the WTRU and how many layers will need to be retrained may be indicated to the WTRU by the gNB. For example, the number of layers may be indicated explicitly (e.g., an indication to train layer group 1 corresponding to the first N1 layers) and / or implicitly (e.g., a request to use the AIML model for beam prediction in a joint beam and blocking prediction model). The selection of parameters indicating 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 one or both of the functionality of the AIML model required by the WTRU (e.g., RAN function / sub-function) and the configuration of the model (e.g., [Model ID][Layer Group 1 ID][Layer Group 2 ID]).

[0140] The WTRU may be configured to implicitly determine the identity of the AIML model or its version. The WTRU may be configured to determine the identity of the AIML model based on a hash of the learned parameters. A mechanism may be defined for deriving a unique identity of the AIML model to ensure proper synchronization between the encoder and decoder. For some applications, the AIML model may become very large. A mapping between the learned parameters and the version ID may be created. For example, the WTRU may be configured to derive an identity (version) of the AIML model using any one or any combination of the following: hashing the quantized learned parameters (e.g., reducing the bits per weight and / or bias; hashing the statistics of the learned parameters (e.g., summing / averaging / variance of all weights per neuron and / or layer); hashing the filtered learned parameters (e.g., hashing on a few selected weights, last few layers, activations above a threshold, etc.); and / or hashing the deltas of the learned parameters relative to a reference model. The reference model may be one or more of the following: a predefined model with normalized weights and biases, an AIML model as a result of offline training, and / or an AIML model previously synchronized between the WTRU and the gNB.

[0141] The WTRU may be configured to determine an identity of an AIML model based on the training data. For example, the WTRU may be configured to determine an identity of a set of training data and / or test data. For example, the WTRU may be configured to determine an identity of the last training and / or test data. For example, the WTRU may be configured to determine a time at which the last training and / or test data was received / generated.

[0142] The WTRU may be configured with a link between a pre-configured identification space and a reference model. The WTRU may use a portion of the identification space to indicate different versions, and this may be based on different conditions in some cases. The WTRU may be configured to assume a pre-configured identification for the reference model (e.g., 0). The WTRU may be configured to increment the identification by a predetermined value (e.g., 1) during the online training process.

[0143] The WTRU may be configured to update the identifier based on one or more conditions. For example, the WTRU may be configured to increment the identifier by a predetermined value for each successfully completed training process. The WTRU may be configured to increment the identifier by a predetermined value for each training data sample. The WTRU may be configured to increment the identifier by a predetermined value for each stochastic gradient descent batch. The WTRU may be configured to increment the identifier by a predetermined value for each epoch of the training process. The WTRU may be configured to increment the identifier by a predetermined value upon successful AIML model synchronization with the gNB. The WTRU may be configured to increment the identifier by a predetermined value for each update of the learning parameters. The WTRU may be configured to increment the identifier by a predetermined value when a timer expires. The WTRU may be configured to increment the identifier by a predetermined value (e.g., based on the performance of an intermediate KPI or an end-to-end KPI) when a pre-configured threshold in the loss function is reduced. The WTRU may be configured to determine different levels of version updates based on full convergence and partial convergence.

[0144] The WTRU may be configured to explicitly determine the identification of the AIML model. The WTRU may be configured to determine the identification of the AIML model based on explicit signaling. The WTRU may be configured to apply the identification of the AIML model based on explicit signaling. The WTRU may be configured to apply the identification of the ML model based on explicit signaling from the gNB. The WTRU may be configured to apply the identification of the ML model based on explicit signaling during the training process. The WTRU may be configured to apply the identification of the AIML model based on explicit signaling during one or more steps. The WTRU may be configured to apply the identification of the AIML model based on the WTRU vendor configuration. The WTRU may be configured to apply the identification of the AIML model based on the default configuration specified in the standard.

[0145] In one or more cases, the WTRU may be configured with one or more AIML models and global IDs for these models. For example, the WTRU may receive such configuration from a WTRU vendor. In some examples, the WTRU may receive the configuration from the WTRU vendor during implementation or via OTT signaling. In one or more cases, the WTRU vendor may notify (e.g., register) one or more AIML models to the NW vendor. The WTRU vendor may indicate one or more AIML models via optional metadata associated with the model (e.g., but not limited to, together with the global ID), etc. In one or more cases, the network (NW) vendor may configure / provide information corresponding to the global ID to the OAM entity and / or gNB.

[0146] The WTRU may be configured to indicate to the gNB / network a list of global IDs of the models supported by the WTRU. For example, the WTRU may indicate the global IDs in a list / sequence {G1, G2, G3 ... Gn}. In one or more cases, the WTRU may send the indication of the global IDs via WTRU capability signaling. For example, the WTRU may send the indication of the global IDs during a registration procedure. Additionally or alternatively, in another example, the WTRU may send the indication via RRC or NAS signaling.

[0147] In one or more cases, the WTRU may receive a configuration from the gNB / network indicating one or more allowed models. For example, the allowed models may be indicated via a Boolean field with reference to a list of supported models sent by the WTRU. For example, the allowed models may be configured as a list {1,0,1…0}. For example, 0 may indicate that the model is not allowed. As another example, 1 may indicate that the model is allowed. Additionally or alternatively, models corresponding to, for example, global IDs G1 and G3 are allowed, and the remaining global IDs are not allowed. In one or more cases, the WTRU may derive local IDs for the allowed models as follows. For example, for each allowed model in the list, the WTRU may start with an initial local ID for the first allowed model (e.g., 0 or pre-configured by the gNB / NW) and sequentially increment the model ID for each allowed model in the list. In one or more cases, the WTRU may be configured with different initial local IDs for different use cases. In one or more cases, the WTRU may be configured to append a use case specific ID to the local ID. In one or more cases, the WTRU may receive an explicit assignment for a local ID from the gNB / NW. For example, the WTRU may receive a model transfer from the NW, and the WTRU may receive the local ID during the model transfer.

[0148] In one or more cases, the WTRU may receive an indication from the gNB / network regarding a list of models that can be acquired. For example, the gNB may have information from the WTRU vendor about models that are not yet available at the WTRU. The WTRU may receive a list of global IDs associated with the models that can be acquired. Upon receiving the list of models that can be acquired, the WTRU may trigger a model transfer of these models from a server. For example, the WTRU may trigger a model transfer of these models from a server (such as, but not limited to, a WTRU vendor server, a non-3GPP entity, a CN entity, etc.). In one or more cases, the WTRU may be configured to indicate to the gNB / network when the download of one or more models in the list that can be acquired is completed. The WTRU may indicate when the download is complete via one or more of WTRU capability signaling, a model update procedure, or a registration procedure.

[0149] In one or more cases, the WTRU may be configured with a model ID or a portion thereof, depending on the task. In one or more cases, the WTRU may be configured with more than one type of model ID, where the type of model ID that the WTRU determines to use may vary depending on the task at hand. In one or more other cases, the model ID may include multiple parts, where the part used by the WTRU may vary depending on the task at hand. For example, a part of the model ID may include a static model ID or a portion thereof and a dynamic model ID or a portion thereof. In another example, a part of the model ID may include a WTRU-specific model ID or a portion thereof and a model-specific model ID or a portion thereof. In another example, a part of the model ID may include a global model ID or a portion thereof and a local model ID or a portion thereof. For example, one or more levels (e.g., those levels described herein as components of an AIML model identification) may correspond to a global part, while one or more other levels may correspond to a local part. In another example, a local model ID may correspond to a cell. In yet another example, a local model ID may correspond to a cell group / tracking area, etc. In another example, a part of the model ID may include a frozen model ID or a portion thereof and a trainable model ID or a portion thereof.

[0150] In one or more cases, the WTRU may be configured with rules that define which model ID or a portion thereof is to be used for which task. For example, to provide a capability indication (e.g., to provide an indication to another cell), the WTRU may use a global model ID or a portion thereof. In another example, to provide a capability indication (e.g., to provide an indication to the same cell after a long period of inactivity / after a transition from an idle state), the WTRU may use a local model ID or a portion thereof. In another example, for model transfer (e.g., from the WTRU to a gNB or another WTRU via a SL), the WTRU may use a global model ID or a portion thereof. In another example, for model training / retraining / fine-tuning (e.g., based on local data), the WTRU may use a local model ID or a portion thereof. In another example, for model switching (e.g., based on poor model performance measured by the WTRU or indicated to the WTRU by the NW), the WTRU may use a local model ID or a portion thereof.

[0151] In one or more cases, the WTRU may be configured with an association between multiple granularities of model IDs and / or rules on how to convert model IDs. The association may correspond to a mapping table that associates one type of model ID to another type of model ID. For example, the mapping table may associate mapping global model IDs to local model IDs and / or vice versa. The mapping table may, for example, include rules / configurations for the WTRU to convert between two or more formats of model IDs. For example, the rules / configurations may correspond to converting a model ID from local to global, or vice versa. For example, the rules / configurations may include removing a field with information corresponding to a cell ID to convert the model ID from "local" to "global". In another example, the rules / configurations may include adding a field with information about tracking areas / cell groups to convert the model ID from "global" to "local", and in this case, from local to cell groups. In another instance, the rules / configurations may include converting from global to local, or vice versa, which may change the format of the model ID (for example, in the case where the cell ID may be scrambled with an existing field in the global model ID to make the model ID local). In such cases, the WTRU may be configured with an association / mapping table to convert between the two types of Model IDs.

[0152] In one or more cases, the WTRU may report the start / end of the LCM component to the network. The start / end of the LCM component may include, for example, but not limited to, the start / end of training / retraining, the completion of a model switch, etc. In one or more cases, the WTRU may report the start / end of the LCM component to the network using one type of model ID. In some cases, the network may determine that the granularity of the report does not provide enough details and may request the WTRU to increase the granularity of the report. For example, the format of the local model ID may be shorter than the format of the global model ID, which may provide additional information to the network. The additional information provided may include, for example, but not limited to, training parameters such as the number of iterations before convergence, the training time, etc. In some cases, the WTRU may start reporting the end of training using the local model ID due to lower overhead. The WTRU may receive a request from the network to report future training-related processes (e.g., the start / end of training) using the global model ID including additional parameters about the training. The WTRU may switch from the local model ID to the global model ID to report the start / end of any subsequent processes related to model training. In one or more cases, the WTRU may receive a configuration from the network at a granularity for reporting the start / end / milestone of each process. The start / end / milestone of each process may include, for example, but not limited to, the end of training, the start of model monitoring, the percentage of model training completed (e.g., 80%), etc. In one or more cases, the WTRU may receive resources and / or configuration from the network to enable reporting at a granularity specified by the network. In one or more cases, the network may update the reporting granularity at any point in the process and transmit an indication to the WTRU.

[0153] The WTRU may be configured to determine the configuration of the registered AIML models for inference. Initial AIML model configuration may be performed at the gNB. The gNB may have an initial set of AIML models, which may be gNB-specific, region-specific, and / or global. The gNB may configure the AIML model for inference. The gNB may train the AIML model based on a data set at the gNB. The WTRU may receive a request from the gNB to report some parameters (e.g., transmit CSI report, beam index corresponding to the best Tx beam, etc.) to establish a training data set at the gNB and / or help train the AIML model at the gNB. Configuration for performance monitoring and mechanisms for falling back to traditional procedures (e.g., setting performance thresholds at the gNB) may be performed during the initial AIML model configuration. The initial model configuration may have an initial model ID (e.g., which may be set by the WTRU vendor) at the WTRU (e.g., the model may come from the WTRU vendor). The WTRU may be configured with rules to perform various stages of model registration as described herein.

[0154] The WTRU may determine to activate and / or deactivate the AIML model and transmit an indication to the gNB (e.g., via a MAC CE). The motivation for activation may include any of one or more determinations. For example, if the WTRU determines that the AIML model at the WTRU may provide better performance than traditional RAN procedures, the WTRU may determine to activate. For example, if the WTRU determines that the training of the AIML model has reached a convergence level for a specific configuration and is ready to be used / deployed, the WTRU may determine to activate. For example, if the WTRU (e.g., through an indication from the gNB) determines that the gNB may have an AIML model that can provide better performance than traditional RAN procedures, the WTRU may determine to activate, and the WTRU then requests a model transfer / download from the gNB. For example, if the WTRU has determined that using the AIML model can reduce overhead (e.g., a smaller number of reference signals from the gNB are required during inference / deployment, a smaller number of UL signaling (such as measurement reports) to be transmitted when the AIML model is adopted, etc.), the WTRU may determine to activate. For example, if the WTRU has decided to prioritize one RAN function associated with a given model over another RAN function for AIML operation, the WTRU may determine to activate. For example, if the WTRU is not configured with legacy RAN functions and requires an AIML model for RAN functionality, the WTRU may determine to activate.

[0155] The motivation for deactivation may include any of one or more determinations. For example, if the WTRU has determined that the model performance is below a performance threshold configured by the gNB, the WTRU may determine to deactivate. For example, if the WTRU has determined that the WTRU cannot handle the ML model training overhead (e.g., computation, training time, (re)training frequency), the WTRU may determine to deactivate. For example, if the WTRU has determined that the WTRU has deprioritized one RAN function associated with a given model over another RAN function for AIML operation, the WTRU may determine to deactivate (e.g., if the WTRU is limited in the number of AIML models it can support).

[0156] Activation / deactivation may be the final decision of the WTRU (eg, the WTRU stops using the model in case of deactivation and immediately starts using the model in case of activation upon determining to activate or deactivate the AIML model).

[0157] Activation / deactivation may be a request transmitted to the gNB and may become effective with a positive response from the network.

[0158] Activation / deactivation may be a request transmitted to the gNB and may become inactive if a negative response is received from the network (e.g., if the model is determined to be deactivated, the model remains active, or if the model is determined to be activated, the model remains inactive).

[0159] Activation / deactivation may be a request transmitted to the gNB and may become inactive if no positive response is received from the network within a given configured time.

[0160] Activation / deactivation may be a request transmitted to the gNB and may become effective if no negative response is received from the network within a given configured time.

[0161] Activation / deactivation may involve multiple models. For example, the MAC CE may be a bitmap field, where activation is indicated by 1 and deactivation is indicated by 0. A specific bitmap position may be pre-configured (assigned) to a specific model ID.

[0162] The response to the activation / deactivation request from the gNB can be a negative response or a positive response applicable to all indicated models.

[0163] The response to the activation / deactivation request from the gNB may be specific to each indicated model. For example, a response MAC CE may be transmitted by the gNB containing a bitmap in response to the received request MAC CE, where 0 indicates that the request has been rejected for the specific model ID associated with the bitmap field and 1 indicates that the request has been accepted for the specific model ID associated with the bitmap field.

[0164] The acceptance or rejection from the network may contain associated timing information (eg, activation allowed after x seconds / milliseconds). This timing information may be indicated for all models indicated in the request, or a different time may be specified / indicated for each model.

[0165] The time to wait before application activation or deactivation may be pre-configured before transmitting the activation / deactivation request. For example, the waiting time may be configured during the model registration, configuration and / or update process. The waiting time may be configured at the WTRU level and can be applied to all models.

[0166] An inhibit timer may be defined to limit the frequency of activation / deactivation. An inhibit timer may be for each activation / deactivation request, regardless of which model or models are being activated or deactivated, or there may be an inhibit timer associated with each model. The WTRU may start an inhibit timer when transmitting an activation / deactivation indication or request, and may not allow another activation / deactivation indication to be transmitted while the inhibit timer is running (e.g., for a selected model or models or all models, depending on whether the inhibit timer applies to all models or is specific to one model or a selected number of models). Different inhibit timers may be specified for transmitting consecutive deactivation indications / requests, for transmitting consecutive activation indications / requests, for transmitting an activation indication / request after a deactivation indication / request, or for transmitting a deactivation indication / request after an activation indication / request.

[0167] The gNB may also activate / deactivate AIML models due to similar motivations as those for the WTRU. The WTRU may then receive an indication from the gNB regarding the model activation / deactivation (e.g., via a MAC CE). As in the case of a WTRU-initiated activation / deactivation indication, the activation / indication message (e.g., MAC CE) may contain information about multiple models simultaneously (e.g., some activated, some deactivated). The indication may be accompanied by a time duration during which the activation / deactivation may be valid. The indication may be accompanied by a wait time after which the activation / deactivation becomes valid.

[0168] The network alone may activate / deactivate a given model. Alternatively, the WTRU alone may activate / deactivate a given model. Furthermore, both the WTRU and the network may activate / deactivate a given model. Some of the models may be activated / deactivated by the WTRU alone, some of the models may be activated / deactivated by the network, and some of the models may be activated / deactivated by both the WTRU and the network.

[0169] The WTRU may be configured to monitor the performance of AIML models. The WTRU may measure and / or report the performance of AIML models that are actively being used for inference. Unless otherwise configured by the gNB, the WTRU may monitor the performance of active AIML models by default. The WTRU may optionally be configured to perform performance monitoring on AIML models that are not currently being used for inference.

[0170] The WTRU may be configured to monitor the performance of an AIML model based on activation / deactivation signaling. A model identifier may identify the model for performance monitoring. The WTRU may be configured to report the performance of different AIML models. The WTRU may optionally indicate the model identifier in an associated performance report. A WTRU with AIML capability may receive configuration information from a gNB / NW to monitor model performance.

[0171] An AIML-capable WTRU may perform model performance monitoring for any one or more active AIML models. The WTRU may be configured by the network with a set of performance metrics (KPIs) including, but not limited to, normalized mean square error (NMSE), cosine similarity, etc.

[0172] The KPIs used by the WTRU may be specific to the RAN function for which the model is deployed. For example, under the beam management use case, one KPI may be the number of times there is a difference between the "best" beam predicted by the AIML model and the actual beam with the highest L1-RSRP measurement.

[0173] The WTRU may receive reference signals from the gNB to evaluate the performance of the AIML model (e.g., CSI-RS, SRS). For example, if the performance of the AIML model is managed by the gNB, the periodicity of receiving reference signals from the gNB may be determined by the gNB. In another example, if the model performance is managed by the WTRU and reported to the gNB, the WTRU may determine the periodicity of requesting reference signals from the gNB.

[0174] The WTRU may receive an explicit request from the gNB, based on which one or more KPIs are to be used for model monitoring as part of the performance monitoring configuration that the WTRU may receive from the gNB.

[0175] The WTRU may be configured with associations (eg, from a lookup table) that associate KPIs with scenarios / functions. For example, the model for CSI prediction may always be evaluated using cosine similarity.

[0176] The WTRU may receive a threshold corresponding to the received KPI from the gNB such that the model performance must exceed the threshold to be assigned a model version ID. The WTRU may still assign a model version ID to the AIML model, where the ID reflects the fact that the model does not meet the performance metric. The WTRU may assign an intermediate model version ID to the AIML model to reflect that the model performance is not within the standards acceptable to the gNB. The AIML model performance may not be reflected in the model version ID, so that if the model does not meet the performance threshold, the WTRU may transmit a separate indication to the gNB to report the poor performance.

[0177] The gNB may optionally be configured for performance monitoring of the AIML model and performance monitoring configurations (e.g., KPIs, methods for performance monitoring) that are not currently used for inference. An inactive AIML model may be a spare AIML model or a new AIML model that may be deployed in the future (e.g., making the model active).

[0178] The configuration received by the WTRU for performance monitoring and / or reporting may include situations when the WTRU capabilities have been exceeded (e.g., using multiple AIML models with high computational load). For example, the WTRU may be configured to evaluate / prioritize the RAN functions that benefit most from the AIML models. For example, the WTRU may select the AIML model with the best measured performance.

[0179] The WTRU may be configured to report performance results to the gNB after performance evaluation of the model. The WTRU may be configured to report performance after each evaluation moment. The WTRU may be configured to report results periodically with a periodicity set by the gNB. The WTRU may be configured to report performance only if performance drops below a pre-configured performance threshold. The WTRU may be configured to report performance if performance remains below a performance threshold for longer than a time threshold.

[0180] The WTRU may be configured to update the AIML model after WTRU-based online and / or offline training. The WTRU may receive an AIML model that the WTRU may train, retrain and / or update. Once the WTRU receives the AIML model, if the model has not been trained, the WTRU may train the model, or the WTRU may choose to directly use a pre-trained AIML model or retrain all or part of the received AIML model. In some cases, directly using a pre-trained AIML model may not result in an update to the model version ID. In some cases, any complete, partial training, retraining and / or update of the AIML model may result in an update to at least a portion of the model version ID.

[0181] The WTRU may determine that the received trained AIML model is not suitable for immediate direct use (e.g., the model may have been trained under different channel conditions). The WTRU may receive a trained AIML model together with some training parameters (e.g., the channel conditions, BWP, position, and velocity on which the model was trained). The training parameters may not constitute part of the model version ID. Instead, the AIML model may be shared with the training parameters, which together may constitute the AIML model configuration file. One or more training parameters may be incorporated into the model ID. For example, the most important training parameters may be incorporated into the model ID. If the WTRU training is performed in one frequency band (e.g., FR1), the AIML model may not deliver results in another frequency band (e.g., FR2). Thus, the frequency band may be a field incorporated into the model ID. The WTRU may determine to retrain the AIML model using suitable channel conditions and subsequently update the model version ID. The WTRU may determine to transmit the AIML model back to the gNB without making any updates to the model version ID.

[0182] Even if the received model may not be suitable for direct deployment, parts of the model may be directly used for inference and / or (re)training purposes. Any complete / partial (re)training of the model may result in an update of at least part of the model version ID.

[0183] The WTRU may assign different version numbers to different updates of the same AIML model. For example, the update may be caused by a training process (e.g., the AIML model needs to converge within a KPI threshold from the gNB in ​​order for the WTRU to assign a version number to the model). The AIML model may be trained, but convergence may not be achieved. In such cases, the AIML model may not be assigned a model version ID, or the model may be assigned an intermediate model version ID, depending on the configuration at the WTRU and / or instructions from the network.

[0184] After model training, retraining and / or updating, the WTRU may be configured to select a version number within the version number space configured by the gNB.

[0185] After model training, retraining and / or updating, the WTRU may be configured to request a new model version ID to be assigned to the trained, retrained and / or updated AIML model.

[0186] After model training, retraining and / or updating, the WTRU may assign a model version ID to the trained, retrained and / or updated AIML model and notify the gNB of the new version ID. In case of a conflict (whereby another WTRU may already be using the same version and / or a portion thereof), the WTRU may receive a request from the gNB to update the conflicting version number or a portion thereof.

[0187] The WTRU may be configured with a version number format that consists of more than one part, which may be of different types. For example, the different part types may include a static part and a dynamic part, a WTRU-specific part and a model-specific part, a global part and a local part, and / or a frozen part and a trainable part.

[0188] The WTRU may be configured to train and / or retrain a portion of an AIML model (e.g., a number of layers different from a baseline N-layer model (i.e., N1)). Once training at the WTRU is complete and an indication that training has been completed has been transmitted to the gNB, the gNB may transmit a request to the WTRU to transmit the AIML model or a portion thereof to the gNB. The WTRU may be requested to share the trained model parameters and some statistics about the training data conditions with the gNB. The training data conditions may include the channel conditions (e.g., Doppler spread, delay spread, number of multipaths, channel coherence time, channel coherence bandwidth, etc.) under which the model was trained. For example, if the WTRU has already trained and / or utilized an existing AIML model received from the gNB, and a portion of the base model received from the gNB (e.g., the last N1 layers) has been trained, while other layers (e.g., the first N-N1 layers) remain constant or frozen, the WTRU may indicate to the gNB that only a portion of the AIML model is to be retrained and the weights corresponding to the trained layers (e.g., the last N1 layers) are shared.

[0189] After training, retraining and / or updating a portion of the AIML model, the WTRU may be configured to update the entirety or a portion (e.g., only certain fields) of the model version ID and transmit it back to the gNB / NW.

[0190] After training, retraining and / or updating a portion of an AIML model, the WTRU may transmit an indication that training has been performed and the original version ID of the AIML model to the gNB, which is responsible for updating the model version ID and / or assigning a new / updated model version ID to the trained AIML model or portion thereof. Part of the indication may include metadata about the AIML model (e.g., updated number of layers) and metadata about the training conditions (e.g., channel conditions).

[0191] The WTRU may be configured to update the AIML model after joint WTRU-gNB training. The WTRU may update its AIML model based on joint training with a peer AIML model at the gNB. If the joint training is successful, the WTRU may receive an updated model identification from the gNB. The WTRU may be configured to reuse the same model ID used before the joint training. If the model ID remains the same before and after the joint training, the WTRU may be configured to delete the old AIML model. If the gNB indicates that the joint training is successful, the WTRU may implicitly assume that the model registration is successful.

[0192] The WTRU may be configured to handle model registration during model transfer from the NW. For example, the WTRU may receive one or more AIML models from the gNB / network. The WTRU may be configured to perform model validation upon receiving the AIML model from the gNB. The WTRU may indicate the result of the model validation to the network. Upon successful model validation, the WTRU may receive an AIML model identity assignment for the transferred AIML model.

[0193] The WTRU may be configured to handle AIML model registration during an AIML model transfer from an external server. For example, the WTRU may receive one or more AIML models from a WTRU vendor. The WTRU vendor may add a new AIML model, or an existing AIML model may be updated / replaced with a new AIML model. In both cases, the WTRU may be configured to initiate a model registration process. The WTRU may indicate the type of registration (e.g., new or updated). An example registration process may involve capability exchange, model validation, and / or model ID assignment, as described herein.

[0194] The WTRU may be configured for AIML model registration, AIML model performance monitoring, AIML model activation and / or deactivation, AIML model selection and / or AIML model suitability. The WTRU may be configured for AIML model registration, which may include one or more of capability exchange, AIML model validation, and AIML model identity assignment. The WTRU may be configured to configure the registered AIML model for inference. The WTRU may be configured for performance monitoring of the AIML model. The WTRU may be configured to handle model registration after model update. The WTRU may be configured to handle model registration during model transfer from the NW. The WTRU may be configured to handle model registration during model transfer from an external server.

[0195] Local may correspond to basic information that identifies an AIML model. The local LCM phase reports basic information at the identification (ID) granularity that may identify the functionality of the AIML and / or the version of the AIML model relative to a reference model. For example, a local identifier may identify a model with respect to a cell and / or a group of cells and / or a tracking area and may involve lower overhead than its global model ID counterpart.

[0196] The global LCM phase report ID granularity may include basic information for uniquely identifying an AIML model and additional information corresponding to the AIML model. For example, the global model ID may contain additional information / details to enable unique identification of the model (e.g., at the network). Therefore, the global model ID may be longer and / or consist of a larger number of fields than the local model ID.

[0197] The additional information at the global LCM phase report ID granularity may correspond to one or more of RAN functions / sub-functions, (sub)functionality, (sub)features, feature groups, use cases, scenarios, training and / or layer groupings within the AIML model.

[0198] The additional information may correspond to an association between the AIML model and one or more other AIML models.

[0199] The additional information may also correspond to a specific layer within the AIML model.

[0200] For example, the additional information at the global LCM stage report ID granularity may correspond to a defined cell area or tracking area in which the WTRU may implement the AIML model and / or any information that allows unique identification of the model, such as information about any one or more of the following: model input (type / format / size), model output (type / format / size), model vendor information, model version, AIML capabilities required to deploy the model, applicable scenarios / configurations / sites for training the model / where the model can be deployed, the computational complexity of the model (e.g., FLOPs, pre-processing / post-processing levels), model size, model performance, model functionality, model monitoring methods, etc.

[0201] The WTRU may receive an indication to switch from lower granularity reporting of AIML LCM phase feedback to higher granularity reporting of AIML LCM phase feedback.

[0202] For example, the WTRU may receive an indication to switch from the local LCM phase report ID granularity to the global LCM phase report ID granularity for subsequent reporting of the AIML LCM phase. The WTRU may use the new higher granularity for subsequent reporting of the AIML LCM phase.

[0203] Switching to a global LCM stage reporting identification (ID) granularity may require additional resources to report on one or more AIML LCM stages compared to a local LCM stage reporting ID granularity.

[0204] For example, an indication received by the WTRU to switch to a global LCM phase reporting ID granularity may be necessary because some AIML LCM phases require additional information to be reported while other AIML LCM phases do not.

[0205] As another example, an indication received by the WTRU to switch to a global LCM phase reporting ID granularity may correspond to a switch in the AIML LCM phase of the AIML model implemented on the WTRU. For example, the UE may use a local model ID to report LCM phase feedback (e.g., model training start / end, model monitoring start / end, model switching, model activation / deactivation, etc.). After receiving an indication to switch reporting granularity (e.g., switching from local ID-based reporting to global ID-based reporting), the UE may switch to using a global model ID to report subsequent LCM phase feedback (e.g., to the network).

[0206] Figure 3 is a process diagram illustrating an example for indicating the granularity of AIML LCM phase report IDs.

[0207] At 302, the WTRU sends a capability indicator to the gNB. The capability indicator may include the AIML capability of the WTRU.

[0208] The WTRU receives configuration information from the gMB at 304. The configuration information may define an AIML LCM phase reporting ID granularity for reporting one or more AIML LCM phases of an AIML model.

[0209] For example, the configuration information may define a local LCM phase reporting identification (ID) granularity and a global LCM phase reporting ID granularity for reporting any one of one or more AIML LCM phases of the AIML model.

[0210] For example, the AIML LCM phase of an AIML model may include model training, model monitoring, model switching, and model activation or deactivation.

[0211] At 306, the WTRU receives an indication of the handover LCM phase reporting ID granularity from the gNB.

[0212] For example, this indication may be used for the WTRU to switch from a local LCM phase reporting ID granularity to a global LCM phase reporting ID granularity for reporting AIML LCM phase feedback.

[0213] At 308, the WTRU sends a LCM Phase Report ID Granularity Switch Confirm message to the gNB.

[0214] For example, an ID granularity switch confirmation message to the gNB may confirm the switch from local LCM phase reporting ID granularity to global LCM phase reporting ID granularity for reporting any one of one or more AIML LCM phases.

[0215] Figure 4is a flow chart illustrating an example method for implementing AIML LCM phase report ID granularity.

[0216] In step 402, the WYRU receives configuration information including information about one or more AIML LCM phases of an AIML model and information about LCM phase report identification (ID) granularity for the one or more AIML LCMs.

[0217] One or more of the AIML LCM phases may include training, monitoring, switching, and activation / deactivation of an AIML model. LCM phase report ID granularity may provide granularity for information reported on each AIML LCM phase. Information about AIML LCM phase report ID granularity may define a local LCM phase report ID granularity and a global LCM phase report ID granularity for reporting on one or more AIML LCM phases.

[0218] The local LCM phase report ID granularity includes basic information identifying the AIML model. The basic information may correspond to the function of the AIML model, or to the version of the AIML model relative to the reference model.

[0219] The global LCM phase report ID granularity includes basic information identifying the AIML model and additional information corresponding to the AIML model. The additional information may correspond to a RAN function / sub-function, a use case, a scenario, a training, or a layer group within the AIML model. The additional information may correspond to an association between the AIML model and one or more other AIML models and / or layers of the AIML model.

[0220] For example, the additional information may correspond to layers of the AIML model, indicating a first number of layers that are unchanged / frozen and a second number of layers whose weights can be updated as a result of training.

[0221] Due to the different granularity of the reported information, the global LCM phase report ID granularity is configured to utilize a different amount of resources than the local LCM phase report ID granularity. For example, the global LCM phase report ID granularity may be configured to utilize a greater amount of resources than the local LCM phase report ID granularity.

[0222] In step 404, the WTRU sends feedback for the first AIML stage of the AIML model using the first LCM stage reporting granularity.

[0223] In step 406, the WTRU receives an indication to switch to a global LCM phase reporting ID granularity for reporting on one or more AIML LCM phases.

[0224] In step 408, the WTRU sends an LCM Phase Report ID Granularity Switch Confirm message.

[0225] In step 410, the WTRU sends feedback for the second AIML LLCM stage of the AIML model using the global LCM stage report ID granularity.

[0226] Although the features and elements are described above in particular combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information including information about one or more artificial intelligence / machine language (AIML) lifecycle management (LCM) phases associated with an AIML model and information about a local LCM phase reporting identification (ID) granularity and a global LCM phase reporting ID granularity for reporting on the one or more AIML LCM phases, wherein the global LCM phase reporting ID granularity is configured to utilize a different amount of resources than the local LCM phase reporting ID granularity; sending feedback for a first AIML LCM stage of the AIML model using the local LCM stage report ID granularity; receiving an indication to switch to the global LCM phase reporting ID granularity for reporting on the one or more AIML LCM phases; Sending LCM phase report ID granularity switching confirmation message; and Feedback for a second AIML LCM stage of the AIML model is sent using the global LCM stage report ID granularity. 2 . The method of claim 1 , wherein the one or more stages in the AIML LCM stage include training, monitoring, switching, and activation / deactivation of the AIML model.

3. The method according to claim 1 or 2, wherein the local LCM stage report ID granularity corresponds to basic information identifying the AIML model.

4. The method according to any one of claims 1 to 3, wherein the global LCM stage report ID granularity includes basic information identifying the AIML model and additional information corresponding to the AIML model.

5. The method according to claim 3 or 4, wherein the basic information identifies the function of the AIML model.

6. The method according to claim 3 or 4, wherein the basic information identifies the version of the AIML model relative to a reference model.

7. The method of claim 4, wherein the additional information corresponds to one or more of RAN functions / sub-functions, use cases, scenarios, and training.

8. The method of claim 4, wherein the additional information identifies an association between the AIML model and one or more other AIML models.

9. The method of claim 4, wherein the additional information includes information corresponding to layer groupings within the AIML model. 10 . The method of claim 9 , wherein the additional information corresponding to the layers of the AIML model indicates a first number of unchanged / frozen layers and a second number of layers whose weights can be updated as a result of training.

11. A wireless transmit / receive unit (WTRU), comprising: A processor, the processor being configured to: receiving configuration information including information about one or more artificial intelligence / machine language (AIML) lifecycle management (LCM) phases associated with an AIML model and information about a local LCM phase reporting identification (ID) granularity and a global LCM phase reporting ID granularity for reporting on the one or more AIML LCM phases, wherein the global LCM phase reporting ID granularity is configured to utilize a different amount of resources than the local LCM phase reporting ID granularity; sending feedback for a first AIML LCM stage of the AIML model using the local LCM stage report ID granularity; receiving an indication to switch to the global LCM phase reporting ID granularity for reporting on the one or more AIML LCM phases; Sending LCM phase report ID granularity switching confirmation message; and Feedback for a second AIML LCM stage of the AIML model is sent using the global LCM stage report ID granularity.

12. The WTRU of claim 11, wherein the one or more phases in the AIML LCM phase include training, monitoring, switching, and activation / deactivation of the AIML model.

13. The WTRU according to claim 11 or 12, wherein the local LCM phase report ID granularity includes basic information identifying the AIML model.

14. The WTRU according to any one of claims 11 to 13, wherein the global LCM phase report ID granularity includes basic information identifying the AIML model and additional information corresponding to the AIML model.

15. The WTRU of claim 13 or 14, wherein the basic information identifies a function of the AIML model.

16. The WTRU of claim 13 or 14, wherein the basic information identifies a version of the AIML model relative to a reference model.

17. The WTRU of claim 14, wherein the additional information corresponds to one or more of a RAN function / sub-function, a use case, a scenario, and training.

18. The WTRU of claim 14, wherein the additional information identifies an association between the AIML model and one or more other AIML models.

19. The WTRU of claim 14, wherein the additional information includes information corresponding to layer groupings within the AIML model.

20. The WTRU of claim 19, wherein the additional information corresponding to the layers of the AIML model indicates a first number of layers that are unchanged / frozen and a second number of layers whose weights can be updated as a result of training.

Images