Systems and methods for enabling adaptative in-time selection and distribution of artificial intelligence / machine learning models in a wireless system

Abstract

A wireless transmit / receive unit (WTRU) may send a message. The WTRU may send the message to a network, for example to an artificial intelligence (AI) machine learning (ML) enabler server. The message may include an indication of a request for an AIML model update. The request may include an identifier (ID) associated with the WTRU and / or AIML model data. The AIML model data may include an indication of an objective associated with the AIML model, an indication of a performance characteristic associated with the AIML model, and / or an AIML model ID. The WTRU may receive a response, for example from the network. The response may include a subscription ID associated with the AIML model.

Description

SYSTEMS AND METHODS FOR ENABLING ADAPTATIVE IN-TIME SELECTION AND DISTRIBUTION OF ARTIFICIAL INTELLIGENCE / MACHINE LEARNING MODELS IN A WIRELESS SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Application No. 63 / 574,426 filed on April 04, 2024, the entire contents of which are incorporated herein by reference.BACKGROUND

[0002] Artificial Intelligence and Machine Learning technology is becoming ubiquitous in computing. AIML usage is ever-expanding to new technological spaces.

[0003] One such technological space is wireless networking. Capabilities of new wireless User Equipment (WTRU) may be augmented with the addition of one or more of dedicated hardware for executing AIML workloads, new functional elements of the wireless system core defined for supporting AIML technology, and / or an AIML enablement layer for mobile application and servers are being defined.SUMMARY

[0004] A wireless transmit / receive unit (WTRU) may determine to access an AIML model distribution function (AMDF) service, for example from a network. The WTRU may send a message to the network. The message may include a request for artificial intelligence machine learning (AIML) information. The message may include one or more of a WTRU identifier, AIML application characteristics, AIML WTRU capabilities, and / or AIML model characteristics. The WTRU may receive a response, for example from the network. The response may include information associated with an AIML model. The WTRU may select the AIML model.

[0005] The WTRU may store the information associated with the AIML model, for example in a (e.g., local) memory. The WTRU may determine if one or more conditional AIML models are available, for example based on the information associated with the AIML model. The WTRU may send a (e.g., second) message, for example to an AIML application. The (e.g., second) message may include an indication of availability of an AIML model. The WTRU may determine to revoke selection of the AIML model, for example based on the information associated with the AIML model and / or a message received from the network.

[0006] The WTRU may determine to access the AMDF service, for example based on an AIML application request. The WTRU may determine to establish connectivity and / or select the AIMLmodel based on requirements for fetching the AIML model. The information associated with the AIML model may include AIML model family information. Additionally, or alternatively, the information associated with the AIML model may include one or more of data for the AIML model, connectivity information for the AIML model, or requirements for fetching the AIML model.

[0007] A WTRU may send a message. The WTRU may send the message to a network, for example to an AIML enabler server. The message may include an indication of a request for an AIML model update. The request may include an identifier (ID) associated with the WTRU and / or AIML model data. The AIML model data may include an indication of an objective associated with the AIML model, an indication of a performance characteristic associated with the AIML model, and / or an AIML model ID. The WTRU may receive a response, for example from the network. The response may include a subscription ID associated with the AIML model. The response may include AIML model data and / or information for fetching the AIML model. The WTRU may fetch the AIML model, for example based on the AIML model data and / or the information for fetching the AIML model.

[0008] The AIML model may be a first AIML model. The WTRU may receive an indication that a second AIML model is available. For example, a network may determine that the second AIML model is available at a model repository. The network may determine that the second AIML model is available at a model repository based on the AIML model data. The network may send a discovery request, for example to the model repository, for example in response to the request for the AIML model update. The discovery request may include an indication of the AIML model data.

[0009] The response may additionally, or alternatively, include the AIML model. The WTRU may determine a validity of the AIML model, for example based on a memory requirement associated with the AIML model. The subscription ID may be associated with a model repository. The response may additionally, or alternatively, include AIML model data associated with the model repository.

[0010] The objective associated with the AIML model may indicate what the model is used for, an output of the model, and / or a purpose of the model. The AIML model may be trained to meet the objective and / or provide an estimate associated with the objective associated with the AIML model. The performance characteristic associated with the AIML model may include accuracy of the AIML model. The AIML model may be trained to meet the performance characteristic and / or provide an estimate associated with the performance characteristic associated with the AIML model.

[0011] The Al ML model data may include operation information associated with the Al ML model and / or associated with the WTRU. The AIML model data may include information for discovering the AIML model and / or an indication of a memory requirement associated with the AIML model. The AIML model data may include an indication of a usage requirement associated with the AIML model. The usage requirement associated with the AIML model may additionally or alternatively be associated with the objective, the performance characteristic, a model type of the AIML model, an availability associatedBRIEF DESCRIPTION OF THE DRAWINGS

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

[0013] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0014] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0015] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0016] FIG. 2 shows a diagram of an AIML model system and method.

[0017] FIG. 3 shows an example of an AIML model selection and distribution.

[0018] FIG. 4 shows another example of an AIML model selection and distribution.

[0019] FIG. 5 shows another example of an AIML model selection and distribution.

[0020] FIG. 6 shows an example procedure for supporting the AMDF capabilities at WTRU registration.

[0021] FIG. 7 shows an example procedure for supporting the AMDF capabilities at WTRU subscription.

[0022] FIG. 8 shows an example procedure for supporting AMDF events for model distribution.DETAILED DESCRIPTION

[0023] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may bea multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division 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, filter bank multicarrier (FBMC), and the like.

[0024] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU. Further, any description herein that is described with reference to a UE may be equally applicable to a WTRU (or vice versa). For example, a WTRU may be configured to perform any of the processes or procedures described herein as being performed by a UE (or vice versa).

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

[0026] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e. , one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0028] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 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 establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

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

[0032] 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), GSM EDGE (GERAN), and the like.

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

[0034] 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 internetprotocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 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 be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0038] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0040] Although the transmit / receive element 122 is depicted in FIG. 1 B 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.

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

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

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

[0044] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0045] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touchsensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0047] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

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

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

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

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

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

[0054] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0055] Although the WTRU is described in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0056] In representative embodiments, the other network 112 may be a WLAN.

[0057] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) thesource and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0058] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every ST A), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0059] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0061] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11 ah relative to those used in 802.11 n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representativeembodiment, 802.11ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0062] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0063] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

[0064] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an 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.

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

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

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

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

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

[0070] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. 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.

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

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

[0073] 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 serves 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 the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0074] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0076] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry(e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0077] Systems and methods may describe one or more of AIML model selection, AIML model distribution, and / or AIML model performance monitoring. One or more of in-time selection and distribution of AIML models, adaptative selection and distribution of AIML models, and / or WTRU registration, AIML model update subscription and notification may be described herein. Systems and methods may include an AIML model distribution function (AMDF). AMDF capability may be determined and / or offered as a service, for example in the 5G core network and / or as an application enablement layer. The AMDF may provide capabilities to adaptatively select and / or distribute AIML models, for example to a WTRU based on one or more of the WTRU context, environment, and / or tasks.

[0078] An AIML application may describe an application that uses an AIML model to perform a task. The terms AIML application and application may be used interchangeably herein. An AIML application may be locally stored, executing (e.g., self-executing), and / or associated with a WTRU.

[0079] A WTRU may determine the need for using the AMDF service, for example from the network. The WTRU may determine (e.g., as in FIG. 6) the need for using the AMDF service, for example based on local information. Local information may include configuration, application manifests and / or registry, etc. The WTRU may determine (e.g., as in FIG. 7) the need for using the AMDF service, for example based on an AIML application request.

[0080] The WTRU may send a message to the network. The message may include an indication of AIML WTRU requirements. The message may be a WTRU registration request, for example sent to the AMF (e.g., as in FIG. 6). The message may be an adaptative model update subscribe request (e.g., a subscription request for adaptative updates of AIML models), for example sent to the AIML enabler server (e.g., as in FIG. 7). The WTRU requirements may include one or more of the WTRU identifier, the WTRU AIML application characteristics, the AIML WTRU capabilities, and / or the AIML model characteristics (e.g., as herein)

[0081] The WTRU may receive a message, for example from the network. The message may include an indication of AIML model information. The message may be a registration accept request, for example from the AMF (e.g., as in FIG. 6). The message may be an adaptative model update subscribe response (e.g., a subscription response for adaptative updates of AIML models) from the AIML enabler server (e.g., as in FIG. 7). The message may be an adaptative model update notification (e.g., a notification for adaptative updates of AIML models), for example from the AIML enabler server (e.g., as in FIG. 8).

[0082] The Al ML model information may include information about the selected Al ML model(s) for the WTRU, for example including one or more of AIML model data, connectivity information for fetching the selected AIML models for the WTRU, and / or requirements for fetching the selected AIML model (e.g., as herein). The AIML model data may include one or more of the AIML model, the AIML model type, the AIML model version, the AIML model family, the AIML model associated application identifier, the AIML model validity criteria, the AIML model requirements and characteristics, and / or the AIML model performance characteristics (e.g., as described herein).

[0083] The WTRU may store, evaluate, establish connectivity, fetch, revoke an AIML model, and / or notify an AIML application, for example based on the AIML model information received. The WTRU may store the information (e.g., locally), for example for future use. The WTRU may determine if AIML models for the WTRU are available, for example based on fetching requirements. The WTRU may monitor context and / or tasks, for example based on conditional fetching requirements. The WTRU may determine if conditional AIML models for the WTRU are available. The WTRU may determine to establish connectivity and / or fetch an AIML model, for example based on the determination of fetching requirements and / or conditional fetching requirements. The WTRU may notify an AIML application about the availability of an AIML model for the WTRU. The WTRU may revoke an AIML model for the WTRU, for example based on the received AIML model information.

[0084] FIG. 2 shows a diagram of an example AIML model 200 system and method. Data collection may be performed. For example, a data source 202 may provide data for data collection at 204. Data collection may include gathering data relevant to training an AIML model, for example based on the goals and / or objectives of the model. Data collection may additionally, or alternatively, include capturing data from multiple sources and / or may result in high volumes of data. The captured data may be stored in data storage 220, for example to facilitate access during the data preparation stage of the AIML model lifecycle.

[0085] The collected data may be analyzed and / or prepared at 206, for example for training the AIML model. Since AIML model performance (e.g., the quality and accuracy of the model’s predictions or outputs) may be related to the quality of the data used to train the model, data may be curated before training the model. For example, data analysis and / or preparation may include data curating. Curating a dataset may include identifying flaws associated with the dataset, such as for example identifying bias and imbalance, inaccuracy, relevancy (e.g., to the model objective), and / or missing data. The curated dataset may be stored in data storage 220,for example to facilitate access during the model training stage of the Al ML model lifecycle. The data storage 220 may include one or more storage media.

[0086] An algorithm and / or model may be trained at 208. The algorithm and / or model may be developed and / or selected, for example based on the curated dataset and / or the AIML goal and / or objective. Additionally, or alternatively, parameters (e.g., hyperparameters) may be configured to influence algorithm and / or model training for obtaining optimal performance. Iterating with different hyperparameters may be utilized, for example to obtain optimal performance and / or to develop a set of models with distinctive characteristics. Requirements for the model operation and / or deployment may be determined at algorithm and / or model training. The trained model may be stored in a model storage 210, for example to facilitate access during the model distribution stage of the AIML model lifecycle.

[0087] The trained AIML model may be deployed on one or more computer systems (e.g., AIML model consumer), for example for performing inference and / or producing predictions and / or outputs. The trained AIML model may be deployed to a focus area 212. The focus area 212 may include one or more model consumers 214. For example, the one or more model consumers 214 may include one or more WTRUs and / or network entities.

[0088] At 216 the trained AIML model may be distributed. During the model distribution stage for example, the model may be obtained and / or selected from AIML model storage 210 and / or may be transmitted to a AIML model consumer 214 for executing inference or prediction.

[0089] The AIML model predictions and / or outputs may be monitored at 218, for example to determine any degradation of predictions and / or outputs. Additionally, or alternatively, the AIML model predictions and / or outputs may be monitored to achieve a desired (e.g., the best and / or a threshold) system performance. The monitored predictions and / or outputs may be stored in a data repository, for example to facilitate the evaluation of the model performance over a period of time and / or under changing conditions. For example, the data repository may include the data storage 220.

[0090] AIML model distribution 216 and AIML model monitoring 214 (e.g., of an AIML model lifecycle) are discussed herein. AIML model distribution and AIML model monitoring may be related to one or more of how to adaptatively select and distribute AIML models to a WTRU (e.g., an AIML model consumer), how to trigger the selection and distribution of the AIML model, and / or how to ensure on-time delivery of the selected AIML model to the WTRU when the AIML model needs to be changed or updated (e.g., for example using a different AIML model, using a new AIML model version).

[0091] Systems and methods may include a predictive wireless network. The predictive wireless network may include a wireless network that has prediction capabilities. Prediction performed by a wireless network may be based on one or more network features. Example network features may include one or more of external parameters provisioning and / or network data analytics service. Predictive capabilities of the wireless network, as described herein, may be used to support and / or improve triggering for AIML model distribution to a WTRU. Although the predictive capabilities of the network may rely on using AIML models in the network in some examples, there may be no procedure defined for a network to select and / or distribute AIML models to a WTRU in an adaptative manner.

[0092] There may be external parameters provisioning. An application function (AF) may provide the network with predictive information (e.g., external parameters), which for example may be stored in a unified data management (UDM)Zunified data repository (UDR). The provided predictive information may be associated with and / or include WTRU behavioral information, such as for example information on expected WTRU movement and / or communication characteristics. Expected WTRU behavior parameters may be supported by the 5G core (5GC) and / or may be considered (e.g., include) predictive behavioral parameters.

[0093] Expected WTRU moving trajectory may identify the WTRU's expected geographical movement or path of movement. Communication duration time may indicate how long the WTRU is expected to stay in connection management (CM)-CONNECTED state for data transmission. Periodic time may indicate the expected interval time for periodic communication. Scheduled communication time may indicate the expected time and / or day of the week when the WTRU is available for communication. Scheduled communication type may indicate the expected communication type (e.g., downlink, uplink, or bi-directional). Expected time and day of week in trajectory may identify the time and day of week when the WTRU is expected to be at each location included in the expected WTRU moving trajectory.

[0094] Additionally, or alternatively, an (e.g., each) expected WTRU behavior parameter may have an associated confidence and / or accuracy level. Since WTRU predictive information may be provided by an AF, the performance and / or accuracy of the AF prediction may be based on (e.g., highly dependent on) the AF predictions which, for example may be based on an AIML model.

[0095] The 5GC (e.g., AMF and / or SMF) may use the expected WTRU behavior parameters for improving network behavior and / or performance. For example, the 5GC may select one or more RAN parameter values based on expected WTRU behavior.

[0096] There may be a network data analytics service. The 5GC may provide a network data analytics service, for example based on a network data analytics function (NWDAF) functional entity. Functional elements utilized by (e.g., needed by) the network data analytics service may be included in the 5G system (5GS) architecture.

[0097] The NWDAF and / or its related functional elements may provide capabilities , for example for one or more of collecting and storing network analytics, training models with goals and objectives related to network operation, performing federated learning, and / or storing trained models.

[0098] The network data analytics service may include one or more capabilities for exposing collected analytics and / or prediction outputs. For example, the network data analytics service may expose collected analytics and / or prediction outputs to the network function, to an application function directly, and / or via a network exposure function (NEF). Data analytics that may be provided by the NWDAF are provided herein.

[0099] Network performance analytics may provide statistics and / or predictions on one or more of the gNB status, gNB resource usage, communication performance, and / or mobility performance in an area of interest. Additionally, or alternatively, statistics and / or predictions on the number of WTRUs located in an area of interest may be provided. WTRU-related analytics may provide statistics and / or predictions on one or more of WTRU mobility, WTRU communication, expected WTRU behavioral parameters, and / or abnormal WTRU behavior. User data congestion analytics may provide statistics and / or predictions on congestion experienced. For example, statistics and / or predictions on congestion experienced may be while transferring user data over the control plane and / or user plane, and / or may be related to a specific area.

[0100] New challenges may emerge from new capabilities. One such challenge may be related to increasingly diverse and complex AIML models, for example that may utilize ever-increasing storage space. With limited storage and other resources in a WTRU, it may be difficult to preload all candidate AIML models. Systems and methods for in-time adaptative selection and / or distribution of AIML models are disclosed herein.

[0101] A space-saving (e.g., storage saving) strategy may include using a smaller AIML model that, for example may be valid in certain WTRU contexts. For example, the AIML model may be valid in a given area. The AIML model may (e.g., dynamically) replace an AIML model, for example as the WTRU context changes. Multi-functional WTRU(s) may dynamically replace AIML model(s), for example in response to AIML tasks performed and / or their environment (e.g., context) variations.

[0102] To benefit from the usage of AIM L technology for example, wireless networks may provide capabilities for distributing AIML model(s) to WTRU(s), and / or assist in determining context changes for triggering model selection and distribution. The wireless network may distribute the AIML model(s) to WTRU(s) that request the AIML model(s) and / or that the wireless network determines to distribute the AIML model(s).

[0103] AIML model(s) may not be instantaneously distributed to a WTRU, for example due to the AIML model size and / or network congestion caused by a high WTRU density in a given area. Context and task prediction capabilities may be utilized to ensure the on-time distribution of the AIML models (e.g., considering transfer time of AIML model(s) and / or network congestion and / or concurrent distribution to several WTRUs in an area).

[0104] There may be a challenge (e.g., a first challenge) related to determining how and / or on what basis to trigger the distribution of an AIML model. There may be a challenge e.g., a second challenge) related to determining how and / or on what basis to perform the selection of candidate AIML models for distribution. There may be a challenge (e.g., a third challenge) related to determining how to provide consistency and / or predictability for the distribution of AIML models on time. The solutions described herein may describe functions and / or information flows needed to provide adaptative in-time selection and / or distribution of AIML model(s) in a wireless system.

[0105] Adaptative in-time selection and / or distribution of AIML models may enable a WTRU to adaptatively use AIML models, for example according to tasks and / or WTRU context.

[0106] WTRU capacity may be improved by distributing smaller AIML models (e.g., the WTRU may be able to concurrently use more AIML models for performing different tasks). AIML model performance may be improved by using less complex and / or smaller models, for example that may be valid in some contexts.

[0107] Systems and methods as herein may describe an AIML model distribution function (AMDF) capability. An AMDF capability may be implemented as a service. For example, AMDF functionality may be implemented as a standalone service. The standalone service may include one or more of an application function (AF), a network function (NF), an AMDF NF, and / or AIML enablement server AF. Additionally, or alternatively, AMDF may be implemented as an extension to an existing service.

[0108] Systems and methods as herein may be included in (e.g., added to) the 5G core network and / or to the AIML enablement layer. Systems and methods may help (e.g., an identified need for) AIML model selection and / or distribution. Capabilities for adaptatively selecting and / ordistributing AIML models to a WTRU may additionally, or alternatively, be utilized in distributing AIML models to an application function and / or to a network function (e.g., as described herein).

[0109] The AMDF may provide a service enabling selection and / or distribution of AIML models to a WTRU, for example based on the WTRU tasks and / or context. The AMDF may ensure timely distribution of the AIML model. AMDF functional entity, procedures, and / or information flows may be discussed herein.

[0110] The AMDF may offer a service for the selection and / or distribution of AIML models, for example to a WTRU. The determination of AIML models distributed to a WTRU may be based (e.g., dependent) on WTRU conditions. The WTRU conditions may include one or more of a task performed by a WTRU, the environment and / or context of a WTRU, and / or the network environment and / or capabilities. Model selection and / or distribution may be adaptative.

[0111] The AMDF functionality may be implemented as a standalone application function (AF) and / or as a network function (NF). The AMDF functionality may be combined with an existing AF and / or NF. An application programming interface (API) may be offered as an extension of an existing API.

[0112] The AMDF service may be offered using a communication protocol. For example, a hyper text transfer protocol (HTTP) and / or the non-access stratum (NAS) protocol for 5G systems may provide the capabilities for offering the AMDF service.

[0113] Providing AMDF capabilities in a wireless network may present advantages, for example as described herein. For example, providing AMDF capabilities in a wireless network may result in coordination of AIML model distribution to several WTRUs. For example, AIML models may be delivered to WTRU(s) quickly (e.g., on time) and / or may prevent network congestion. An example capability may leverage network prediction of a WTRU context. The AMDF may use WTRU location prediction capabilities of the wireless network to determine to trigger model distribution to a WTRU, for example before the WTRU reaches a location. The AMDF may associate a predicted location with coordination of AIML model distribution, for example such that distribution planning to a group of WTRU may be accomplished without causing network congestion. The AMDF may choose to trigger the distribution of an AIML model, for example based on predicted network congestion. The AMDF may predict network congestion using network congestion prediction capabilities of the NWDAF for example.

[0114] Providing AMDF capabilities in a wireless network may result in decreasing and / or minimization of the complexity of applications, for example by automating model distribution and / or (e.g., while) providing visibility to network operators about the AIML operations being used with the network. An AIML model distribution service may provide one or more ofconsistent, predictable, and / or reliable model distribution, for example resulting in a better user experience. The visibility provided by an Al ML model distribution service may additionally, or alternatively, provide opportunities for improved network planning and / or better enforcement of regulatory compliance.

[0115] FIG. 3 shows an example of an AIML model selection and distribution 300. Model selection and distribution may be a model selection and distribution lifecycle, for example at WTRU startup. At 302 the WTRU may startup. At startup for example, the model (e g., no model) may be at the WTRU. Power may be applied to the WTRU, which for example may allow the WTRU to begin a bootstrapping process. The bootstrapping process may include one or more of finding a suitable network and / or cell to attach to, starting the kernel, and / or starting the operating system and registration to the network.

[0116] At 304 the WTRU may scrub application information and / or register with a network. The WTRU may perform registration with the network (e.g., the AMF) and / or provide an indication about AIML WTRU requirements. The WTRU may determine AIML WTRU requirements, for example including the need for AIML applications present on the WTRU and / or including the need for in-time AIML model selection and / or distribution. For example, the WTRU may scrub one or more of manifests information, configurations information, and / or registry information associated with applications, for example to determine the need for in-time AIML model selection and / or distribution and information about required AIML models.

[0117] The AMDF may be informed about the application requirements for AIML models needed and / or requested by applications on the WTRU. The AMDF may select and / or distribute the required AIML models to the WTRU. For example, the AMDF may store the WTRU provided information in the UDM / UDR. The AMDF may be notified of WTRU requirements by the UDM.

[0118] At 306 the WTRU may receive one or more AIML model, for example one or more selected (e.g., by the AMDF) AIML model. At 308 the WTRU may store (e.g., locally) the one or more AIML models selected and / or distributed by the AMDF. The WTRU may notify any applications determined, for example, of the availability of the selected and / or distributed AIML models.

[0119] FIG. 4 shows another example of an AIML model selection and distribution 400. Model selection and distribution may be a model selection and distribution lifecycle, for example at application startup. An AIML application may start. At 402 the WTRU may detect AIML application startup. For example, the AIML model may be present on the WTRU. The WTRU may detect that the AIML application execution has begun and / or determine the application AIML requirements (e.g., manifest, configuration, and / or registry information). Alternatively, oradditionally, the WTRU may provide an API, which may for example allow the AIML application (e g., upon startup) to provide its AIML requirements.

[0120] At 404 the WTRU may subscribe for AIML model updates. For example, the WTRU may, based on the AIML model requirements, subscribe to receive the AIML model updates. The subscription may trigger the AMDF to perform an AIML model selection and / or distribution to the WTRU. Additionally, or alternatively, if the AMDF does not determine that a model update is required for example, it may not trigger the AIML model distribution.

[0121] At 406 the WTRU may determine if a (e.g., valid) AIML model is available locally (e.g., at the WTRU). The WTRU may determine if the AIML model required by an AIML application is available locally. For example, the WTRU may determine that the AIML model is present locally. If a valid model is available for example, the AIML application may use the AIML model. For example, if the AIML model is present locally, at 412 the a WTRU may notify the AIML application that the model is present at the WTRU and / or that the AIML application may use the AIML model.

[0122] The WTRU may determine that the AIML model is not present locally. If a valid model is not available for example, the AMDF may select and / or distribute the required AIML model (e.g., according to WTRU requirements). The distribution may be triggered based on the WTRU subscription (e.g., subscription to receive AIML model updates), for example by one or more of detecting a change in the WTRU tasks / context, by an indication of the degradation of the AIML model performance, and / or by the availability of an AIML model. At 408 the WTRU may receive the AIML model, for example from the model distribution.

[0123] At 410 the WTRU may store the AIML model, for example received from the network. The WTRU may store (e.g., locally) the AIML model, for example selected and / or distributed by the AMDF. The WTRU may notify the related AIML application of the availability of the AIML model. The AIML application may use the AIML model, for example notified by the WTRU.

[0124] FIG. 5 shows another example of an AIML model selection and distribution 500. Model selection and distribution may be a model selection and distribution lifecycle, for example at WTRU task and / or context change. An AIML application may be executing and / or may have been provided with the (e.g., necessary) AIML model, for example before the example of FIG. 5. At 502 the WTRU and / or AMDF may detect a WTRU task and / or environment change. For example, the WTRU and / or AMDF may detect that the WTRU task(s), environment, and / or context has changed and / or requests / needs an AIML model update (e.g., the model present on the WTRU is outdated).

[0125] The AMDF may select and / or distribute the required AIML model(s), for example according to WTRU requirements. The distribution may be triggered based on one or more of a detected change in the WTRU tasks / context, the indication of an AIML model performance degradation, and / or by the availability of an AIML model. At 504 the WTRU may receive the (e.g., selected) AIML model, for example from the network.

[0126] At 506 the WTRU may store the (e.g., received) AIML model. For example, the WTRU may store (e.g., locally) the AIML model selected and / or distributed by the AMDF. At 508 the WTRU may notify an AIML application, for example a related AIML application, of the availability of the AIML model and / or that the AIML model is present on the WTRU. The AIML application may use the AIML model, for example notified by the WTRU.

[0127] There may be AIML model data, for example metadata. Model data as discussed herein may include AIML metadata. Additionally, or alternatively, model data as discussed herein may include one or more of data related to AIML model content and / or AIML model characteristics, for example AIML metadata. The model data may be maintained within a model (e.g., according to a file format), and / or may be maintained alongside and / or associated with an AIML model. Information that may be included in the AIML model data is described herein. AIML data as described herein may include AIML metadata.

[0128] The AIML model data may include an AIML model identifier. The AIML model identifier may provide identity information about the AIML model. For example, the AIML model identifier may uniquely identify an AIML model instance. Different versions of an (e.g., the same) AIML model have different identifiers.

[0129] The AIML model data may include an AIML model type. The AIML model type may provide information about the type of AIML model. For example, the AIML model type may uniquely identify and / or characterize one or more of the goals and / or objectives of an AIML model, and / or input / output characteristics. Different versions of an (e.g., the same) AIML model may have the same AIML model type. For example, different AIML model instances trained with (e.g., different) performance characteristics to achieve the same goal and / or objective may have the same AIML model type.

[0130] The AIML model data may include an AIML model version. The AIML model version may provide information about AIML model revision. The AIML model version information may be used to identify a version of an AIML model, for example chronologically.

[0131] The AIML model data may include an AIML model family. The AIML model family may provide information about a group of AIML models, for example that are interrelated. The AIML family may identify a group of AIML models, for example that may be used interchangeablyaccording to a WTRU context and / or tasks. The AIML models that may be used interchangeably by an AC depending on the WTRU context for example, may belong to the same family. The multiple AIML models that may be used in a specific location and / or are dependent on time and / or WTRU density may belong to the same family. An (e.g., one) AIML model may belong to several families.

[0132] The AIML model data may include an AIML model associated application identifier. The AIML model associated application identifier may provide information about the application(s) that may utilize (e.g., consume) the AIML model. For example, the information may be used to identify possible AIML models for a given application.

[0133] The AIML model data may include an AIML model criteria. The AIML model validity criteria may provide information for adaptatively determining the validity of a model. The information may indicate an area of interest (e.g., geographical and / or topological), for example where the model may be used. Additionally, or alternatively, the criteria may include one or more of time of day, a WTRU density, and / or the model performance. The information may indicate if an AIML model is available for adaptative selection and / or may be used to adaptatively select an AIML model for a WTRU.

[0134] The AIML model data may include an AIML model requirement and / or characteristic. The AIML model requirement and / or characteristic may provide information about aspects for using the AIML model. For example, the requirement and / or characteristic may indicate one or more of memory requirements, CPU and / or GPU requirements, input analytics requirements, and / or output analytics requirements.

[0135] The AIML model data may include an AIML model performance characteristics. The AIML model performance characteristics may provide information about the expected performance of the AIML model. The information may additionally, or alternatively, indicate how a WTRU may measure the AIML model performance. For example, performance characteristics may indicate that an AIML model prediction(s) should have an 80% success rate, and / or may indicate what the output predictions should be compared to determine the success rate.

[0136] An AIML model data may include attributes, for example additional dynamic attributes. For example, a dynamic attribute for the AIML model instance may include a current and / or measured AIML model performance / accuracy.

[0137] Extensible markup language (XML) and / or derivatives may be used for one or more of expressing, recording, storing, analyzing, and / or transferring AIML model data, for example associated with a particular AIML model and / or a functional group of AIML models.

[0138] The AIML model data may include an AIML WTRU requirement. The AIML WTRU requirements may include information associated with a WTRU. For example, the information may include information related to the WTRU capabilities and / or information related to applications available on the WTRU. The AIML WTRU requirements may be available on a WTRU (e.g., determined, or pre-provisioned) and / or may be provided to the network. For example, the AIML WTRU requirements may be stored in the UDM / UDR for operational purposes. Information that may be included in the AIML WTRU requirements is described herein.

[0139] The WTRU identifier may include information about the associated (e.g., related) WTRU. For example, the WTRU identifier may uniquely identify a WTRU. The WTRU identifier may be a generic public subscription identifier (GPSI).

[0140] There may be WTRU AIML application characteristics. The WTRU AIML application characteristics may indicate AIML applications available on the WTRU, for example that may utilize (e.g., need) support for adaptative selection and / or distribution of AIML models. Application characteristics may include one or more of the application identifier, the AIML model identifiers, and / or versions and / or families needed for each application. The AIML application characteristics may be used by the network, for example for determining suitable AIML models.

[0141] There may be AIML WTRU capabilities. The AIML WTRU capabilities may indicate the WTRU capabilities for AIML model inferencing. The AIML WTRU capabilities may be used in the network, for example for determining suitable AIML models to be provided to a WTRU. For example, capabilities may indicate one or more of the WTRU memory resource (e.g., total, available) for storing AIML models and / or the CPU and / or GPU capabilities.

[0142] There may be AIML model characteristics. The AIML model characteristics may indicate the WTRU expected performance characteristics for the AIML model, for example one or more of conformance level and / or minimum conformance requirement. The AIML model characteristics may be used to select model(s) that may satisfy performance requirements, for example to be utilized (e.g., needed) by the WTRU. Two models may be available to satisfy performance requirements for example. A first model may be optimized for providing low latency predictions and / or a second model may be optimized for providing accurate predictions with higher latency. The AIML model characteristics may indicate whether a low latency prediction and / or accurate prediction is preferred.

[0143] FIG. 6 shows an example procedure 600 for supporting the AMDF capabilities at WTRU registration to the network. AIML model(s) for adaptative selection and distribution may be provisioned in a model repository 612, for example before an AMDF-enabled WTRUregistration. AIML model data associated with an (e.g., each) model may be available, for example before an AMDF-enabled WTRU registration. For example, the AIML data may be available in one or more of the UDM / UDR 606, AMDF 610, and / or model repository 612.

[0144] A WTRU 602 may startup at 614. For example, the WTRU may be powered on and / or perform an initiation sequence. The WTRU initiation sequence may include AIML information scrubbing. For example, as part of the WTRU initialization sequence, the WTRU may locally collect information about available applications and / or information about requirements for AMDF support (e.g., support for adaptative selection and / or distribution of AIML models from the network). For example, the WTRU may obtain information from one or more of the application manifest, configuration, and / or registry and scrub the collected information to discover the AIML WTRU requirements. AIML WTRU requirement information may be described herein.

[0145] The WTRU may perform a network registration procedure. At 616 the WTRU 602 may send a registration request, for example to an AMF 604. The registration request may include AIML WTRU requirement information.

[0146] The AMF 604 may determine (e.g., identify) AIML WTRU requirements at 618. For example, the AMF 604 may determine (e.g., identify) if AIML WTRU requirements are included in the request, for example upon receiving the registration request from the WTRU. If AIML WTRU requirements have been provided for example, the AMF may proceed in selecting one or more of an (e.g., any) instance of an AMDF server, an instance of a NWDAF server, and / or an instance of a model repository 612. The selected server instances may be associated with the WTRU and / or may be reselected at any time (e.g., if needed), for example if the WTRU is served by a different AMF and / or if WTRU mobility happens.

[0147] An AMDF 610 may be included, for example having one or more AMDF functions. An AMDF function may have a certain adaptability profile. The adaptability profile of an AMDF 610 may include analytics that the AMDF 610 may use to predict a WTRU 602 context. An (e.g., one) AMDF 610 may support obtaining and / or using network performance metrics / predictions and / or WTRU analytics metrics / predictions, for example to determine that a WTRU context changed or will change in the future.

[0148] A (e.g., certain) WTRU 602 may have a request and / or preference to use (e.g., certain) metrics to determine and / or predict that a WTRU context has changed. This preference and / or configuration may be stored in the network (e.g. 5GS), for example at a UDM / UDR 606 and / or with WTRU subscription, for example if the preference is static. The metrics to determine and / or predict WTRU context status and status change may be provided by the WTRU 602, for example in the registration request message (e.g., via the network registration procedure). Thenetwork (e.g., 5GC), for example the AMF 610, may select an AMDF instance that uses the WTRU provided metric / approach for determination of WTRU context status and / or prediction of WTRU context status change.

[0149] The WTRU context may have different statuses, depending for example on the application family the WTRU supports. Different application families may have different preferences to determine WTRU context for the application family. For example, an application family 1 that uses AIML models to localize WTRU and / or provide some content depending on the WTRU location, may have a requirement and / or preference to evaluate WTRU context status and / or WTRU context change related to this application family based on WTRU expected mobility behavior metric. In another example, an application family that uses AIML models for 3D gaming, may have a preference to determine and / or predict WTRU context status using a user congestion metric.

[0150] The WTRU context (e.g., itself) may be granular, for example depending on one or more of (e.g., certain) data, such as application IDs, application type, or application family, and / or etc. The AMF 604 may select an AMDF instance that is able (e.g., or supports) to obtain and / or use the metric A to evaluate and / or predict WTRU context for application family 1 and / or use metric B to evaluate or predict WTRU context for application family 2. An AMDF 610 may have a WTRU context prediction profile, which for example may include (e.g., either) all the supported predictions methods for the WTRU context, and / or the prediction method(s) supported for each granularity (e.g., each application family or application type).

[0151] At 620 the AMF 610 may send and / or receive a message. The message may include AIML WTRU requirements. For example, the AMF 610 may send the message to the UDM / UDR 606, for example for storing the provided AIML WTRU requirements and / or associations (e.g., identified by the AMF) in the UDR / UDM 606. Upon receiving the AIML WTRU requirements and associations (e.g., the message) for example, the UDM / UDR 608 may store the provided information in the UDR. The UDM / UDR 606 may determine subscribers (e.g., NF or AF subscribing with the UDM), for example for AIML WTRU requirements and / or associations. The UDM / UDR 608 may send a response back to the AMF 604. The response may contain an indication that the provided AIML WTRU requirements and / or associations were stored in the UDM / UDR.

[0152] At 622 the UDM / UDR 606 may send a notification, for example to an NWDAF 608. The notification may include an indication of AIMLWTRU requirements. For example, the UDM / UDR 606 may notify the NWDAF 608 indicating that AIML WTRU requirements are available, for example if the UDM / UDR 606 determines that the NWDAF 608 has subscribed for AIML WTRUrequirements. The notification may include the AIML WTRU requirements and / or include a URI for retrieving the AIML WTRU requirements. The NWDAF 608 may store one or more of information about the WTRU, the association(s) with the WTRU, and / or the AIML WTRU requirements, for example upon receiving the notification.

[0153] At 624 the UDM / UDR 606 may send a notification, for example to the AMDF 610. The notification may include an indication of AIML WTRU requirements. For example, the UDM / UDR 606 may notify the AMDF 610 with an indication that AIML WTRU requirements are available, for example if the UDM / UDR 606 determines that the AMDF 610 has subscribed for AIML WTRU requirements. The notification may include the AIML WTRU requirements and / or include a URI for retrieving the AIML WTRU requirements. Upon receiving the notification for example, the AMDF 610 may store one or more of information about the WTRU, the association(s) with the WTRU, and / or the AIML WTRU requirements.

[0154] At 626 the AMDF 610 may determine the WTRU context and / or select a (e.g., valid) AIML model. The AMDF 610 may determine the registering WTRU context and / or valid AIML models for the WTRU, for example based on the notified AIML WTRU requirements. The WTRU context may for example be determined by obtaining information from network functions, for example such as the UDM / UDR 606 and / or the NWDAF 608. The availability of AIML models for the WTRU may for example be determined by using the model information from the AIML WTRU requirements (e.g., as herein) and / or obtaining information about model availability from a model repository 612 and / or from an application function (AF) that may provide such information. The validity of the AIML model for the WTRU 602 may for example be determined by comparing the obtained WTRU context information with the AIML model data (e.g., as herein). The AMDF 610 may store information related to the selected models in the UDM / UDR, for example as herein.

[0155] At 628 the AMDF 610 may send an indication of the AIML WTRU selected model, for example to the UDM / UDR 606. The indication may include a request to store information, for example in the UDR. The AMDF 610 may send a request to the UDM to store information in the UDR, for example about the valid and / or selected AIML models for the WTRU 602. The request may include one or more of the selected model data, and / or a subset thereof (e.g., the selected model identifier) for identifying the selected model(s).

[0156] At 630 the UDM / UDR 60 may send an indication of the AIML WTRU selected model, for example to the AMF 604. For example, the UDM / UDR 606 may notify the AMF 604 about information on the selected and valid AIML models for the WTRU. The AMF 604 may include this information in a registration accept request (e.g., at 632).

[0157] At 632 the AMF 604 may send the registration accept request, for example to the WTRU 602. Upon receiving the request for example, the WTRU 602 may determine if information about the selected and / or valid AIML models for the WTRU 602 is included in the request If information about the selected and / or valid AIML models for the WTRU 602 is included for example, the WTRU 602 may store and / or evaluate the provided information. The provided information may contain information about the selected AIML model(s) for the WTRU 602 (e.g., including AIML model Data), may include connectivity information (e.g., DN.EDN) for establishing connectivity to fetch the selected AIML models, and / or may include requirements for fetching the selected AIML models. The WTRU 602 may store the fetched AIML models for the WTRU locally and / or may configure and / or notify the AIML applications requiring the AIML models as needed.

[0158] For example, fetching requirements may indicate to the AIML enablement client that a model may be fetched (e.g., immediately) at a given URI. The WTRU 602 may establish a packet data unit (PDU) session to the indicated DN, for example based on the provided connectivity information. The WTRU 602 may fetch and / or store locally (e.g., in local memory) the AIML model fetched from the given URI, and / or may notify the AIML application(s) requiring the model.

[0159] The fetching requirements may be based on predictions and / or may indicate to the AIML enablement client that a model may be fetched, for example, within a certain delay, at a certain time, and / or when the WTRU 602 reaches a certain location, for example such that models may not be fetched if the prediction does not happen. The WTRU 602 may (e.g., then) evaluate the fetching requirements and / or may establish connectivity, fetch, and / or notify the AIML application if the prediction happens. In some examples the WTRU 602 may otherwise not fetch the model.

[0160] The AMDF 610 may be notified at any time of one or more of changes to the AIML WTRU requirements, WTRU context, AIML model for the WTRU availability, and / or data updates. The AMDF 610 may at any time re-consider the validity and / or selection of AIML models for the WTRU 602 and / or update the UDM / UDR accordingly. The re-selection may be triggered based as described herein and / or may be timer based. A timer value may be preconfigured, and / or provided to the AMDF 610 for example via one or more of a configuration, a message, and / or a policy. The AMF 604 may be notified at any time about information on the selected and valid AIML models for the WTRU 602. The AMF 604 may inform the WTRU 602 of such information, for example via a registration update.

[0161] FIG. 7 shows an example procedure 700 for supporting the AMDF capabilities at WTRU subscription. Al ML model(s) for adaptative selection and / or distribution may be provisioned in a model repository 716, for example before the AMDF-enabled WTRU subscription. AIML model data associated with each model (e.g., described herein) may be available, for example before the AMDF-enabled WTRU subscription. The AIML data may be available in one or more of a UDM / UDR 710, AMDF 714, and / or model repository 716.

[0162] A WTRU 702 may include an AIML application client (AC) 704 and / or an AIML enabler client 706 (e.g., enabler entity). The execution of the AIML AC 704 may be started on the WTRU 702. The WTRU 702 may have local AIML management capabilities and / or may provide a local function, for example such as the AIML enabler client 706 which may allow an AC (e.g., the AIML AC 704) to request AIML support. At 718 the AIML AC 704 may request adaptive model updates, for example by sending a request to the AIML enabler client 706. The AIML AC 704 may request that the WTRU 702 provide adaptative updates of AIML models, for example through an API and / or programming interface. The request may include AIML WTRU requirements of the AC (e.g., AIML AC 704).

[0163] At 720 the WTRU 702 (e.g., AIML enabler client 706) may send an adaptive model updates subscribe request. The AIML enabler client 706 may determine if it has already subscribed for adaptative updates of AIML models, for example considering the AC (e.g., AIML AC 704) instance and / or the AIML WTRU requirements of the AC (e.g., AIML AC 704). If the AIML enabler client 706 determines (e.g., needs) to subscribe for adaptative updates of AIML models for example, the AIML enabler client 706 may send the adaptative model update subscription request (e.g., a subscription request for adaptative updates of AIML models) to the AIML enabler server which may implement the AMDF function. The adaptive model updates subscribe request may include an indication of AIML WTRU requirements. Upon receiving the notification for example, the AIML enabler client may store information about the WTRU and the AIML WTRU requirements. The WTRU 702 (e.g., AIML enabler client 706) may send the adaptive model updates subscribe request to an AIML enabler server 714, for example at an AMDF.

[0164] The AIML enabler server 714 may store (e.g., in locally available storage memory) the AIML WTRU requirements and / or may send a request to the UDM / UDR 710 to update the AIML WTRU requirements in the UDM / UDR 710. For example, the AIML enabler server 714 may send the update AIML WTRU requirements request (e.g., to the UDM / UDR 710) at 722. The UDM / UDR 710 may store the provided information in the UDR, for example upon receiving the AIML WTRU requirements. The UDM / UDR 710 may additionally, or alternatively, determinesubscribers (e.g., NF and / or AF subscribing with the UDM) for AIML WTRU requirements and / or notify subscribers of the updated information. The UDM / UDR 710 may notify the AMF of the updated information by sending the AIML WTRU requirements update notification. For example, the UDM / UDR 710 may send (e.g., to the AMF 708) an AIML WTRU requirements update notification at 724.

[0165] The AMF 708 may determine if there is already an association of the NWDAF 712 and model repository 716 for the WTRU 702, for example upon receiving the notification (e.g., at 724). The AMF 708 may select an NWDAF 712 and / or model repository 716 at 726. Additionally, or alternatively, the WTRU 702 may perform the selection.

[0166] At 728 the AMF 708 may send an AIML WTRU requirements update notification response, for example to the UDM / UDR 710. The AIML WTRU requirements update notification response may include an indication of the association information of the NWDAF 712 and / or model repository 716, for example if the AMF 708 performed the selection (e.g., of the NWDAF 712 and / or model repository 716). At 730 the UDM / UDR 710 may send an update AIML WTRU requirements response, for example to the AIML enabler server 714. The update AIML WTRU requirements response may include an indication of the NWDAF 712 and / or model repository 716 association information for the corresponding AIML WTRU requirements update request.

[0167] At 732 the AIML enabler server 714 (e.g., AMDF) may determine the WTRU context and / or valid AIML models for the WTRU 702, for example based on the requested AIML WTRU requirements and / or the association information. The WTRU context may be determined by obtaining information from network functions, for example such as an indication of the UDM / UDR 710 and / or the NWDAF 712. The availability of AIML models for the WTRU 702 may be determined by using the model information from the AIML WTRU requirements (e.g., as herein) and / or obtaining information about model availability from a model repository 716 and / or from an AF that may provide such information. The validity of the AIML model for the WTRU 702 may for example be determined by cross-referencing the obtained WTRU context information with the AIML model data. The AIML enabler server 714 may store information related to the selected models in locally available storage memory and / or in the UDM / UDR 710, for example.

[0168] At 734 the AIML enabler server 714 may send an adaptative model update subscribe response (e.g., a subscription response for adaptative updates of AIML models), for example to the AIML enabler client 706 (e.g., WTRU 702). The adaptative model update subscribe response may include a subscription identifier for managing (e.g., reading, updating, and / or deleting) the subscription. The adaptative model update subscribe response may additionally, oralternatively, include information about the selected AIML models for the WTRU 702. The AIML enabler client 706 may store and / or evaluate the provided information, for example if information about the selected and / or valid AIML models for the WTRU 702 is included. The provided information may contain information about the selected AIML model(s) for the WTRU 702 (e.g., including AIML model data), may include connectivity information for fetching the selected AIML models for the WTRU 702, and / or may include requirements for fetching the selected AIML models for the WTRU 702. The AIML enabler client 706 may store the fetched AIML models for the WTRU 702 (e.g., locally) and / or configure and / or notify the AIML applications requiring the AIML models as needed. At 736 the AIML enabler client 706 may send an adaptive model updates response, for example to the AIML AC 704. The adaptive model updates response may include at least some of the information included in the adaptive model updates subscribe response (e.g., at 734). For example, the information may include one or more of an AIML mode, AIML model data, connectivity information for fetching the AIML mode, and / or requirements for fetching the (e.g., selected) AMIL model. The AIML AC 704 may use the information to determine whether and / or how to use an AIML model, for example after receiving the adaptive model updates response. Additionally, or alternatively, the AIML AC 704 may use the connectivity information for fetching the AIML model and / or the requirements for fetching the AIML model to fetch the AIML model.

[0169] For example, a fetching requirement may indicate to the AIML enabler client 706 that a model may be fetched (e.g., immediately) at a given URL The AIML enabler client 706 may establish a PDU session to an indicated DN, for example based on the provided connectivity information. The AIML enabler client 706 may fetch and / or store locally (e.g., in local memory) the AIML model fetched from the given URI, and / or may notify the AIML application(s) requiring the model.

[0170] The fetching requirements may be based on predictions and / or may indicate to the AIML enablement client that a model may be fetched, for example, within a certain delay, at a certain time, and / or when the WTRU 702 reaches a certain location, for example such that models are not fetched if the prediction does not happen. The AIML enabler client 706 may (e.g., then) evaluate the fetching requirements and / or may (e.g., only) establish connectivity, fetch, and notify the AIML application if the prediction happens, and for example may otherwise never fetch the model.

[0171] The AIML AC 704 may be a newly installed AC. The AIML enabler client 706 may detect a newly installed AC. The AIML enabler client 706 may subscribe to receive adaptative updates of AIML models for the WTRU 702, for example based on detection of the (e.g., newly installed)AC. The AIML enabler client 706 may determine if a subscription update is needed based on the AIML WTRU requirements provided by the AC, for example if the AIML enabler client 706 has already subscribed for an AC instance and / or is requested again by the same AC instance. The AIML model selection may result in the WTRU 702 being informed about the selection and / or may result in the WTRU 702 being notified, for example as described herein. The response may indicate that an AIML model may be revoked (e.g., may not be used). Such revocation may be performed locally by the WTRU 702, for example according to the information included in the AIML model data. The revocation may be triggered by the network by sending a notification. The WTRU 702 may notify the AIML application to stop using the AIML model and / or remove the AIML model from local storage, for example upon receiving a revocation indication.

[0172] FIG. 8 shows an example procedure 800 for supporting AMDF events for model distribution. A WTRU 802 may subscribe to receive adaptative updates of AIML models (e.g., as described herein), for example before AMDF events enablement.

[0173] At 816 there may be a model selection trigger, for example at the AIML enabler server 812 (e.g., AMDF). For example, the AIML enabler server 812 (e.g., AMDF) may be triggered by an event, for example indicating that the selected AIML model for the WTRU 702 should be reevaluated. The AIML enabler server 812 may be triggered by a notification. For example, the AIML enabler server 812 may be notified by the UDM / UDR 808 indicating a predicted WTRU context (e.g., WTRU external parameters) change, and / or be notified by the NWDAF 810 indicating a predicted WTRU context change (e.g., WTRU analytics, performance analytics, and / or congestion analytics, etc.), and / or be notified by a WTRU about a selected AIML model performance degradation, and / or be notified by the model repository 814 indicating a model change.

[0174] At 818 the AIML enabler server 812 (e.g., AMDF) may determine WTRU context and / or select a valid AIML model. For example, based on the AIML WTRU requirements stored in the UDM / UDR 808, the AIML enablement server 812 may obtain the selected AIML WTRU requirements, and / or the AIML enabler server 812 may determine the current and predicted WTRU context (e.g., if not already determined), and / or may determine valid AIML models for the WTRU 802. The WTRU current and / or predicted context may be determined by obtaining information from network functions, for example such as the UDM / UDR 808 and / or the NWDAF 810. The availability of AIML models for the WTRU 802 may be determined by using the model information from the AIML WTRU requirements (e.g., as herein) and / or obtaining information about model availability from a model repository 814 and / or from an AF, for example that mayprovide such information. The validity of the AIML model for the WTRU 802 may for example be determined by comparing the current and / or predicted WTRU context information with the AIML model information captured in AIML model data (e.g., as herein). The AIML enabler server 812 may store information related to the currently selected AIML model and / or predicted AIML model(s), for example in the UDM / UDR 808.

[0175] AIML model availability may be determined. The AIML enabler server 812 (e.g., AMDF) determination of future AIML model may trigger (e.g., just-in-time) AIML model training. The AIML enabler server 812 (e.g., AMDF) may predict how a WTRU context may change and / or may determine available AIML models needed according to the predicted context. The AIML enabler server 812 (e.g., AMDF) may additionally, or alternatively, determine that the predicted AIML model may not be available and / or may not meet the performance requirements. The AIML enabler server trigger and / or solicit other entities for training an AIML model (e.g., just-in- time), for example to meet the expected performance requirements. The WTRU 802 may use the newly available model if it is available, and / or for example (e.g., otherwise) the model may become available for future requests.

[0176] At 820 the AIML enabler server 812 (e.g., AMDF) may exercise traffic influence and / or quality of service (QoS), for example based on AIML model distribution. The AIML enabler server 812 (e.g., AMDF) may exercise traffic influence and / or QoS using the capabilities of the 5GC, for example based on the characteristics and / or data of the selected AIML model for the WTRU 802, and / or on the network predictions. The traffic influence and / or QoS may be helpful to ensure in-time delivery of the selected AIML models and / or may be determined for example by considering one or more of the WTRU 802 and network analytics, performance analytics, and / or congestion analytics.

[0177] At 822 the AIML enabler server 812 (e.g., AMDF) may send an adaptive model update notification, for example to the AIML enabler client 806 (e.g., WTRU 802). The AIML enabler server 812 (e.g., AMDF) server may send the adaptative model update notification (e.g., a notification for adaptative updates of AIML models) to the AIML enabler client 806, for example, if needed. The adaptive model update notification may include information about the selected AIML model(s) for the WTRU 802. If information about the selected and valid AIML models for the WTRU 802 is included for example, the AIML enabler client 806 may store and / or evaluate the provided information. The provided information may contain information about the selected AIML model(s) for the WTRU 802 (e.g., including AIML model data). The provided information may alternatively, or additionally, include connectivity information for fetching the selected AIML models for the WTRU 802 and / or requirements for fetching the selected AIML models for theWTRU 802. The AIML enabler client 806 may store the fetched AIML models for the WTRU 802 (e g., locally) and / or may configure and / or notify the AIML applications requiring the AIML models as needed. At 824 the AIML enabler client 806 may store a (e.g., selected) AIML model and / or AIML model information and / or may monitor WTRU context, for example according to fetching requirements.

[0178] For example, the fetching requirements may indicate to the AIML enablement client 806 that a model may be fetched immediately at a given URI. The AIML enabler client 806 may establish a PDU session to the indicated DN based on the provided connectivity information, fetch and / or store locally (e.g., in local memory) the AIML model and / or AIML model information fetched from the given URI, and / or may notify the AIML application(s) requiring the model.

[0179] The fetching requirements may be based on predictions and / or may indicate to the AIML enablement client 806 that a model may be fetched within a certain delay, at a certain time, and / or when the WTRU reaches a certain location, for example such that models may not be fetched if the prediction does not happen. The AIML enabler client 806 may (e.g., then) evaluate the fetching requirements and / or may (e.g., only) establish connectivity, fetch, and / or notify the AIML application, for example if the prediction happens. In some examples the AIML may otherwise never fetch the model.

[0180] The AIML enablement client 806 may store the information received in the notification and / or may initiate monitoring of the WTRU context, for example according to the received requirements for fetching the selected AIML models. The WTRU 802 may start a timer, monitor the WTRU location, and / or initiate the download of a selected AIML model, for example (e.g., only) if triggered by such a timer and / or WTRU location.

[0181] The AIML enabler client 806 may, for example at 826, notify the associated AC (e.g., the AIML AC 804) instances about the newly available models and / or may remove the old models to free resources on the WTRU 802, for example upon fetching a selected AIML model according to requirements for fetching the selected AIML model.

[0182] The AIML enabler server 812 (e.g., via the AMDF model selection trigger) may be triggered by a WTRU 802 request. For example, the AIML enabler client 806 and / or AC (e.g., the AIML AC 804) may monitor whether the predictions provided by the AIML model inference are within an expected success rate. When the predictions do not meet the expected success rate for example, the AIML enabler client 806 may request the AIML enablement server 812 (e.g., AMDF) to trigger the re-selection of the AIML model and / or provide analytics related to the AIML model performance.

[0183] The traffic influence exercised by the AIML enabler server 812 and / or the processing of the notification may result in an update of the USRP policy in the network and / or on the WTRU 802. For example, to fetch selected AIML models, new USRP rules may be pushed to the WTRU 802 and / or the AIML enabler client 806 may add USRP rules locally.

[0184] At 826 the AIML enabler client 806 may send an adaptive model update notification, for example to the AIML AC 804. The adaptative model update notification (e.g., a notification for adaptative updates of AIML models) may for example indicate newly available models and / or indicate that an AIML model may be revoked (e.g., may not be used). AIML model revocation may be performed locally by the WTRU 802, for example according to the information included in the AIML model data. Additionally, or alternatively, the revocation may be triggered by the network, for example by sending a notification. The WTRU 802 may notify the AIML application that to stop using the AIML model and / or remove the AIML model from local storage, for example upon receiving a revocation indication.

[0185] The adaptative model update notification (e.g., a notification for adaptative updates of AIML models) may indicate, for example to the AIML enabler client 806, that the AIML enabler server 812 (e.g., AMDF) requests to be informed about the AIML model usage and / or configuration. The AIML enabler client 806 may send a notification response to the AIML enabler server 812 (e.g., AMDF), for example when an indication is included. The response may include information about the AIML models for the WTRU 802 (e.g., that are locally stored on the WTRU 802) and / or about the AIML model usage by AIML applications.

Claims

CLAIMS:

1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: send a message comprising an indication of a request for an artificial intelligence (Al) machine learning (ML) model update, wherein the request comprises AIML model data and an identifier (ID) associated with the WTRU, wherein the AIML model data comprises an indication of an objective associated with the AIML model, an indication of a performance characteristic associated with the AIML model, and an AIML model ID; and receive a response comprising a subscription ID associated with the AIML model.

2. The WTRU of claim 1 , wherein the response further comprises AIML model data and information for fetching the AIML model, and wherein the processor is configured to fetch the AIML model based on the AIML model data and the information for fetching the AIML model.

3. The WTRU of claim 1 , wherein the AIML model comprises a first AIML model, and wherein the processor is configured to receive an indication that a second AIML model is available.

4. The WTRU of claim 1 , wherein the subscription ID is associated with a model repository, and wherein the response further comprises AIML model data associated with the model repository.

5. The WTRU of claim 1 , wherein the objective associated with the AIML model indicates what the model is used for, an output of the model, or a purpose of the model, and wherein the AIML model is trained to meet the objective or provide an estimate associated with the objective.

6. The WTRU of claim 1 , wherein the performance characteristic associated with the AIML model is an accuracy of the AIML model, and wherein the AIML model is trained to meet the performance characteristic or provide an estimate associated with the performance characteristic.

7. The WTRU of claim 1 , wherein the AIML model data comprises operation information associated with the AIML model and associated with the WTRU.

8. The WTRU of claim 1 , wherein the AIML model data comprises information for discovering the AIML model and an indication of a memory requirement associated with the AIML model.

9. The WTRU of claim 1 , wherein the AIML model data comprises an indication of a memory requirement associated with the AIML model.

10. The WTRU of claim 1, wherein the AIML model data comprises an indication of a usage requirement associated with the AIML model.

11. The WTRU of claim 10, wherein the usage requirement associated with the AIML model is further associated with the objective, the performance characteristic, a model type of the AIML model, an availability associated with the AIML model, or a location associated with the AIML model.

12. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: sending a message comprising an indication of a request for an artificial intelligence (Al) machine learning (ML) model update, wherein the request comprises AIML model data and an identifier (ID) associated with the WTRU, wherein the AIML model data comprises an indication of an objective associated with the AIML model, an indication of a performance characteristic associated with the AIML model, and an AIML model ID; and receiving a response comprising a subscription ID associated with the AIML model.

13. The method of claim 12, wherein the response further comprises AIML model data and information for fetching the AIML model, and wherein the method comprises fetching the AIML model based on the AIML model data and the information for fetching the AIML model.

14. The method of claim 12, wherein the AIML model comprises a first AIML model, and wherein the method comprises receiving an indication that a second AIML model is available.

15. The method of claim 12, wherein the subscription ID is associated with a model repository, and wherein the response further comprises AIML model data associated with the model repository.

16. The method of claim 12, wherein the objective associated with the AIML model indicates what the model is used for, an output of the model, or a purpose of the model, and wherein the AIML model is trained to meet the objective or provide an estimate associated with the objective associated with the AIML model.

17. The method of claim 12, wherein the performance characteristic associated with the AIML model is an accuracy of the AIML model, and wherein theAIML model is trained to meet the performance characteristic or provide an estimate associated with the performance characteristic associated with the AIML model.

18. The method of claim 12, wherein the AIML model data comprises operation information associated with the AIML model and associated with the WTRU.

19. The method of claim 12, wherein the AIML model data comprises information for discovering the AIML model and an indication of a memory requirement associated with the AIML model.

20. The method of claim 12, wherein the AIML model data comprises an indication of a usage requirement associated with the AIML model, and wherein the usage requirement associated with the AIML model is further associated with the objective, the performance characteristic, a model type of the AIML model, an availability associated with the AIML model, or a location associated with the AIML model.

Images