Method, Architecture, Device, and System for Traceability Aware Artificial Intelligence

Abstract

Artificial intelligence (AI) tasks, and procedures, methods, architectures, devices, systems, devices, and computer program products that enable tracing of a host device. The device receives from at least one other device an AI model for installation on the device to execute an artificial intelligence (AI) task and information indicating a trace instruction based on a trace criterion of the AI model requested by the device, the trace information corresponding to information for tracing one or more stages of an AI pipeline associated with the AI model, installs the AI model, creates a record of the installed AI model, and sends a message including information indicating at least a part of the created record to a recording device.

Description

Technical Field

[0001] The present disclosure generally relates to the fields of communication, software, and coding, including, for example, methods, architectures, devices, and systems for traceability ware artificial intelligence (AI).

Summary of the Invention

[0002] In a first aspect, the principle is directed to a device including at least one processor, the at least one processor receiving, from at least one other device, an AI model for installation on the device to perform an artificial intelligence (AI) task and information indicating trace instructions based on trace criteria for the AI model requested by the device, the trace information corresponding to information for tracing one or more stages of an AI pipeline associated with the AI model, installing the AI model, creating a record of the installed AI model, and transmitting, to a recording device, a message including information indicating at least a portion of the created record.

[0003] In a second aspect, the principle is directed to a method executed by a device, the method including receiving, from at least one other device, an AI model for installation on the device to perform an artificial intelligence (AI) task and information indicating trace instructions based on trace criteria for the AI model requested by the device, the trace information corresponding to information for tracing one or more stages of an AI pipeline associated with the AI model, installing the AI model, creating a record of the installed AI model, and transmitting, to a recording device, a message including information indicating at least a portion of the created record.

[0004] In a third aspect, the present principle is directed to a device including at least one processor, the processor receiving from another device an AI model for installation on the device to execute an artificial intelligence (AI) task, and information indicating trace instructions for the AI model, the trace instructions corresponding to information for tracing one or more stages of an AI pipeline associated with the AI model, installing the AI model, and being configured to send a message including information indicating installation of the AI model on the device to another device.

[0005] In a fourth aspect, the present principle is directed to a method executed by a device, the method including receiving from another device an AI model for installation on the device to execute an artificial intelligence (AI) task, and information indicating trace instructions for the AI model, the trace instructions corresponding to information for tracing one or more stages of an AI pipeline associated with the AI model, installing the AI model, and sending a message including information indicating installation of the AI model on the device to another device.

Brief Description of the Drawings

[0006] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. The figures of such drawings are merely examples, like the detailed description. Therefore, the figures and the detailed description should not be regarded as limiting, and other equally effective examples are possible and likely. Further, similar reference numerals ( "references") in the figures indicate similar elements.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Embodiments for Carrying Out the Invention

[0007] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently (collectively "provided") described, disclosed, or otherwise provided herein. In this specification, various embodiments are described and / or claimed in which an apparatus, system, device, etc. and / or any element thereof performs various operations, processes, algorithms, functions, etc. and / or any part thereof, but it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any element thereof is configured to perform any operation, process, algorithm, function, etc. and / or any part thereof.

[0008] Exemplary Communication System The methods, apparatuses, and systems provided herein are well-suited for communication including both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to FIGS. 1A - 1D, in which various elements of the network may utilize, execute, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatuses, and systems provided herein.

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

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

[0011] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as, for example, CN106 / 115, the Internet 110, and / or network 112. As an example, base stations 114a, 114b may be any of a base transceiver station (BTS), Node-B (NB), eNode-B (eNB), Home Node-B (HNB), Home eNode-B (HeNB), gNode-B (gNB), NR Node-B (NR NB), a site controller, an access point (AP), a wireless router, etc. Although base stations 114a, 114b are each depicted as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0014] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a of RAN104 / 113 and WTRU102a, 102b, 102c can establish the air interface 116 using wideband CDMA (WCDMA), and can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

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

[0016] In one embodiment, the base station 114a and WTRU102a, 102b, 102c can implement radio technologies such as NR radio access, and this technology can establish the air interface 116 using New Radio (NR).

[0017] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by transmissions sent between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).

[0018] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), 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 communication (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0019] The base station 114b in Fig. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connections in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any one of a small cell, a pico cell, or a femto cell. As shown in Fig. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0020] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that employ the same or a different radio access technology (RAT) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 that may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that employs any one of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0021] CN106 / 115 may also function as a gateway for the WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, and these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs that may employ the same RAT or a different RAT as the RAN104 / 114.

[0022] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include multimode functionality (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.

[0023] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 can include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 can include any partial combination of the foregoing elements while maintaining consistency with one embodiment.

[0024] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated, for example, in an electronic package or chip.

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

[0026] Although the transmit / receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. For example, 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 via the air interface 116.

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

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

[0029] Processor 118 may receive power from power supply 134 and may be configured to distribute power to and / or control other components in WTRU 102. Power supply 134 may be any suitable device for supplying power to WTRU 102. For example, power supply 134 may include one or more dry 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.

[0030] Processor 118 may also be coupled to GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of WTRU 102. In addition to, or instead of, information from GPS chipset 136, WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via air interface 116 and / or may determine its location based on the timing of signals received from two or more neighboring base stations. It will be understood that WTRU 102 may obtain location information by any suitable location determination method while maintaining consistency with one embodiment.

[0031] Processor 118 may be further coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connections. For example, the element / peripheral 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), 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, etc. The element / peripheral 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0032] The WTRU 102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either through hardware (e.g., a choke) or through signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either uplink (e.g., for transmission) or downlink (e.g., for reception)).

[0033] Figure 1C is a system diagram showing RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0034] RAN 104 can include eNodeBs 160a, 160b, 160c, but it will be understood that RAN 104 can include any number of eNodeBs while maintaining consistency with one embodiment. Each of eNodeBs 160a, 160b, 160c can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, eNode-B 160a can, for example, transmit a wireless signal to WTRU 102a and receive a wireless signal from WTRU 102a using multiple antennas.

[0035] Each of eNodeBs 160a, 160b, and 160c can be associated with a particular cell (not shown) and can be configured to handle wireless resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. As shown in Figure 1C, eNodeBs 160a, 160b, 160c can communicate with each other via the X2 interface.

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

[0037] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c within the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may authenticate users of the WTRUs 102a, 102b, 102c, activate / deactivate bearers, select a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

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

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

[0040] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, 102c with access to a circuit switched network such as PSTN 108 to facilitate communication between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, CN 106 can include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN 106 and PSTN 108. In addition, CN 106 can provide WTRUs 102a, 102b, 102c with access to other network 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] The WTRU is described as a wireless terminal in FIGS. 1A - 1D, but in certain representative embodiments, it is contemplated that such a terminal can use a (e.g., temporary or permanent) wired communication interface with a communication network.

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

[0043] 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 interface to a distribution system (DS) that conveys traffic within and / or outside the BSS or to another type of wired / wireless network. Traffic to an STA originating from outside the BSS may reach and be delivered to the STA through the AP. Traffic originating from an STA to a destination outside the BSS may be sent to the AP to be delivered to their respective destinations. Traffic between STAs within the BSS may be sent, for example, through the AP, where the source STA may send the traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS communication mode may also be referred to herein as the "ad hoc" communication mode.

[0044] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel may have a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) may sense the primary channel. If the primary channel is detected / determined to be busy by a particular STA, the particular STA may back off. Only one STA (e.g., only one station) may transmit at any given time in a given BSS.

[0045] A high throughput (HT) STA may use a 40 MHz wide channel for communication, for example, by combining a primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0046] A very high throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel may be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non - consecutive 80 MHz channels, which may be referred to as an 80 + 80 configuration. In the case of the 80 + 80 configuration, after channel encoding, the data may pass through a segment parser that may divide the data into two streams. The inverse fast fourier transform (IFFT) process and time - domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the aforementioned operations for the 80 + 80 configuration may be reversed, and the combined data may be sent to the medium access control (MAC) layer, entity, etc.

[0047] The sub-1 GHz operation mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequency are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV white space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine-type communication (MTC) such as MTC devices in a macro coverage area. The MTC device may have limited capabilities, including specific capabilities, for example, support for a specific and / or limited bandwidth (e.g., support only for these). The MTC device may include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

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

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

[0050] FIG. 1D is a system diagram showing RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0051] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Thus, gNB 180a, for example, may transmit a wireless signal to WTRU 102a and / or receive a wireless signal from WTRU 102a using multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0052] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or absolute times of continuously varying lengths).

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

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

[0055] CN 115 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one data network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it will be understood that any of these elements can be owned and / or operated by a legal entity other than the CN operator.

[0056] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can authenticate users of WTRUs 102a, 102b, and 102c, support network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), select specific SMFs 183a and 183b, manage registration areas, terminate NAS signaling, perform mobility management, etc. Network slicing can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on, for example, the type of services utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) using other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or Wi-Fi.

[0057] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating the UE's IP address, managing the PDU session, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0058] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, which can provide access to a packet-switched network such as the Internet 110 for WTRU102a, 102b, and 102c, for example, to facilitate communication between WTRU102a, 102b, and 102c and IP-compatible devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0060] In view of FIGS. 1A-1D, and the corresponding descriptions of FIGS. 1A-1D, one or more or all of the functions described herein with respect to any of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other element / device described herein may be performed by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

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

[0062] One or more emulation devices can perform one or more functions including all while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing) to implement tests for one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by an emulation device to transmit and / or receive data.

[0063] Introduction Blockchain Technology Blockchain technology combines and builds upon existing techniques such as cryptography, hashing, Merkle trees, distributed ledgers, peer-to-peer networking, and consensus protocols. It integrates into a system (i.e., a blockchain system) that can provide advanced features such as decentralization, immutability, transparency, and security. Applications that use and / or are supported by a blockchain system are called blockchain applications. A blockchain system is supported by a blockchain network composed of participating blockchain nodes. Each blockchain node hosts one or more distributed blockchains (i.e., a form of distributed ledger) and participates in the blockchain system. For example, blockchain nodes can form a peer-to-peer network to broadcast blockchain transactions and blocks among themselves. Blockchain nodes also implement a consensus protocol to achieve distributed trust without relying on a centralized party. A blockchain transaction can be, for example, a digital representation of a real-world transaction, a digital record of a physical asset, a digital record of a physical event, a digital record of any action in an information system, a digital payment, and / or a digital smart contract. A block groups multiple blockchain transactions. A blockchain is a data structure that chains an increasing number of blocks. In this specification, blockchain technology is used as a non-limiting example of distributed ledger technology. Therefore, this principle can be applied not only to any specific blockchain technology but also to distributed ledger technologies such as permissioned distributed ledgers (see ETSI GR PDL 003 V1.1.1 (2020-12); Permissioned Distributed Ledger (PDL); Application Scenarios).

[0064] The general workflow of a blockchain system includes five steps.

[0065] Step 1: Initiate a transaction. Each blockchain client or blockchain user independently generates a new transaction. Each blockchain user has a user or account identifier, typically the hash of the user's public key used to sign the new transaction. The newly signed transaction is then sent to the blockchain network.

[0066] Step 2: Broadcast and verify the transaction. The new transaction is first received by a few blockchain nodes, and the blockchain nodes verify its integrity using the public key of the user included in the transaction. If the validity of the new transaction is successfully verified, the new transaction is relayed and broadcast within the blockchain network. Eventually, all blockchain nodes will receive and have a copy of any newly generated valid transaction.

[0067] Step 3: Construct a new block. Certain block-constructing blockchain nodes (referred to as mining nodes or full blockchain nodes) initiate the grouping of multiple newly generated, pending transactions and generate a new block. The new block will include a block header and a block body. The block header generally includes the hash of the previously confirmed block and the hash of all the transactions included (e.g., Merkle tree). Depending on the consensus protocol, the block header may include additional information. The block body includes the content of all the transactions included. Each block-constructing blockchain node attempts to create a new block independently.

[0068] Step 4: Verify the new block based on the consensus protocol. In Step 3, the building block chain nodes independently attempt to create new blocks. They execute the same consensus protocol (e.g., proof of work in the Bitcoin system) and reach an agreement on who (i.e., the winner) is permitted to insert a block into the existing block chain. The winner of the consensus protocol sends the newly generated block to the block chain network. This new block is broadcast, and all building block chain nodes receive and verify it.

[0069] Step 5: Update the block chain. After the newly generated block is verified in Step 4, since it contains the hash of the previous block (i.e., the last block of the previous block chain), it is successfully added to and linked to the existing block chain.

[0070] Introduction to AI The AI system includes one or more AI agents that learn and / or utilize an AI model based on at least one AI approach such as deep learning, federated learning, and reinforcement learning. The AI agents typically reside within different physical or logical nodes (e.g., devices, servers, virtual machines within the cloud) commonly referred to as an AI host (AIH). Each AI agent typically hosts and executes an AI task, which is, for example, a task for learning an AI model according to an AI algorithm (e.g., deep learning algorithm, federated learning algorithm, reinforcement learning algorithm), or a task for using the AI model to infer knowledge. Deep learning and reinforcement learning typically use one AI agent, while federated learning utilizes multiple AI agents that work together to learn an AI model, which can be a deep neural network model and a policy model for reinforcement learning. Federated learning can be used to solve various types of learning tasks including but not limited to deep learning and reinforcement learning. The AI algorithm can be supervised by relying on tagged training data or unsupervised without using tagged data. FIG. 2 shows an AI host with an AI agent accompanying an AI task using an AI model.

[0071] In this specification, the process of (re)installing an AI task (e.g., one software code and data) on an AI agent on an AI host is referred to as "AI task deployment", and "AI model deployment" refers to the process of transferring and / or (re)installing an AI model to an existing AI task. Note that when the AI task has already been deployed on the AI agent, the AI agent and the AI task can be used interchangeably in this description.

[0072] In this specification, "model" and "AI model" are used interchangeably and mean the same thing unless explicitly stated otherwise. Similarly, "task" and "AI task" are used interchangeably and mean the same thing unless explicitly stated otherwise.

[0073] Figure 3 shows a general AI pipeline for supervised learning. The pipeline typically includes: 1) task configuration, which involves the deployment of an AI application or an AI agent / task by a user; 2) data preparation, which includes data collection and optionally feature engineering / extraction; 3) training to learn an AI model; 4) validation to test and verify the trained AI model; 5) model deployment to deploy and transfer the validated AI model; and 6) inference, which includes multiple stages of using new data as input (referred to as input data for inference) to infer and predict future knowledge. The results from inference (e.g., outcomes) can be utilized for actions or triggers to return to training in order to retrain the AI model.

[0074] Depending on the choice of AI deployment, the AI agent can be: 1) an AI agent for learning (AI Agent for Learning, AIA4L) responsible for learning the AI model; 2) an AI agent for inference (AI Agent for Inference, AIA4I) that uses the trained AI model for inference and prediction; and 3) an AI agent for learning and inference (AI Agent for Learning and Inference, AIA4LI) that combines the former two. AI model transfer generally occurs between AIA4L and AIA4I, or between multiple AIA4LIs.

[0075] Deep learning Deep learning (DL), as is well known in the art, is a special type of supervised machine learning (ML) that uses a deep neural network (DNN). A DNN typically includes an input layer, a plurality of hidden layers, and an output layer. Each layer (especially the hidden layers) has several artificial neurons connected to the neurons of the previous layer and the neurons of the next layer. A weight indicating the degree to which a neuron in the previous layer affects a neuron in the next layer is assigned to the connection between two neurons in two adjacent layers. Training a DNN involves repeated feedforward and backpropagation.

[0076] Feedforward: Input data passes through the DNN from the input layer to the output layer to generate an output (e.g., a scalar or a vector).

[0077] Backpropagation: Using the generated output, a loss is calculated according to a predetermined loss function. The loss is then used to adjust the weights between two adjacent layers all the way from the output layer to the input layer using gradient descent. A trained AI model in deep learning is a set of weights that connect all the neurons in the DNN. A deep learning system can be deployed as a single AI agent (i.e., AIA4LI), or as multiple separate AI agents (e.g., one AIA4L and multiple AIA4I).

[0078] DNN can provide a good approach for learning or approximating a non-linear function that maps an input to an output. However, the data items used to train the DNN should be uncorrelated or weakly correlated in order to achieve good performance (e.g., learning accuracy). DNN can be used to solve many machine learning problems such as prediction and classification. Different types of DNNs are designed for different applications. For example, Convolutional Neural Network (CNN) has been successful in computer vision and acoustic modeling, while Recurrent Neural Network (RNN) and Long Short-Term Memory (LSTM) are good tools for natural language processing.

[0079] Federated learning Federated Learning (FL) is a framework for distributed ML or distributed AI. In FL, training data is maintained locally at a plurality of distributed federated learning clients (FLCs) (e.g., mobile devices). Each FLC performs local training (e.g., deep learning), generates local model updates, and sends the local model updates to a federated learning server (FLS). The FLS, as a central entity, aggregates the local model updates from the FLCs, generates global model updates, and the global model updates are sent to the participating FLCs for the next training round. Exemplary advantages of federated learning include: 1) since the training data stays at the FLCs, data privacy protection is improved; 2) since there is no need to collect / transmit training data to a central entity, communication overhead is reduced; 3) since model training utilizes distributed computing resources at the FLCs, the learning speed is improved. However, FL requires sending model updates between the FLS and the FLCs, which introduces additional communication overhead compared to centralized machine learning. Also, FL requires that the data at all FLCs follows independent and identical distribution (IID) (i.e., IID data) in order to achieve good learning performance. In addition, FL inherits potential security problems and threats such as data poisoning attacks and model poisoning attacks. In fact, the FLS hosts an FL agent for learning (i.e., AIA4L), while each FLC has an FL agent (i.e., AIA4LI) that can be for both learning and inference. Note that both the FLS and the FLC are AIHs.

[0080] Figure 4 shows a general federated learning process, where, for example, the FLS can be an NWDAF in 5G and the FLC can be a UE. The FLS and the FLC jointly take the following steps to execute an FL task.

[0081] Step S401 (not shown): The FLS selects a set of FLCs that participate in the FL task. In the illustrated example, FLCs 1 to 3 are selected.

[0082] Step S402: The FLS configures the FL task for each selected FLC (e.g., deploys or instructs the FLC to start local training of the already deployed FL task).

[0083] Step S403: The FLS sends the initial global model to each selected FLC.

[0084] Step S404: Each FLC independently trains the global model based on the received initial global model and its local data.

[0085] Step S405: After the local training round in Step S404, each FLC generates a local model update to send to the FLS.

[0086] Step S406: The FLS receives the local model updates from the selected FLCs, aggregates them, and generates a global model update. In synchronous FL, the FLS waits until it receives local model updates from all participating FLCs before performing the aggregation. In asynchronous FL, the FLS can start the aggregation when it receives local model updates from a subset of the participating FLCs.

[0087] Step S407 is the same as Step S403, but the FLS sends the global model update to the selected FLCs. Note that the FLS can change the set of selected FLCs between training rounds, e.g., it can retain one or more FLCs from the previous set.

[0088] Step S408 is the same as step S404, that is, the selected FLC independently trains the global model based on the received global model update.

[0089] Step S409 (not shown) is the same as step S405. The FLC sends the local model update to the FLS. Next, the FLS can generate a new global model update and the FLS can send it to the FLC as the start of further iterations.

[0090] AI-related 3GPP standards 3GPP TS 22.261 (3GPP TS 22.261 V18.5.0 (2021-12); Service requirements for the 5G system; Stage 1 (Release 18)) specifies the AI model transfer requirements for the following three types of AI operations. 1) Splitting of AI operations between AI endpoints, 2) Distribution and sharing of AI models / data over the 5G system (5GS), and 3) Distributed / federated learning (FL) over the 5GS.

[0091] 3GPP TR23.700-80 (3GPP TR 23.700-80 v0.3.0 (2022-05) Study on 5G system support for AI-based services (Release 18)) aims to define intelligent transmission support for AI-based services in the 5GS. This focuses on 5GS architecture extension and functional enhancement to enable service providers to utilize the 5GS as an intelligent transmission platform to support AI-based services.

[0092] TR 23.700-80 has several main objectives as follows. To study possible architectural and functional extensions for supporting application layer AI operations defined in TS 22.261. To study possible QoS and policy enhancements for supporting application AI operation traffic while supporting normal (non-application AI) 5GS user traffic. To study whether and how 5GS provides assistance to AF and UE to facilitate cooperative application AI based on the federated learning operation between the application client executed on UE (i.e., FLC) and the application server (i.e., FLS) for AF and UE to manage FL operation and model dispersion / redispersion (e.g., FL member selection).

[0093] In addition, 3GPP has recently approved a new Release 19 study item (3GPP SA1 S1-220183, "Study on AI Model Transfer Phase2," 3GPP SA WG1 Meeting #97-e, February 14-24, 2022) to study use cases and potential service and performance requirements for distributed AI training / inference with direct device connection, which has two objectives, namely, distributed AI training / inference based on device indirect connection and aspects of charging and security.

[0094] ETSI SAI ETSI GR SAI 0010 (ETSI GR SAI 0010 V0.0.1 (2022-01); Securing Artificial Intelligence (SAI); Traceability of AI Models) aims to study the role of AI traceability in securing AI and to investigate potential issues related to sharing and reusing models across different tasks or various industry-related applications. The scope of AI traceability includes, but is not limited to, the discovery of potential threats and their related mitigation. Further AI traceability can improve the determination of where AI traceability is applicable, protect the ownership of AI creators, protect the origin of model verification, guarantee the integrity of the model, or discover its purpose.

[0095] Wireless AI Use Cases Two wireless AI use cases are described, including deep learning (DL) in wireless networks and federated learning for wireless networks. In both use cases, it is necessary to deploy AI tasks (i.e., deep learning and federated learning) and AI models from edge data networks (or core networks) to wireless devices. As shown in ETSI GR SAI 0010, it may be important to provide traceability to the deployed AI tasks and AI models, which requires that the AI tasks and AI models be traced during their life cycles and can be utilized as a basis for building auditable, explainable, and trustworthy AI.

[0096] Figure 5 shows two examples of DL application to a wireless network, where a UE hosts a DL agent that hosts an AI task. The AI task uses a DL model, learns a DL model, or both. The DL agent in each UE is either pre-installed or deployed at runtime. Note in Figure 5 that DL can be replaced with another type of AI algorithm. In this use case, the base station and each UE are AIH.

[0097] DL for wireless resource allocation: DL is used to learn the wireless resource allocation between UE-1 and the base station. For example, a DL agent (i.e., DLA4L) is deployed on an edge server located at the same location as the base station. The DL agent is composed of an AI task for learning a wireless resource allocation policy. Based on the historical transmission information regarding UE-1 (and / or other UEs) and the base station, the DL agent learns a model for allocating wireless resources to UE-1 (and / or UE-2). Then the learned model is deployed to UE-1 (and / or UE-2). For each new time slot, the DL agent (i.e., DLA4I) in UE-1 and / or UE-2 can use the model to determine new wireless resources for upstream transmission. Such an AI-based approach can capture wireless channel dynamics and changing traffic on the wireless channel more quickly and accurately, which can then lead to an improvement in wireless resource utilization.

[0098] DL for vehicle-to-vehicle content distribution: Three vehicles (i.e., UE-3, UE-4, and UE-5) are in the same vicinity and can communicate directly with each other to share content (e.g., media files). To distribute the content more efficiently, each vehicle has a DL agent (i.e., DLA4LI) installed, which learns social relationships and content popularity for example.

[0099] FIG. 6 shows an example of FL application to a wireless network, where each UE cooperates and participates in learning a global model and hosts an FL agent that uses the learned global model for inference. The FL agent in each UE is either pre-installed or deployed at runtime. In this case, each UE and the edge server are AIHs.

[0100] FL for Spectrum Management: FL is used to learn an accurate spectrum utilization model. Each UE (i.e., UE-1, UE-2, UE-3, and UE-4) hosts an FL agent (i.e., FLA4LI) that acts as an FLC to generate local model updates. The local model updates are sent to the edge server, which has an FL agent (i.e., FLA4L) mainly responsible for aggregating the local model updates from the UEs to generate global model updates. The global model updates are sent to the UEs to continue the next training round until the global model converges. Then, the converged final global model is sent to the FL agents in each UE, and each UE uses the FL agent together with the final global model to manage its local spectrum access.

[0101] In the foregoing AI use cases for wireless networks, the UE typically hosts an AI agent (e.g., AIA4L, AIA4I, or AIA4LI) that either learns a model, uses the model for knowledge inference, or participates in both. To deploy a specific AI approach for a wireless network, the AI agent (e.g., software) must first be installed on the corresponding UE and / or other network nodes such as an edge server. The AI agent then begins training an AI model that may request collection of training data. After the AI model is trained, the AI agent needs to test and validate the AI model against test data and validation data before the AI model is deployed (e.g., transferred from one AI agent to another). Finally, the deployed or transferred AI model can be used to infer and predict future knowledge from real data and take actions based thereon.

[0102] In particular, in a wireless environment where there are distributed parties and potential threats to AI agents and AI models such as data poisoning attacks, it may be important to make the entire AI system trustworthy. Therefore, one approach is to trace and document the entire AI system, which is called AI traceability. Such requirements for AI traceability can originate from AI agents, AI applications, or AI users. However, tracing the entire AI system can introduce significant overhead, especially in communication systems where network latency is an important parameter. Furthermore, it may not be necessary to trace each stage of the AI system. For example, in federated learning, the training stage is executed by multiple distributed nodes with more potential threats or risks, so tracing the training stage may be more important than the inference stage. In general, an efficient and flexible AI traceability method may be required, especially for wireless AI use cases. According to this principle, AI trace information or AI trace records or AI trace documents are information generated from tracing the AI system or AI pipeline.

[0103] AI management according to this principle mainly refers to multiple stages / operations / procedures. Examples include, but are not limited to, AI host registration for registering AIH in a repository, AI task deployment, AI model registration, AI model discovery, and AI model transfer / deployment. Existing AI management procedures are not aware of traceability. As a result, AI management becomes inefficient, the reliability of AI decreases, and ultimately, the user's trust in AI may be low. For example, an AI user may need to discover an AI model that supports traceability, which can provide better transparency and reliability to the AI user. However, AI model registration without awareness of traceability cannot indicate whether an AI model supports traceability, and thus cannot meet the needs of AI users. In addition, if traceability is not supported when an AI task / model is deployed, the AI task / model may be removed and may need to be redeployed later when traceability is required. In the worst case, due to the lack of traceability, an AI model / task may need to be (re)deployed and / or retrained multiple times, which introduces extra overhead in terms of repeated AI management procedures and consumed resources. Furthermore, each of these AI management stages / procedures may be performed by different physical nodes and / or logical nodes. For example, the training and knowledge inference in FIG. 5 for wireless resource allocation are performed by a base station and a UE, respectively. These physical nodes and / or logical nodes generally have different resources (e.g., computing power) that should be considered together in a unified manner to enable traceability-aware AI management.

[0104] Based on the above considerations, the following problems are identified.

[0105] Problem #1: How to design an AI management architecture that can flexibly trace an AI pipeline?

[0106] Real-world AI systems (e.g., FL systems) can be dynamic and of different types, for example, with respect to the type of AI task, the amount of available training data, the number of AI agents involved, and the capabilities of the AI agents involved. A traceability-aware AI management architecture should be applicable and adaptable to different AI systems, different AI tasks, and different AI agents. Such a flexible traceability-aware AI management architecture should also support different levels of traceability using different but appropriate traceability instructions (e.g., tracing the entire AI pipeline or tracing one stage of the pipeline), be able to generate appropriate AI trace records as needed, and / or be extensible in such a way. As an example, such a flexible traceability-aware AI management architecture can provide a common method / interface / procedure that can be utilized to enable the traceability of different AI systems based on their requirements.

[0107] To design a flexible traceability-aware AI management architecture, the following issues are considered.

[0108] Problem #2: Traceability-aware AI host registration.

[0109] When an AI host registers itself with an AI repository entity, in one way, it can represent the traceability capabilities of the AI host and how to expose those traceability capabilities to other entities.

[0110] Problem #3: Traceability-aware AI task deployment.

[0111] When an AI task is deployed, it may be important to explicitly and simultaneously configure traceability instructions for the AI task so that the AI task can automatically trace itself according to the configured traceability instructions.

[0112] Question #4: Traceabilityware AI Model Registration.

[0113] When an AI model is registered with an AI repository entity, in one way, appropriate trace instructions can be configured or associated with the AI model.

[0114] Question #5: Discovery and Deployment of Traceabilityware AI Models.

[0115] If an AI host discovers and requests to install / host an AI model, in one way, it can be ensured that the trace instructions of the discovered AI model match the trace capabilities of the AI host.

[0116] Summary Here, the following terms are defined as follows.

[0117] AI Model: A learned model (e.g., a set of parameters) from training data that can accurately model or capture patterns in the training data.

[0118] AI Task: A task for training an AI model and / or using a trained AI model. An AI task can be deployed to an AI host as software having associated information (e.g., an initial AI model, training data, and / or input data).

[0119] AI Agent: An entity that can execute an AI task. An AI agent is hosted by an AI host, and the AI host can host multiple AI agents. An AI agent can generate / train an AI model and / or use a trained AI model to infer knowledge.

[0120] AI Host: An entity having both software and hardware that supports one or more AI agents.

[0121] AI Repository: An entity that enables the registration of AI hosts and / or AI models, the discovery of AI hosts and / or AI models, etc.

[0122] AI Pipeline: A set of stages for executing one or more AI tasks. The AI pipeline may include one or more (e.g., all) of task configuration, data preparation, training for learning an AI model, verification for testing a trained AI model, model deployment for deploying and transferring a verified AI model, and inference for inferring and predicting future knowledge using new data as input.

[0123] AI Trace Manager: An entity that manages whether, when, how, and / or what to trace an AI pipeline. The AI Trace Manager may generate, configure, update, and remove trace instructions for / from an AI host, an AI agent, an AI task, and / or an AI model.

[0124] Trace Instruction: A specification, condition, criterion, policy, or rule for describing whether, when, how, and / or what to trace an AI pipeline. An AI agent (or an AI host) generates a trace record according to the configured trace instruction. The trace instruction can be called a trace condition, a trace criterion, a trace command, a trace rule, and / or a trace policy.

[0125] AI Manager: An entity that manages AI tasks, AI agents, AI hosts, AI repositories, and further the AI Trace Manager.

[0126] Distributed Storage System (DSS): A system that stores information (such as information about an AI model, information about an AI host, training data, inferred knowledge, trace instructions, trace records, etc.). The DSS can be a distributed database, a distributed ledger, a blockchain system, etc.

[0127] Traceability-aware AI Management Architecture AI management refers to operations for managing AI hosts, AI tasks, and AI models, such as AI host registration, AI task deployment, and AI model deployment. Conventional AI management solutions used to trace them after the AI tasks or AI models are deployed are called post-deployment tracing methods. This principle proposes a more proactive approach that enables or embeds AI traceability during AI management operations. For example, the post-deployment tracing method may fail if the deployed AI task does not support AI traceability. Furthermore, for example, the post-deployment tracing method may require extra overhead to modify or redeploy the deployed AI task to support AI traceability, which this principle can avoid or reduce. The traceability-aware AI management framework is proposed as a proactive tracing method that combines traceability enabling and AI management by considering together what needs to be traced (i.e., trace instructions) for AI tasks / models and the resources (i.e., trace capabilities) that an AI host can allocate or provide to trace the AI tasks / models it hosts. The proposed traceability-aware AI management framework can provide essential and common functions and interfaces that are not limited to a specific AI system / task / model (e.g., constructing trace instructions when constructing an AI task). Furthermore, the proposed traceability-aware framework enables configuring appropriate trace instructions for different AI hosts according to their trace capabilities and the characteristics of the AI tasks / models they host. Therefore, it may be possible to collect more useful trace information regarding the AI pipeline.

[0128] The proposed traceability-aware AI management is characterized by at least one of the following functions.

[0129] The AI Trace Manager (AITM) can provide and determine trace instructions for tracing AI tasks / models (e.g., for generating AI trace records for each training round) based on the trace instructions of the AI tasks / models and the trace capabilities of the AI host (AIH) that hosts the AI tasks / models (e.g., the storage available for storing the generated AI trace records). Note that the AIH can host one or more AI agents, which can be AIA4L, AIA4I, and / or AIA4LI.

[0130] The AIH can register its trace capabilities with the AI repository (AIR), and the AI repository can be published and discovered by both entities such as the AI manager (AIM). The AIH can be an AI model producer (AIMP) or an AI model user (AIMU). The AIMP can host one or more AIA4L or ALA4LI, and the AIMU can host one or more AIA4I. The AIR can publish each registered AIH to a distributed storage system (DSS) such as a distributed ledger system.

[0131] The AIM can enable traceability when deploying an AI task to the AIMP by constructing trace instructions using the AI task. The trace instructions match the trace capabilities that the AIMP can support.

[0132] The AIM can enable traceability when deploying an AI task to the AIMU by constructing trace instructions using the AI task. The trace instructions match the trace capabilities that the AIMU can support.

[0133] AIR can also maintain a list of AI models that AIMP generates and registers with AIR. When AIMP registers an AI model, AIMP can configure trace instructions for the AI model. AIMU can access AIR to discover an appropriate AI model that has trace instructions matching the tracing capabilities of AIMU. AIR can publish each registered AI model to a DSS such as a distributed ledger system.

[0134] If an AI task with trace instructions is installed in AIMP, AIMP executes the AI task and, during that time, generates an AI trace record according to the trace instructions configured in the AI task. The AI trace record is sent to a DSS such as a distributed ledger system.

[0135] After an AI task and the corresponding AI model with trace instructions are installed in AIMU, AIMU executes the AI task and, during that time, generates an AI trace record according to the trace instructions configured in the AI task / model. The AI trace record is sent to a distributed storage system (DSS) such as a distributed ledger system.

[0136] AIM can actively discover a new AI model and push it to an AIMU with new trace instructions.

[0137] AIMP can pre-register a partially trained AI model with AIR together with trace instructions, or notify AIMU of it. After the AI model is fully trained, AIMP can actively push the AI model to AIR or AIMU.

[0138] Figure 7 shows an embodiment of the proposed traceability-aware AI management architecture that includes several logical entities, including an AI Manager (AIM), an AI Trace Manager (AITM), an AI Repository (AIR), an AI Model Producer (AIMP), an AI Model User (AIMU), and a Distributed Data System (DDS). A notable feature of this architecture is the integrated AI pipeline management and traceability through the collaborative interaction between these logical entities. In other words, AI traceability can be effectively enabled in the proposed architecture in the process of managing AI tasks and models. Note that the AIMU and AIMP in Figure 7 can be combined to host and support the AIA4LI agent.

[0139] AI Task: An AI task can be installed as part of an AI agent in a particular AI Model Producer (AIMP) or a particular AI Model User (AIMU) for that AIMP or that AIMU. The AIMP has an AI agent for learning (AIA4L), which is used to 1) train and generate an AI model and 2) generate an AI trace record according to the installed trace instructions. In contrast, the AIMU has an AI agent for inference (AIA4I), which is used to 1) infer knowledge based on the installed AI model and input data for inference and 2) generate an AI trace record according to the installed trace instructions. The AIMU and AIMP can be collocated within the same physical node, such as a UE or an edge server. To support AI traceability and AI management, each AI agent (or AI task executor) can support a new Application Programming Interface (API).

[0140] As an example, it is possible to communicate with AI tasks using the following three APIs that can be implemented as a single API. When implemented as a single API, the request can indicate which of the following API functions are triggered.

[0141] TRACE-INSTRUCTION-CONFIG-API (Trace-Instruction-Configuration-API): This API enables other entities such as an AI Manager (AIM) or an AI Trace Manager (AITM) to configure one or more trace instructions to an AI agent. When the AI agent executes the corresponding AI task, the AI agent generates an AI trace record according to the trace instructions.

[0142] TRACE-RECORD-MGMT-API (Trace-Record-Management-API): This API enables other entities to retrieve / delete the generated AI trace record, or enables the AI agent to actively push the generated AI trace record to other entities (e.g., DSS or AIM) via this interface.

[0143] MODEL-MGMT-API (Model-Management-API) An AI task for inferring knowledge (i.e., AIA4I) may have this additional API that enables other entities (e.g., AIM, AIH) to dynamically configure / update / retrieve the AI model used by the AI agent. This API can configure both the trace instructions related to the AI model and the AI model itself simultaneously, especially when the TRACE-INSTRUCTION-CONFIG-API is not available.

[0144] Each API can be described, for example, using the following API information (referred to as API-Info). API endpoints for communication (e.g., URIs, FQDNs, IP addresses, etc.), API transport information, such as the type of protocol (e.g., REST / HTTP, CoAP, Topic-based, Pub Sub, RPC, WebSocket, etc.), security-related information (e.g., security authentication credentials, certificates, public keys, etc.), version, and so on.

[0145] The API-Info of each API can be shared with and / or composed of another entity (e.g., AI manager, AI trace manager, AI repository, etc.).

[0146] AI Model: The AI model can be generated by the AIMP, which has an AI agent that executes AI tasks to train an AI model (e.g., a set of DNN parameters / weights) according to the corresponding AI algorithm (e.g., DNN backpropagation). The stand-alone AIMP can generate an AI model independently. Multiple AIMPs can also train an AI model collaboratively, and the trace instructions can be defined and created by the AIM in this case. For example, in the FL setting, the FL server and FL clients cooperate to generate a converged global AI model. The AIMU can use the AI model generated to infer knowledge based on the actual data input, and multiple AIMUs can use the same AI model with different data inputs. The content of the AI model can include its own trace instructions and requirements (Trace-Instructions), and based on which AI task is using this AI model, each AI task can generate an AI trace record accordingly. The status of the AI model in the AIMP can be, for example, 1) fully trained (the AI model is fully trained and verified and can be deployed to infer knowledge) or 2) partially trained (the AIMP has not completed the training or verification of the model and cannot be deployed or used to infer knowledge).

[0147] AI Trace Instruction (ATI): The AI trace instruction describes how the AI process and the information resulting from the AI task (e.g., model weights, inference results, etc.) should be recorded under what conditions for traceability. The AI trace instruction and the trace instruction are used interchangeably in this disclosure.

[0148] AI Manager (AIM): The AIM maintains a list of AI tasks. The main purpose of the AIM is to enable AI traceability while managing AI tasks and models. Specifically, the AIM is responsible for requesting trace instructions from and receiving trace instructions from the AI Trace Manager (AITM), discovering the AI Model Producer (AIMP) from the AIR, installing AI tasks to the AIMP, discovering and downloading AI models from the AI Repository (AIR), discovering the AI Model User (AIMU) from the AI Repository (AIR), and installing AI tasks and AI models to the AIMU.

[0149] As an example, first, the AIM requests or receives trace instructions from the AI Trace Manager (AITM) for one or more AI tasks. The AITM can also actively retrieve AI tasks from the AIM and then construct appropriate trace instructions for each task. The trace instructions can be applied to one or more AI tasks. As a result, each trace instruction includes a list of AI task IDs indicating the AI tasks to which the trace instruction can be applied. One AI task can be applied or executed with multiple trace instructions.

[0150] Next, the AIM decides to install the selected AI task to the AIMP. The AIM discovers the AIMP for the selected AI task from the AIR. The AIM generates an AI task package that includes the AI task itself (i.e., software code with any necessary configuration files) and the applicable trace instructions received from the AITM. The AIM sends the AI task package to the AIMP, and the AIMP locally installs the AI task package to its AI agent. Thereafter, the AIM and the AITM can reconfigure new trace instructions to the AI task via its TRACE-CONFIG-API (Trace-Configuration-API).

[0151] Similar to installing an AI task on AIMP, AIM can install another AI task on AIMU, and the trace instructions are embedded in the AI task package sent to AIMU. AIM can discover AIMU from AIR. The AI task package sent to AIMU can include one or more AI models that AIM can discover and download from AIR. If the AI task package does not include an AI model, AIMU can discover and download an AI model from AIR. Alternatively, AIM or AIR can configure an AI model for the AI task installed on AIMU via its MODEL-MGMT-API.

[0152] AI Trace Manager (AITM): AITM enables AI traceability as part of AI management. AITM can be a management application or implemented as part of AIM. AITM is mainly responsible for configuring trace instructions for one or more AI tasks via AIM, AIMP, and / or AIMU. AITM can update or delete any configured trace instructions from AIM, AIMP, and / or AIMU. Further, AITM can manage AI trace records stored in a distributed storage system (DSS).

[0153] AITM can discover an AI task from AIM and determine applicable trace instructions for the AI task according to the supplied policy. Alternatively, AIM can request an AI task from AITM and retrieve its trace instructions.

[0154] AITM can update and remove any configured trace policy for the AI task installed on AIMP via its TRACE-MGMT-API.

[0155] AITM can update and delete any configured trace policy for AI tasks installed in AIMU via its TRACE-MGMT-API.

[0156] AITM can query, retrieve, aggregate, and even modify AI trace records stored in DSS.

[0157] AI Repository (AIR): AIR maintains a list of registered AI models. AIR can also maintain a list of potential AIMPs and AIMUs. AIR is mainly responsible for the following operations.

[0158] An AIMP can register itself and / or its model with the AIR, thereby indicating 1) whether it can be used as an AIMP and host AI tasks to train an AI model, and / or 2) whether it has a trained AI model to be registered with the AIR. During this registration with the AIR, the AIMP can also indicate its trace capability, which can be described as the amount of available computing / storage / communication resources that the AIMP can allocate to trace AI tasks in the AIMP.

[0159] An AIMU can register itself and / or its model with the AIR, thereby indicating 1) whether it can be used as an AIMU and host AI tasks to infer knowledge using an AI model, and / or 2) whether it has installed any AI model for knowledge inference. During this registration with the AIR, the AIMU can also indicate its trace capability, which can be described as the amount of available computing / storage / communication resources that the AIMU can allocate to trace AI tasks in the AIMU.

[0160] AIMU can actively discover and download an AI model from the AIR for an AI task (i.e., an AI agent) installed in the AIMU. During this process, the AIR can either compose new trace instructions for the AI task in the AIMU or update existing trace instructions.

[0161] The AIR can also store a list of registered AI models, a list of registered AIPs, and a list of registered AIMUs in the DSS. In this case, the AIM can directly discover an AI model, an AMIP, and / or an AIMU from the DSS. The AIMU can also directly discover and download an AI model from the DSS.

[0162] AI Model Producer (AIMP): The AIMP can host an AI task to train and generate an AI model while supporting AI traceability processed by an AI agent for learning (AIA4L). To achieve this purpose, the AIMP can interact with other entities as follows.

[0163] Before an AI task is installed, the AIMP can register itself with the AIR along with its traceability capability, so that the AIM (and / or AITM) can find the AIMP, and the AIM can assign an appropriate AI task that matches its traceability capability to the AIMP (and / or the AITM can assign trace instructions to the AIMP).

[0164] After the AI task is installed, AIMP executes the AI task to train the AI model specified by the AI task. AIMP can generate an AI trace record while training the model according to the trace instructions associated with the AI task. AIMP can store the generated AI trace record in the DSS. AIMP can also manage (e.g., query, retrieve, aggregate, modify, delete) those AI trace records stored on the DSS.

[0165] After the AI model is trained, AIMP can register the AI model with the AIR, wait for the AIMU to download the AI model, and / or actively push the AI model to the AIMU. How to process the generated AI model may be described as part of the AI task.

[0166] When or after AIMP executes the AI task to train the AI model, the AITM and / or AIM can update the trace instructions associated with the AI task.

[0167] AIMP can have an embedded AITM, which manages the traceability of the AI agent in AIMP and / or other AI agents that use the AI models provided by AIMP.

[0168] AI Model User (AIMU): The AIMU hosts the AI task, which infers knowledge using the AI model. The AIMU can support AI traceability during such knowledge inference. The AI traceability function during knowledge inference is processed by the inference AI agent (AIA4I). To achieve this purpose, the AIMU can interact with other entities as follows.

[0169] Before the AI task is installed, the AIMU can register itself with the AIR along with its trace - capability. As a result, the AIM (and / or AITM) can find the AIMU, and the AIM can assign an appropriate AI task that matches the Trace - Capability of the AIMU to the AIMU (and / or the AIM can assign a trace instruction to the AIMU).

[0170] If the installed AI task does not come with an AI model or if the AI model needs to be updated, the AIMU can discover and download a new AI model from the AIR.

[0171] Next, the AIMU can execute the AI task to infer knowledge. The AIMU can generate an AI trace record during this inference stage according to the trace instructions associated with the AI task. The AIMU can store the generated AI trace record in the DSS. The AIMU can also manage (e.g., query, retrieve, aggregate, modify, delete) those AI trace records stored on the DSS.

[0172] When or after the AIMU executes an AI task and uses the associated AI model to infer knowledge, the AITM and / or AIM can update the trace instructions associated with the AI task.

[0173] In addition, the AIMU can discover, download, or receive an AI model directly from the AIMP.

[0174] Distributed Storage System (DSS): The DSS stores the AI trace records transmitted from the AIMP and / or AIMU. The DSS can also store repository information regarding the AIR (for example, a list of registered AI models, a list of registered AIMPs, a list of registered AIMUs). Furthermore, the DSS also supports the AITM to manage the AI trace records stored on the DSS. The DSS can be, for example, a distributed ledger system, a blockchain system, a distributed file system, or a distributed database, but is not limited thereto.

[0175] According to this principle, the addresses and / or identifiers of logical entities (for example, AI hosts, AI agents, AI tasks, AIMUs, AIMPs, AIMs, AITMs, AIRs, DSSs, APIs, etc.) or information objects (for example, AI models, trace records, trace instructions, AIH records, AI model records, training data, input data, inference knowledge, transactions on the ledger, blocks on the ledger, smart contracts on the ledger, etc.) may also be called endpoints and may be, for example, Uniform Resource Identifiers (URIs), Fully Qualified Domain Names (FQDNs), IP addresses, port numbers, and / or combinations thereof.

[0176] Next, based on the exemplary architecture of FIG. 7, the following features and corresponding procedures according to this principle will be described. Traceability-aware AI host registration, traceability-aware AI task deployment, traceability-aware AI model registration, traceability-aware AI model discovery and registration.

[0177] As a first example, the exemplary architecture of FIG. 7 can be deployed in the future wireless system shown in FIG. 8. In this first example, AIM and AITM are deployed together (or separately) as a single network function within the core network or cloud network, AIR-1 is co-located with edge server-1, AIR-2 is co-located with edge server-2, and AIR-1 and AIR-2 can communicate directly with each other to exchange any information (e.g., AIH records) maintained within both AIRs. Further, each AIH is co-located with a UE, the AIH under base station-1 registers with AIR-1, and the AIH under base station-2 registers with AIR-2. AIH-1 and AIH-2 can communicate with each other, for example, to exchange AI models and / or inferred knowledge, directly and / or assisted by AIR-1 / AIM / AITM. AIH-3 and AIH-4 can communicate with each other, for example, to exchange AI models and / or inferred knowledge, directly and / or assisted by AIR-2 / AIM / AITM. AIM can communicate directly with each AIH (e.g., to install AI tasks on each AIH) without going through any AIR. AITM can communicate directly with each AIH (e.g., to configure trace instructions on each AIH) without going through any AIR.

[0178] As a second example, the exemplary architecture of FIG. 7 can be deployed in a future wireless system as shown in FIG. 9. In this second example, AIR and AITM are deployed together (or separately) as a single network function within a core network or a cloud network, AIM-1 is collocated with edge server-1, AIM-2 is collocated with edge server-2, and AIM-1 and AIM-2 can communicate directly with each other to exchange any information (e.g., AI tasks) maintained within both AIMs. Each AIH is collocated with a UE. The AIH under base station-1 is managed by AIM-1, and the AIH under base station-2 is managed by AIM-2. AIH-1 and AIH-2 can communicate with each other directly and / or assisted by AIM-1 to exchange, for example, AI models and / or inferred knowledge. AIH-3 and AIH-4 can communicate with each other directly and / or assisted by AIM-2 to exchange, for example, AI models and / or inferred knowledge. Each AIH can communicate directly with AIR (e.g., to register the AIH with AIR) without going through any AIM. AITM can communicate directly with each AIH (e.g., to configure trace instructions for each AIH) without going through any AIM.

[0179] Traceability Aware AI Host Registration An AI host (AIH) can be an AIMP for training an AI model or an AIMU for using an AI model to infer knowledge. The AIH can register itself with AIR so that it can be discovered by an AIM before the AIM can install an AI task on the AIH. During such AIH registration, the AIH indicates its AI capabilities and trace capabilities to AIR. AIR can maintain a list of registered AIH records that are disclosed to AIMs and / or other entities. Note that the AIH may be preconfigured with the address of AIR or with an entity by which the AIH can discover AIR.

[0180] Figure 10 shows an embodiment of a method for registering traceability ware AIH.

[0181] In step S1002, AIH1001 sends a message for registering AIH1001 with AIR1003 to AIR1003, and AIR1003 receives the message. This message may include one or more of the following parameters.

[0182] AIH-ID: The identifier or address of the AIH. If the AIH is a blockchain node or a user, its blockchain address (for example, a unique identifier generated from its public key) can be used as the AIH-ID.

[0183] AIH-Type: Indicates whether the AIH is AIMP, AIMU, or both.

[0184] AI-Capability (AI-capability): The capabilities and available resources that the AIH can allocate to host AI tasks. This parameter may include, for example, one or more of the following training data properties: 1) a computational resource budget for executing AI tasks, 2) a memory resource budget for executing AI tasks, and 3) the number of data samples and the number of features in the data samples. If the AIH is already hosting an AI task, the AI capabilities may indicate, but are not limited to, 1) a unique identifier of the hosted AI task (AI task ID), 2) the type of the hosted AI task (AI task type) as defined in step S1202 of Figure 12, and 3) additional information including API information of the MODEL-MGMT-API.

[0185] Trace-Capability: The capabilities and available resources that the AIH can allocate to trace AI tasks. This parameter can include, but is not limited to: 1) the computational resource budget for tracing AI tasks, 2) the memory resource budget for tracing AI tasks, 3) whether the AIH has an interface to other external entities for storing DSS or AI trace records, 4) communication capabilities such as the bandwidth that the AIH can use to send AI trace records to DSS or other entities, 5) the supported communication modes for other entities to obtain AI trace records (e.g., push or pull), 6) whether the AIH intends to trace "training data" if it is an AIMP, or whether the AIH intends to trace "input data for inference" if it is an AIMU. If the AIH is already hosting an AI task, Trace-Capability can indicate additional information regarding the traceability of the hosted AI task, including, for example, one or more of the following: 1) API-Info of the TRACE-INSTRUCTION-CONFIG-API, 2) API-Info of the TRACE-RECORD-MGMT-API, 3) which parts of the AI pipeline of the AI task can be traced, 4) the trace instructions configured in the hosted AI task, and 5) statistical information regarding the AI trace records generated during the period of the hosted AI task (e.g., how frequently the AI task generated AI trace records during that period, the number of AI trace records generated during that period, where the generated AI trace records were stored, etc.).

[0186] Training-Data-Info (Training-Data-Information): When the AIH is an AIMP and has local training data, the AIH uses the Training-Data-Info parameter to indicate metadata information about the training data (e.g., the type of training data, the amount of training data, the characteristics of the training data, the time when the training data was generated or collected, the location where the training data can be retrieved, etc.).

[0187] Input-Data-Info (Input-Data-Information): When the AIH is an AIMU and has local input data for inferring knowledge, the AIH uses the Input-Data-Info parameter to indicate metadata information about the input data (e.g., the type of input data, the characteristics of the input data, the freshness of the input data, etc.).

[0188] AIM-ID: The identifier or address of the AIM that controls and manages the AIR. For example, when the AIH re-registers itself with the same or a different AIR, the AIH already knows the AIM-ID and can include the AIM-ID in the current registration request. In another example, the AIM-ID can be pre-installed or provided together with the AIH.

[0189] Step S1004: When the registration request from step 1 is approved (e.g., after the AIR1003 verifies, authenticates, and / or authorizes the registration request received from step S1002), the AIR can generate a new AIH-ID for the AIH. The AIR can assign an AIM and an AITM to the AIH. When the AIH is an AIMP, the AIR can recommend an AIMU to the AIH from its local repository. When the AIH is an AIMU, the AIR can recommend an AMIP to the AIH from its local repository. Next, the AIR creates an AIH record for the AIH and stores the AIH record, for example, in its local repository. The AIR can publish the AIH record to the DSS or an AIM. This AIH record includes, for example, -AIH-ID: The AIH-ID received in step S1002 or generated in step S1004. -AIH-Type: That received in step S1002. -AI-Capability: That received in step S1002. -Trace-Capability: That received in step S1002. -AIM-ID: That received in step S1002, or may include one or more of the identifier and / or address of the AIM assigned to the AIH by the AIR. -AITM-ID: The identifier and / or address of the AITM assigned to the AIH by the AIR. -AIMP-ID: The identifier and / or address of the AIMP recommended by the AIR to the AIH when the AIH is an AIMU. -AIMU-ID: The identifier and / or address of the AIMU recommended by the AIR to the AIH when the AIH is an AIMP.

[0190] AIR can store the created AIH records in a DSS (e.g., a distributed ledger). For this purpose, AIR creates a transaction Txt-Example that can include the entire created AIH record or a part of it. AIR sends the transaction to the DSS, and the DSS adds the transaction to a ledger structure (e.g., a blockchain, a block-directed acyclic graph, a blockless directed acyclic graph) after a consensus protocol. When the transaction is added to the ledger structure, the transaction has a transaction sequence number (i.e., Transaction-Seq-Num) and / or an associated block sequence number (i.e., Block-Seq-Num) if the ledger uses a block-based structure. Transaction-Seq-Num and Block-Seq-Num uniquely identify the transaction Txt-Example stored on the ledger. The DSS can return Transaction-Seq-Num and / or Block-Seq-Num to AIR. Any entity including AIR can use Transaction-Seq-Num and Block-Seq-Num to retrieve the transaction Txt-Example from the ledger. AIR can include Transaction-Seq-Num and Block-Seq-Num in the response message sent to the AIH.

[0191] In step S1006, AIR sends a response to the AIH. This response can include, for example, - AIH-ID: A new AIH-ID if generated in step S1004. - AIM-ID: From the AIH record generated in step S1004. - AITM-ID: From the AIH record generated in step S1004. - AIMP-ID: From the AIH record generated in step S1004. - AIMU-ID: One or more of those from the AIH record generated in step S1004. -AIH-Record-ID (AIH - Record - ID): The identifier and / or address of the AIH record created in step S1004.

[0192] Note that if the AIH has an AI capability and / or traceability capability that has been changed, the AIH can update the AIR with its new AI capability and / or traceability capability using the method of Figure 10. Similarly, the AIH can register itself with the AIM and simply replace the AIR with the AIM using the method of Figure 10. In step S1002, the AIH can also request the AIR to delete itself from the local repository of the AIR by adding an unregistration indicator.

[0193] Figure 11 shows an embodiment of the traceability aware AI host registration via the DSS according to this principle. In this case, the AIH stores its registration information in the DSS (e.g., a distributed ledger) and passes the DSS transaction and block sequence number to the AIR at the time of registration. Such an approach can provide better immutability and reliability compared to the method shown in Figure 10.

[0194] In step S1102, the AIH1101 can generate a transaction and send the transaction to the DSS1103. The transaction can include, for example, one or more of the following. -AIH-ID: The same as in step S1002 of Figure 10. -AIH-Type: The same as in step S1002 of Figure 10. -AI-Capability: The same as in step S1002 of Figure 10. -Trace-Capability: The same as in step S1002 of Figure 10. -Training-Data-Info: The same as in step S1002 of Figure 10. -Input-Data-Info: The same as in step S1002 of Figure 10. -Smart-Contract (Smart-Contract): Information indicating the intention and contract of the AIH for hosting AI tasks. The AIH can include multiple smart contracts in a transaction. Each smart contract may include one or more of the following. ·Desired-AI-Task (Desired-AI-Task): Indicates the type of the desired AI task. Potential types of AI tasks are described in the section titled "Traceability Aware AI Task Deployment". ·Requested-Payment (Requested-Payment): Indicates the payment that the AIH wishes to collect when the AIH hosts and executes the desired AI task. If the desired AI task is for training an AI model and the AIH provides training data, the AIH can request additional or different payment. ·AI-Task-Address (AI-Task-Address): Indicates the address (e.g., software code) of the AI task that the AIH can download. This is an input parameter of this smart contract. For example, after this smart contract is published to the DSS, the AIM can discover this smart contract. If the AIM wants to trigger this smart contract to deploy the target AI task to the AIH, the AIM needs to provide the address of the target AI task to this smart contract via this input parameter "AI-Task-Address". ·AI-Model-Contract-Address (AI-Model-Contract-Address): Indicates the address of another smart contract for using or deploying the AI model. This is an input parameter. When this smart contract is triggered by AIM (or other entity), AIM can provide "AI-Model-Contract-Address" as an input parameter to the smart contract of this AIH. As a result, the AIH can execute the smart contract to perform an AI task for generating the AI model. In this case, the AI model can be automatically sent as an input parameter to another smart contract as indicated by "AI-Model-Contract-Address".

[0195] When DSS1103 supports a distributed ledger function such as a blockchain, the transaction is added to the distributed ledger after a specific consensus protocol or mechanism. After the transaction is added to the distributed ledger, DSS1103 sends a response to the AIH in step S1104. The response can include, for example, the following. -Transaction-Seq-Num (Transaction-Sequence-Number): The sequence number of the transaction added to the distributed ledger. -Block-Seq-Num (Block-Sequence-Number): The sequence number of the block in which the transaction was included.

[0196] Note that there is a possibility that DSS may not send a response to the AIH that can still obtain Transaction-Seq-Num and Block-Seq-Num from observing the progress of the distributed ledger.

[0197] In step S1106, the AIH sends a request to register itself to AIR1105. This request can include, for example, the following -AIH-ID: The same as that in step S1102. -AIH-Type: The same as that in step S1102. -Transaction-Seq-Num: The same as that in step S1104. -Block-Seq-Num: The same as that in step S1104.

[0198] In step S1108, AIR1105 can send a request to DSS1103 to retrieve additional information about AIH1101 (e.g., other parameters included in step S1102 such as AI capabilities and trace capabilities). This request can include Transaction-Seq-Num and Block-Seq-Num, as well as the names of other parameters to be retrieved.

[0199] DSS1103 uses identifiers (e.g., Transaction-Seq-Num and Block-Seq-Num) to find the corresponding transaction created in step S1104 and extracts the information requested from this transaction. In step S1110, DSS1103 sends a response containing the requested information to AIR1105.

[0200] In step S1112, similar to step S1004 in Figure 10, AIR1105 creates an AIH record for AIH1101. This AIH record can be simpler than that described with reference to Figure 10 and can include the following. -AIH-ID: The same as that in step S1106. -Transaction-Seq-Num: The same as that in step S1106. -Block-Seq-Num: The same as that in step S1106. -AIM-ID: The identifier and / or address of the AIM that the AIR assigns to the AIH. -AITM-ID: The identifier and / or address of the AITM that the AIR assigns to the AIH. -AIMP-ID: When AIH is AIMU, the identifier and / or address of the AIMP recommended by AIR to AIH. For this purpose, AIR may contact DSS to retrieve detailed information about other AMIPs. -AIMU-ID: When AIH is AIMP, the identifier and / or address of the AIMU recommended by AIR to AIH. For this purpose, AIR may contact DSS to retrieve detailed information about other AMIUs.

[0201] In step S1114, AIR1105 sends a response to AIH1101. This response may include the following. -AIM-ID: Similar to that in step S1112. -AITM-ID: Similar to that in step S1112. -AIMP-ID: Similar to that in step S1112. -AIMU-ID: Similar to that in step S1112. -AIH-Record-ID: The identifier and / or address of the AIH record created in step S1112.

[0202] In step S1116, AIM1107 (or another AIH) sends a request to AIR1105 to discover one or more target AIHs. The request can include a discovery filter (e.g., wildcards for the AIH-Type and / or AIH-ID of the target AIH).

[0203] AIR1105 uses the discovery filter to examine the AIH records and find the target AIHs. For each discovered target AIH, AIR can include the following information in the response sent to AIM1107 (or another AIH) in step S1118. -Transaction-Seq-Num: The sequence number of the transaction containing detailed information about the target AIH. -Block-Seq-Num: Sequence number of the block containing the transaction related to the target AIH. -AIH-ID: Identifier or address of the target AIH. -AIH-Type: Type of the target AIH.

[0204] Similar to other embodiments, Transaction-Seq-Num and Block-Seq-Num are examples of information that can constitute a ledger identifier.

[0205] In step S1120, similar to step S1108, AIM1107 (or another AIH) sends a request to DSS1103 to retrieve additional information about each discovered target AIH.

[0206] In step S1122, similar to step S1110, DSS1103 that has retrieved the requested information sends a response containing additional information about the discovered target AIH to AIM1107 (or another AIH).

[0207] Traceabilityware AI Task Deployment Four embodiments of traceabilityware AI task deployment will be described. FIG. 12 shows AIH-initiated traceabilityware AI task deployment. FIG. 13 shows AIM-initiated traceabilityware AI task deployment. FIG. 14 shows AIH-initiated traceabilityware FL task deployment. FIG. 15 shows AIM-initiated traceabilityware FL task deployment.

[0208] AIH-Initiated Traceabilityware AI Task Deployment The AI host (AIH) (AIMP or AIMU) actively requests AI tasks from the AIM. The AIH first presents the requested AI task, its AI capabilities, and its tracing capabilities to the AIM. Next, the AIM approves and determines the appropriate AI task according to the AI capabilities of the AIH. The AIM also obtains trace instructions from the AITM for the AI task according to the tracing capabilities of the AIH. These trace instructions are simultaneously sent to the AIH during the deployment of the AI task to the AIH. The AIM creates an AI task record for each AI task being deployed to the AIH. The AIM can store the AI task record locally and / or in other entities (e.g., DSS). It is assumed that 1) the AIM is provided to the AIH and the AIH knows the address of the AIM, and 2) the AITM is provided to the AIM and the AIM knows the address of the AITM. Note that the AIM and the AITM can be implemented together as one physical node or logical node.

[0209] FIG. 12 shows a method for AIH-initiated tracerability-aware AI task deployment according to one embodiment.

[0210] In step S1202, the AIH 1201, for example, an AI model user or an AI model producer, sends a request message to the AIM 1203 to request an AI task to be deployed to the AIH 1201. This message may include one or more of the following. - AI-Task-ID (AI-task ID): A unique identifier or address of the AI task to be deployed. If this parameter is included in the message, further parameters can be omitted. - AIH-ID: An identifier or address of the AIH 1101. -AI-Task-Type: The type of AI task required by AIH1101. AI-Task-Type can indicate whether the requested task is for model training, knowledge inference, or both. AI-Task-Type can also indicate whether the requested AI task is a DL task, an FL task, an RL task, or other types. AI-Task-Type can also indicate the purpose of the requested AI task (e.g., regression, classification, clustering, etc.). AI-Task-Type can also indicate the application category of the requested AI task (e.g., natural language processing, text processing, image processing, video processing, etc.). -AI-Task-Size-Threshold (AI-Task-Size-Threshold): AIH1101 requires that the size of the AI task it requests should be less than the AI-Task-Size-Threshold. The size of the AI task usually depends on the size of the software code and the size of any related data. -AI-Capability: The capabilities and available resources that AIH1101 can allocate to host an AI task. This parameter can indicate, for example, 1) the computational resource budget for executing the AI task, 2) the memory resource budget for executing the AI task, and 3) training data properties such as the number of data samples and the number of features in the data samples, but is not limited to these. -Trace-Capability: The capabilities and available resources that AIH1101 can be assigned to trace AI tasks. This parameter can indicate, for example, 1) the computational resource budget for tracing AI tasks, 2) the memory resource budget for tracing AI tasks, 3) whether AIH1101 has an interface to other external entities for storing DSS or AI trace records, 4) communication capabilities such as the bandwidth that AIH1101 can use to send AI trace records to DSS or other entities, 5) the supported communication modes (e.g., push or pull) for other entities to obtain AI trace records, 6) whether AIH1101 wants to trace "training data" if AIH1101 is an AIMP, or whether AIH1101 wants to trace "input data for inference" if AIH1101 is an AIMU, but is not limited thereto. -AITM-ID: The identifier or address of AITM1205. This parameter, which is optional, can be used by AIH1101 to specify a particular AITM if it is known.

[0211] Note that the AI tasks to be deployed can be uniquely identified by the AI-Task-ID. Alternatively, AIM1203 can identify one or more AI tasks that can be selected for the AIH using a combination of multiple other parameters (e.g., AI-Task-Type and AI-Task-Size-Threshold) in step S1202.

[0212] In step S1204, based on parameters received in step S1202, such as AI-Task-Type and AI-Capability, AIM1203 selects (i.e., determines) an AI task for AIH1101. AIM1203 generates a unique identifier (AI-Task-ID) for the selected AI task, which may be based on AIH-ID, AI-Task-Type, other parameters from the request in step S1202, and / or other local information in AIM1203. Note that each AI task stored in AIM1203 may have an associated AITM1205 through which AIM1203 can request the corresponding trace instruction.

[0213] In step S1206, AIM1203 sends a message requesting a trace instruction for the selected AI task to AITM1205. This message may include AIH-ID, Trace-Capability, and AI-Task-Type, similar to step S1202.

[0214] AITM1205 receives the message and determines a trace instruction for AIH1201 to trace the requested AI task. This determination can be based on parameters such as AIH-ID, Trace-Capability, and AI-Task-Type received in the message in step S1206. AITM1205 sends a response message to AIM1203. The response message includes the determined trace instruction (i.e., Trace-Instructions) for AIH1201. The trace instruction can include one or more trace instructions. Each trace instruction (TI(i)) can include, for example, the following parameters. -Trace-Instruction-ID (trace-instruction-ID): A unique identifier of TI(i) (statistically or probabilistically). As an example, a hash of the TI(i) content along with additional information can be used as the unique identifier. -Trace-Scope (Trace - Scope): The trace scope of the selected AI task. The trace scope can be one or more of the following: 1) for all training rounds or selected training rounds; 2) for all iterations of knowledge inference or selected iterations of knowledge inference; 3) the training data used in a training round; 4) the correlation between the training data and the corresponding model updates (e.g., gradients of the DNN model) in a training round; 5) partial or complete model updates generated in a training round; 6) the trend of model accuracy during training; 7) the model convergence speed during training; 8) the trained model for testing and validation; 9) failures during the testing and validation stage; 10) the final trained model; 11) other statistics for the training stage (e.g., the distribution of the training data used, the weight distribution of the final model if it is a DNN model, etc.); 12) the model used for knowledge inference; 13) the input data for inference; 14) the inferred knowledge; 15) the correlation between the input data for inference and the inferred knowledge; 16) the discrepancy between the inferred knowledge and the actions taken by the AIMU, which may or may not be based on the inferred knowledge; and 17) other statistics for knowledge inference (e.g., the distribution of the input data used for inference, the distribution of the inferred knowledge, time / location information regarding when / where the knowledge inference is triggered, etc.). -Trace-Record-Format (Trace - Record - Format): Defines the format (e.g., Concise Binary Object Representation (CBOR), JavaScript Object Notation (JSON)) and metadata for the generated AI trace record. The metadata of the trace record (TR(j)) can include, but is not limited to, the following parameters. ·Trace-Record-Creator (Trace - Record - Creator): The identifier of the AIH that creates TR(j). ·Trace-Record-Creation-Time (Trace-Record-Creation-Time): The time when TR(j) is created. ·Trace-Record-Creation-Location (Trace-Record-Creation-Location): The location of the AIH when it creates TR(j). This parameter can be useful for capturing the instantaneous position if the AIH is not stationary. ·Trace-Record-Identifier (Trace-Record-Identifier): An identifier for TR(j), such as an address or a Uniform Resource Identifier (URI), through which TR(j) can be accessed. This parameter may be blank if TR(j) is not stored locally in the AIH that creates it. ·Trace-Record-Content-Type (Trace-Record-Content-Type): The type of content included in TR(j), which can be one or a combination of types such as training data, AI model updates, final AI models, input data for inference, inferred knowledge, model training statistics, knowledge inference statistics, etc. -Trace-Record-Creation-Condition (Trace-Record-Creation-Condition): Describes the conditions under which a new trace record is created by the AIH. The conditions can be based on, but are not limited to, one or more of the following parameters. ·Trace-Record-Creation-Time-Windows (Trace-Record-Creation-Time-Windows): The time window during which the AIH creates a trace record according to the following parameters. ·Trace-Record-Creation-Frequency (Trace-Record-Creation-Frequency): The frequency at which trace records are created periodically. ·AI-Model-Training-Accuracy-Range (AI-Model-Training-Accuracy-Range): When the instantaneous accuracy of the AI model during training (i.e., calculated based on the loss function) is within the range defined by AI-Model-Training-Accuracy-Range, a new trace record is created. ·AI-Model-Test-Accuracy-Range (AI-Model-Test-Accuracy-Range): When the tested accuracy of the AI model under test data is within the range defined by AI-Model-Test-Accuracy-Range, a new trace record is created. ·AI-Model-Test-Failure-Threshold (AI-Model-Test-Failure-Threshold): When the number of failures occurring at the test stage exceeds the threshold as defined by AI-Model-Test-Failure-Threshold, a new trace record is generated. ·AI-Model-Attack-Detection (AI-Model-Attack-Detection): When a backdoor or other data poisoning attack is detected by AIH based on the attack detection algorithm, a new trace record is generated. -Trace-Record-Forwarding-Address (Trace-Record-Forwarding-Address): Indicates the location and / or address for storing the created trace record. This parameter may be empty or simply indicate "LOCAL". As a result, the AIH using this trace instruction only stores any created trace records locally. This parameter can include the address of an external entity (e.g., DSS) to which the AIH using this trace instruction forwards any created trace records. -Trace-Record-Forwarding-Condition (Trace-Record-Transfer-Condition): This describes the conditions under which the AIH transfers the created trace record to an external entity as indicated by the Trace-Record-Storage-Address. The conditions can be based on one or more of the following. ·Trace-Record-Maximum-Buffer-Time (Trace-Record-Maximum-Buffering-Time): Indicates the maximum time that the AIH can buffer the trace record locally before transferring it to an external entity. ·Trace-Record-Forwarding-Frequency (Trace-Record-Transfer-Frequency): Indicates how quickly the AIH transfers the generated trace record. For example, the AIH can transfer M trace records together to an external entity each time M new trace records are created. M is included in the Trace-Record-Forwarding-Frequency. -Trace-Record-Forwarding-Metadata (Trace-Record-Transfer-Metadata): Indicates the metadata required by the external entity when the AIH transfers the trace record to an external entity (e.g., DSS). For example, when the external entity is a blockchain or distributed ledger system, the Trace-Record-Forwarding-Metadata can indicate the corresponding blockchain transaction format. The AIH can encapsulate M trace records into one or more blockchain transactions according to the transaction format and send these blockchain transactions to an external blockchain system. -Trace-Record-Forwarding-Credentials (Trace-Record-Storage-Address indicates the credentials used by the AIH to transfer trace records to external entities. The authentication credentials can be a token or a certificate for accessing the external entity. When the AIH transfers a trace record to an external entity, the AIH presents the authentication credentials to an external entity that can authenticate and authorize the AIH based on the authentication credentials. If the external entity is a blockchain or a distributed ledger system, the Trace-Record-Forwarding-Credentials may include a blockchain account (e.g., derived from the public keys of the AIH and / or AITM) assigned by the AITM to the AIH.)

[0215] Both Trace-Scope and Trace-Record-Creation-Condition determine when an AI trace record should be generated according to the format defined by Trace-Record-Format.)

[0216] Note that the response in step S1208 may, for example, simply include a list of trace instruction identifiers instead of the complete content of each trace instruction if the complete content is too large. As a result, the AIM can use separate steps to present one or more trace instruction identifiers to the AITM and retrieve the complete content of the corresponding trace instruction.)

[0217] Also note that steps S1206 and S1208 can be omitted if the AIM1203 can determine the trace instructions for the AIH1201, for example, by leveraging previously provided or buffered trace instructions received from the AITM1205.)

[0218] In step S1210, AIM1203 sends a response to AIH1201 in order to install / deploy the selected AI task to the AIH. This response can include the following. -AI-Task-Content (AI-Task-Content): The software code of the selected AI task. If this is included, AI-Task-Content-Address (see below) may not be required. If this is not included, AI-Task-Content-Address may be required instead. -AI-Task-Content-Address: The address from which the software code of the selected AI task can be downloaded. If this is included, AIH1201 can perform additional actions to download the software code of the AI task before physically installing the AI task. -AI-Task-ID: The unique identifier of the selected AI task. -Trace-Instructions (Trace-Instructions): Those received in the response in step S1208 (or obtained elsewhere). -AIR-ID: The identifier of the AIR where AIH1201 can discover the updated AI model. -AI-Model-ID (AI-Model-ID): The identifier of an existing AI model, and AIM1203 hopes that AIH1201 will take out and install the AI task. This may not be required when the AI task is for learning. If AI-Model-ID is included in the message, AI-Model-Content (see below) can be omitted. -AI-Model-Content: Content of the AI model. This may not be required if the AI task is for learning. Even if the AI task is for knowledge inference, since AIM1203 can instruct AIH1201 to discover and extract the AI model from the AIR using the AIR-ID or AI-Model-ID, this parameter can be optional. If this message contains AI-Model-Content, the AI-Model-ID is not required. If the AI task is a semi-supervised learning task, AI-Model-Content or AI-Model-ID is required.

[0219] If the task to be installed is an AI model training task, the message may further include the following. -Training-Data-Source (Training-Data-Source): The location (e.g., URI, FQDN, etc.) where AIH1201 should retrieve or download the training data. If AIH1201 already has the training data that it may have indicated during AIH registration, there is no need to download the training data. In this case, this is optional. -Model-Handling (Model-Processing): How the trained AI model is processed. This can indicate different possibilities. As a first example, when AIH completes the training process and generates an AI model, it returns that AI model to AIM. Alternatively, AIH notifies AIM of the availability of the AI model, and AIM can retrieve the AI model from AIH. As a second example, assume that AIH registers the trained AI model with the AIR. In this case, this parameter can also include the address of the AIR.

[0220] If the task to be installed is a knowledge inference task, the message may further include the following -Input-Data-Source (Input-Data-Source): The place (e.g., Uniform Resource Locator (URL)) from which the AIH retrieves or downloads input data and can derive knowledge from the input data. If the AIH already has the input data that it may indicate during AIH registration, there is no need to download the input data. In this case, this is optional. -Knowledge-Handling (Knowledge-Processing): How the inferred knowledge is processed. This can indicate different possibilities. As a first example, the AIH can return the knowledge to the AIM after completing the inference process and generating the knowledge. Alternatively, the AIH can inform the AIM of the availability of the knowledge, and the AIM can retrieve the knowledge from the AIH. Also, the AIH can directly send the knowledge to a knowledge consumer (e.g., AIMP for training its own model using the knowledge). As a second example, the AIH can maintain the knowledge locally for itself.

[0221] The response in step S1210 may also request a notification (i.e., in step S1214) to be sent from AIH1201 to AIM1203 after the AIH installs the AI task in step S1212.

[0222] In step S1212, AIH1201 locally installs the AI task. Also, AIH1201 can construct the received trace instructions (i.e., Trace-Instructions) using the installed AI task. As a result, when the AI task starts execution, it generates an AI trace record according to the trace instructions. If AI-Model-Content is included in the response, the AIH installs the corresponding AI-Model-Content together with the AI task. If AIR-ID or AI-Model-ID is included in the message, the AIH can discover or retrieve the AI model from the AIR, and then the AIH installs the AI task. The AIH can generate one or more addresses called AI-Task-Address that can access the installed AI task. The AI-Task-Address can include the following. - API-Info of the TRACE-CONFIG-API of the installed AI task. - API-Info of the TRACE-MGMT-API of the installed AI task. - API-Info of the MODEL-MGMT-API of the installed AI task.

[0223] In step S1214, AIH1201 sends a notification indicating the installation success (or installation failure) of the AI task requested in step S1210 to AIM1203. Optionally, AIH1201 can store this response for DSS or AIR. This notification can include, for example, the following. - AIH-ID: Similar to that in step S1202. - AI-Task-Address: The one generated in step S1212.

[0224] AIH1201 can also create a transaction containing the same notification and send the transaction to a DSS (e.g., a distributed ledger). The transaction may also include an AI-Task-ID, AI-Task-Content, and AI-Task-Type. After the transaction is added to the distributed ledger, AIH will know the corresponding Transaction-Seq-Num and Block-Seq-Num for the added transaction. Then, AIH can send the Transaction-Seq-Num and Block-Seq-Num to AIM.

[0225] In step S1216, AIM1203 that has received the notification creates an AI task record of the AI task installed in AIH1201. AIM1203 can publish the AI task record to a DSS or AIR. For example, AIM1203 can create a transaction containing the AI task record and send the transaction to a DSS (e.g., a distributed ledger). The AI task record may include the following - AIH-ID: Similar to that in step S1214. - AI-Task-ID: Similar to that in step S1210. - AI-Task-Address: Similar to that in step S1214. - AI-Task-Type: Similar to that in step S1202. - Trace-Instructions: Similar to that in step S1210.

[0226] In step S1218, AIM1203 sends the notification to AITM1205. This notification may include the AI task record generated in step S1216. AIM1203 can send the same notification to AIR and / or DSS.

[0227] AIM-Started Tracing Awareness AI Task Deployment To deploy an AI task, the AIM determines the AI task and requests a trace instruction for the AI task from the AITM. In accordance with the trace instruction and the determined AIMU task, the AIM discovers one or more appropriate AIHs (AIMP or AIMU) from the AIR. It should be noted that the AIR maintains the traceability of each registered AIH. Generally speaking, the AIM compares the traceability of each registered AIH with the trace instruction from the AITM to determine an appropriate AIH that can satisfy the trace instruction. Next, the AIM selects an AIH from the list of appropriate AIHs received from the AIR and installs the determined AI task with the trace instruction on the selected AIH.

[0228] FIG. 13 shows a method for deploying a traceability-aware AI task initiated by the AIM according to an embodiment of the present principle.

[0229] In step S1302, the AIM 1303 determines to deploy an AI task. It should be noted that the AIM 1303 maintains a list of AI tasks.

[0230] The AIM 1303 can search for one or more AIRs from the DSS (e.g., a distributed ledger), especially when the AIH information is published to the distributed ledger during the AIH registration process. The search may be performed before or after step S1302. If the AIM searches for the AIR, steps S1304 - S1310 may be omitted.

[0231] In step S1304, the AIM 1303 sends a request message to the AITM 1305 to request a trace instruction for the AI task. This message can include the following. -AI-Task-Type: The type of AI task required by AIH. AI-Task-Type can indicate whether the requested task is for model training, knowledge inference, or both. AI-Task-Type can also indicate whether the requested AI task is a DL task, an FL task, an RL task, or other types. AI-Task-Type can also indicate the purpose of the requested AI task (e.g., regression, classification, clustering, etc.). AI-Task-Type can also indicate the application category of the requested AI task (e.g., natural language processing, text processing, image processing, video processing, etc.). -AI-Task-ID: An optional unique identifier for the selected AI task. AI-Task-ID can be included in the request message, for example, if AITM1305 can use it to understand and determine the corresponding trace instructions.

[0232] AITM1305 uses AI-Task-Type and / or AI-Task-ID to determine the trace instructions for the AI task. In step S1306, AITM1305 sends a response containing Trace-Instructions to AIM, indicating how each type of information related to the AI task should be traced and recorded. This is the same as the Trace-Instructions described in step S1208 of FIG. 12.

[0233] In step S1308, AIM1303 sends a message to AIR1307 to discover one (or more) AIHs 1301 on which the AI task will be deployed. This message can include the following. -AI-Task-ID: The same as in step S1304. -AI-Task-Type: The same as in step S1304. -Trace-Instructions: The same as in step S1306. -Other-Discovery-Criteria (Other Discovery Criteria): Indicates other criteria used to discover AIHs, such as reputation thresholds for selecting AIHs.

[0234] Upon receiving a message, AIR1307 searches a (e.g., its own local) repository to find a list of appropriate AIHs that match the AI-Task-ID, AI-Task-Type, Trace-Instructions, and / or Other-Discovery-Criteria. In step S1310, AIR1307 sends a response to AIH1303. This response can include an AIH-List, which is a list of the appropriate AIHs discovered.

[0235] If AIH information is published to a DSS (e.g., distributed ledger) during the AIH registration process, AIR1307 can search the DSS for AIH information (e.g., AI-Capability, Trace-Capability) to find appropriate AIHs.

[0236] In step S1312, AIM1303 can select one (or more) AIHs from the list of AIHs received from AIR1307. AIM1303 can simply use the Trace-Instructions received in step S1306 as the Trace-Instructions included in step S1314. Alternatively, AIM1303 may modify the trace instructions received in step S1306.

[0237] In step S1314, AIM1303 sends a message requesting installation of the AI task to the selected AIH1301. This message can include the following. -AI-Task-ID: The same as that in step S1304. -AI-Task-Type: The same as that in step S1304. -AI-Task-Content: Software code of the AI task. -AI-Task-ID: (At least probably) unique identifier of the AI task. -Trace-Instructions: From step S1312.

[0238] When AI-Task-Type indicates an AI model training task, the message in step S1314 may include the following -Training-Data-Source: The location (e.g., Uniform Resource Locator (URL)) where the AIH should retrieve or download the training data. -Model-Handling: How the trained AI model is processed. This can indicate different possibilities. As a first example, when AIH1301 completes the training process and generates an AI model, it returns the AI model to AIM1303. Alternatively, AIH1301 can notify AIM1303 of the availability of the AI model, and AIM1303 can retrieve the AI model from AIH1301. As a second example, AIH1301 can register the trained AI model alone with AIR1307. In this case, Model-Handling can also include the address of the AIR.

[0239] When AI-Task-Type indicates a knowledge inference task, the message in step S1314 can additionally include the following. -Input-Data-Source: The location (e.g., Uniform Resource Locator (URL)) where the AIH should retrieve or download the input data and derive knowledge from the input data. -Knowledge-Handling: How the inferred knowledge is processed. This can indicate different possibilities. As a first example, when AIH1301 completes the inference process and generates knowledge, it returns that knowledge to AIM1303. Alternatively, AIH1301 can inform AIM1303 of the availability of the knowledge, and AIM1303 can retrieve the knowledge from AIH1301. Also, AIH1301 can directly send the knowledge to a knowledge consumer (e.g., AIMP for training its own model using the knowledge). As a second example, AIH1301 can maintain the knowledge locally for itself.

[0240] In step S1316, AIH1301 installs an AI task with a trace instruction. This step can be the same as step S1212 in FIG. 12.

[0241] In step S1318, AIH1301 sends a response indicating the success (or failure) of the installation to AIM1303. This step can be the same as step S1214 in FIG. 12.

[0242] AIH1301 can also (or alternatively) create a transaction containing the response and send the transaction to a DSS (e.g., a distributed ledger). The transaction can also include an AI-Task-ID, AI-Task-Content, and AI-Task-Type. After the transaction is added to the distributed ledger, AIH1301 knows the corresponding ledger identifier. Then, AIH1301 can send the ledger identifier to AIM1305.

[0243] In step S1320, AIM1303 creates an AI task record for the AI task installed in AIH1301. This step can be the same as step S1216 in FIG. 12.

[0244] In step S1322, AIM1303 can send a notification to AITM1307. This step can be the same as step S1218 in FIG. 12. AIM1303 can send a notification to AIR1307 and / or DSS. For example, AIM1303 can create a transaction including this notification and send the transaction to DSS (e.g., a distributed ledger).

[0245] AIH-initiated Traceability Aware FL Task Deployment FIG. 14 shows a method for deploying a traceability aware FL task initiated by AIH according to an embodiment of the present principle. This method is similar to that shown in FIG. 12, but extends a general AI task to an FL task.

[0246] In step 1402, FLS1403 sends a message requesting an AI task (i.e., an FL task in this case) to AIM1405. This is the same as step S1202 in FIG. 12. The AIH-ID included in this message is an identifier of the FLS. FLS1403 can indicate in the message whether it requests to discover FLC1401 from AIM1405 and how many FLCs are required. Even if FLS1403 has a list of ready FLCs, FLS1403 can request AIM1405 to reselect FLC1401. FLS1403 can also send the list of its FLCs (e.g., their unique identifiers) to AIM1405, which can authenticate those FLCs based on the information included in this message and / or additional information that AIM1405 can retrieve from AIR for each FLC.

[0247] In step S1404, AIM1405 determines an AI task (i.e., an FL task) for FLS1403. This is the same as step S1204 in FIG. 12. Further, AIM1405 can determine an FLC for the determined AI task, for example, by discovering a suitable AIH from the AIR and assigning the discovered AIH as the FLC. AIM1405 can also select an FL aggregation algorithm (e.g., synchronous or asynchronous) for the determined FL task.

[0248] In step S1406, similar to step S1206 in FIG. 12, AIM1405 sends a message to AITM1407 to request a trace instruction. The AIH-ID included in this message contains the identifier of FLS1403. The AIH-ID can also contain the identifier of the FLC determined in step S1404.

[0249] In step S1408, AITM1407 sends a response to AIM1405. This is the same as step S1208 in FIG. 12. The trace instruction included in this response can be for FLS1403 only, and optionally, if any FLC is indicated in step S1406, it can be for each FLC.

[0250] In step S1410, AIM1405 sends a request to the FLS to install the determined task. This is the same as step S1210 in FIG. 12. The request can include FL parameters, i.e., a list of FLCs (e.g., their identifiers) determined in step S1404, and / or the FL aggregation algorithm selected in step S1404.

[0251] In step S1412, FLS1403 installs an AI task (i.e., an FL task). This is the same as step S1212 in FIG. 12. After successfully installing the AI task, FLS can send a response indicating success (or failure) to AIM, similar to step S1214 in FIG. 12.

[0252] In step S1414, FLS1403 may determine an FLC for the AI task. Even if a list of FLCs is shown in step S1410, FLS1403 may not select anything from the list, may select some, or may select other FLCs.

[0253] In step S1416, FLS1403 determines a trace instruction for each FLC based on the trace instruction received in step S1410.

[0254] In step S1418, FLS1403 sends a request to install the AI task to FLC1401. This step is the same as step S1410, except that this request may include an FLS-ID, which is the identifier of FLS.

[0255] FLC1401 installs the AI task as in step S1412 and, in step S1420, sends a response to FLS1403. This response may include an FLC-ID, which is the identifier of the FLC, and an AI-Task-Address similar to the AI-Task-Address in step S1214 of FIG. 12.

[0256] In step S1422, similar to step S1214 in FIG. 12, FLS1403 transmits a response to AIM1405. FLS1403 can wait to receive responses from all FLCs that requested installation of the FL task, aggregate the responses, generate an aggregated response, and transmit the aggregated response to AIM1405. Alternatively, FLS1403 can transmit individual responses regarding FLC1401 to AIM1405 when it receives a response, for example, in step S1420. The response can include the AIH-ID, that is, the identifiers of FLS1403 and each FLC1401 related to the response, and the AI-Task-Address indicating the addresses of the AI tasks installed in FLS1403 and the AI tasks installed in each FLC1401.

[0257] In step S1424, similar to step S1214 in FIG. 12, AIM1405 creates AI task records of the AI tasks installed in FLS1403 and all FLC1401. Alternatively, AIM1405 creates one AI task record for the AI task installed in FLS1403 and one AI task record for the AI task installed in each FLC1401.

[0258] In step S1426, AIM1405 transmits a notification to AITM1407. This notification can include the AI task records created in step S1424. The notification can also or alternatively be transmitted to AIR and / or DSS.

[0259] AIM-Started Tracability Aware FL Task Deployment FIG. 15 shows a method for deploying a tracability aware FL task started by AIM according to an embodiment of the present principle. This method is similar to that shown in FIG. 13, but the AI task to be deployed is an FL task.

[0260] In step S1502, similar to step S1302 in FIG. 13, AIM1305 determines to deploy an AI task (i.e., in this case, an FL task).

[0261] In step S1504, similar to step S1304 in FIG. 13, AIM1305 sends a message to AITM1307 to request a trace instruction for the determined AI task.

[0262] In step S1506, similar to step S1306 in FIG. 13, AITM1307 sends a response containing the trace instruction to AIM1305.

[0263] In step S1508, similar to step S1308 in FIG. 13, AIM1505 sends a message to AIR1509 to discover an AIH for the AI task. Since the AI task is an FL task, AIM1505 can request to discover both FLS1503 and FLC1501.

[0264] In step S1508, if AIM also requests FLC, AIR1509 searches a repository, e.g., its local repository, to find multiple FLSs and multiple FLCs. In step S1510, AIR1509 sends a response containing an AIH-List indicating the identifiers of the multiple FLSs and the identifiers of all FLCs to AIM1505.

[0265] In step S1512, AIM1505 selects FLS1503 and multiple FLC1501 for the AI task. Alternatively, in step S1518, AIM1505 can select only FLS1503 and let FLS1503 select FLC1501.

[0266] In step S1514, similar to step S1410 in FIG. 14, AIM1505 sends to FLS1501 (or FLS in some cases) to install the FL task on FLS1503.

[0267] FLS1503 installs the FL task. In step S1516, similar to step S1412 in FIG. 14, FLS1503 may send a response indicating the success (or failure) of the installation of the FL task in FLS1505 to AIM1505.

[0268] In step S1518, similar to step S1414 in FIG. 14, FLS1503 may reselect the FLC.

[0269] In step S1520, similar to step S1416 in FIG. 14, FLS1503 determines trace instructions for each FLC.

[0270] In step S1522, similar to step S1418 in FIG. 14, FLS1503 sends a message to FLC1501 to request the installation of the FL task.

[0271] FLC1501 installs the FL task and, in step S1524, sends a response to FLS1503 similar to step S1420 in FIG. 14.

[0272] In step S1526, similar to step S1422 in FIG. 14, FLS1503 sends a response to AIM1505.

[0273] In step S1528, similar to step S1424 in FIG. 14, AIM1505 creates one or more AI task records.

[0274] In step S1530, similar to step S1426 in FIG. 14, AIM1505 sends the AI task records to AITM1507 and AIR1509 (and possibly to DSS as well).

[0275] Traceabilityware AI Model Registration AIMP can register its generated (i.e., trained) AI model with the AIR, and the AIR can be discovered by and shared with the AIMU. Alternatively, when the AIMP generates an AI model, the AIMP can send the AI model including its metadata to the AIM, and the AIM has installed an AI task on the AIMP for training the AI model. As a result, the AIM registers the AI model with the AIR.

[0276] When the AIMP (or AIM) registers an AI model, the AIMP (or AIM) can have traceability requirements for the AI model. As a result, the AIMP (or AIM) constructs the necessary trace instructions using the AI model to be registered.

[0277] It takes time for the AIMP to train an AI model. However, the AIMP may wish for its AI model to be discoverable by the AIMU before it is fully trained. In other words, the AI model registered by the AIMP may be fully trained or partially trained. When the AIMP registers a partially trained AI model, it can be regarded as model pre-registration or model pre-notification.

[0278] FIG. 16 shows a method for the AIMP to register an AI model with the AIR according to an embodiment of the present principle.

[0279] In step S1602, the AIMP1603 sends a message for registering the AI model to the AIR1601.

[0280] Note that AIMP1603 may be informed of the address of AIR1601 when an AIM (not shown) installs an AI training task on AIMP1603. In this case, the information included in registration messages such as Trace-Instructions may be sent by the AIM to AIR1601 and can therefore be omitted from the registration message.

[0281] The message may include the following. -Trace-Instructions: When AIMU wants to use a model to infer knowledge, the trace instructions and requirements for the AI model. For example, one trace requirement may be to require AIMU to record the inferred knowledge and the input data related to the inference when the inferred knowledge is incorrect or below a certain accuracy threshold. This parameter is similar to the Trace-Instructions described in step 1208 of FIG. 12. -AI-Model-Type: The type of the registered AI model. This can describe the type of the AI model at different levels or granularities. For example, 1) at the algorithm level: when the AI model is a linear regression model, a classification model, a DNN model, etc.; 2) at the application level: when the AI model is for wireless channel prediction, image classification, pattern recognition, natural language processing, financial market prediction, autonomous driving, etc., but is not limited thereto. AI-Model-Type can also indicate the number of layers and neurons of the DNN when the AI model is a DNN model. -AI-Model-Content: If the registered AI model is fully trained, the complete AI model (i.e., all parameters / weights of the DNN) and the model version. If the model is not fully trained, AI-Model-Content is not required. Even in the case of a fully trained AI model, AIMP can decide to skip this parameter and not upload the model content to AIR. Instead, another entity can discover the AI-Model-Address and use a separate step to retrieve the model content directly from AIMP. -AI-Model-Usage-Constraints (AI-Model-Usage-Restrictions): Constraints such as who can discover and use the registered model and when. As an example, AI-Model-Usage-Constraints can include a reputation threshold indicating that only AIMUs with a reputation higher than a threshold can discover and use this AI model. -AI-Model-ID: Identifier of a previously registered AI model. AIMP can use the AI-Model-ID to inform AIR that the AI-Model-Content is an update to a previously registered AI model as indicated by the AI-Model-ID. -AI-Model-Address: Address of an AI model that is partially trained or still in training in AIMP. Using this parameter, AIR or AIMU can check the status of the AI model (e.g., fully trained or partially trained) from AIMP and download it from AIMP after it is fully trained. If the AI-Model-Content is not included in the registration message, AIMU or AIR can come to AIMP using the AI-Model-Address and retrieve the model content later. -AIM-ID: If the AI model training task in AIMP is installed by AIM, this parameter indicates the identifier and / or address of AIM. -AIMP-ID: The identifier and / or address of the AIMP where the AI model is generated or still under training.

[0282] Step S1602 can be triggered when a new AI model is generated / trained in AIMP1603. Also, AIMP1603 can use Step S1602 to pre-register or pre-notify an AI model that is still under training.

[0283] If AI-Model-Content is included in the message, in Step S1604, AIR1601 stores the AI model in its (e.g., local) repository. If AI-Model-Content is not included in the message, Step S1604 can be skipped. If in Step S1602, AIMP1603 requests to update a previously registered AI model, in Step S1602, AIR1601 replaces the previous version of the AI model with the new AI-Model-Content included in the message and deletes the corresponding AI model record.

[0284] In Step S1606, AIR1601 creates an AI model record for the AI model indicated by the message in Step S1602. AIR1601 may publish the AI model to a DSS (e.g., a distributed ledger). For example, AIR1601 may create a transaction containing the AI model and send the transaction to the distributed ledger. The AI model record may include the following, which can be discovered and / or published to other entities such as AIMU. -AI-Model-ID: If it is included, it is the same as that in the message in step S1602. If it is not included, this means that the AI model is registered for the first time, and AIR1601 creates an AI-Model-ID for the registered AI model. Later, AIMP1603 can use the AI-Model-ID to update the registered AI model. -AI-Model-Usage-Constraints: If it is included, it is the same as that in the message in step S1602. If it is not included, AIR1601 can determine the AI model usage constraints. -AI-Model-Address: If it is included, it is the same as that in the message in step S1602. If it is not included, it is not required. -AI-Model-Content: If it is included, it is the same as that in the message in step S1602. If it is not included, it is not required. -AI-Model-Mode (AI-Model-Mode): Indicates that the AI model is registered. -Trace-Instructions: The same as that in the message in step S1602.

[0285] In step S1608, AIR1601 sends the response to AIMP1603. The response may include the following. -AI-Model-ID: The same as that in step S1602. -AI-Model-Record-ID (AI-Model-Record-ID): The identifier of the AI model record created in step S1606.

[0286] When AIMP1603 receives the response in step S1608, it can transfer the response to an AIM (not shown) previously installed in AIMP for an AI task to train / generate the registered AI model.

[0287] If the AIM-ID was included in step S1602, AIR1601 can also transfer the response sent to AIMP1603 in step S1608 to the AIM indicated by the AIM-ID. When receiving the response, the AIM can at any time retrieve the AI model from AIR1601 or examine other information regarding the AI model.

[0288] Note that AIMP1603 can also use this method to register its model with the AIM or DSS (i.e., replace the AIR in Figure 16 with the AIM or DSS).

[0289] After step S1608, AIR1601 can send a notification containing the AI model record created in step S1606 to the AIM or AITM.

[0290] Note that when AIMP1603 generates an AI model, it can send the AI model to the AIM. Then, the AIM can interact with the AIM instead of the AIMP and register the AI model with the AIR using the method in Figure 16. Then, the AIM may publish the AI model to the DSS (e.g., distributed ledger). For example, the AIM can create a transaction containing the AI model and send the transaction to the distributed ledger.

[0291] In particular, note that if the trace instruction is purely determined by the AIMP, or if the AIR wants to verify the Trace-Instructions using the AITM, the AIR can transfer the Trace-Instructions received from the AIMP to the AITM. When the AIR transfers the Trace-Instructions, the AIR can also associate the Trace-Instructions with the corresponding AI-Model-ID and AIMP-ID and transfer the association to the AITM.

[0292] Discovery and Deployment of Traceability-Aware AI Models Discovery of AIR-Assisted Traceability Aware Model AIMU is for installing an AI model. From AIR, AIMU discovers an AI model that meets its traceability criteria. AIR can send the AI model address to AIMU or send the model content and related trace instructions to AIMU. If AIMU only receives the AI model address from AIR, AIMU can retrieve the AI model content from the AI model address (e.g., AIMP). AIMU can also retrieve trace instructions from AITM. Then, AIMU installs an AI model incorporating the trace instructions and any user input. AIMU creates an AI model record for the installed AI model. Finally, AIMU sends the AI model record to AIR and / or other entities (e.g., AIMP, DSS, AITM).

[0293] Figure 17 shows a method for the discovery and deployment of an AIR-assisted traceability aware model according to an embodiment of the present principle.

[0294] An AIM (not shown) has already installed an AI task in AIMU1701 without an associated AI model. However, AIMU1701 requires an AI model to execute the AI task for inferring knowledge.

[0295] In step S1702, AIMU1701 sends a message to AIR1703 to discover its desired AI model. Note that AIMU1701 has a local AI agent that was already installed together with the AI task when the AI task was installed, and the address of AIMU1703 can be configured for AIR1701. This message can include one or more of the following. -Trace-Criteria (Trace Criteria): Trace criteria for discovering an AI model. In other words, AIMU1701 requires an AI model for which the "Trace-Instructions" meet the trace criteria indicated by the Trace-Criteria. The Trace-Criteria may include similar information (e.g., "Trace-Scope") that is part of the "Trace-Instructions", as explained in step S1208 of FIG. 12. -AI-Model-Type: The type of the registered AI model. This can describe the type of the AI model at different levels or granularities. For example, 1) at the algorithm level: when the AI model is a linear regression model, a classification model, a DNN model, etc.; 2) at the application level: when the AI model is for wireless channel prediction, image classification, pattern recognition, natural language processing, financial market prediction, autonomous driving, etc., but is not limited thereto. When the AI model is a DNN model, the AI-Model-Type can also indicate the number of layers and neurons of the DNN. -AI-Model-ID: The identifier of the previously downloaded AI model. AIMU1701 can use this parameter to download a new version of the AI model from AIR1703.

[0296] It should be noted that AIMU1701 can indicate in the message that the Trace-Criteria is of secondary priority, which implies that an AI model with inconsistent Trace-Instructions can still be discovered and installed in AIMU1701.

[0297] AIR1703 checks the locally maintained AI model records to find a registered AI model that has Trace - Instructions matching the received Trace - Criteria. For example, AIR1703 can check whether the "Trace - Scope" included in the Trace - Criteria matches the "Trace - Scope" of the Trace - Instructions of any maintained AI model. If the AI - Model - ID is included in the message, AIR1703 can simply use it to find the corresponding registered AI model.

[0298] In step S1704, AIR1703 sends a response to AIMU1701. The response can provide the complete AI model with trace instructions to AIMU1701. In a variant, the response includes only the AI model address information that AIMU can use to download the complete AI model. Specifically, the response can include the following information for each discovered AI model. - AI - Model - ID: The identifier of the discovered AI model. - AI - Model - Content: The content of the discovered AI model. - Trace - Instructions: Trace instructions composed of the AI model discovered by AIMP or AIR. - AI - Model - Address: The address of the discovered AI model from which the content of the AI model can be retrieved. If this information is included, AIMU1701 can use it to retrieve the AI model from AIMP as described in steps S1706 and S1708. -AITM-ID: An identifier or address of AITM from which AIMU1701 can retrieve trace instructions for the AI model. If this information is included in the message in step S1702, AIMU1701 can execute steps S1710 and S1712 as described. This information can be omitted if Trace-Instructions are included in the response of step S1704. -Notification-Target: The address or identifier of one or more notification targets (e.g., AIR, AITM, etc.) to which AIMU1701 sends a notification after installing the AI model (i.e., step 1722).

[0299] Note that AIR1703 can find an AI model that does not match the Trace-Instructions of AIMU1701, for example, when a search is performed without using Trace-Instructions, or when there is no AI model that matches the Trace-Instructions, especially when AIMU1701 indicates that Trace-Criteria is of secondary priority in the discovery message of step S1702. It is worth noting that the trace instructions received by AIMU in the response in step S1704 may include additional trace requirements that exceed the trace requirements requested by AIMU in the discovery message in step S1702 (e.g., set by AIMP).

[0300] In step S1704, if AI-Model-Address is included in the response, in step S1706, AIMU1701 sends a message to AIMP1705 to retrieve the AI model indicated by the AI-Model-Address. This message may include the following. -AI-Model-ID: Similar to that in step S1704. -AI-Model-Address: Similar to that in step S1704. -AI-Model-Push-Address (AI-Model-Push-Address): The address that AIMP1705 can use to push the content of the fully trained AI model to AIMU1701.

[0301] AIMP1705 can uniquely identify the AI models maintained locally by AIMP1705 using the AI-Model-ID and / or AI-Model-Address.

[0302] AIMP1705 uses the received AI-Model-Address to identify the corresponding AI model and, in step S1708, sends a response to AIMU1701. If the AI model is fully trained here, the response includes the content of the AI model. Otherwise, the response may include an indication that the AI model is not available and is still being trained. When the AI model is fully trained, AIMP1705 can push the content of the AI model to the AI-Model-Push-Address. The response may include the following. -AI-Model-ID: The same as that in step S1706. -AI-Model-Content: The content of the AI model when the AI model is fully trained. -Trace-Instructions: The trace instructions and requirements required by the AI model when the AI model is fully trained. -AI-Model-Ready-Time (AI-Model-Ready-Time): The estimated time until the AI model is fully trained. -AITM-ID: The identifier or address of the AITM from which AIMU1701 can retrieve the trace instructions from the AI model. If this parameter is included, AIMU1701 can execute the following steps S1710 and S1712.

[0303] In step S1710, when AIMU1701 obtains the content of the AI model in its response in step S1704 or S1708, AIMU1701 sends a request message to AITM1707 in order to extract the trace instruction for the AI model.

[0304] It should be noted that step S1710 can be omitted, for example, when AIMU1701 receives a trace instruction from AIR in its response in step S1704. In addition, if AIMU1701 does not know the address or identifier of AITM1707, step S1710 is omitted.

[0305] The request message may include the following. - AIMU-ID: The identifier of AIMU1701. - AI-Model-ID: The identifier of the AI model. - Trace-Criteria: The same as "Trace-Criteria" in the request message in step S1702. - Trace-Capability: The same as "Trace-Capability" received in step S1002 of FIG. 10.

[0306] AITM1707 determines, for example, the trace instruction for AIMU1701 based on the Trace-Criteria and Trace-Capability received in the request message in step S1710. Alternatively, the trace instruction for the AI model indicated by AI-Model-ID may be provided to AIMU1701. In step S1712, AITM1707 sends a response including the determined Trace-Instructions to AIMU1701.

[0307] Note that here too, the AIMU 1701 itself can determine trace instructions from the Trace-Instructions received in the response in step S1704 or S1708. In this case, steps S1710 and S1712 are unnecessary.

[0308] In step S1714, the AIMU 1701 installs the AI model obtained in step S1704 or step S1708.

[0309] In step S1716, the AIMU 1701 can present the Trace-Instructions received in step S1712 or determined in another way as already described, to the person requesting the input. For example, the person can accept or reject the trace instructions, and the person can specify the address to which the AIMU sends the AI trace record.

[0310] In step S1718, the AIMU 1701 can receive the input from that person. The AIMU 1701 can generate a final trace configuration (Trace-Configuration) by combining the Trace-Instructions and the input from that person. The AIMU 1701 configures the Trace-Configuration into the AI model.

[0311] In step S1720, the AIMU 1701 creates an AI model record of the installed AI model. The AI model record can include the following. - AIMU-ID: The identifier of the AIMU 1701. - AI-Model-ID: The identifier of the installed AI model. - AI-Model-Address: The same as that in step S1704. - AI-Model-Push-Address: The same as that in step S1706. -Trace-Configuration: Result of combining Trace-Instructions and input from that person.

[0312] In step S1722, AIMU1701 sends a notification to the AIR or AITM determined by the Notification-Target received in step S1704. The notification may include the entire AI model record created in step S1720 or may include an identifier of the AI model record. Optionally, AIMU1701 can also publish this AI model record to the DSS. Also, if the AI model is generated and contributed by AIMP1701, AIMU1701 can send the same notification to this AIMP1705.

[0313] Note that when using an existing AI model as the initial model to train a new AI model where AIMU is replaced by AIMP-X, another AIMP-X can discover and retrieve the content of the existing AI model using a method similar to the method in Figure 17.

[0314] Discovery and Deployment of AIM-Adjusted Traceable AI Models AIMU discovers, in the AIR, an AI model that meets its trace criteria relying on AIM. The AIR can return the AI model address to AIMU or return the model content and related trace instructions to AIM. If AIM receives only the AI model address from the AIR, AIM retrieves the AI model content from the AI model address (e.g., AIMP). AIM can also retrieve the trace instructions from the AITM. Then, AIM pushes the model content and associated trace instructions to AIMU. AIMU installs an AI model that incorporates the trace instructions and any user input. AIM creates an AI model record for the AI model installed in AIMU. Finally, AIM sends the AI model record to the AIR and / or other entities (e.g., DSS, AIMP, AITM).

[0315] Figure 18 shows a method for discovering and deploying an AIM - adjusted traceability aware AI model according to an embodiment of the present principle.

[0316] In step S1800, AIMU1801 can start discovering an AI model by sending a message to AIM1803. This is similar to step S1702 in FIG. 17. Furthermore, AIMU1801 can include its Trace - Capability in this step.

[0317] Since AIM1803 has installed AI tasks on AIMU1801, it knows what kind of AI model AIMU1801 needs. In step S1802, AIM1803 sends a message to AIR1805 to discover and download an AI model for AIMU1801. This is similar to step S1702 in FIG. 17.

[0318] In step S1804, AIR1805 sends a response containing AI model information to AIM1803, similar to step S1704 in FIG. 17.

[0319] In step S1806, AIM1803 sends a message to AIMP1807 to retrieve the AI model. This is similar to step S1706 in FIG. 17, but the AI - Model - Push - Address included in the message can indicate the address of AIM1803 for receiving the AI model from AIMP1807, or the address of AIMU1801 for receiving the AI model from AIMP1807. If the AI - Model - Push - Address is the address of AIMU1801, AIMP1807 can use this AI - Model - Push - Address to directly push or send the AI model to AIMU1801.

[0320] In step S1808, AIMP1807 can send the required AI model to AIM1803. This step is the same as step S1708 in FIG. 17.

[0321] In step S1810, AIM requests Trace-Instructions from AITM1809. This is the same as step S1710 in FIG. 17.

[0322] In step S1812, after extracting the Trace-Instructions, AITM1809 sends them to AIM1803. This is the same as step S1712 in FIG. 17.

[0323] Based on the trace instructions received in step S1804 and / or step S1812, AIM1803 determines the final trace instructions for the AI model to be deployed. In step S1814, AIM1803 sends a response message to AIMU1801, instructing AIMU1801 to deploy the AI model. This message may include the following. - AI-Model-ID: The identifier of the AI model sent to and deployed at AIMU1801. - AI-Model-Content: The content of the AI model sent to and deployed at AIMU1801. - Trace-Instructions: The final trace instructions for the AI model sent to and deployed at AIMU1801.

[0324] In a variant, AIM1803 does not send the Trace-Instructions to AIMU1801. Instead, AIMU1803 can inform AIMU1801 of the identifier of the trace instructions determined or created for AIMU1801, so that AIM1801 can retrieve the trace instructions from AITM1809, for example, by presenting the identifier and / or any identifier of the determined trace instructions.

[0325] In step S1816, AIMU1801 installs the AI model. This is the same as step S1714 in FIG. 17.

[0326] In step S1818, AIMU1801 requests user input for the traceability option. This is the same as step S1716 in FIG. 17.

[0327] In step S1820, AIMU1801 receives the user input and configures the AI model using the final trace configuration determined using the user input. This is the same as step S1718 in FIG. 17.

[0328] In step S1822, AIMU1801 sends a notification message indicating the deployment of the AI model to AIM1803. This notification message may include the following. - AIMU-ID: The identifier of AIMU1801. - Trace-Configuration: The final trace configuration determined in step S1820.

[0329] In step S1824, AIM1803 creates an AI model record of the AI model deployed to AIMU1801. This is the same as step S1720 in FIG. 17. The AI model record may include the following. - AIMU-ID: The identifier of AIMU1801. - AI-Model-ID: The identifier of the installed AI model. - AI-Model-Address: The address for retrieving the AI model from AIMP1807. - AI-Model-Push-Address: The same as that in step S1806. - Trace-Configuration: The same as that in step S1822. - AIM-ID: The identifier of AIM1803.

[0330] In step S1826, AIM1803 sends a notification message to AIR1805 or AITM1809 determined by the Notification-Target received by AIMU in step S1804 in a message. AIM1803 may also determine to send a notification to AIR1805 and / or AITM1809 based on a preconfigured policy. The notification may include the entire AI model record created in step S1824, or may include an identifier of this AI model record. Optionally, AIMU1801 can publish this AI model record to the DSS. Also, if the AI model is generated and contributed by AIMP1807, AIM1803 can send a notification message to this AIMP1807.

[0331] Note that another AIMP-Y can use the method shown in FIG. 18 to discover and retrieve the content of an existing AI model instead of AIMU if it wants to use the existing AI model as an initial model for training a new AI model.

[0332] Discovery and Deployment of AIMP-Started Tracing Awareness AI Models AIMP is for deploying an AI model to AIMU. From the AIR, AIMP discovers an AIMU that meets its trace criteria and AI criteria. The AIR examines its locally maintained AI host record and finds one or more AIMUs whose AI capabilities and trace capabilities match the AI criteria and trace criteria from AIMP. The AIR returns the discovered AIMU to AIMP. Next, AIMP contacts each AIMU to obtain permission to deploy the AI model. The AIMU receives the model content from AIMP and receives a trace instruction from AIMP or AITM. Then, the AIMU installs an AI model incorporating the trace instruction and any user input. The AIMU creates an AI model record for the installed AI model. Finally, the AIMU sends the AI model record to the AIR and / or other entities (e.g., AIMP, DSS, AITM).

[0333] Figure 19 shows a method for discovering and deploying an AIR-assisted traceability awareness model according to an embodiment of the present principle.

[0334] In step S1902, AIMP1905 sends a message to AIR1903 to discover AIMU1901. This message may include the following. - AIMP-ID: The (unique) identifier of the AIMP. - Trace-Criteria: Trace criteria for discovering the AIMU. In other words, the AIMP discovers an AIMU whose "Trace-Capability" meets the trace criteria indicated by the Trace-Criteria. The Trace-Criteria may include information similar to the information (e.g., "Trace-Scope") of a part of the "Trace-Capability" described in step S1208 of FIG. 12. - AI-Criteria: AI requirements for discovering the AIMU. In other words, the AIMP discovers an AIMU whose "AI capability" meets the AI criteria indicated by the AI-Criteria. The AI-Criteria may include information similar to the "AI-Capability" described in step S1002 of FIG. 10. Further, the AI-Criteria may include metadata about the AI model that the AIMP wants to deploy to the AIMU.

[0335] AIR1903 uses the received Trace-Criteria and AI-Criteria to check the AI host records maintained (locally) and find registered AIMUs with Trace-Instructions that match the Trace-Criteria. Next, in step S1904, AIR1903 sends a response to AIMP1905. The response message may include the following for each discovered AIMU. - AIMU-ID: The identifier of the discovered AIMU, which may include the address of the AIMU. -AI-Capability: AI capabilities of the discovered AIMU. -Trace-Capability: Trace capabilities of the discovered AIMU.

[0336] Upon receiving the response, AIMP1905 selects at least one AIMU from the list of discovered AIMUs included in the response in step S1904.

[0337] Steps S1906 to S1924 are executed for each selected AIMU.

[0338] In step S1906, AIMP1905 sends a notification to the selected AIMU1901 to deploy the AI model. This notification message may include the following. -AIMU-ID: Identifier or address of the selected AIMU1901. -AI-Model-ID: (Unique) identifier of the AI model to be deployed. -AI-Model-Type: Type of the AI model to be deployed. -Trace-Criteria: Trace-Criteria included in the message in step S1902.

[0339] AIMU1901 may receive a notification message that it may accept or reject. If AIMU1901 accepts the notification message, the method continues for that AIMU1901.

[0340] In step S1908, AIMU1901 sends a message to AIMP1905 to retrieve the AI model identified by AI-Model-ID. This message may include the following. -AI-Model-ID: The same as that in step S1906. -AI-Model-Push-Address: An address that can be used by AIMP1905 to push the content of the fully trained AI model to AIMU1901.

[0341] AIMP1905 receives a message and uses the AI-Model-ID to identify the corresponding AI model. In step S1910, AIMP1905 sends a response to AIMU1901.

[0342] If the AI model is fully trained, the response can include the content of the AI model. Otherwise, the response can include information indicating that the AI model is not available and is still being trained. When the AI model is fully trained, AIMP1905 can also or alternatively push the content of the AI model to the AI-Model-Push-Address. The response can include one or more of the following. - AI-Model-Content: The content of the AI model when the AI model is fully trained. - Trace-Instructions: The trace instructions and requirements required by the AI model when the AI model is fully trained. Note that AIMP1905 can obtain the trace instructions from AITM1907. - AI-Model-Ready-Time: The estimated time until the AI model is fully trained. - AITM-ID: The identifier or address of AITM1907 from which AIMU1901 can retrieve the trace instructions from the AI model. If this information is included in the response, AIMU1901 can execute steps S1912 and S1914.

[0343] Steps S1912 - S1922 are the same as steps S1710 - S1720.

[0344] Step S1924 is the same as step S1722 in FIG. 17, with the addition that AIMU1901 also notifies AIMP1905.

[0345] Discovery and Deployment of an AIMP-Started Traceability Aware AI Model Implemented Using a Distributed Ledger The method shown in FIG. 19 can be implemented using a blockchain and / or a distributed ledger as an example of a DSS, as will be described in the following example.

[0346] Each entity in FIG. 19 (i.e., AIMU1901, AIR1903, AIMP1905, and AITM1907) is a blockchain user. Each entity has a blockchain account. Each entity is connected to a different (or the same) blockchain node that hosts the blockchain or the entire ledger.

[0347] AIR1903 may publish AI host records on the blockchain. AIR1903 may maintain information regarding where each AI host record is stored in the blockchain, called the blockchain address of each AI host record (e.g., the block containing the AI host record and the sequence number of the transaction).

[0348] AIR1903 (and / or AIMP1905) may publish AI model records on the blockchain. AIR1903 may maintain information regarding where each AI model record is stored in the blockchain, called the blockchain address of each AI model record (e.g., the block containing the AI model record and the sequence number of the transaction).

[0349] AITM1907 may publish trace commands on the blockchain. AITM1907 may maintain information regarding where each trace command is stored in the blockchain, called the blockchain address of each trace command (e.g., the block containing the trace command and the sequence number of the transaction).

[0350] Step S1902 remains unchanged.

[0351] In step S1904, AIR1903 can include only the blockchain address of the AI host record for the found AIMU in the response. That is, this response does not include AIMU-ID, Trace-Capability, and AI-Capability. AIMP1905 uses the blockchain address to retrieve the corresponding AI host record from the blockchain node to which AIMP1905 is connected.

[0352] In step S1906, AIMP1905 can include only the blockchain address of the AI model record.

[0353] In step S1908, AIMU1901 uses the blockchain address of the AI model to retrieve the AI model content and the associated trace instructions from the blockchain node to which the AIMU is connected.

[0354] In step S1910, AIMU1901 receives the AI model from the blockchain node.

[0355] Step S1912 remains unchanged.

[0356] In step S1914, the response can include only the blockchain address of the trace instruction. Next, AIMU1901 uses this blockchain address to retrieve the trace instruction from the blockchain node to which AIMU1901 is connected.

[0357] Steps S1916 - S1922 remain unchanged.

[0358] Instead of or in addition to sending a notification in step S1924, AIMU1901 publishes the AI model record to the blockchain via the blockchain node to which the AIMU is connected. In an alternative, step S1924 remains unchanged.

[0359] Embodiment The following shows how the present principle can be implemented in various types of network architectures.

[0360] Embodiment of 3GPP SA2 Embodiment of the architecture The entities (e.g., AIMU, AIR, AIMP, and AITM) for traceability aware AI tasks and model management described in this specification can be implemented in a 3GPP cellular network as follows, using the 5G service architecture as a non-limiting example.

[0361] AIMU can be a UE, a Network Function (NF), and / or an Application Function (AF).

[0362] AIMP can be a UE, an NF, and / or an AF.

[0363] AIM and AIR can be integrated into one device or node as an AI Management and Repository Function (AIMRF) deployed as a stand-alone NF, AF, an extension to the 5G Network Repository Function (NRF), an extension to the 5G Network Data Analytics Function (NWDAF), or an extension to the 5G Unstructured Data Storage Function (UDSF).

[0364] AITM can be implemented as an AI Trace Management Function (AITMF) deployed as a stand-alone NF or an extension to the 5G Policy Control Function (PCF).

[0365] The DSS can be implemented as a stand-alone NF with the DSS function (DSSF) deployed, an extension to the 5G Unified Data Repository (UDR) function, or an extension to the 5G UDSF.

[0366] AIMU, AIMP, AIMRF, AITMF, and DSSF can be deployed in various locations of a cellular network above 5G, such as a device, an edge data network, a core network, a data network, and / or a cloud.

[0367] Figure 20 shows an example of the deployment of traceability-aware AI tasks and model management in a 3GPP cellular network. In this example, it is as follows. - UE-1 is an AIMU that hosts an AI task that uses the AI model provided by AIMP for knowledge inference. UE-1 has its AI-Capability and Trace-Capability. - UE-2 is an AIMP that hosts an AI task that generates an AI model. The generated AI model is deployed to UE-1. UE-1 has its AI-Capability and Trace-Capability. - AIMRF is deployed as an NF or AF in the 3GPP network or the data network. UE-1 registers itself with AIMRF as an AIMU that shows its own AI-Capability and Trace-Capability, while UE-2 registers itself with AIMRF as an AIMP and also shows its own AI-Capability and Trace-Capability. AIMRF maintains a list of the registered AIMU and AMIP. Alternatively, AIMRF publishes / stores the registered AIMU and AIMP to the DSSF. - The AITMF is deployed as an NF or AF in a 3GPP network or a data network to manage trace instructions. The AITMF can determine appropriate Trace-Instructions for UE-1 and UE-2. The AITMF can store Trace-Instructions in the DSSF and can also retrieve Trace-Instructions from the DSSF. - Information regarding the registered AIMU, registered AIMP, registered AI models, deployed AI tasks, and / or trace instructions can be stored in and maintained by the DSSF.

[0368] The AIMRF is responsible for deploying an AI task to UE-2 to train an AI model. When deploying an AI task to UE-2, the AIMRF can assign Trace-Instructions to the AI task. Such trace instructions can be obtained from the AITMF.

[0369] After UE-2 generates an AI model, UE-2 registers the AI model with the AIMRF. When UE-2 registers the AI model, UE-2 can indicate the Trace-Instructions associated with the AI model. The AIMRF maintains a list of registered AI models, and each registered AI model may have associated Trace-Instructions.

[0370] The AIMRF is also responsible for deploying an AI task to UE-1 for using an AI model for knowledge inference. When the AIMRF deploys an AI task to UE-1, the AIMRF can configure the AI task using Trace-Instructions. Such Trace-Instructions can be obtained from the AITMF.

[0371] UE-1 can discover an AI model (e.g., an AI model generated by UE-2) from the AIMRF. The AIMRF ensures that the Trace-Capability of UE-1 matches the Trace-Instructions of the discovered AI model.

[0372] The AIMRF can push the discovered AI model to UE-1 along with its Trace-Instructions. Also, UE-1 can use a separate step to retrieve / pull the discovered AI model and its Trace-Instructions from the AIMRF.

[0373] Alternatively, UE-2 can find UE-1 from the AIMRF and actively push an AI model with Trace-Instructions to UE-1.

[0374] Figure 21 shows another example of deployed traceability-aware AI management in a 3GPP cellular network. In this example, the AIMU is still a UE, but the difference from Figure 20 is that the AIMP is an NF or AF within the 3GPP network or data network.

[0375] Figure 22 shows another example of deployed traceability-aware AI management in a 3GPP cellular network. In this example, the AIMP is still a UE, but the difference from Figure 20 is that the AIMU is an NF or AF within the 3GPP network or data network.

[0376] Service flow embodiments for the discovery and deployment of traceability-aware AI models Figure 23 shows an example of a service flow for the discovery and deployment of a traceability-aware AI model based on the procedure of Figure 19. Note that the AIMU-ID in Figure 23 is a UE identifier such as, but not limited to, the Global Unique Temporary Identifier (GUTI) of the UE or the Subscription Concealed Identifier (SUCI) of the UE.

[0377] Assume the following. The AIMP in the 3GPP core network trains a new AI model for efficient radio resource allocation for upstream communication. The AIMP is for deploying the AI model as an AIMU to the UE. On the other hand, the AIMP wants to know whether the AI model is accurate or useful for the UE and the system as a whole. In other words, the AIMP hopes that the UE can trace the AI model when the AI model is deployed and executed. First, the AIMP finds a suitable UE with Trace-Capability that matches the Trace-Criteria of the AIMP from the AIMRF. Next, the AIMP can determine the trace instruction by itself, or the AIMP can obtain the trace instruction from the AITMF. Finally, the AIMP deploys an AI model with the corresponding trace instruction to the UE.

[0378] The following preconditions can be assumed for Figure 23. - The AIMRF, AITMF, DSSF, AIMP, and PCF are registered with the NRF. - The AIMP has found the AIMRF, AITMF, and PCF. - The UE is registered with the 3GPP cellular network and can communicate with core network functions such as the AIMRF via the AMF (not shown). - Both the UE and the AIMP are registered with the AIMRF. - The AIMP generates an AI model.

[0379] Next, the service flow in FIG. 23 will be described.

[0380] In step S2302, AIMP2305 sends a request to AIMRF2303 to discover an AIMU in order to deploy the AI model to AIMU2301.

[0381] In step S2304, AIMRF2303 sends a message to PCF2309 to check whether there is an AIMU discovery policy applicable to AIMP2305.

[0382] In step S2306, PCF2309 sends the AIMU discovery policy to AIMRF2305.

[0383] AIMRF2303 permits the request of AIMP received in step S2302. If approved, AIMRF2303 finds one or more AIMU2301 from the AIH records held locally. In step S2308, AIMRF2303 sends the discovered AIMU to AIMP2305 (i.e., in this case, the UE).

[0384] In step S2310, AIMP2305 sends a request message for deploying the AI model to UE2301.

[0385] UE2301 approves the received request. (Otherwise, the service flow stops). In step S2312, UE2301 sends a request to AIMP2305 to retrieve the AI model.

[0386] In step S2314, AIMP2305 sends the content of the AI model with a trace instruction to UE2301.

[0387] In step S2316, UE2301 may send a request to AITMF2309 to retrieve the trace instructions of the AI model. In this case, in step S2318, AITMF2309 sends the requested trace instructions to UE2301.

[0388] In step S2320, UE2301 installs the AI model.

[0389] In step S2322, UE2301 requests user input for the traceability option.

[0390] In step S2324, UE2301 receives the user input and uses it to configure the AI model.

[0391] In step S2326, UE2301 creates an AI model record of the installed AI model.

[0392] In step S2328, UE2301 sends the AI model record to AIMRF2303, AIMP2305, AITMF2307, and / or DSSF2311.

[0393] ETSI SAI Embodiment FIG. 24 shows an example of a method for traceability-aware AI task and model deployment according to the present principle implemented in the framework of ETSI SAI including the following logical entities. - AIMU: The same as AIMU in FIG. 7. - AIMP: The same as AIMP in FIG. 7. - AITM: The same as AITM in FIG. 7. - DSS: The same as DSS in FIG. 7. - AIRM: A combination of AIR and AIM in FIG. 7.

[0394] In step 2402a, AIMU 2401 registers itself with AIRM 2403 which indicates its Trace-Capability, using steps S1002, S1004, and S1006 in FIG. 10. In step 2402b, AIMP 2405 registers itself with AIRM 2403 which indicates its Trace-Capability, using steps S1002, S1004, and S1006 in FIG. 10.

[0395] In step 2404, AIRM 2403 generates an AI host record to DSS 2409 (that is, the registration records of AIMU and AIMP).

[0396] In step 2406, AIRM 2403 requests Trace-Instructions for the registered AIMP 2405 and AIMU 2401 from AITM 2407, for example, based on their Trace-Capability.

[0397] In step 2408a, AIRM 2403 deploys an AI task to AIMU 2401. In step 2408b, AIMR 2403 also deploys the AI task to AIMP 2405. The same steps from any of FIG. 12, FIG. 13, FIG. 14, or FIG. 15 can be used for steps 2408a and 2408b.

[0398] In step 2410, AIMP 2405 trains and generates an AI model using the deployed AI task.

[0399] In step 2412, AIMP 2405 registers the generated AI model which indicates its Trace-Instructions. For step 2412, the same steps as in FIG. 16 can be used.

[0400] In step 2414, in some cases, via AIRM2403, AIMP2405 deploys the generated AI model to AIMU2401. AIMP2405 can directly install the AI model to AIMU2401. Alternatively, AIMU2401 can discover and download the AI model from AIRM2403. The same step from any of FIGS. 17, 18, or 19 can be used for step 2414.

[0401] In step 2416, AIMU2401 installs the AI model and configures the related Trace-Instructions.

[0402] In step 2418, AIMU2401 generates an AI model record of the installed AI model. AIMU2401 sends the AI model record to AIRM2403 and / or DSS2409.

[0403] Conclusion In the foregoing, the features and elements are provided in specific combinations, but it will be understood by those skilled in the art that each feature or each element can be used alone or in any combination with other features and elements. The present disclosure should not be limited in terms of the specific embodiments described in this application, and these embodiments are intended as examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations may be made without departing from the spirit and scope of the present invention. Any element, operation, or instruction used in the description of this application should not be construed as important or essential to the present invention unless explicitly presented as such. In addition to those listed in this specification, functionally equivalent methods and devices within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure should be limited only by the terms of such claims together with the full scope of equivalents to which the claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

[0404] The foregoing embodiments have been discussed in terms of the terminology and structure of infrared-compatible devices (i.e., infrared radiation emitters and receivers) for the sake of brevity. However, the embodiments discussed are not limited to these systems and can also be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0405] It should also be understood that the terms used in this specification are for the purpose of describing particular embodiments only and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed over time. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote", and / or the term "head-mounted display" or its abbreviation "HMD" may mean (i) a wireless transmit and / or receive unit (WTRU), (ii) any of some embodiments of a WTRU, (iii) a wireless and / or wired (e.g., tetherable) device configured to have some or all of the structure and functionality of a WTRU, (iii) a wireless and / or wired device configured to have less structure and functionality than all of the structure and functionality of a WTRU, or (iv) the like, or may include the same. Details of exemplary WTRUs that may represent any of the WTRUs listed herein are provided herein with respect to FIGS. 1A-1D. As another example, the various embodiments disclosed herein and the various embodiments below are described as utilizing a head-mounted display. One of ordinary skill in the art will recognize that devices other than a head-mounted display may be utilized and that some or all of the present disclosure and the various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an augmented reality experience.

[0406] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0407] Without departing from the scope of the present invention, variations of the methods, apparatuses, and systems provided above are possible. Considering the wide variety of embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the following claims. For example, the embodiments provided herein include portable devices that may include or be utilized with any suitable voltage source, such as a battery that provides any suitable voltage.

[0408] Furthermore, in the above embodiments, attention should be paid to the processing platform, computing system, controller, and other devices including a processor. These devices may include at least one Central Processing Unit ("CPU") and memory. In accordance with the convention of those skilled in the art of computer programming, references to operations and symbolic representations of operations or instructions may be implemented by various CPUs and memories. Such operations, and operations or instructions may be referred to as "executed", "executed by a computer", or "executed by a CPU".

[0409] Those skilled in the art will understand that operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. An electrical system represents data bits that can cause a resulting conversion or reduction of electrical signals, maintains the data bits in a memory location of a memory system, thereby reconstructing or otherwise changing the operation of the CPU and the processing of other signals. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic characteristics corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

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

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

[0412] There is little difference between the hardware implementation and the software implementation of the aspects of the system. Whether to use hardware or software is generally (not always, but in certain contexts the choice between hardware and software may be important) a design choice representing a cost and efficiency trade-off. There may be various means of implementation (e.g., hardware, software, and / or firmware) by which the processes and / or systems and / or other techniques described herein can be effective, and the preferred means of implementation can vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if the implementer determines that speed and accuracy are of utmost importance, the implementer can primarily select means of implementation of hardware and / or firmware. If flexibility is of utmost importance, the implementer can primarily select a software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0413] In the foregoing detailed description, various embodiments of devices and / or processes have been shown through the use of block diagrams, flowcharts, and / or examples. As long as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or any actual combination thereof. In one embodiment, some portions of the subject matter described herein can be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit as one or more computer programs operating on one or more computers (e.g., as one or more programs operating on one or more computer systems), as one or more programs operating on one or more processors (e.g., as one or more programs operating on one or more microprocessors), as firmware, or as any actual combination thereof, and it will be recognized by those skilled in the art that designing the circuitry and / or writing the code for the software and / or firmware is within the scope of the skill of those in the art in light of this disclosure. Additionally, it will be understood by those skilled in the art that the mechanisms of the subject matter described herein can be distributed as various forms of program products and that the exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal transmission medium used to actually effect the distribution. Examples of signal transmission media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memories, and the like, and transmission media such as digital and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.).

[0414] It will be recognized by those skilled in the art that it is common in the art to describe a device and / or process in the manner described herein and then, using engineering techniques, integrate such described device and / or process into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. A typical data processing system generally includes one or more of a system unit housing, a video display device, memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, an operating system, drivers, a graphical user interface, and computing entities such as application programs, one or more interaction devices such as a touchpad or screen, and / or a control system including a feedback loop and a control motor (e.g., a feedback for detecting position and / or speed, a control motor for moving and / or adjusting components and / or quantities). It will be recognized by those skilled in the art that a typical data processing system can be implemented using any suitable commercially available components as typically found in a data computing / communication system and / or a network computing / communication system.

[0415] The subject matter described in this specification may refer to different components that are included within or connected to different other components. Such depicted architectures are merely examples, and it should be understood that many other architectures that achieve the same functionality may be implemented in practice. Conceptually, any arrangement of components for achieving the same functionality is effectively "associated" so that the desired functionality can be achieved. Thus, any two components in this specification that are combined to achieve a particular functionality can be considered to be "associated" with each other such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components thus associated can be considered to be "operably connected" or "operably coupled" to each other for achieving the desired functionality, and any two components that can be thus associated can also be considered to be "operably couplable" to each other for achieving the desired functionality. Specific examples of operably couplable include, but are not limited to, components that are physically fittable and / or physically interact, and / or wirelessly interactable and / or wirelessly interact, and / or logically interact and / or logically interactable components.

[0416] Regarding the use of substantially any plural and / or singular terms in this specification, one of ordinary skill in the art can convert from plural to singular and / or from singular to plural as appropriate for the context and / or application. In this specification, various singular / plural permutations may be explicitly recited for clarity purposes.

[0417] Generally, it will be understood by those skilled in the art that the terms used in this specification, particularly in the appended claims (e.g., the body of the appended claims), are generally intended to be “non-limiting” terms (e.g., the term “comprising” should be construed as “comprising, but not limited to,” the term “having” should be construed as “having at least,” the term “including” should be construed as “including but not limited to,” etc.). Further, where a specific number of introduced claim recitations is intended, such intention will be expressly recited in the claim, and it will be understood by those skilled in the art that where such recitation is not present, such intention does not exist. For example, where only one item is intended, the term “single” or similar words may be used. To assist understanding, the following appended claims and / or the description in this specification may include the use of introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to limit any particular claim that introduces a claim recitation with the indefinite article “a” or “an” to embodiments that include only such one recitation, even if the same claim includes an introductory phrase such as “one or more” or “at least one” and an indefinite article such as “a” or “an” (e.g., “a” and / or “an” is to be construed as meaning “at least one” or “one or more”). The same applies to the use of the definite article used to introduce a claim recitation. Additionally, even where a specific number of introduced claim recitations is expressly recited, it will be recognized by those skilled in the art that such recitation should be construed to mean at least the recited number (e.g., a simple recitation of “two recitations” without other modifiers means at least two recitations, or two or more recitations).Furthermore, when notations similar to “at least one of A, B, and C, etc.” are used, generally, such a structure is intended to mean what a person skilled in the art would understand from that notation (e.g., “a system having at least one of A, B, and C” includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). When notations similar to “at least one of A, B, or C, etc.” are used, generally, such a structure is intended to mean what a person skilled in the art would understand from that notation (e.g., “a system having at least one of A, B, or C” includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It should be further understood by those skilled in the art that any actual discrete words and / or phrases presenting two or more alternative terms in any of the specification, claims, or drawings are intended to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” is understood to include the possibility of “A” or “B” or “A and B”. Further, as used herein, the term “any of” following a list of items and / or a list of categories of items is intended to include “any of”, “any combination of”, “any plurality of”, and / or “any combination of a plurality of” the items and / or categories of items, individually or in combination with other items and / or other categories of items. Further, as used herein, the term “set” is intended to include any number of items including zero. Additionally, as used herein, the term “number” is intended to include any number including zero. Also, as used herein, the term “plurality” is intended to be synonymous with “multiple”.

[0418] In addition, when a feature or aspect of the present disclosure is described from the perspective of a Markush group, those skilled in the art will recognize that the present disclosure is thereby also described from the perspective of any individual element or subgroup of elements of the Markush group.

[0419] As will be understood by those skilled in the art, for all purposes, such as for the purpose of providing a written description, all ranges disclosed herein include any possible sub-ranges and combinations of sub-ranges thereof. Any recited range can be readily recognized as enabling the same range to be decomposed, for example, into at least equal halves, thirds, fourths, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily decomposed into a lower third, a middle third, and an upper third, etc. Also, as will be understood by those skilled in the art, all words such as "up to", "at least", "more than", "less than", etc. include the recited number and refer to a range that can be later decomposed into sub-ranges as discussed above. Finally, as will be understood by those skilled in the art, a range includes each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0420] Furthermore, the claims should not be read as being limited to the order provided or the elements provided unless specifically so recited. In addition, in any claim, the use of the term "means for" is not intended to invoke 35 U.S.C. § 112, paragraph 6, or a means-plus-function claim format, and any claim that does not have the term "means for" is not so intended.

Claims

1. A device comprising at least one processor, wherein the at least one processor receives from at least one other device, information indicating an AI model for installation on the device to execute an artificial intelligence (AI) task, and information indicating a trace instruction based on a trace criterion for the AI model requested by the device, wherein the trace information corresponds to information for tracing one or more stages of an AI pipeline associated with the AI model, installs the AI model, creates a record of the installed AI model, and transmits a message including information indicating at least a part of the created record to a recording device, and is configured to be a device.

2. The device according to claim 1, wherein the at least one processor is configured to transmit, to at least one of the at least one other device, a request for an AI model, the request indicating information including the criterion.

3. The device according to claim 1, wherein the request further includes an identifier of the AI model.

4. The at least one processor is configured to receive, from a first device of the at least one other device, information indicating a second device, and the device according to claim 1, wherein the at least one processor is configured to receive the AI model by downloading the AI model from the second device.

5. The at least one processor receives, from the first device, information indicating a third device, and the device according to claim 4, wherein the at least one processor is configured to transmit, to the third device, information indicating a request for the trace instruction.

6. The at least one processor receives, from a first device, information indicating a third device, and the device according to claim 1, wherein the at least one processor is configured to transmit, to the third device, information indicating a request for the trace instruction.

7. The at least one processor and the device according to claim 1, wherein the at least one processor is configured to create the record using a trace configuration based on the trace instruction.

8. The at least one processor presents the trace instruction to the user, Receiving an input from the user, The device according to claim 7, configured to generate the trace configuration based on the trace instruction and the input from the user.

9. The device according to claim 8, wherein the input indicates a recipient of the message.

10. The device according to claim 1, wherein the created record regarding the installed AI model includes at least one of an identifier of the device, an identifier of the installed AI model, an address from which the AI model can be retrieved, and an address that can be used to push the fully trained AI model to the device.

11. A method performed by a device, Receiving from at least one other device, an AI model for installation on the device to execute an artificial intelligence (AI) task, and information indicating a trace instruction based on a trace criterion for the AI model requested by the device, wherein the trace information corresponds to information for tracing one or more stages of an AI pipeline associated with the AI model, Installing the AI model, Creating a record of the installed AI model, Sending a message including information indicating at least a part of the created record to a recording device, A method comprising.

12. The method according to claim 11, further comprising sending to at least one of the at least one other device, information indicating a request for an AI model, the request including the criterion.

13. The method according to claim 11, wherein the request further includes an identifier of the AI model.

14. The method according to claim 14, further comprising receiving from a first device of the at least one other device, information indicating a second device, wherein receiving the AI model includes downloading the AI model from the second device. The method according to claim 11.

15. Receiving from the first device, information indicating a third device, Sending to the third device, information indicating a request for the trace instruction, The method according to claim 14, further comprising.

16. Receiving from a first device, information indicating a third device, transmitting information indicating a request for the trace instruction to the third device; The method according to claim 11, further comprising.

17. creating the record using a trace configuration based on the trace instruction; The method according to claim 11, further comprising.

18. presenting the trace instruction to the user; receiving an input from the user; generating the trace configuration based on the trace instruction and the input from the user; The method according to claim 17, further comprising.

19. The method according to claim 18, wherein the input indicates a recipient of the message.

20. The created record regarding the installed AI model includes at least one of an identifier of the device, an identifier of the installed AI model, an address from which the AI model can be retrieved, and an address that can be used to push the fully trained AI model to the device. The method according to claim 11.

21. A device comprising at least one processor, wherein the at least one processor receives from another device an AI model for installation on the device to execute an artificial intelligence (AI) task and information indicating a trace instruction for the AI model, the trace instruction corresponding to information for tracing one or more stages of an AI pipeline associated with the AI model; installs the AI model; sends a message to the other device that includes information indicating the installation of the AI model on the device; configured to be device.

22. The device according to claim 21, wherein the at least one processor is configured to send to the other device information indicating a request for an AI model and resources available in the device for tracing the AI model on the device.

23. The at least one processor presents the trace instruction to the user; receives an input from the user; generates a trace configuration based on the trace instruction and the input from the user; The device according to claim 21, configured to be.

24. The device according to claim 23, wherein the input indicates a recipient of the message. **Claim 25** A method performed by a device, comprising: receiving, from another device, an AI model for installation on the device to perform an artificial intelligence (AI) task, and information indicating a trace instruction for the AI model, the trace instruction corresponding to information for tracing one or more stages of an AI pipeline associated with the AI model; installing the AI model; sending, to the other device, a message including information indicating the installation of the AI model on the device; The method includes the above steps. **Claim 26** The method according to claim 25, further comprising sending, to the other device, information indicating a request for an AI model and resources available in the device for tracing the AI model on the device. **Claim 27** presenting the trace instruction to a user; receiving an input from the user; generating a trace configuration based on the trace instruction and the input from the user; The method according to claim 25, further including the above steps. **Claim 28** The method according to claim 27, wherein the input indicates a recipient of the message.

Images