Methods, architectures, devices, and systems for traceability awareness artificial intelligence

Abstract

Programs, methods, architectures, apparatuses, systems, devices, and computer program products implementing retrospection of artificial intelligence (AI) tasks and host devices. A device receives, from at least one other device, an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating a retrospect instruction based on a retrospect criterion of the AI model requested by the device, wherein the traceability information corresponds to information for tracing one or more stages of an AI pipeline associated with the AI model; the AI model is installed; creating a record for the installed AI model; and transmitting a message to the recording device, the message including information indicating at least a portion of the created record.

Description

Background Art

[0001] The present disclosure relates generally to the fields of communications, software, and coding, including, for example, methods, architectures, devices, and systems related to traceability-aware artificial intelligence (AI). Summary of the invention

[0002] In a first aspect, the present principles are directed to a device comprising at least one processor configured to: receive from at least one other device an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating traceability instructions based on a traceability standard of the AI ​​model requested by the device, wherein the traceability information corresponds to information for tracing one or more stages of an AI pipeline associated with the AI ​​model; install the AI ​​model; create a record for the installed AI model; and transmit a message to a recording device, the message including information indicating at least a portion of the created record.

[0003] In a second aspect, the present principles are directed to a method performed by a device, the method comprising: receiving from at least one other device an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating traceability instructions based on a traceability standard of the AI ​​model requested by the device, wherein the traceability 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 for the installed AI model; and transmitting a message to a recording device, the message including information indicating at least a portion of the created record.

[0004] In a third aspect, the present principles are directed to a device comprising at least one processor configured to: receive from another device an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating traceback instructions for the AI ​​model, the traceback instructions corresponding to information for tracing back one or more stages of an AI pipeline associated with the AI ​​model; install the AI ​​model; and transmit a message to another device, the message comprising information indicating the installation of the AI ​​model on the device.

[0005] In a fourth aspect, the present principles are directed to a method performed by a device, the method comprising: receiving from another device an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating traceback instructions for the AI ​​model, the traceback instructions corresponding to information for tracing back one or more stages of an AI pipeline associated with the AI ​​model; installing the AI ​​model; and transmitting a message to another device, the message including information indicating the installation of the AI ​​model on the device. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding may be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, each of the figures in such drawings is an example. Therefore, the figures (figures) and detailed description should not be considered limiting, and other equally effective examples are possible and possible. In addition, the same reference numerals ("labels") in the various figures indicate the same elements, and wherein:

[0007] Figure 1A is a system diagram illustrating an example communication system;

[0008] Figure 1B It shows that it can be Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown;

[0009] Figure 1C It shows that it can be Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0010] Figure 1D It shows that it can be Figure 1A A system diagram of yet another example RAN and yet another example CN used within the communication system shown;

[0011] Figure 2 An AI host is shown having an AI agent with an AI task using an AI model;

[0012] Figure 3 Shows a general AI pipeline for supervised learning;

[0013] Figure 4 Showing the general federated learning (FL) process;

[0014] Figure 5 Two examples of deep learning (DL) applications for wireless networks are shown;

[0015] Figure 6 An example of FL application for a wireless network is shown;

[0016] Figure 7 An embodiment of the proposed traceability-aware AI management architecture is shown;

[0017] Figure 8 Shows the wireless system Figure 7 A first example of an embodiment of;

[0018] Fig. 9 Shows the wireless system Figure 7 A second example of an embodiment of;

[0019] Fig.10An embodiment of a traceability aware AI host (AIH) registration method is shown;

[0020] Fig.11 Another embodiment of the traceability-aware AIH registration method is shown;

[0021] Fig.12 An embodiment of traceability-aware AI task deployment initiated by AIH is shown;

[0022] Fig.13 An embodiment of traceability-aware AI task deployment initiated by an AI manager (AIM) is shown;

[0023] Fig.14 An embodiment of a traceability-aware FL task deployment initiated by an AIH is shown;

[0024] Fig.15 An embodiment of an AIM-initiated traceability-aware FL task deployment is shown;

[0025] Fig.16 A method for an AI model producer (AIMP) to register an AI model to an AI repository (AIR) according to an embodiment is shown;

[0026] Fig.17 A method of AIR-assisted traceability-aware model discovery and deployment according to an embodiment is shown;

[0027] Fig.18 A method of AIM-coordinated traceability-aware AI model discovery and deployment according to an embodiment is shown;

[0028] Fig.19 A method of AIMP-initiated traceability awareness model discovery and deployment according to an embodiment is shown;

[0029] Fig. 20 A first example of deploying traceability-aware AI tasks and model management in 3GPP cellular networks is shown;

[0030] Fig.21 A second example of deploying traceability-aware AI management in a 3GPP cellular network is shown;

[0031] Fig. 22 A third example of deploying traceability-aware AI management in a 3GPP cellular network is shown;

[0032] Fig.23 An exemplary service flow illustrating traceability-aware AI model discovery and deployment; and

[0033] Fig.24An example of a traceability-aware AI management approach including task and model deployment in the framework of ETSI Secure Artificial Intelligence (SAI) is shown. DETAILED DESCRIPTION

[0034] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, programs, components and circuits are not described in detail to avoid blurring the following description. In addition, the embodiments and examples not specifically described herein can replace the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein to practice or practice in combination with them. Although various embodiments in which equipment, systems, devices, etc. and / or any of its elements perform operations, processes, algorithms, functions, etc. and / or any part thereof are described and / or claimed herein, it should be understood that any embodiment described and / or claimed herein assumes that any equipment, systems, devices, etc. and / or any of its elements are configured to perform any operations, processes, algorithms, functions, etc. and / or any part thereof.

[0035] Example Communication System

[0036] The methods, devices, and systems provided herein are well suited for communications involving both wired and wireless networks. Figures 1A to 1D An overview of various types of wireless devices and infrastructure is provided in which various elements of the network can utilize, perform, be arranged according to, and / or be adapted and / or configured for the methods, devices, and systems provided herein.

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

[0038] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio 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, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include (or 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 smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated process chain), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

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

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

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

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

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

[0044] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio (NR) to establish NR radio access over the air interface 116.

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

[0046] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology 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 Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0047] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-a Pro, NR, etc.) to establish any of a small cell, a pico cell, or a femto cell. As Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0048] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although Figure 1A Not shown, but it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs any of GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

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

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

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

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

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

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

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

[0056] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from: a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. 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).

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

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

[0059] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the components / peripherals 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, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Components / peripherals 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

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

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

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

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

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

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

[0067] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

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

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

[0071] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to another type of wired / wireless network that reaches a distribution system (DS) or loads traffic into and / or out of the BSS. Traffic originating from outside the BSS to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent by the AP, for example, where the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between the source STA and the destination STA using a direct link setup (DLS) (e.g., directly sent between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

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

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

[0074] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, the data can be passed through a fragment parser after channel coding, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed on each stream respectively. The stream can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-mentioned operation of the 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC) layer, an entity, etc.

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

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

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

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

[0079] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the WTRUs 102a, 102b, 102c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be located on an unlicensed spectrum, while the remaining component carriers may be located on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

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

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

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

[0083] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least two session management functions (SMFs) 183a, 183b, and at least one data network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0084] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing, for example, to customize CN support for the WTRU 102a, 102b, 102c based on the type of service the WTRU 102a, 102b, 102c is utilizing. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-APro) and / or non-3GPP access technologies (such as Wi-Fi).

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

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

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

[0088] Given that Figures 1A to 1D and Figures 1A to 1D 102a to 102d, base stations 114a to 114b, eNode-Bs 160a to 160c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a to 180c, AMFs 182a to 182b, UPFs 184a to 184b, SMFs 183a to 183b, DNs 185a to 185b, and / or any other elements / devices described herein. A simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0089] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions when 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 simulation devices can perform one or more or all functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly connected to another device for testing purposes, and / or can use over-the-air wireless communication to perform testing.

[0090] One or more simulation devices can perform one or more (including all) functions when not implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., tested) to implement testing of one or more components. One or more simulation devices can be test equipment. The simulation device can use direct RF connection and / or wireless communication via RF circuits (e.g., which can include one or more antennas) to transmit and / or receive data.

[0091] introduce

[0092] Blockchain Technology

[0093] Blockchain technology jointly utilizes and builds on existing technologies such as encryption, hashing, Merkle trees, distributed ledgers, peer-to-peer networking, and consensus protocols. Blockchain technology integrates them 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 blockchain systems are called blockchain applications. Blockchain systems are supported by a blockchain network consisting 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 be peer-to-peer networked to broadcast blockchain transactions and blocks between them. Blockchain nodes also execute consensus protocols to achieve distributed trust without relying on centralized parties. For example, blockchain transactions can be digital representations of real-world transactions, digital records of physical assets, digital records of physical events, digital records of any actions in information systems, digital payments, and / or digital smart contracts. A block groups multiple blockchain transactions. Blockchain is a data structure that links more and more blockchains together. Herein, blockchain technology is used as a non-limiting example of a distributed ledger technology; therefore, the present principles 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].

[0094] The general workflow of a blockchain system consists of five steps.

[0095] 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, usually a hash of the user's public key, which is used to sign the new transaction. The signed new transaction is then sent to the blockchain network.

[0096] Step 2: Broadcast and verify transactions. A small number of blockchain nodes first receive the new transaction, which uses the public key of the user included in the transaction to verify its integrity. 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.

[0097] Step 3: Build a new block. A specific blockchain building node (called a mining node or a full blockchain node) begins grouping multiple newly generated and pending transactions to generate a new block. The new block will include a block header and a block body. The block header typically includes a hash of the previously confirmed block and a hash of all included transactions (e.g., a Merkle tree). Depending on the consensus protocol, the block header can contain additional information. The block body contains the contents of all included transactions. Each blockchain building node independently attempts to create a new block.

[0098] Step 4: Verify the new block based on the consensus protocol. In step 3, the building blockchain nodes independently try to create a new block. They run the same consensus protocol (e.g., proof of work in the Bitcoin system) and agree on who (i.e., the winner) is allowed to insert the block in the existing blockchain. The winner of the consensus protocol sends its newly generated block to the blockchain network. This new block is broadcasted and all building blockchain nodes receive and verify it.

[0099] Step 5: Update the blockchain. After the newly generated block is verified in step 4, it is successfully appended to the existing blockchain and linked to it because it contains the hash value of the previous block (i.e. the last block of the previous blockchain).

[0100] Introduction to AI

[0101] The AI ​​system includes one or more AI agents that learn and / or utilize AI models based on at least one AI scheme (such as deep learning, federated learning, and reinforcement learning). AI agents typically reside in different physical or logical nodes (e.g., devices, servers, virtual machines in the cloud), referred to as AI hosts (AIH). Each AI agent typically hosts and runs AI tasks, such as tasks of learning AI models based on AI algorithms (e.g., deep learning algorithms, federated learning algorithms, reinforcement learning algorithms), or tasks of reasoning knowledge using AI models. Deep learning and reinforcement learning typically use one AI agent, while federated learning uses multiple AI agents to work together to learn AI models, which can be deep neural network models and policy models 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. AI algorithms can be supervised by relying on labeled training data, or can be unsupervised without using any labeled data. Figure 2 An AI host is shown having an AI agent with an AI task using an AI model.

[0102] In this article, the process of (re)installing an AI task (e.g., a piece of software code plus data) on an AI agent on an AI host is called "AI task deployment", while "AI model deployment" refers to the process of transferring and / or (re)installing an AI model to an existing AI task. It should be noted that when an AI task has been deployed on an AI agent, AI agent and AI task can be used interchangeably in this description.

[0103] In this document, “model” and “AI model” are used interchangeably and have the same meaning unless otherwise specified; similarly, “task” and “AI task” are used interchangeably and have the same meaning unless otherwise specified.

[0104] Figure 3 A general AI pipeline for supervised learning is shown. The pipeline typically includes multiple stages: 1) task configuration, which includes deploying AI agents / tasks by AI applications or users; 2) data preparation, which includes data collection and optional feature engineering / extraction; 3) training to learn AI models; 4) validation to test and validate the learned AI models; 5) model deployment, which is used to deploy and transfer validated AI models; and 6) inference, which is used to infer and predict future knowledge using new data as input (referred to as input data for inference). The results (e.g., outcomes) from inference can be used to take actions or trigger return training to retrain the AI ​​model.

[0105] Depending on the AI ​​deployment choice, an AI agent can be: 1) an AI agent for learning (AIA4L) responsible for learning AI models; 2) an AI agent for reasoning (AIA4I) that uses the learned AI models for reasoning and prediction; and 3) an AI agent for learning and reasoning (AIA4LI) that combines the first two. AI model transfer usually occurs between AIA4L and AIA4I or between multiple AIA4LIs.

[0106] Deep Learning

[0107] Deep learning (DL) is a specialized supervised machine learning (ML) that uses deep neural networks (DNNs) that are well known in the art. DNNs typically include an input layer, multiple hidden layers, and an output layer. Each layer (especially the hidden layer) has a certain number of artificial neurons that are connected to neurons in the previous layer and neurons in the next layer. The connection between two neurons in two adjacent layers is assigned a weight that indicates to what extent the neurons in the previous layer will affect the neurons in the next layer. Training DNNs involves repeated feedforward and backpropagation.

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

[0109] Back Propagation: The generated output is used to calculate the loss according to a predefined loss function. The loss is then used to adjust the weights between two adjacent layers using gradient descent all the way back from the output layer to the input layer. The AI ​​model learned in deep learning is the set of weights connecting all the neurons in the DNN. A deep learning system can be deployed as a single AI agent (i.e., AIA4LI) or multiple separate AI agents (e.g., one AIA4L and multiple AIA4Is).

[0110] DNNs can provide a good way to learn or approximate nonlinear functions that map inputs to outputs. However, the data items used to train DNNs should have no or only small correlations to achieve good performance (e.g., learning accuracy). DNNs can be used to solve many machine learning problems, such as prediction and classification. Different types of DNNs have been designed for different applications. For example, convolutional neural networks (CNNs) have been successfully used in computer vision and acoustic modeling, while recurrent neural networks (RNNs) and long short-term memory (LSTM) are good tools for natural language processing.

[0111] Federated Learning

[0112] Federated learning (FL) is a framework for distributed ML or distributed AI. In FL, training data is maintained locally at multiple distributed federated learning clients (FLCs) (e.g., mobile devices). Each FLC performs local training (e.g., deep learning), generates local model updates, and sends local model updates to a federated learning server (FLS). As a central entity, the FLS aggregates local model updates from the FLCs and generates global model updates, which are sent to participating FLCs for the next round of training. Exemplary advantages of federated learning may include: 1) improved data privacy protection because the training data is retained in the FLCs; 2) reduced communication overhead because the training data does not need to be collected / transmitted to the central entity; and 3) improved learning speed because model training now utilizes distributed computing resources at the FLCs. However, FL requires that model updates be transmitted between the FLSs and the FLCs, which incurs additional communication overhead compared to centralized machine learning. In addition, FL requires that the data at all FLCs follow independent and identical distribution (IID) (i.e., IID data) to achieve good learning performance. In addition, FL inherits potential security issues and threats, such as data poisoning and model poisoning attacks. In fact, FLS hosts an FL agent for learning (i.e., AIA4L), while each FLC has an FL agent that can be used for learning and reasoning (i.e., AIA4LI). It should be noted that both FLS and FLC are AIHs.

[0113] Figure 4A general federated learning process is shown, where, for example, the FLS can be the NWDAF in 5G and the FLC can be the UE. The FLS and FLC jointly take the following steps to perform the FL task.

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

[0115] Step S402: The FLS configures the FL task (eg, deploys or instructs the FLC to start local training of the deployed FL task) to each selected FLC.

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

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

[0118] Step S405: After the local training round in step S404, each FLC generates a local model update and sends it to the FLS.

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

[0120] Step S407 is similar to step S403, but the FLS sends the global model update to the selected FLCs. Note that the FLS may change the set of selected FLCs between training rounds, such as retaining one or more FLCs in the previous set.

[0121] Step S408 is similar to step S404, ie, the selected FLC independently trains the global model based on the received global model update.

[0122] Step S409 (not shown) is similar to step S405: the FLC sends the local model update to the FLS. The FLS may then generate a new global model update, which the FLS may send to the FLC as the start of a further iteration.

[0123] AI-related 3GPP standards

[0124] 3GPP TS22.261 [3GPP TS22.261 V18.5.0 (2021-12); Service requirements for 5G systems; Stage 1 (Release 18)] specifies AI model delivery requirements for three types of AI operations: 1) splitting of AI operations between AI endpoints; 2) distribution and sharing of AI models / data on the 5G system (5GS); and 3) distributed / federated learning (FL) on the 5GS.

[0125] 3GPP TR23.700-80 [3GPP TR 23.700-80v0.3.0 (2022-05) Study on support for AI-based services in 5G system (Release 18)] aims to define intelligent transport support for AI-based services in 5GS. It will focus on 5GS architecture and functional extensions so that service providers can use 5GS as an intelligent transport platform to support AI-based services.

[0126] TR 23.700-80 has a number of key objectives: to study possible architectural and functional extensions to support application layer AI operations defined in TS 22.261; to study possible QoS, policy enhancements to support application AI operation traffic while supporting regular (non-application AI) 5GS user traffic; and to study whether and how 5GS can provide assistance to AF and UE so that AF and UE manage FL operations and model distribution / redistribution (e.g. FL member selection) to facilitate collaborative application AI based on federated learning operations between application clients (i.e. FLCs) and application servers (i.e. FLSs) running on UEs.

[0127] In addition, 3GPP recently approved a new Release 19 study item [3GPP SA1 S1-220183, “Study of AI Model Transfer Phase 2”, 3GPP SA WG1 Meeting #97-e, February 14-24, 2022] to study use cases and potential services and performance requirements for distributed AI training / inference involving direct device connections, with the following two goals: distributed AI training / inference based on device-to-device connections; and charging and safety aspects.

[0128] ETSI SAI

[0129] 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 explore potential issues related to sharing and reusing models in different tasks or various industry-related applications. The scope of AI traceability includes, but is not limited to, discovering potential threats and their associated remediation measures. Further AI traceability can improve the decisions to which AI traceability will apply, protect the ownership of AI creators, and protect the source of model verification, ensuring model integrity or discovering its purpose.

[0130] Wireless AI Use Cases

[0131] Two wireless AI use cases are described, including deep learning (DL) in wireless networks and federated learning for wireless networks. In both use cases, AI tasks (i.e., deep learning and federated learning) and AI models need to be deployed from the edge data network (or core network) to wireless devices. As shown in ETSI GR SAI 0010, it is very important to provide traceability for deployed AI tasks and AI models, which requires tracing AI tasks and AI models during their lifecycle, which can serve as the basis for building auditable, explainable, and trustworthy AI.

[0132] Figure 5 Two examples of DL applications for wireless networks are shown, where the UE hosts a DL agent that hosts an AI task. The AI ​​task uses a DL model, a learned DL model, or both. The DL agent at each UE is pre-installed or deployed at runtime. Note that in Figure 5 In this use case, the DL can be replaced by another type of AI algorithm. In this use case, the base station and each UE are AIHs.

[0133] DL for radio resource allocation: DL is used to learn the radio resource allocation between UE-1 and the base station. For example, the DL agent (i.e., DLA4L) is deployed in an edge server co-located with the base station. The DL agent is configured with an AI task to learn a radio resource allocation policy. Based on historical transmission information about UE-1 (and / or other UEs) and the base station, the DL agent learns a model for allocating radio resources to UE-1 (and / or UE-2). The learned model is then deployed to UE-1 (and / or UE-2). At each new time slot, the DL agent (i.e., DLA4I) at UE-1 and / or UE-2 can use the model to decide on new radio resources for upstream transmission. This AI-based approach can capture wireless channel dynamics and changing traffic on wireless channels more quickly and accurately, and in turn lead to improved radio resource utilization.

[0134] DL for vehicle-to-vehicle content dissemination: Three vehicles (i.e., UE-3, UE-4, and UE-5) are located in the same area and can communicate directly with each other to share content (e.g., media files). To disseminate content more efficiently, each vehicle is installed with a DL agent (i.e., DLA4LI), for example to learn social relationships and content popularity.

[0135] Figure 6 An example of FL application for wireless networks is shown, where each UE hosts a FL agent that collaboratively participates in learning a global model and uses the learned global model for reasoning. The FL agent at each UE is pre-installed or deployed at runtime. In this case, each UE and edge server is an AIH.

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

[0137] In the AI ​​use cases for wireless networks described above, the UE typically hosts an AI agent (e.g., AIA4L, AIA4I, or AIA4LI) that learns a model, uses the model for knowledge reasoning, or participates in both. In order to deploy a specific AI solution for a wireless network, it is first necessary to install an AI agent (e.g., a software) on the corresponding UE and / or other network nodes (such as edge servers). The AI ​​agent then begins training the AI ​​model, which may require collecting training data. After training the AI ​​model, the AI ​​agent needs to test and verify the AI ​​model based on test data and verification data before the AI ​​model can be deployed (e.g., transferred from one AI agent to another). Finally, the deployed or transmitted AI model can be used to infer and predict future knowledge from real data, and take action based on this.

[0138] It is critical to ensure that the entire AI system is trustworthy, especially in wireless environments because there are distributed parties and potential threats to AI agents and AI models, such as data poisoning attacks, may occur. Therefore, one approach is to trace and record the entire AI system, known as AI traceability. This requirement for AI traceability can come from AI agents, AI applications, or AI users. However, tracing the entire AI system can bring huge overhead, especially in communication systems where network latency is an important parameter. In addition, it may not be necessary to trace every stage of the AI ​​system. For example, in federated learning, tracing the training stage may be more important than the reasoning stage because the training stage is performed by multiple distributed nodes with more potential threats or risks. In general, efficient and flexible AI traceability schemes may be required, especially for wireless AI use cases. According to the present principle, AI traceability information or AI traceability records or AI traceability documents are information generated from tracing AI systems or AI pipelines.

[0139] AI management according to the present principles mainly refers to multiple stages / operations / procedures, such as but not limited to AI host registration, AI task deployment, AI model registration, AI model discovery, and AI model transmission / deployment for registering AIH to the repository. Existing AI management procedures ignore traceability, which can lead to inefficient AI management, reduced AI reliability, and ultimately reduced user trust in AI. For example, AI users may need to discover AI models that support traceability, which can provide better transparency and credibility for AI users. However, AI model registration that is not related to traceability cannot indicate whether the AI ​​model supports traceability, thereby failing to meet the needs of AI users. In addition, if traceability is not supported when deploying an AI task / model, the AI ​​task / model may need to be removed and redeployed when traceability is needed later. In the worst case, due to the lack of traceability, the AI ​​model / task may need to be (re)deployed and / or retrained multiple times, which will bring additional overhead in terms of repeated AI management procedures and consumed resources. In addition, each of these AI management stages / procedures can be performed by different physical nodes and / or logical nodes; for example, Figure 5 The training and knowledge inference for radio resource allocation in are done by the base station and the UE respectively. These physical nodes and / or logical nodes usually have different resources (e.g., computing power), which should be considered together in a unified way to achieve traceability-aware AI management.

[0140] In light of the above discussion, the following questions are identified:

[0141] Question #1: How to design an AI management architecture that can flexibly trace the AI ​​pipeline?

[0142] Real-world AI systems (e.g., FL systems) can be dynamic and heterogeneous, for example, in terms of the types of AI tasks, the amount of training data available, the number of AI agents involved, and the capabilities of the AI ​​agents involved. A traceability-aware AI management architecture should be applied and suitable for different AI systems, different AI tasks, and different AI agents. Such a flexible traceability-aware AI management architecture may also be capable and / or extensible to support different levels of traceability (e.g., tracing the entire AI pipeline or tracing a stage of a pipeline), using different but appropriate traceability instructions and generating appropriate AI traceability records as needed. For example, such a flexible traceability-aware AI management architecture may provide general methods / interfaces / procedures that can be utilized to implement traceability for different AI systems based on the needs of different AI systems.

[0143] In order to design a flexible traceability-aware AI management architecture, the following issues need to be considered.

[0144] Issue #2: Traceability-aware AI host registration.

[0145] When an AI host registers itself to an AI repository entity, methods can represent the traceability of the AI ​​host and how to expose its traceability to other entities.

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

[0147] When deploying an AI task, it may be important to explicitly and simultaneously configure the traceability instructions of the AI ​​task, so that the AI ​​task can automatically trace itself according to the configured traceability instructions.

[0148] Problem #4: Traceability-aware AI model registration.

[0149] When an AI model is registered to an AI repository entity, a method may configure or associate appropriate traceback instructions with the AI ​​model.

[0150] Problem #5: Traceability-aware AI model discovery and deployment.

[0151] When an AI host discovers and requests to install / host an AI model, the method can ensure that the traceability instructions of the discovered AI model match the traceability capabilities of the AI ​​host.

[0152] Overview

[0153] As used herein, the following terms are defined below.

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

[0155] AI task: A task used to train an AI model and / or use a trained AI model. An AI task can be deployed to an AI host as a piece of software with relevant information (e.g., an initial AI model, training data, and / or input data).

[0156] AI Agent: An entity capable of running AI tasks. AI agents are hosted by an AI host, which can host multiple AI agents. AI agents can generate / train AI models and / or use trained AI models to infer knowledge.

[0157] AI Host: An entity with the software and hardware to support one or more AI agents.

[0158] AI Repository: An entity that allows registration of AI hosts and / or AI models, discovery of AI hosts and / or AI models, etc.

[0159] AI pipeline: A set of stages for performing one or more AI tasks. The AI ​​pipeline may include one or more (e.g., all) of task configuration, data preparation, training for learning AI models, validation for testing and validating the learned AI models, model deployment for deploying and transmitting validated AI models, and inference using new data as input to reason and predict future knowledge.

[0160] AI Traceback Manager: An entity that manages whether, when, how, and / or how the contents of an AI pipeline are traced. The AI ​​Traceback Manager can generate, configure, update, and remove traceback instructions for / from an AI host, AI agent, AI task, and / or AI model.

[0161] Traceability Instructions: Specifications or conditions or standards or policies or rules that describe whether, when, how, and / or what to trace back to the AI ​​pipeline. The AI ​​agent (or AI host) generates traceability records according to the configured traceability instructions. Traceability instructions can be called traceability conditions, traceability standards, traceability commands, traceability rules, and / or traceability policies.

[0162] AI Manager: An entity that manages AI tasks, AI agents, AI hosts, AI repositories, and even AI traceback managers.

[0163] Distributed Storage System (DSS): A system that stores information (e.g., information about AI models, information about AI hosts, training data, inference knowledge, traceability instructions, traceability records, etc.). A DSS can be a distributed database, a distributed ledger, a blockchain system, etc.

[0164] Traceability-aware AI management architecture

[0165] 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. Traditional AI management solutions for tracing AI tasks or AI models after they are deployed are referred to as post-deployment tracing methods. This principle proposes a more proactive approach that simultaneously enables or embeds AI traceability during AI management operations. For example, if the deployed AI task does not support AI traceability, the post-deployment tracing method may fail. In addition, this principle can avoid or reduce additional overhead, for example, the post-deployment tracing method may require modification or redeployment of deployed AI tasks in order to support AI traceability. A traceability-aware AI management framework is proposed as an active tracing method that combines traceability support and AI management by jointly considering which AI task / model needs to be traced (i.e., tracing instructions) and what resources the AI ​​host can allocate or afford to trace its hosted AI tasks / models (i.e., tracing capabilities). The proposed traceability-aware AI management framework can provide basic and general functions and interfaces (e.g., configuring tracing instructions when configuring AI tasks) without being limited to specific AI systems / tasks / models. Furthermore, the proposed traceability-aware framework allows configuring appropriate traceability instructions for different AI hosts, depending on their traceability capabilities and the characteristics of the AI ​​tasks / models they host. Thus, more useful traceability information about the AI ​​pipeline can be collected.

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

[0167] The AI ​​traceability manager (AITM) can provide and determine the traceability instructions for tracing the AI ​​task / model (e.g., generating an AI traceability record for each training round) based on the traceability instructions of the AI ​​task / model and the traceability capabilities of the AI ​​host (AIH) hosting the AI ​​task / model (e.g., available storage for storing the generated AI traceability records). It should be noted that the AIH can host one or more AI agents, which can be AIA4L, AIA4I and / or AIA4LI.

[0168] An AIH can register its traceability capabilities with an AI Repository (AIR), which can be exposed to and discovered by both entities, such as an AI Manager (AIM). An AIH can be an AI Model Producer (AIMP) or an AI Model User (AIMU); an AIMP can host one or more AIA4Ls or ALA4LIs, while an AIMU can host one or more AIA4Is. An AIR can publish each registered AIH to a distributed storage system (DSS), such as a distributed ledger system.

[0169] AIM can enable traceability at the same time when deploying AI tasks to AIMP by configuring traceability instructions for AI tasks. The traceability instructions match the traceability capabilities that AIMP can support.

[0170] AIM can enable traceability simultaneously when deploying AI tasks to AIMU by configuring traceability instructions for AI tasks. The traceability instructions match the traceability capabilities that AIMU can support.

[0171] AIR can also maintain a list of AI models generated by AIMP and registered to AIR. When AIMP registers an AI model, AIMP can configure traceability instructions for the AI ​​model. AIMU can come to AIR to find appropriate AI models with traceability instructions that match the traceability capabilities of AIMU. AIR can publish each registered AI model to a DSS, such as a distributed ledger system.

[0172] When an AI task with a traceability instruction has been installed to AIMP, AIMP runs the AI ​​task and simultaneously generates an AI traceability record according to the traceability instruction configured for the AI ​​task. The AI ​​traceability record is sent to a DSS, such as a distributed ledger system.

[0173] After the AI ​​task with the traceability instruction and the corresponding AI model are installed to the AIMU, the AIMU runs the AI ​​task and generates an AI traceability record according to the traceability instruction configured for the AI ​​task / model. The AI ​​traceability record is sent to a distributed storage system (DSS), such as a distributed ledger system.

[0174] AIM can proactively discover new AI models and push them to the AIMU with new retroactive instructions.

[0175] AIMP can pre-register a partially trained AI model with AIR or announce it to AIMU along with traceback instructions. After the AI ​​model is fully trained, AIMP can proactively push the AI ​​model to AIR or AIMU.

[0176] Figure 7 An embodiment of the proposed traceability-aware AI management architecture is shown, which includes many logical entities: AI Manager (AIM), AI Traceability Manager (AITM), AI Repository (AIR), AI Model Producer (AIMP), AI Model User (AIMU) and Distributed Data System (DDS). The salient feature of this architecture is the integrated AI pipeline management and traceability achieved through collaborative interactions between these logical entities. In other words, AI traceability can be effectively enabled in the process of managing AI tasks and models in the proposed architecture. It should be noted that Figure 7 The AIMU and AIMP in can be combined to host and support AIA4LI agents.

[0177] AI Mission :AI tasks can be installed on an AI model producer (AIMP) or an AI model user (AIMU) as part of an AI agent at an AIMP or AIMU. AIMP has an AI agent for learning (AIA4L), which is used to: 1) train and generate AI models; and 2) generate AI traceability records according to installed traceability instructions. In contrast, AIMU has an AI agent for reasoning (AIA4I), which is used to: 1) infer knowledge based on the installed AI model and input data for reasoning; 2) generate AI traceability records according to installed traceability instructions. AIMU and AIMP can be co-located within the same physical node, such as a UE or edge server. To support AI traceability and AI management, each AI agent (or AI task executor) can support a new application programming interface (API).

[0178] As an example, the following three APIs that can be implemented as a single API can be used to communicate with the AI ​​task. When implemented as a single API, the request can indicate which of the following API functions are triggered.

[0179] TRACE-INSTRUCTION-CONFIG-API: This API allows other entities (such as the AI ​​Manager (AIM) or the AI ​​Traceability Manager (AITM)) to configure one or more trace instructions to the AI ​​agent. When the AI ​​agent runs the corresponding AI task, the AI ​​agent will generate AI trace records according to the trace instructions.

[0180] TRACE-RECORD-MGMT-API: This API allows other entities to retrieve / delete generated AI trace records, or allows the AI ​​agent to actively push generated AI trace records to other entities (e.g., DSS or AIM) via this interface.

[0181] MODEL-MGMT-API: AI tasks for reasoning about knowledge (i.e., AIA4I) can have this additional API that allows 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 AI ​​model and the associated traceback instructions, especially when the TRACE-INSTRUCTION-CONFIG-API is not available.

[0182] For example, the following API information (referred to as API-Info) can be used to describe each API: the endpoint of the API used for communication (e.g., URI, FQDN, IP address, etc.); and the transport information of the API, such as the protocol type (e.g., REST / HTTP, CoAP, topic-based, PubSub, RPC, WebSocket, etc.), security-related information (e.g., security credentials, certificates, public keys, etc.), version, etc.

[0183] The API information for each API may be shared with and / or configured by another entity (eg, an AI manager, an AI traceability manager, an AI repository, etc.).

[0184] AI Models :The AI ​​model can be generated by an AIMP, which has an AI agent that runs AI tasks to train the AI ​​model (e.g., a set of parameters / weights of a DNN) according to the corresponding AI algorithm (e.g., backpropagation of a DNN). An independent AIMP can generate an AI model on its own. Multiple AIMPs can also collaborate to train an AI model, and trace instructions can be defined and created by the AIM for this situation. For example, in a FL setting, the FL server and the FL client work together to generate a fused global AI model. The AIMU can use the generated AI model to infer knowledge based on real data inputs, and multiple AIMUs can use the same AI model with different data inputs. The content of the AI ​​model can contain its own trace instructions and requirements (Trace-Instructions), and each AI task can generate an AI trace record accordingly based on which AI task is using this AI model. The state of the AI ​​model at the AIMP can be, for example: 1) fully trained-the AI ​​model has been fully trained and verified, and can be deployed to infer knowledge; 2) partially trained-the AIMP has not yet completed the training or verification of the model, and it cannot be deployed or used to infer knowledge.

[0185] AI Tracing Instruction (ATI) :AI traceability instructions describe how AI processes and result information from AI tasks (e.g., model weights, inference results, etc.) should be recorded to achieve traceability and under what conditions. AI traceability instructions and traceability instructions are used interchangeably in this disclosure.

[0186] AI Manager (AIM):AIM maintains a list of AI tasks. The main goal of AIM is to achieve AI traceability while managing AI tasks and models. Specifically, AIM is responsible for requesting and receiving traceability instructions from the AI ​​Traceability Manager (AITM), discovering AI Model Producers (AIMPs) from AIR, installing AI tasks to AIMPs, discovering and downloading AI models from AIR, discovering AI Model Users (AIMUs) from the AI ​​Repository (AIR), and installing AI tasks and AI models to AIMUs.

[0187] As an example, first, the AIM requests or receives a traceback instruction from the AI ​​traceback manager (AITM) for one or more AI tasks. The AITM can also actively retrieve AI tasks from the AIM, and then configure appropriate traceback instructions for each task. The traceback instruction can be applied to one or more AI tasks. Therefore, each traceback instruction contains a list of AI-Task-IDs, which indicates the AI ​​tasks to which the traceback instruction can be applied. An AI task can apply or enforce multiple traceback instructions.

[0188] AIM then determines to install the selected AI task to the AIMP. AIM discovers the AIMP for the selected AI task from AIR. AIM generates an AI task package, which includes the AI ​​task itself (i.e., software code with any necessary configuration files) and the applicable traceback instructions received from AITM. AIM sends the AI ​​task package to AIMP, which installs the AI ​​task package locally to its AI agent. Afterwards, AIM and AITM can reconfigure new traceback instructions to the AI ​​task via their TRACE-CONFIG-API.

[0189] Similar to installing an AI task to AIMP, AIM can install another AI task to AIMU and embed traceback instructions into the AI ​​task package to be sent to AIMU. AIM can discover AIMU from AIR. The AI ​​task package sent to AIMU can contain one or more AI models, which AIM can discover and download from AIR. If the AI ​​task package does not contain any AI models, AIMU can discover and download the AI ​​model from AIR. Alternatively, AIM or AIR can configure the AI ​​model to the AI ​​task installed at AIMU via its MODEL-MGMT-API.

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

[0191] The AITM may discover the AI ​​task from the AIM and determine the traceback instructions applicable to the AI ​​task according to the pre-assigned policy. Alternatively, the AIM may request and retrieve the traceback instructions for the AI ​​task from the AITM.

[0192] The AITM can update and remove any configured traceability policies of the AI ​​tasks installed at the AIMP via its TRACE-MGMT-API.

[0193] The AITM can update and remove any configured traceability policies of the AI ​​tasks installed at the AIMU via its TRACE-MGMT-API.

[0194] AITM can query, retrieve, summarize and even modify AI traceability records stored in DSS.

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

[0196] AIMP can register itself and / or its models with AIR, indicating: 1) whether it can be used as an AIMP and can host AI tasks to train AI models; and / or 2) whether it has any trained AI models to register with AIR. During such registration with AIR, AIMP can also indicate its traceability, which can be described as the amount of available computing / storage / communication resources that AIMP can allocate for tracing AI tasks at AIMP.

[0197] An AIMU may register itself and / or its models with AIR, thereby indicating: 1) whether it can be used as an AIMU and can host AI tasks to reason about knowledge using AI models; and / or 2) whether it has any AI models installed for knowledge reasoning. During such registration with AIR, an AIMU may also indicate its traceability, which may be described as the amount of available computation / storage / communication resources that the AIMU can allocate for tracing AI tasks at the AIMU.

[0198] AIMU can proactively discover and download AI models from AIR for AI tasks (i.e., AI agents) installed at AIMU. During this process, AIR can configure new tracing instructions for AI tasks at AIMU or update existing tracing instructions.

[0199] AIR can also store the list of registered AI models, the list of registered AIMPs, and the list of registered AIMUs to DSS. In this case, AIM can directly discover AI models, AIMPs, and / or AIMUs from DSS; AIMU can also directly discover and download AI models from DSS.

[0200] AI Model Producer (AIMP) : AIMP can host AI tasks to train and generate AI models while supporting AI traceability, which is handled by the AI ​​Agent for Learning (AIA4L). To achieve this goal, AIMP can interact with other entities as follows.

[0201] Before installing the AI ​​task, AIMP can register its traceability (Trace-Capability) to AIR by itself so that AIM (and / or AITM) can find AIMP and AIM can assign it an appropriate AI task that matches its Trace-Capability (and / or AITM can assign it trace instructions).

[0202] After installing the AI ​​task, AIMP runs the AI ​​task to train the AI ​​model as specified by the AI ​​task. AIMP can generate AI traceability records while training the model according to the traceability instructions associated with the AI ​​task. AIMP can store the generated AI traceability records to DSS. AIMP can also manage (e.g., query, retrieve, summarize, modify, remove) those AI traceability records stored on DSS.

[0203] After training the AI ​​model, AIMP can register the AI ​​model to AIR, wait for AIMU to download the AI ​​model, and / or actively push the AI ​​model to AIMU. How to process the generated AI model can be described as part of the AI ​​task.

[0204] While or after the AIMP runs an AI task to train an AI model, the AITM and / or AIM may update the traceability instructions associated with the AI ​​task.

[0205] The AIMP may have an embedded AITM that manages traceability of the AI ​​agent at the AIMP and / or other AI agents that use the AI ​​models provided by the AIMP.

[0206] AI Model User (AIMU): AIMU hosts AI tasks that use AI models to reason about knowledge. AIMU can support AI traceability during this knowledge reasoning phase. AI traceability functionality during knowledge reasoning is handled by the AI ​​Agent for Reasoning (AIA4I). To achieve this goal, AIMU can interact with other entities as follows.

[0207] Before installing an AI task, the AIMU can register its trace-capability with the AIR so that the AIM (and / or AITM) can find the AIMU and the AIM can assign it an appropriate AI task that matches the AIMU Trace-Capability (and / or the AITM can assign it trace instructions).

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

[0209] The AIMU can then run the AI ​​task to infer the knowledge. The AIMU can generate AI traceability records during this inference phase according to the traceability instructions associated with the AI ​​task. The AIMU can store the generated AI traceability records to the DSS. The AIMU can also manage (e.g., query, retrieve, summarize, modify, remove) those AI traceability records stored on the DSS.

[0210] While or after the AIMU runs an AI task and uses the associated AI model to infer knowledge, the AITM and / or AIM may update traceability instructions associated with the AI ​​task.

[0211] In addition, AIMU can discover, download or receive AI models directly from AIMP.

[0212] Distributed Storage System (DSS) :DSS stores AI traceability records sent from AIMP and / or AIMU. DSS can also store repository information of AIR (e.g., a list of registered AI models, a list of registered AIMPs, a list of registered AIMUs). In addition, DSS also supports AITM to manage AI traceability records stored on DSS. 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.

[0213] According to the present principles, the address and / or identifier of a logical entity (e.g., an AI host, an AI agent, an AI task, AIMU, AIMP, AIM, AITM, AIR, DSS, API, etc.) or an information object (e.g., an AI model, a traceability record, a traceability instruction, an AIH record, an AI model record, a piece of training data, a piece of input data, a piece of inference knowledge, a transaction on a ledger, a block on a ledger, a smart contract on a ledger, etc.) may also be referred to as an endpoint, which may be a uniform resource identifier (URI), a fully qualified domain name (FQDN), an IP address, a port number and / or a combination thereof, etc.

[0214] based on Figure 7 With reference to the exemplary architecture of FIG. 1 , the following features and corresponding processes according to the principles of the present invention will now be described: traceability-aware AI host registration, traceability-aware AI task deployment, traceability-aware AI model registration, traceability-aware AI model discovery and registration.

[0215] As a first example, Figure 7 The exemplary architecture in can be deployed in future wireless systems, such as Figure 8 As shown. In this first example, AIM and AITM are deployed together (or separately) as a single network function in the core or cloud network, AIR-1 is co-located with edge server-1, and AIR-2 is co-located with edge server-2, and AIR-1 and AIR-2 can talk directly to each other to exchange any information maintained in the two AIRs (e.g., AIH records). In addition, each AIH is co-located with the UE, the AIH under base station-1 is registered with AIR-1, and the AIH under base station-2 is registered with AIR-2. AIH-1 and AIH-2 can interact directly with each other and / or with the help of AIR-1 / AIM / AITM, for example, to exchange AI models and / or reasoning knowledge. AIH-3 and AIH-4 can interact directly with each other and / or with the help of AIR-2 / AIM / AITM, for example, to exchange AI models and / or reasoning knowledge. AIM can talk directly to each AIH (e.g., install AI tasks to each AIH) without going through any AIR. AITM can talk directly to each AIH (e.g., configure traceback instructions to each AIH) without going through any AIR.

[0216] As a second example, Figure 7 The exemplary architecture in can be deployed in future wireless systems, such as Fig. 9As shown. In this second example, AIR and AITM are deployed together (or separately) as a single network function in the core or cloud network, AIM-1 is co-located with edge server-1, and AIM-2 is co-located with edge server-2, and AIM-1 and AIM-2 can directly talk to each other to exchange any information maintained in the two AIMs (e.g., AI tasks). Each AIH is co-located with the 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 interact directly with each other and / or with the help of AIM-1, for example, to exchange AI models and / or reasoning knowledge. AIH-3 and AIH-4 can interact directly with each other and / or with the help of AIM-2, for example, to exchange AI models and / or reasoning knowledge. Each AIH can talk directly to AIR (e.g., registering the AIH to AIR) without going through any AIM. AITM can talk directly to each AIH (e.g., configuring traceback instructions to each AIH) without going through any AIM.

[0217] Traceability Awareness AI Host Registration

[0218] An AI host (AIH) can be an AIMP for training AI models or an AIMU for using AI models to reason about knowledge. AIH can register itself with AIR so that AIM can discover it before AIM can install AI tasks on AIH. During this AIH registration, AIH indicates its AI capabilities and traceability capabilities to AIR. AIR can maintain a list of registered AIH records, which are exposed to AIM and / or other entities. It should be noted that AIH can pre-configure the address of AIR or pre-configure entities from which AIH can discover AIR.

[0219] Fig.10 An embodiment of a traceability-aware AIH registration method is shown.

[0220] In step S1002, AIH 1001 sends a message to AIR 1003 to register AIH 1001 with AIR 1003, and AIR 1003 receives the message. The message may include one or more of the following parameters:

[0221] AIH-ID: An identifier or address of the AIH. If the AIH is a blockchain node or user, its blockchain address (e.g., a unique identifier generated from its public key) can be used as the AIH-ID.

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

[0223] AI-Capability: The AIH can allocate capabilities and affordable resources for hosting AI tasks. For example, this parameter may include one or more of the following: 1) the computing resource budget for running AI tasks, 2) the storage resource budget for running AI tasks, and 3) training data attributes, such as the number of data samples and the number of features in the data samples. If the AIH is already hosting an AI task, AI-Capability may indicate additional information, including but not limited to: 1) the unique identifier of the hosted AI task (AI-Task-ID), 2) Fig.12 The type of managed AI task (AI-Task-Type) defined in step S1202, and 3) API-Info of MODEL-MGMT-API.

[0224] Trace-Capability: AIH can allocate capabilities and available resources for tracing AI tasks. This parameter can indicate, but is not limited to: 1) the computing resource budget for tracing AI tasks, 2) the storage resource budget for tracing AI tasks, 3) whether AIH has an interface with DSS or other external entities for storing AI tracing records, 4) the communication capabilities (such as bandwidth) that AIH can use to send AI tracing records to DSS or other entities, 5) the communication mode (such as push or pull) that supports other entities to obtain AI tracing records, 6) if AIH is AIMP, whether AIH is willing to trace "training data" or if AIH is AIMU, whether AIH is willing to trace "input data for reasoning". If the AIH has hosted an AI task, Trace-Capability may indicate additional information about the traceability of the hosted AI task, such as one or more of the following: 1) API-Info of TRACE-INSTRUCTION-CONFIG-API, 2) API-Info of TRACE-RECORD-MGMT-API, 3) which part of the AI ​​pipeline of the AI ​​task can be traced, 4) the traceability instructions that have been configured using the hosted AI task, and 5) statistical information about the AI ​​traceability records generated by the hosted AI task within a certain time period (for example, the frequency with which the AI ​​task generates AI traceability records within the time period, the number of AI traceability records generated within the time period, the location where the generated AI traceability records have been stored, etc.).

[0225] Training-Data-Info: If 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 from which the training data can be retrieved, etc.).

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

[0227] 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 different AIR, it already knows the AIM-ID and can include the AIM-ID in the current registration request. In another example, the AIH can pre-install or pre-allocate the AIM-ID.

[0228] In step S1004: If the registration request from step 1 is approved (e.g., after AIR 1003 verifies, authenticates, and / or authorizes the registration request received from step S1002), AIR may generate a new AIH-ID for the AIH. AIR may assign an AIM and an AITM to the AIH. If the AIH is an AIMP, AIR may recommend an AIMU to the AIH from its local repository. If the AIH is an AIMU, AIR may recommend an AIMP to the AIH from its local repository. AIR then creates an AIH record for the AIH and stores the AIH record, for example, in its local repository. AIR may publish the AIH record to a DSS or an AIM. The AIH record may, for example, include one or more of the following:

[0229] - AIH-ID: AIH-ID received in step S1002 or generated in step S1004.

[0230] -AIH-Type: received in step S1002.

[0231] -AI-Capability: received in step S1002.

[0232] -Trace-Capability: received in step S1002.

[0233] - AIM-ID: The identifier and / or address of the AIM of the AIH received in step S1002 or allocated by the AIR.

[0234] -AITM-ID: The identifier and / or address of the AITM assigned by AIR to the AIH.

[0235] -AIMP-ID: If the AIH is an AIMU, the identifier and / or address of the AIMP recommended by the AIR to the AIH.

[0236] -AIMU-ID: If the AIH is an AIMP, the identifier and / or address of the AIMU recommended by the AIR to the AIH.

[0237] AIR can store the created AIH record to DSS (e.g., a distributed ledger). To do this, AIR creates a transaction Txt-Example, which can contain the entire created AIH record or a portion thereof. AIR sends the transaction to DSS, which adds the transaction to the ledger structure (e.g., blockchain, block directed acyclic graph, blockless directed acyclic graph) after reaching a consensus agreement. Once the transaction has been added to the ledger structure, if the ledger uses a block-based structure, it will have a transaction sequence number (i.e., Transaction-Seq-Num) and / or an associated block sequence number (i.e., Block-Seq-Num). Transaction-Seq-Num and Block-Seq-Num uniquely identify the transaction Txt-Example stored on the ledger. DSS can return Transaction-Seq-Num and / or Block-Seq-Num to AIR. Any entity (including AIR) can retrieve the transaction Txt-Example from the ledger using Transaction-Seq-Num and Block-Seq-Num. AIR may include the Transaction-Seq-Num and Block-Seq-Num in the response message to be sent to the AIH.

[0238] In step S1006, AIR sends a response to AIH. For example, the response may include one or more of the following:

[0239] -AIH-ID: new AIH-ID, if one is generated in step S1004.

[0240] - AIM-ID: from the AIH record generated in step S1004.

[0241] - AITM-ID: from the AIH record generated in step S1004.

[0242] - AIMP-ID: from the AIH record generated in step S1004.

[0243] - AIMU-ID: from the AIH record generated in step S1004.

[0244] - AIH-Record-ID: the identifier and / or address of the AIH record created in step S1004.

[0245] It should be noted that if the AIH has a modified AI-Capability and / or Trace-Capability, it can use Fig.10 The methods in AIR are used to update AIR with its new AI-Capability and / or Trace-Capability. Similarly, AIH can use Fig.10 The method in will register itself with AIM, just replace AIR with AIM. In step S1002, AIH can also request AIR to remove itself from AIR's local repository by adding a deregistration indicator.

[0246] Fig.11 An embodiment of traceability-aware AI host registration via DSS according to the present principles is shown. In this case, AIH stores its registration information to DSS (e.g., distributed ledger) and passes the transaction and block sequence number of DSS to AIR upon registration. Fig.10 This approach can provide better invariance and reliability than the method shown in .

[0247] In step S1102, AIH 1101 generates a transaction and may send the transaction to DSS 1103. The transaction may include, for example, one or more of the following:

[0248] -AIH-ID: with Fig.10 The same as step S1002 in .

[0249] -AIH-Type: Fig.10 The same as step S1002 in .

[0250] -AI-Capability: Fig.10 The same as step S1002 in .

[0251] -Trace-Capability: Fig.10 The same as step S1002 in .

[0252] -Training-Data-Info: with Fig.10 The same as step S1002 in .

[0253] -Input-Data-Info: with Fig.10 The same as step S1002 in .

[0254] -Smart-Contract: Information indicating that the AIH is willing and signs a contract to host the AI ​​task. The AIH can include multiple smart contracts in a transaction. Each smart contract can include one or more of the following:

[0255] Desired-AI-Task: Indicates the type of desired AI task. Potential types of AI tasks will be described in the section titled Traceability-Aware AI Task Deployment.

[0256] Requested-Payment: Indicates the payment that the AIH wishes to collect if the AIH hosts and runs the Required AI Task. The AIH may request additional or different payments if the Required AI Task is used to train an AI model and if the AIH provides training data.

[0257] AI-Task-Address: Indicates the address of the AI ​​task from which the AIH can download the AI ​​task (e.g., software code). This is an input parameter of this smart contract. For example, after publishing this smart contract 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".

[0258] AI-Model-Contract-Address: Indicates the address of another smart contract used to use or deploy the AI ​​model. This is an input parameter. When this smart contract is triggered by an AIM (or other entity), the AIM can provide "AI-Model-Contract-Address" as an input parameter of the smart contract of this AIH. Therefore, the AIH can execute the smart contract to run the AI ​​task to generate the AI ​​model. In this case, the AI ​​model can be automatically sent to another smart contract as an input parameter, as indicated by "AI-Model-Contract-Address".

[0259] In the case where DSS 1103 supports distributed ledger functionality (such as blockchain), the transaction will be added to the distributed ledger after a certain consensus protocol or mechanism. After adding the transaction to the distributed ledger, DSS 1103 sends a response to AIH in step S1104. The response may include, for example:

[0260] -Transaction-Seq-Num: The sequence number of the transaction added to the distributed ledger.

[0261] -Block-Seq-Num: The sequence number of the block in which the transaction is included.

[0262] It should be noted that DSS may not send a response to AIH, but can still obtain Transaction-Seq-Num and Block-Seq-Num by observing the progress of the distributed ledger.

[0263] In step S1106, AIH sends a request to register itself to AIR 1105. For example, the request may include the following content:

[0264] - AIH-ID: as in step S1102.

[0265] - AIH-Type: as in step S1102.

[0266] -Transaction-Seq-Num: as in step S1104.

[0267] - Block-Seq-Num: as in step S1104.

[0268] In step S1108, AIR 1105 may send a request to DSS 1103 to retrieve additional information about AIH 1101 (eg, other parameters included in step S1102, such as AI-Capability and Trace-Capability). The request may include Transaction-Seq-Num and Block-Seq-Num and the names of other parameters to be retrieved.

[0269] The DSS 1103 uses the identifiers (eg, Transaction-Seq-Num and Block-Seq-Num) to find the corresponding transaction created in step S1104 and extract the requested information from the transaction. In step S1110 , the DSS 1103 sends a response including the requested information to the AIR 1105 .

[0270] In step S1112, similar to Fig.10 In step S1004, AIR 1105 creates an AIH record for AIH 1101. The AIH record can be compared to the reference Fig.10 Descriptive records are simpler and can include:

[0271] - AIH-ID: as in step S1106.

[0272] -Transaction-Seq-Num: as in step S1106.

[0273] - Block-Seq-Num: as in step S1106.

[0274] -AIM-ID: The identifier and / or address of the AIM assigned by AIR to the AIH.

[0275] -AITM-ID: The identifier and / or address of the AITM assigned by AIR to the AIH.

[0276] -AIMP-ID: If the AIH is an AIMU, the identifier and / or address of the AIMP recommended by the AIR to the AIH. To this end, the AIR may contact the DSS to retrieve detailed information about other AIMPs.

[0277] - AIMU-ID: If the AIH is an AIMP, the identifier and / or address of the AIMU recommended by the AIR to the AIH. To this end, the AIR may contact the DSS to retrieve detailed information about other AIMUs.

[0278] In step S1114, AIR 1105 sends a response to AIH 1101. The response may include:

[0279] -AIM-ID: As in step S1112.

[0280] -AITM-ID: as in step S1112.

[0281] - AIMP-ID: as in step S1112.

[0282] - AIMU-ID: as in step S1112.

[0283] - AIH-Record-ID: the identifier and / or address of the AIH record created in step S1112.

[0284] In step S1116, AIM 1107 (or another AIH) sends a request to AIR 1105 to discover one or more target AIHs 1101. The request may include a discovery filter (eg, a wildcard for the AIH-Type and / or AIH-ID of the target AIH).

[0285] AIR 1105 uses the discovery filter to find the AIH record to find the target AIH. For each discovered target AIH, AIR can include the following information in the response it sends to AIM 1107 (or other AIH) in step S1118:

[0286] -Transaction-Seq-Num: The sequence number of the transaction containing detailed information about the target AIH.

[0287] - Block-Seq-Num: The sequence number of the block containing the transaction concerning the target AIH.

[0288] - AIH-ID: Identifier or address of the target AIH.

[0289] -AIH-Type: The type of the target AIH.

[0290] As with other embodiments, Transaction-Seq-Num and Block-Seq-Num are examples of information that may constitute a ledger identifier.

[0291] In step S1120 (similar to step S1108 ), the AIM 1107 (or another AIH) sends a request to the DSS 1103 to retrieve additional information about each discovered target AIH.

[0292] In step S1122 (similar to step S1110 ), after retrieving the requested information, DSS 1103 sends a response including additional information about the discovered target AIH to AIM 1107 (or another AIH).

[0293] Traceability-aware AI task deployment

[0294] Four embodiments of traceability-aware AI task deployment will be described. Fig.12 Shows the traceability awareness AI task deployment initiated by AIH. Fig.13 Showing the traceability-aware AI task deployment initiated by AIM. Fig.14 Showing the traceability-aware FL task deployment initiated by AIH. Fig.15 Showing the traceability-aware FL task deployment initiated by AIM.

[0295] AIH initiated traceability awareness AI task deployment

[0296] The AI ​​host (AIH) (AIMP or AIMU) actively requests an AI task from the AIM. The AIH first presents the requested AI task, its AI capabilities, and its traceability capabilities to the AIM. The AIM then approves and determines the appropriate AI task based on the AI ​​capabilities of the AIH. Based on the traceability capabilities of the AIH, the AIM also obtains traceability instructions for the AI ​​task from the AITM. During the deployment of the AI ​​task to the AIH, these traceability instructions are sent to the AIH simultaneously. The AIM creates an AI task record for each AI task deployed to the AIH. The AIM can store the AI ​​task records locally and / or to other entities (e.g., DSS). Assumptions: 1) The AIH has pre-allocated the AIM and knows the address of the AIM; and 2) The AIM has pre-allocated the AITM and knows the address of the AITM. It should be noted that the AIM and the AITM can be implemented together as a physical or logical node.

[0297] Fig.12 A method of traceability-aware AI task deployment initiated by an AIH according to an embodiment is shown.

[0298] In step S1202, AIH 1201 (eg, AI model user or AI model producer) sends a request message to AIM 1203 to request deployment of the AI ​​task to AIH 1201. The message may include one or more of the following:

[0299] -AI-Task-ID: The unique identifier or address of the AI ​​task to be deployed. If this parameter is included in the message, the other parameters can be omitted.

[0300] -AIH-ID: Identifier or address of AIH 1101.

[0301] -AI-Task-Type: The type of AI task requested by AIH 1101. AI-Task-Type may indicate whether the requested task is used to train a model, infer knowledge, or both. AI-Task-Type may also indicate whether the requested AI task is a DL task, FL task, RL task, or other type. AI-Task-Type may also indicate the purpose of the requested AI task (e.g., regression, classification, clustering, etc.). AI-Task-Type may also indicate the application category of the requested AI task (e.g., natural language processing, text processing, image processing, video processing, etc.).

[0302] - AI-Task-Size-Threshold: AIH 1101 requires that the size of the AI ​​task it requests should be less than AI-Task-Size-Threshold. The size of an AI task is usually determined by the size of the software code and the size of any associated data.

[0303] -AI-Capability: AIH 1101 can allocate capabilities and affordable resources for hosting AI tasks. This parameter can indicate, for example, but not limited to: 1) the computing resource budget for running AI tasks, 2) the storage resource budget for running AI tasks, and 3) training data attributes, such as the number of data samples and the number of features in the data samples.

[0304] -Trace-Capability: AIH 1101 can allocate capabilities and available resources for tracing AI tasks. This parameter can indicate, for example, but not limited to: 1) the computing resource budget for tracing AI tasks, 2) the storage resource budget for tracing AI tasks, 3) whether AIH 1101 has an interface with DSS or other external entities for storing AI tracing records, 4) the communication capabilities (such as bandwidth) that AIH 1101 can use to send AI tracing records to DSS or other entities, 5) the communication mode (such as push or pull) that supports other entities to obtain AI tracing records, 6) if AIH 1101 is AIMP, whether AIH 1101 is willing to trace "training data" or if AIH 1101 is AIMU, whether AIH 1101 is willing to trace "input data for reasoning".

[0305] - AITM-ID: Identifier or address of the AITM 1205. This parameter is optional and can be used by the AIH 1101 to specify a specific AITM if known.

[0306] It should be noted that the AI ​​task to be deployed can be uniquely identified by AI-Task-ID. Alternatively, AIM 1203 can use a combination of multiple other parameters (e.g., AI-Task-Type and AI-Task-Size-Threshold) in step S1202 to identify one or more AI tasks that it can select for AIH.

[0307] In step S1204, AIM 1203 selects (i.e., determines) an AI task for AIH 1101 based on the parameters (e.g., AI-Task-Type and AI-Capability) received in step S1202. AIM 1203 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 at AIM 1203. It should be noted that each AI task stored at AIM 1203 may have an associated AITM 1205 through which AIM 1203 may request corresponding traceability instructions.

[0308] In step S1206, AIM 1203 sends a message to AITM 1205 to request trace instructions for the selected AI task. The message may include AIH-ID, Trace-Capability, AI-Task-Type, all as in step S1202.

[0309] The AITM 1205 receives the message and determines the trace instructions of the AIH 1201 to trace the requested AI task. The determination may be based on the parameters received in the message in step S1206, such as AIH-ID, Trace-Capability, and AI-Task-Type. The AITM 1205 sends a response message to the AIM 1203. The response message contains the determined trace instructions (i.e., Trace-Instructions) of the AIH 1201. The Trace-Instructions may contain one or more trace instructions. Each trace instruction (TI(i)) may, for example, include the following parameters:

[0310] - Trace-Instruction-ID: A (statistically or possibly) unique identifier of the TI(i). As an example, a hash value of the TI(i) content with additional information may be used as a unique identifier.

[0311] -Trace-Scope: The tracing scope of the selected AI task. The tracing scope can be one or more of the following: 1) for all training rounds or for selected training rounds, 2) for all knowledge reasoning iterations or selected knowledge reasoning iterations, 3) the training data used in the training rounds, 4) the correlation between the training data in the training rounds and the corresponding model updates (e.g., the gradient of the DNN model), 5) some or all model updates generated in the training rounds, 6) the trend of the model accuracy during training, 7) the model convergence speed during training, 8) the training model used for testing and verification, 9) the failure of the testing and verification phase, 10) the final model trained, 11) about the training phase The AIMU may include the following: 1) other statistics about the AIMU (e.g., the distribution of training data used, the weight distribution of the final model if it is a DNN model, etc.), 2) the model used for knowledge reasoning, 3) the input data used for reasoning, 4) the knowledge reasoned, 5) the correlation between the input data for reasoning and the knowledge reasoned, 6) the difference between the reasoned knowledge and the action taken by the AIMU, which may or may not be based on the reasoned knowledge, and 7) other statistics about knowledge reasoning (e.g., the distribution of input data used for reasoning, the distribution of the reasoned knowledge, time / location information about when / where the knowledge reasoning is triggered, etc.).

[0312] -Trace-Record-Format: defines the format (e.g., Concise Binary Object Representation (CBOR), JavaScript Object Notation (JSON)) and metadata used for the generated AI trace records. The metadata of the trace record (TR(j)) can include, but is not limited to, the following parameters:

[0313] Trace-Record-Creator: Identifier of the AIH that created TR(j).

[0314] Trace-Record-Creation-Time: The time when TR(j) was created.

[0315] Trace-Record-Creation-Location: The location of the AIH when TR(j) was created. If the AIH is not stationary, this parameter can be used to capture the instantaneous position.

[0316] Trace-Record-Identifier: An identifier of TR(j), such as an address or Uniform Resource Identifier (URI), by which TR(j) can be accessed. This parameter may be empty if TR(j) has never been stored locally at the AIH that created TR(j).

[0317] Trace-Record-Content-Type: The type of content contained in TR(j) can be one of the following types or a combination of them: training data, AI model update, final AI model, input data for reasoning, reasoning knowledge, model training statistics, knowledge reasoning statistics, etc.

[0318] -Trace-Record-Creation-Condition: describes the conditions under which a new trace record will be created by the AIH. The conditions can be based on one or more of the following parameters, but are not limited to:

[0319] Trace-Record-Creation-Time-Windows: Time windows within which AIH creates trace records according to the following parameters.

[0320] Trace-Record-Creation-Frequency: The frequency of periodically creating trace records.

[0321] AI-Model-Training-Accuracy-Range: When the instantaneous accuracy of the AI ​​model in training (i.e., calculated based on the loss function) is within the range defined by AI-Model-Training-Accuracy-Range, a new traceability record is created.

[0322] AI-Model-Test-Accuracy-Range: When the test accuracy of the AI ​​model under the test data is within the range defined by AI-Model-Test-Accuracy-Range, a new traceability record is created.

[0323] AI-Model-Test-Failure-Threshold: When the number of failures occurring in the test phase exceeds the threshold defined by AI-Model-Test-Failure-Threshold, a new traceback record is generated.

[0324] AI-Model-Attack-Detection: When AIH detects a backdoor or other data poisoning attack based on the attack detection algorithm, a new traceability record is generated.

[0325] -Trace-Record-Forwarding-Address: Indicates the location and / or address for storing the traceback record to be created. This parameter can be empty or simply indicate "LOCAL". Therefore, the AIH using this traceback instruction will simply store any traceback records created locally. This parameter may include an address pointing to an external entity (e.g., DSS) to which the AIH using this traceback instruction will forward any traceback records created.

[0326] -Trace-Record-Forwarding-Condition: It describes the conditions under which the AIH should forward the created trace records to an external entity, as indicated by the Trace-Record-Storage-Address. These conditions can be based on one or more of the following:

[0327] Trace-Record-Maximum-Buffer-Time: Indicates the maximum time that a trace record can be buffered locally at the AIH before the AIH forwards the trace record to an external entity.

[0328] Trace-Record-Forwarding-Frequency: Indicates how fast the AIH should forward the generated traceback records. For example, whenever M new traceback records are created, the AIH can forward M traceback records together to the external entity. M is contained in Trace-Record-Forwarding-Frequency.

[0329] -Trace-Record-Forwarding-Metadata: indicates the metadata required by the external entity (e.g., DSS) when the AIH forwards the traceability record to it. For example, when the external entity is a blockchain or distributed ledger system, the Trace-Record-Forwarding-Metadata may indicate the corresponding blockchain transaction format. The AIH may encapsulate the M traceability records in one or more blockchain transactions according to the transaction format and send these blockchain transactions to the external blockchain system.

[0330] -Trace-Record-Forwarding-Credentials: Indicates the credentials that the AIH should use in order to forward the trace record to the external entity, as indicated by the Trace-Record-Storage-Address. The credentials can be a token or certificate to access the external entity. When the AIH forwards the trace record to the external entity, it presents the credentials to the external entity, which can authenticate and authorize the AIH based on the credentials. If the external entity is a blockchain or distributed ledger system, the Trace-Record-Forwarding-Credentials can contain the blockchain account assigned to the AIH by the AITM (e.g., obtained from the public key of the AIH and / or AITM).

[0331] The Trace-Scope and Trace-Record-Creation-Condition together determine when an AI trace record should be generated, which will follow the format defined by Trace-Record-Format.

[0332] It should be noted that the response in step S1208 may include only a list of traceback instruction identifiers, rather than the full content of each traceback instruction, for example if the full content is too large. Therefore, the AIM may use a separate step to present one or more traceback instruction identifiers to the AITM to retrieve the full content of the corresponding traceback instruction.

[0333] It should also be noted that if the AIM 1203 can determine the traceback instructions for the AIH 1201 , then steps S1206 and S1208 may be omitted, for example, by utilizing previously pre-allocated or buffered traceback instructions received from the AITM 1205 .

[0334] In step S1210, AIM 1203 sends a response to AIH 1201 to install / deploy the selected AI task to AIH. The response may include:

[0335] - AI-Task-Content: The software code of the selected AI task. If this address is included, AI-Task-Content-Address (see below) may not be required; if this address is not included, AI-Task-Content-Address may be required instead.

[0336] - AI-Task-Content-Address: The address from which the software code for the selected AI task can be downloaded. If this address is included, the AIH 1201 can perform additional actions to download the software code for the AI ​​task, and then the AI ​​task can be physically installed.

[0337] - AI-Task-ID: Unique identifier of the selected AI task.

[0338] - Trace-Instructions: as received in the response in step S1208 (or obtained elsewhere).

[0339] -AIR-ID: Identifier of the AIR from which the AIH 1201 can discover updated AI models.

[0340] - AI-Model-ID: Identifier of an existing AI model that the AIM 1203 wants the AIH 1201 to retrieve and install with the AI ​​task. This identifier may not be required when the AI ​​task is used for learning. If the AI-Model-ID is included in the message, the AI-Model-Content may be omitted (see below).

[0341] -AI-Model-Content: The content of the AI ​​model. If the AI ​​task is for learning, this identifier may not be required. Even if the AI ​​task is for inferring knowledge, this parameter is optional because the AIM 1203 can use AIR-ID or AI-Model-ID to indicate to the discoverer that the AIH 1201 retrieves the AI ​​model from AIR. When AI-Model-Content is included in this message, 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.

[0342] If the task to be installed is an AI model training task, the message may also include:

[0343] - Training-Data-Source: The location (eg, URI, FQDN, etc.) where the AIH 1201 should retrieve or download the training data. If the AIH 1201 already has the training data (as it may have indicated during AIH registration), it does not need to download the training data; in this case, this is optional.

[0344] -Model-Handling: How the trained AI model should be handled. This can indicate different possibilities. As a first example, once the AIH completes the training process and generates the AI ​​model, the AIH should return the AI ​​model to the AIM. Alternatively, the AIH should notify the AIM of the availability of the AI ​​model, and the AIM can retrieve the AI ​​model from the AIH. As a second example, the AIH should register the trained AI model with the AIR. In this case, this parameter can also include the address of the AIR.

[0345] If the task to be installed is a knowledge reasoning task, the message may also include:

[0346] - Input-Data-Source: The location (e.g., a Uniform Resource Locator (URL)) from which the AIH can retrieve or download the input data and derive knowledge from the input data. If the AIH already has the input data (as it may have indicated during AIH registration), it does not need to download the input data; in this case, this is optional.

[0347] -Knowledge-Handling: How the inferred knowledge should be handled. This can indicate different possibilities. As a first example, once the AIH completes the reasoning process and generates knowledge, the AIH can return the knowledge to the AIM. Alternatively, the AIH can notify the AIM of the availability of the knowledge, and the AIM can retrieve the knowledge from the AIH. In addition, the AIH can send the knowledge directly to the 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.

[0348] The response in step S1210 may also request a notification sent from the AIH 1201 to the AIM 1203 after the AIH installs the AI ​​task in step S1212 (ie, in step S1214 ).

[0349] In step S1212, AIH 1201 installs the AI ​​task locally. AIH 1201 may also configure the received traceability instructions (i.e., Trace-Instructions) with the installed AI task so that the AI ​​task generates an AI traceability record according to the traceability instructions when it starts running. If the response contains AI-Model-Content, the AIH will install the corresponding AI-Model-Content together with the AI ​​task. If the message contains AIR-ID or AI-Model-ID, the AIH can discover or retrieve the AI ​​model from AIR and then install it together with the AI ​​task. The AIH can generate one or more addresses through which the installed AI tasks can be accessed, called AI-Task-Address. The AI-Task-Address may include:

[0350] - API-Info of TRACE-CONFIG-API of installed AI tasks.

[0351] - API-Info of the TRACE-MGMT-API for the installed AI tasks.

[0352] -API-Info of the MODEL-MGMT-API for the installed AI tasks.

[0353] In step S1214, AIH 1201 sends a notification to AIM 1203, indicating that the installation of the AI ​​task requested in step S1210 is successful (or failed). AIH 1201 may optionally store the response to DSS or AIR. The notification may include, for example:

[0354] - AIH-ID: as in step S1202.

[0355] -AI-Task-Address: generated in step S1212.

[0356] The AIH 1201 may also create a transaction containing the same notification and send the transaction to the DSS (e.g., distributed ledger). The transaction may also contain the AI-Task-ID, AI-Task-Content, and AI-Task-Type. After adding the transaction to the distributed ledger, the AIH will know the corresponding Transaction-Seq-Num and Block-Seq-Num for the added transaction. The AIH may then send the Transaction-Seq-Num and Block-Seq-Num to the AIM.

[0357] In step S1216, after having received the notification, AIM 1203 creates an AI task record for the AI ​​task installed at AIH 1201. AIM 1203 may publish the AI ​​task record to DSS or AIR. For example, AIM 1203 may create a transaction containing the AI ​​task record and send the transaction to DSS (e.g., distributed ledger). The AI ​​task record may include:

[0358] - AIH-ID: as in step S1214.

[0359] - AI-Task-ID: as in step S1210.

[0360] -AI-Task-Address: as in step S1214.

[0361] -AI-Task-Type: as in step S1202.

[0362] -Trace-Instructions: as in step S1210.

[0363] In step S1218, AIM 1203 sends a notification to AITM 1205. The notification may include the AI ​​task record generated in step S1216. AIM 1203 may send the same notification to AIR and / or DSS.

[0364] AIM initiated traceability awareness AI mission deployment

[0365] In order to deploy an AI task, AIM determines the AI ​​task and requests the traceability instruction of the AI ​​task from AITM. Based on the traceability instruction and the determined AI task, AIM discovers one or more appropriate AIHs (AIMP or AIMU) from AIR. It should be noted that AIR maintains the traceability capability of each registered AIH. In general, AIM compares the traceability capability of each registered AIH with the traceability instruction from AITM to determine the appropriate AIH that can satisfy the traceability instruction. Then, AIM selects an AIH from the list of appropriate AIHs, which is received from AIR, and AIM installs the determined AI task with the traceability instruction to the selected AIH.

[0366] Fig.13 A method of AIM-initiated traceability-aware AI task deployment according to an embodiment of the present principles is shown.

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

[0368] AIM 1303 may search one or more AIRs from a DSS (e.g., a distributed ledger), particularly if the AIH information has been published to the distributed ledger during the AIH registration process. The search may be performed before or after step S1302. In the case where the AIM searches for AIRs, steps S1304 to S1310 may be omitted.

[0369] In step S1304, AIM 1303 sends a request message to AITM 1305 to request traceability instructions for the AI ​​task. The message may include:

[0370] -AI-Task-Type: The type of AI task requested by the AIH. AI-Task-Type can indicate whether the requested task is used to train a model, infer knowledge, or both. AI-Task-Type can also indicate whether the requested AI task is a DL task, FL task, RL task, or other type. 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.).

[0371] - AI-Task-ID: Optional unique identifier of the selected AI task. This may be included in the request message, for example, if the AITM 1305 is able to understand it and use it to determine the corresponding traceback instructions.

[0372] AITM 1305 uses AI-Task-Type and / or AI-Task-ID to determine the traceability instructions for the AI ​​task. In step S1306, AITM 1305 sends a response to AIM, which includes traceability instructions indicating how information related to the AI ​​task should be traced and recorded and what type of information should be traced and recorded. This is similar to Fig.12 The traceback instruction described in step S1208.

[0373] In step S1308, AIM 1303 sends a message to AIR 1307 to discover one (or more) AIHs 1301 that will deploy the AI ​​task. The message may include:

[0374] - AI-Task-ID: the same as in step S1304.

[0375] -AI-Task-Type: Same as in step S1304.

[0376] -Trace-Instructions: Same as in step S1306.

[0377] -Other-Discovery-Criteria: Indicates other criteria for discovering AIHs, such as a reputation threshold for selecting AIHs.

[0378] Upon receiving the message, AIR 1307 searches (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, AIR 1307 sends a response to AIM 1303. The response may include AIH-List, i.e., a list of appropriate AIHs being discovered.

[0379] If the AIH information has been published to the DSS (eg, a distributed ledger) during the AIH registration process, the AIR 1307 may search the AIH information (eg, AI-Capability, Trace-Capability) from the DSS in order to find the appropriate AIH.

[0380] In step S1312, AIM 1303 may select one (or more) AIHs from the list of AIHs received from AIR 1307. AIM 1303 may simply use the traceback instructions received in step S1306 as the traceback instructions to be included in step S1314. Alternatively, AIM 1303 may modify the traceback instructions received in step S1306.

[0381] In step S1314, the AIM 1303 sends a message requesting the selected AIH 1301 to install the AI ​​task. The message may include:

[0382] - AI-Task-ID: the same as in step S1304.

[0383] -AI-Task-Type: Same as in step S1304.

[0384] -AI-Task-Content: Software code of the AI ​​task.

[0385] - AI-Task-ID: A (at least potentially) unique identifier for the AI ​​task.

[0386] -Trace-Instructions: from step S1312.

[0387] In the case where AI-Task-Type indicates an AI model training task, the message in step S1314 may include:

[0388] -Training-Data-Source: The location (e.g., Uniform Resource Locator (URL)) from which the AIH should retrieve or download training data.

[0389] -Model-Handling: How the trained AI model should be handled. This can indicate different possibilities. As a first example, once AIH 1301 completes the training process and generates the AI ​​model, it should return the AI ​​model to AIM 1303. Alternatively, AIH 1301 should notify AIM 1303 of the availability of the AI ​​model, and AIM 1303 can retrieve the AI ​​model from AIH 1301. As a second example, AIH 1301 can register the trained AI model to AIR 1307 by itself. In this case, Model-Handling can also include the address of AIR.

[0390] In the case where AI-Task-Type indicates a knowledge reasoning task, the message in step S1314 may also include:

[0391] - Input-Data-Source: The location (eg, Uniform Resource Locator (URL)) from which the AIH should retrieve or download input data and derive knowledge from the input data.

[0392] -Knowledge-Handling: How the inferred knowledge should be handled. This can indicate different possibilities. As a first example, once AIH 1301 completes the reasoning process and generates knowledge, it should return the knowledge to AIM 1303. Alternatively, AIH 1301 should notify AIM 1303 of the availability of the knowledge, and AIM 1303 can retrieve the knowledge from AIH 1301. In addition, AIH 1301 can send the knowledge directly to knowledge consumers (e.g., AIMP, for using the knowledge to train its own models). As a second example, AIH 1301 can maintain knowledge locally for itself.

[0393] In step S1316, AIH 1301 installs the AI ​​task with the traceability instruction. Fig.12 The same as step S1212 in.

[0394] In step S1318, AIH 1301 sends a response to AIM 1303 to indicate the success (or failure) of the installation. Fig.12 The same as step S1214 in.

[0395] AIH 1301 may also (or alternatively) create a transaction containing the response and send the transaction to the DSS (e.g., distributed ledger). The transaction may also contain AI-Task-ID, AI-Task-Content, and AI-Task-Type. After adding the transaction to the distributed ledger, AIH 1301 knows the corresponding ledger identifier. AIH 1301 may then send the ledger identifier to AIM 1305.

[0396] In step S1320, AIM 1303 creates an AI task record for the AI ​​task installed at AIH 1301. This step can be combined with Fig.12 The same as step S1216 in.

[0397] In step S1322, AIM 1303 may send a notification to AITM 1307. This step may be similar to Fig.12 The same as step S1218 in . AIM 1303 can send the notification to AIR 1307 and / or DSS. For example, AIM 1303 can create a transaction containing this notification and send the transaction to DSS (e.g., distributed ledger).

[0398] AIH initiated traceability awareness FL task deployment

[0399] Fig.14 A method for traceability awareness FL task deployment initiated by AIH according to an embodiment of the present principles is shown. This method is similar to Fig.12 but extends the general AI task to the FL task.

[0400] In step 1402, the FLS 1403 sends a message to the AIM 1405 to request an AI task (i.e., a FL task in this case). This is similar to Fig.12 Step S1202 in this message. The AIH-ID contained in this message is the identifier of the FLS. FLS1403 can indicate in the message whether AIM 1405 is required to discover FLC 1401 and how many FLCs are required. Even if FLS1403 has prepared a list of FLCs, FLS1403 can request AIM 1405 to reselect FLC 1401. FLS1403 can also send a list of its FLCs (e.g., their unique identifiers) to AIM 1405, and AIM 1405 can authenticate these FLCs based on the information contained in this message and / or additional information about each FLC that AIM 1405 can retrieve from AIR.

[0401] In step S1404, AIM 1405 determines the AI ​​task (i.e., FL task) of FLS 1403. This is similar to Fig.12 In step S1204 of FIG. 1405 , AIM 1405 may determine the FLC of the determined AI task, for example, by discovering an appropriate AIH from the AIR and assigning the discovered AIH as the FLC. AIM 1405 may also select a FL aggregation algorithm (eg, synchronous or asynchronous) for the determined FL task.

[0402] In step S1406, similar to Fig.12 In step S1206 of the embodiment, the AIM 1405 sends a message to the AITM 1407 to request a traceback instruction. The AIH-ID included in this message includes the identifier of the FLS 1403. The AIH-ID may also include the identifier of the FLC determined in step S1404.

[0403] In step S1408, AITM 1407 sends a response to AIM 1405. This is similar to Fig.12 The traceback instructions contained in this response may be used only for FLS 1403, and may optionally be used for each FLC if any FLC was indicated in step S1406.

[0404] In step S1410, AIM 1405 sends a request to FLS to install the determined task. This is similar to Fig.12 The request may include FL parameters, ie, the list of FLCs determined in step S1404 (eg, their identifiers), and / or the FL aggregation algorithm selected in step S1404.

[0405] In step S1412, FLS1403 installs the AI ​​task (ie, FL task). This is similar to Fig.12 After successfully installing the AI ​​task, the FLS may send a response to the AIM to indicate success (or failure), similar to Fig.12 Step S1214 in .

[0406] In step S1414, the FLS 1403 may determine the FLC of the AI ​​task. Even in the case where the list of FLCs is indicated in step S1410, the FLS 1403 may not select or select some FLCs from the list, or select other FLCs.

[0407] In step S1416 , the FLS 1403 determines a traceback instruction for each FLC based on the traceback instruction received in step S1410 .

[0408] In step S1418, the FLS 1403 sends a request to install the AI ​​task to the FLC 1401. This step is similar to step S1410, except that the request may include the identifier FLS-ID of the FLS.

[0409] FLC 1401 installs the AI ​​task, similar to step S1412, and sends a response to FLS 1403 in step S1420. The response may include FLC-ID (i.e., the identifier of the FLC) and AI-Task-Address (similar to Fig.12 AI-Task-Address in step S1214).

[0410] In step S1422, Fig.12 , FLS1403 sends a response to AIM 1405. FLS1403 may wait to receive responses from all FLCs for which it has requested to install FL tasks, aggregate these responses, and generate an aggregate response and send it to AIM 1405. Alternatively, FLS1403 may send a separate response about FLC 1401 to AIM 1405, for example, upon receiving a response in step S1420. The response may include AIH-ID, i.e., an identifier of the FLS1403 and each FLC 1401 to which the response relates, and AI-Task-Address indicating the address of the AI ​​task installed at FLS1403 and the AI ​​task installed at each FLC 1401.

[0411] In step S1424, Fig.12 Similar to step S1214 in , AIM 1405 creates an AI task record for the AI ​​tasks installed at FLS 1403 and all FLCs 1401. Alternatively, AIM 1405 creates one AI task record for the AI ​​tasks installed at FLS 1403 and one AI task record for the AI ​​tasks installed at each FLC 1401.

[0412] In step S1426, the AIM 1405 sends a notification to the AITM 1407. The notification may include the AI ​​task record created in step S1424. The notification may also or alternatively be sent to the AIR and / or DSS.

[0413] AIM initiated traceability aware FL mission deployment

[0414] Fig.15 A method for traceability-aware FL task deployment initiated by AIM according to an embodiment of the present principles is shown. This method is similar to Fig.13 The method shown in , but the AI ​​task deployed is the FL task.

[0415] In step S1502, similar to Fig.13 In step S1302 , the AIM 1305 determines to deploy an AI task (ie, a FL task in this case).

[0416] In step S1504, similar to Fig.13 In step S1304 of , the AIM 1305 sends a message to the AITM 1307 to request traceability instructions for the determined AI task.

[0417] In step S1506, similar to Fig.13 In step S1306 , AITM 1307 sends a response including a traceback instruction to AIM 1305 .

[0418] In step S1508, similar to Fig.13 In step S1308 of , the AIM 1505 sends a message to the AIR 1509 to discover the AIH of the AI ​​task. Since the AI ​​task is a FL task, the AIM 1505 can request to discover both the FLS 1503 and the FLC 1501.

[0419] If the AIM also requests FLCs in step S1508, AIR 1509 searches a repository (eg, its local repository) for multiple FLSs and multiple FLCs. In step S1510, AIR 1509 sends a response to AIM 1505, the response including an AIH-List indicating identifiers of multiple FLSs and identifiers of all FLCs.

[0420] In step S1512, the AIM 1505 selects the FLS 1503 and the plurality of FLCs 1501 for the AI ​​task. Alternatively, in step S1518, the AIM 1505 may select only the FLS 1503 and let the FLS 1503 select the FLC 1501.

[0421] In step S1514, Fig.14 Similar to step S1410 in , AIM 1505 sends to FLS 1501 (or FLS as the case may be) to install the FL task at FLS 1503 .

[0422] FLS1503 installs the FL task. In step S1516, Fig.14 Similar to step S1412 in , FLS 1503 may send a response to AIM 1505 , indicating successful installation (or failure) of the FL task at FLS 1505 .

[0423] In step S1518, Fig.14Similar to step S1414 in , FLS1503 can reselect FLC.

[0424] In step S1520, Fig.14 Similar to step S1416 in , FLS1503 determines the traceback instructions for each FLC.

[0425] In step S1522, Fig.14 Similar to step S1418 in , FLS 1503 sends a message to FLC 1501 to request installation of the FL task.

[0426] The FLC 1501 installs the FL task and in step S1524, Fig.14 Similar to step S1420 in , a response is sent to FLS1503.

[0427] In step S1526, Fig.14 Similar to step S1422 in , FLS1503 sends a response to AIM 1505.

[0428] In step S1528, Fig.14 Similar to step S1424 in , AIM 1505 creates one or more AI task records.

[0429] In step S1530, Fig.14 Similar to step S1426 in , AIM 1505 sends the AI ​​task record to AITM 1507 and AIR 1509 (and possibly also to DSS).

[0430] Traceability-aware AI model registration

[0431] AIMP can register its generated (i.e. trained) AI model with AIR, which can be discovered and shared with AIMU. Alternatively, when AIMP generates an AI model, it can send the AI ​​model including its metadata to AIM, which has installed the AI ​​task to AIMP in order to train the AI ​​model, and thus, AIM registers the AI ​​model with AIR.

[0432] When AIMP (or AIM) registers an AI model, it may have traceability requirements for the AI ​​model. Therefore, AIMP (or AIM) configures the required traceability instructions together with the AI ​​model to be registered.

[0433] It takes time for AIMP to train an AI model. But AIMP may want its AI model to be discovered by AIMU before it is fully trained. In other words, the AI ​​model registered by AIMP can be fully trained or partially trained. When AIMP registers a partially trained AI model, it can be regarded as a model pre-registration or model pre-announcement.

[0434] Fig.16 A method for AIMP to register an AI model to AIR according to an embodiment of the present principles is shown.

[0435] In step S1602, the AIMP 1603 sends a message to the AIR 1601 to register the AI ​​model.

[0436] It should be noted that when the AIM (not shown) installs the AI ​​training task to the AIMP 1603, the AIMP 1603 may have been informed of the address of the AIR 1601. In this case, the information contained in the registration message (such as Trace-Instructions) may have been sent to the AIR 1601 by the AIM and may therefore be omitted from the registration message.

[0437] The message may include:

[0438] -Trace-Instructions: Traces instructions and requirements on the AI ​​model if the AIMU wants to use the model to infer knowledge. For example, a trace requirement can require the AIMU to log the inferred knowledge and the associated input data for inference when the inferred knowledge is wrong or below a certain accuracy threshold. This parameter is similar to Fig.12 Trace-Instructions described in step 1208 in.

[0439] -AI-Model-Type: The type of AI model being registered. This can describe the type of AI model at different levels or granularity, such as but not limited to: 1) Algorithm level: if the AI ​​model is a linear regression model, classification model, DNN model, etc.; 2) Application level: if the AI ​​model is used for wireless channel prediction, image classification, pattern recognition, natural language processing, financial market prediction, autonomous driving, etc. If the AI ​​model is a DNN model, AI-Model-Type can also indicate the number of layers and neurons of the DNN.

[0440] -AI-Model-Content: If the AI ​​model being registered 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 for fully trained AI models, AIMP can skip this parameter and decide not to upload the model content to AIR. Instead, other entities can discover the AI-Model-Address and use a separate step to retrieve the model content directly from AIMP.

[0441] AI-Model-Usage-Constraints: Constraints, such as who and when can discover and use the registered model. For example, AI-Model-Usage-Constraints may include a reputation threshold, which indicates that only AIMUs with a reputation above the threshold can discover and use the AI ​​model.

[0442] -AI-Model-ID: Identifier of a previously registered AI model. AIMP can use the AI-Model-ID to notify AIR that the AI-Model-Content is an update to the previously registered AI model, as indicated by the AI-Model-ID.

[0443] -AI-Model-Address: The address of the AI ​​model that is partially trained or still being trained at the AIMP. Using this parameter, AIR or AIMU can check the status of the AI ​​model from AIMP (e.g., fully trained or partially trained) and download it from AIMP after it is fully trained. If AI-Model-Content is not included in the registration message, AIMU or AIR can use AI-Model-Address to access AIMP later to retrieve the model content.

[0444] -AIM-ID: If the AI ​​model training task at the AIMP is installed by an AIM, this parameter indicates the identifier and / or address of the AIM.

[0445] -AIMP-ID: The identifier and / or address of the AIMP that generated or is still training the AI ​​model.

[0446] Step S1602 may be triggered when a new AI model is generated / trained at AIMP 1603. In addition, AIMP 1603 may use step S1602 to pre-register or pre-announce an AI model that is still being trained.

[0447] If the message contains AI-Model-Content, then in step S1604, AIR 1601 stores the AI ​​model in (e.g., its local) repository. If the message does not contain AI-Model-Content, step S1604 can be skipped. If AIMP 1603 requests to update the previously registered AI model in step S1602, AIR 1601 replaces the previous version of the AI ​​model with the new AI-Model-Content contained in the message in step S1602 and deletes the corresponding AI model record.

[0448] In step S1606, AIR 1601 creates an AI model record for the AI ​​model indicated in the message in step S1602. AIR 1601 may publish the AI ​​model to a DSS (e.g., a distributed ledger). For example, AIR 1601 may create a transaction including the AI ​​model and send the transaction to the distributed ledger. The AI ​​model record may include the following, which may be discovered and / or exposed to other entities (such as an AIMU):

[0449] - AI-Model-ID: Same as the message in step S1602 (if included). If not included, it means that the AI ​​model is registered first, and AIR 1601 will create an AI-Model-ID for the registered AI model. Later, AIMP 1603 can use the AI-Model-ID to update the registered AI model.

[0450] -AI-Model-Usage-Constraints: Same as in the message in step S1602 (if included therein). If not included therein, AIR 1601 may determine the AI ​​model usage constraints.

[0451] - AI-Model-Address: Same as in the message in step S1602 (if included). Not required if not included.

[0452] - AI-Model-Content: Same as in the message in step S1602 (if included). Not required if not included.

[0453] -AI-Model-Mode: Indicates that the AI ​​model has been registered.

[0454] -Trace-Instructions: Same as in the message in step S1602.

[0455] In step S1608, AIR 1601 sends a response to AIMP 1603. The response may include:

[0456] - AI-Model-ID: the same as in step S1602.

[0457] - AI-Model-Record-ID: the identifier of the AI ​​model record created in step S1606.

[0458] After receiving the response in step S1608, AIMP 1603 may forward the response to an AIM (not shown) that has previously installed the AI ​​task to the AIMP in order to train / generate the AI ​​model being registered.

[0459] In the case where AIM-ID is included in step S1602, AIR 1601 can also forward the response sent to AIMP 1603 in step S1608 to AIM, as indicated by AIM-ID. After receiving the response, AIM can retrieve the AI ​​model from AIR 1601 at any time or find other information about the AI ​​model.

[0460] It should be noted that AIMP 1603 can also use this method to register its model with AIM or DSS (i.e., replace Fig.16 in AIR).

[0461] After step S1608, AIR 1601 may send a notification including the AI ​​model record created in step S1606 to the AIM or AITM.

[0462] It should be noted that when AIMP 1603 generates an AI model, it can send the AI ​​model to AIM. AIM can then use Fig.16 The method in registers the AI ​​model to AIR, thereby interacting with AIM instead of AIMP. AIM can then publish the AI ​​model to DSS (e.g., distributed ledger). For example, AIM can create a transaction containing the AI ​​model and send the transaction to the distributed ledger.

[0463] It should be noted that AIR can forward Trace-Instructions received from AIMP to AITM, especially when the trace instructions are purely determined by AIMP, or when AIR wants to verify the Trace-Instructions using AITM. When AIR forwards Trace-Instructions, AIR can associate the Trace-Instructions with the corresponding AI-Model-ID and AIMP-ID, and also forward these associations to AITM.

[0464] Traceability-aware AI model discovery and deployment

[0465] AIR Assisted Traceability Awareness Model Discovery

[0466] AIMU will install the AI ​​model. From AIR, AIMU finds AI models that meet its traceability standards. AIR can send the AI ​​model address to AIMU, or send the model content and associated traceability 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 traceability instructions from AITM. AIMU then installs the AI ​​model incorporating the traceability 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).

[0467] Fig.17 A method of AIR-assisted traceability-aware model discovery and deployment according to an embodiment of the present principles is shown.

[0468] The AIM (not shown) has installed the AI ​​tasks without any associated AI models to the AIMU 1701. However, the AIMU 1701 requires AI models to run the AI ​​tasks to infer knowledge.

[0469] In step S1702, AIMU 1701 sends a message to AIR 1703 to discover the AI ​​model it needs. It should be noted that AIMU 1701 has a local AI agent that is installed together with the AI ​​task when the AI ​​task is installed, and the address of AIR 1703 can be configured to AIMU 1701. The message may include one or more of the following:

[0470] Trace-Criteria: The traceability criteria used to discover AI models. In other words, AIMU 1701 requires AI models whose "Trace-Instructions" meet the traceability criteria represented by Trace-Criteria. Trace-Criteria can include similar information (e.g., "Trace-Scope"), which are Fig.12 Part of the “Trace-Instructions” described in step S1208.

[0471] -AI-Model-Type: The type of AI model being registered. This can describe the type of AI model at different levels or granularities, such as but not limited to: 1) Algorithm level: if the AI ​​model is a linear regression model, classification model, DNN model, etc.; 2) Application level: if the AI ​​model is used for wireless channel prediction, image classification, pattern recognition, natural language processing, financial market prediction, autonomous driving, etc. If the AI ​​model is a DNN model, AI-Model-Type can also indicate the number of layers and neurons of the DNN.

[0472] -AI-Model-ID: Identifier of a previously downloaded AI model. AIMU 1701 can use this parameter to download a new version of the AI ​​model from AIR 1703.

[0473] It should be noted that the AIMU 1701 may indicate in the message that the Trace-Criteria is of secondary priority, which means that AI models with mismatched Trace-Instructions may still be discovered and installed to the AIMU 1701.

[0474] AIR 1703 uses the received Trace-Criteria to check the (locally) maintained AI model records to find any registered AI models with Trace-Instructions that match the Trace-Criteria. For example, AIR 1703 can check whether the "Trace-Scope" contained 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, AIR 1703 can simply use it to find the corresponding AI model being registered.

[0475] In step S1704, AIR 1703 sends a response to AIMU 1701. The response may give AIMU 1701 the complete AI model with traceback instructions. 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 may include the following information for each discovered AI model:

[0476] -AI-Model-ID: The identifier of the discovered AI model.

[0477] -AI-Model-Content: The content of the discovered AI model.

[0478] -Trace-Instructions: Trace instructions for the discovered AI model that have been configured by AIMP or AIR.

[0479] -AI-Model-Address: The address of the discovered AI model, from which the contents of the AI ​​model can be retrieved. If this information is included, the AIMU 1701 can use it to retrieve the AI ​​model from the AIMP, as will be described in steps S1706 and S1708.

[0480] - AITM-ID: An identifier or address of the AITM from which AIMU 1701 can retrieve trace instructions for the AI ​​model. As will be described, if this information is included in the message in step S1702, AIMU 1701 can perform steps S1710 and S1712. If Trace-Instructions is included in the response in step S1704, this information can be omitted.

[0481] -Notification-Target: The address or identifier of one or more notification targets (e.g., AIR, AITM, etc.) to which AIMU 1701 should send notifications after installing the AI ​​model (ie, step 1722).

[0482] It should be noted that AIR 1703 may find an AI model that does not match the Trace-Instructions of AIMU 1701, for example if the search is performed without using Trace-Instructions, or if no AI model matches the Trace-Instructions, especially when AIMU 1701 indicates in the discovery message in step S1702 that the Trace-Criteria is of secondary priority. It is worth noting that the trace-instructions received by the AIMU in the response in step S1704 may include additional trace requirements (e.g., set by AIMP) that are higher than those trace requirements requested by the AIMU in the discovery message in step S1702.

[0483] In the case where the AI-Model-Address is included in the response in step S1704, the AIMU 1701 sends a message to the AIMP 1705 in step S1706 to retrieve the AI ​​model indicated by the AI-Model-Address. The message may include:

[0484] -AI-Model-ID: as in step S1704.

[0485] -AI-Model-Address: as in step S1704.

[0486] -AI-Model-Push-Address: AIMP 1705 can use this address to push the contents of a fully trained AI model to AIMU 1701.

[0487] The AIMP 1705 may use the AI-Model-ID and / or the AI-Model-Address to uniquely identify the AI ​​model maintained locally by the AIMP 1705 .

[0488] AIMP 1705 uses the received AI-Model-Address to identify the corresponding AI model and sends a response to AIMU 1701 in step S1708. If the AI ​​model is now fully trained, the response includes the content of the AI ​​model; otherwise, the response may include an indication that the AI ​​model is unavailable and is still being trained. When the AI ​​model is fully trained, AIMP 1705 may push the content of the AI ​​model to AI-Model-Push-Address. The response may include:

[0489] - AI-Model-ID: as in step S1706.

[0490] -AI-Model-Content: If the AI ​​model is fully trained, the content of the AI ​​model.

[0491] -Trace-Instructions: Trace-instructions and requirements needed for the AI ​​model if it is fully trained.

[0492] -AI-Model-Ready-Time: The estimated time when the AI ​​model training will be fully trained.

[0493] - AITM-ID: The identifier or address of the AITM from which the AIMU 1701 can retrieve traceback instructions from the AI ​​model. If this parameter is included, the AIMU 1701 can perform steps S1710 and S1712 below.

[0494] In step S1710, in the case where the AIMU 1701 has obtained the content of the AI ​​model in the response of step S1704 or S1708, the AIMU 1701 sends a request message to the AITM 1707 to retrieve the traceability instruction of the AI ​​model.

[0495] It should be noted that step S1710 may be omitted, for example, if AIMU 1701 has received a traceback instruction from AIR in response to step S1704. In addition, if AIMU 1701 does not know the address or identifier of AITM 1707, step S1710 is omitted.

[0496] The request message may include:

[0497] -AIMU-ID: Identifier of AIMU 1701.

[0498] -AI-Model-ID: Identifier of the AI ​​model.

[0499] -Trace-Criteria: the same as "Trace-Criteria" in the request message in step S1702.

[0500] -Trace-Capability: Fig.10 The same as the "Trace-Capability" received in step S1002 in.

[0501] The AITM 1707 determines the trace instructions for the AIMU 1701 based on the Trace-Criteria and Trace-Capability received in the request message in step S1710, for example. Alternatively, the AIMU 1701 may have pre-assigned the trace instructions for the AI ​​model, as indicated by the AI-Model-ID. In step S1712, the AITM 1707 sends a response including the determined trace instructions to the AIMU 1701.

[0502] It should be noted again that the AIMU 1701 itself may determine the trace instructions from the Trace-Instructions received in the response in step S1704 or S1708. In this case, steps S1710 and S1712 are not required.

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

[0504] In step S1716, the AIMU 1701 may present the Trace-Instructions received in step S1712 or otherwise determined (as already described) to the person to request input. For example, the person may accept or reject the trace instructions, and the person may specify an address to which the AIMU should send the AI ​​trace records.

[0505] In step S1718, AIMU 1701 may receive input from a person. AIMU 1701 may generate a final trace configuration (Trace-Configuration) by combining Trace-Instructions and the input from the person. AIMU 1701 configures Trace-Configuration to the AI ​​model.

[0506] In step S1720, AIMU 1701 creates an AI model record for the installed AI model. The AI ​​model record may include:

[0507] -AIMU-ID: Identifier of AIMU 1701.

[0508] -AI-Model-ID: The identifier of the installed AI model.

[0509] -AI-Model-Address: as in step S1704.

[0510] -AI-Model-Push-Address: as in step S1706.

[0511] -Trace-Configuration: The combined result of Trace-Instructions and input from humans.

[0512] In step S1722, AIMU 1701 sends a notification to AIR or AITM, as determined by the Notification-Target received in step S1704. The notification may include the entire AI model record created in step S1720 or an identifier of the AI ​​model record. Optionally, AIMU 1701 may also publish the AI ​​model record to the DSS. In addition, if the AI ​​model is generated and contributed by AIMP 1701, AIMU 1701 may send the same notification to the AIMP 1705.

[0513] It should be noted that if an existing AI model is to be used as an initial model to train a new AI model, another AIMP-X can be used similar to Fig.17 method to discover and retrieve the content of existing AI models, where AIMU is replaced by AIMP-X).

[0514] AIM-coordinated traceability-aware AI model discovery and deployment

[0515] AIMU relies on AIM to discover AI models that meet its traceability criteria at AIR. AIR can return the AI ​​model address to AIMU, or return the model content and associated traceability instructions to AIM. If AIM only receives the AI ​​model address from AIR, AIM retrieves the AI ​​model content from the AI ​​model address (e.g., AIMP). AIM can also retrieve traceability instructions from AITM. AIM then pushes the model content and associated traceability instructions to AIMU. AIMU installs the AI ​​model incorporating the traceability instructions and any user input. AIM creates an AI model record for the AI ​​model installed at AIMU. Finally, AIM sends the AI ​​model record to AIR and / or other entities (e.g., DSS, AIMP, AITM).

[0516] Fig.18 A method of AIM-coordinated traceability-aware AI model discovery and deployment according to an embodiment of the present principles is shown.

[0517] In step S1800, AIMU 1801 may initiate discovery of an AI model by sending a message to AIM 1803. This is similar to Fig.17 In addition, AIMU 1801 may include its Trace-Capability in this step.

[0518] Since AIM 1803 has installed the AI ​​tasks to AIMU 1801, it knows what types of AI models are needed by AIMU 1801. In step S1802, AIM 1803 sends a message to AIR 1805 to discover and download the AI ​​models for AIMU 1801. This is similar to Fig.17 Step S1702 in .

[0519] In step S1804, AIR 1805 sends a response with AI model information to AIM 1803, similar to Fig.17 Step S1704 in .

[0520] In step S1806, AIM 1803 sends a message to AIMP 1807 to retrieve the AI ​​model. This is similar to Fig.171806, but the AI-Model-Push-Address included in the message may indicate the address used by AIM 1803 to receive the AI ​​model from AIMP 1807 or the address used by AIMU 1801 to receive the AI ​​model from AIMP 1807. If AI-Model-Push-Address is the address of AIMU 1801, AIMP 1807 may push or send the AI ​​model directly to AIMU 1801 using the AI-Model-Push-Address.

[0521] In step S1808, AIMP 1807 may send the requested AI model to AIM 1803. This step is similar to Fig.17 Step S1708 in .

[0522] In step S1810, the AIM requests Trace-Instructions from the AITM 1809. This is similar to Fig.17 Step S1710 in .

[0523] In step S1812, after retrieving the Trace-Instructions, AITM 1809 sends them to AIM 1803. This is similar to Fig.17 Step S1712 in .

[0524] Based on the Trace-Instructions received in step S1804 and / or step S1812, AIM 1803 determines the final trace instructions of the AI ​​model to be deployed. In step S1814, AIM 1803 sends a response message to AIMU 1801 to instruct AIMU 1801 to deploy the AI ​​model. The message may include:

[0525] -AI-Model-ID: Identifier of the AI ​​model sent to and deployed at AIMU 1801 .

[0526] -AI-Model-Content: the content of the AI ​​model sent to AIMU 1801 and deployed at AIMU 1801.

[0527] -Trace-Instructions: The final trace instructions of the AI ​​model sent to and deployed at AIMU 1801.

[0528] In one variation, AIM 1803 does not send Trace-Instructions to AIMU 1801. Instead, AIM 1803 may inform AIMU 1801 of the identifier of the trace-instructions determined or created for AIMU 1801, for example by presenting its identifier and / or any identifier of the determined trace-instructions, so that AIMU 1801 may retrieve the trace-instructions from AITM 1809.

[0529] In step S1816, AIMU 1801 installs the AI ​​model. This is similar to Fig.17 Step S1714 in .

[0530] In step S1818, AIMU 1801 requests user input for traceability options. This is similar to Fig.17 Step S1716 in .

[0531] In step S1820, AIMU 1801 receives the user input and configures the AI ​​model using the final traceability configuration determined using the user input. This is similar to Fig.17 Step S1718 in .

[0532] In step S1822, AIMU 1801 sends a notification message to AIM 1803 to indicate the deployment of the AI ​​model. The notification message may include:

[0533] -AIMU-ID: Identifier of AIMU 1801.

[0534] -Trace-Configuration: the final trace configuration determined in step S1820.

[0535] In step S1824, AIM 1803 creates an AI model record for the AI ​​model deployed at AIMU 1801. This is similar to Fig.17 Step S1720 in the AI ​​model record may include:

[0536] -AIMU-ID: Identifier of AIMU 1801.

[0537] -AI-Model-ID: The identifier of the installed AI model.

[0538] -AI-Model-Address: Address used to retrieve the AI ​​model from AIMP 1807.

[0539] -AI-Model-Push-Address: the same as in step S1806.

[0540] -Trace-Configuration: Same as in step S1822.

[0541] -AIM-ID: Identifier of AIM 1803.

[0542] In step S1826, AIM 1803 sends a notification message to AIR 1805 or AITM 1809, as determined by Notification-Target as the AIMU received in the message in step S1804. AIM 1803 may also determine to send a notification to AIR 1805 and / or AITM 1809 based on a pre-configured policy. The notification may include the entire AI model record created in step S1824 or an identifier of the AI ​​model record. Optionally, AIMU 1801 may publish the AI ​​model record to the DSS. In addition, if the AI ​​model is generated and contributed by AIMP 1807, AIM 1803 may send a notification message to the AIMP 1807.

[0543] It should be noted that if another AIMP-Y wants to use an existing AI model as an initial model to train a new AI model, it can use Fig.18 The method shown in replaces AIMU to discover and retrieve the content of existing AI models.

[0544] AIMP-initiated traceability-aware AI model discovery and deployment

[0545] AIMP deploys AI models to AIMUs. AIMP discovers AIMUs from AIR that meet its traceability standards and AI standards. AIR looks up its locally maintained AI host records and finds one or more AIMUs whose AI capabilities and traceability capabilities match the AI ​​standards and traceability standards from AIMP. AIR returns the discovered AIMUs to AIMP. AIMP then contacts each AIMU to obtain their permission to deploy AI models. AIMU receives model content from AIMP and receives traceability instructions from AIMP or AITM. AIMU then installs the AI ​​model incorporating traceability 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).

[0546] Fig.19 A method of AIR-assisted traceability-aware model discovery and deployment according to an embodiment of the present principles is shown.

[0547] In step S1902, AIMP 1905 sends a message to AIR 1903 to discover AIMU 1901. The message may include:

[0548] - AIMP-ID: (unique) identifier of AIMP.

[0549] -Trace-Criteria: The traceability criteria used to discover AIMUs. In other words, AIMP discovers AIMUs whose "Trace-Capability" meets the traceability criteria represented by Trace-Criteria. Trace-Criteria can contain something like Fig.12 The information of a part of the “Trace-Capability” described in step S1208 (for example, “Trace-Scope”).

[0550] -AI-Criterial: used to discover the AI ​​requirements of the AIMU. In other words, the AIMP discovers the AIMU whose "AI-Capability" satisfies the AI ​​criteria as represented by AI-Criteria. AI-Criteria can contain Fig.10 In addition, AI-Criterial may contain metadata about the AI ​​model that AIMP wants to deploy to AIMU.

[0551] AIR 1903 uses the received Trace-Criterial and AI-Criteria to check the (locally) maintained AI host record to find a registered AIMU with Trace-Instructions matching the Trace-Criteria. Then, in step S1904, AIR 1903 sends a response to AIMP 1905. For each discovered AIMU, the response message may include:

[0552] - AIMU-ID: Identifier of the discovered AIMU, which may contain the address of the AIMU.

[0553] -AI-Capability: The AI ​​capabilities of the discovered AIMU.

[0554] -Trace-Capability: The traceability capability of the discovered AIMU.

[0555] Having received the response, AIMP 1905 selects at least one AIMU from the list of discovered AIMUs included in the response in step S1904.

[0556] Steps S1906 to S1924 are performed for each selected AIMU.

[0557] In step S1906, AIMP 1905 sends a notification to the selected AIMU 1901 to deploy the AI ​​model. The notification message may include:

[0558] -AIMU-ID: Identifier or address of the selected AIMU 1901.

[0559] - AI-Model-ID: The (unique) identifier of the AI ​​model to be deployed.

[0560] -AI-Model-Type: The type of AI model to be deployed.

[0561] -Trace-Criteria: Trace-Criteria included in the message in step S1902.

[0562] The AIMU 1901 receives the notification message which it may accept or reject. In the event that the AIMU 1901 accepts the notification message, the method continues for that AIMU 1901.

[0563] In step S1908, AIMU 1901 sends a message to AIMP 1905 to retrieve the AI ​​model identified by AI-Model-ID. The message may include:

[0564] - AI-Model-ID: the same as in step S1906.

[0565] -AI-Model-Push-Address: AIMP 1905 can use this address to push the contents of a fully trained AI model to AIMU 1901.

[0566] The AIMP 1905 receives the message and uses the AI-Model-ID to identify the corresponding AI model. In step S1910, the AIMP 1905 sends a response to the AIMU 1901.

[0567] In the case where the AI ​​model is fully trained, the response may include the content of the AI ​​model. Otherwise, the response may include information indicating that the AI ​​model is not available and is still being trained. When the AI ​​model is fully trained, AIMP 1905 may also or alternatively push the content of the AI ​​model to the AI-Model-Push-Address. The response may include one or more of the following:

[0568] -AI-Model-Content: If the AI ​​model is fully trained, the content of the AI ​​model.

[0569] -Trace-Instructions: If the AI ​​model is fully trained, the trace instructions and requirements required by the AI ​​model. It should be noted that AIMP 1905 can obtain trace instructions from AITM 1907.

[0570] -AI-Model-Ready-Time: The estimated time when the AI ​​model training will be fully trained.

[0571] - AITM-ID: Identifier or address of the AITM 1907 from which the AIMU 1901 can retrieve traceback instructions from the AI ​​model. In the event that this information is included in the response, the AIMU 1901 can perform steps S1912 and S1914.

[0572] Steps S1912 to S1922 are the same as steps S1710 to S1720.

[0573] In step S1924, in addition to AIMU 1901 sending a notification to AIMP 1905, Fig.17 The same as step S1722 in.

[0574] Traceability-aware AI model discovery and deployment initiated by AIMP using distributed ledger implementation

[0575] Fig.19 The method shown in can be implemented using blockchain and / or distributed ledger as an example of DSS, as will be described in the following examples.

[0576] Fig.19 Each entity in the blockchain (i.e., AIMU 1901, AIR 1903, AIMP 1905, and AITM 1907) is a blockchain user. Each entity has a blockchain account. Each entity is connected to a different (or even the same) blockchain node, which hosts the entire blockchain or ledger.

[0577] AIR 1903 may have published the AI ​​host record to the blockchain. AIR 1903 may maintain information about where each AI host record is stored in the blockchain (e.g., the sequence number of the block and transaction containing the AI ​​host record), referred to as the blockchain address of each AI host record.

[0578] AIR 1903 (and / or AIMP 1905) may have published the AI ​​model records to the blockchain. AIR 1903 may maintain information about the storage location of each AI model record in the blockchain (e.g., the sequence number of the block and transaction containing the AI ​​model record), referred to as the blockchain address of each AI model record.

[0579] AITM 1907 may have published the traceability instructions on the blockchain. AITM 1907 may maintain information about the storage location of each traceability instruction record in the blockchain (e.g., the sequence number of the block and transaction containing the traceability instruction record), referred to as the blockchain address of each traceability instruction record.

[0580] Step S1902 remains unchanged.

[0581] In step S1904, AIR 1903 may include only the blockchain address of the AI ​​host record of the found AIMU in the response. In other words, the response does not include AIMU-ID, Trace-Capability, and AI-Capability. AIMP 1905 uses the blockchain address to retrieve the corresponding AI host record from the blockchain node to which AIMP 1905 is connected.

[0582] In step S1906, AIMP 1905 may include only the blockchain address of the AI ​​model record.

[0583] In step S1908, AIMU 1901 uses the blockchain address of the AI ​​model to retrieve the AI ​​model content and associated traceability instructions from a blockchain node to which the AIMU can connect.

[0584] In step S1910, AIMU 1901 receives the AI ​​model from the blockchain node.

[0585] Step S1912 remains unchanged.

[0586] In step S1914, the response may include only the blockchain address of the tracing instructions. AIMU 1901 then uses the blockchain address to retrieve the tracing instructions from the blockchain node to which AIMU 1901 is connected.

[0587] Steps S1916 to S1922 remain unchanged.

[0588] In addition to or in addition to sending the notification in step S1924, AIMU 1901 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.

[0589] Example

[0590] The following illustrates how the present principles may be implemented in different types of network architectures.

[0591] 3GPP SA2 Embodiment

[0592] Architecture Embodiment

[0593] The entities for traceability-aware AI tasks and model management described herein (e.g., AIMU, AIR, AIMP, and AITM) can be implemented in a 3GPP cellular network, as shown below, using the 5G service architecture as a non-limiting example.

[0594] The AIMU may be a UE, a network function (NF) and / or an application function (AF).

[0595] The AIMP can be UE, NF and / or AF.

[0596] AIM and AIR can be integrated in one device or node as an AI management and repository function (AIMRF), which can be deployed as a standalone NF, AF, an extension of the 5G network repository function (NRF), an extension of the 5G network data analysis function (NWDAF), or an extension of the 5G unstructured data storage function (UDSF).

[0597] AITM can be implemented as an AI Tracing Management Function (AITMF), which can be deployed as a standalone NF or as an extension of the 5G Policy Control Function (PCF).

[0598] DSS can be implemented as a DSS function (DSSF), which is deployed as a standalone NF, an extension of the 5G unified data repository (UDR) function, or an extension of the 5G UDSF.

[0599] AIMU, AIMP, AIMRF, AITMF and DSSF can be deployed in various locations outside 5G and cellular networks, such as devices, edge data networks, core networks, data networks and / or the cloud.

[0600] Fig. 20 An example of deploying traceability-aware AI tasks and model management in 3GPP cellular networks is shown. In this example:

[0601] -UE-1 is the AIMU that hosts the AI ​​task, and it uses the AI ​​model provided by AIMP for knowledge reasoning. UE-1 has its AI-Capability and Trace-Capability.

[0602] -UE-2 is the AIMP that hosts the AI ​​task, and it generates an AI model. The generated AI model is deployed to UE-1. UE-1 has its AI-Capability and Trace-Capability.

[0603] -AIMRF is deployed as NF or AF in a 3GPP network or a data network. UE-1 registers itself as an AIMU to the AIMRF, indicating its AI-Capability and Trace-Capability, while UE-2 registers itself as an AIMP to the AIMRF and also indicates its AI-Capability and Trace-Capability. The AIMRF maintains a list of registered AIMUs and AIMPs; alternatively, the AIMRF publishes / stores the registered AIMUs and AIMPs to the DSSF.

[0604] -AITMF is deployed as NF or AF in 3GPP network or data network to manage trace instructions. AITMF can determine appropriate Trace-Instructions for UE-1 and UE-2. AITMF can store Trace-Instructions to DSSF and can also retrieve Trace-Instructions from DSSF.

[0605] – Information about registered AIMUs, registered AIMPs, registered AI models, deployed AI tasks and / or traceability instructions may be stored in and maintained by the DSSF.

[0606] AIMRF is responsible for deploying AI tasks to UE-2 in order to train AI models. When AIMRF deploys AI tasks to UE-2, it can assign Trace-Instructions along with the AI ​​tasks. Such trace instructions can be obtained from AITMF.

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

[0608] AIMRF is also responsible for deploying AI tasks to UE-1 so that knowledge reasoning can be performed using AI models. When AIMRF deploys AI tasks to UE-1, it can configure AI tasks with Trace-Instructions. Such Trace-Instructions can be obtained from AITMF.

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

[0610] AIMRF can push the discovered AI models and their Trace-Instructions to UE- 1. In addition, UE- 1 can retrieve / pull the discovered AI models and their Trace-Instructions from AIMRF using a separate step.

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

[0612] Fig.21 Another example of deploying traceability-aware AI management in a 3GPP cellular network is shown. In this example, the AIMU is still a UE, but with Fig. 20 The difference is that AIMP is NF or AF in 3GPP network or data network.

[0613] Fig. 22 Another example of deploying traceability-aware AI management in a 3GPP cellular network is shown. In this example, the AIMP is still a UE, but with Fig. 20 The difference is that the AIMU is a NF or AF in a 3GPP network or data network.

[0614] Example of a service flow for traceability-aware AI model discovery and deployment

[0615] Fig.23 Shown based on Fig.19 An example of a process traceability awareness service flow for AI model discovery and deployment. It should be noted that Fig.23 The AIMU-ID in is a UE identifier, such as but not limited to a UE's Globally Unique Temporary Identifier (GUTI), a UE's Subscription Hidden Identifier (SUCI), etc.

[0616] The assumptions are as follows. AIMP within the 3GPP core network trains a new AI model for efficient radio resource allocation for upstream communications. AIMP deploys the AI ​​model to the UE, which acts as an AIMU. At the same time, AIMP wants to know whether the AI ​​model is accurate or useful for the UE and the entire system. In other words, AIMP wants the UE to trace the AI ​​model after it is deployed and executed. First, AIMP finds a suitable UE from AIMRF whose Trace-Capability matches AIMP's Trace-Criteria. Then, AIMP can determine the trace instructions on its own, or AIMP can obtain the trace instructions from AITMF. Finally, AIMP deploys the AI ​​model and the corresponding trace instructions to the UE.

[0617] for Fig.23 , the following prerequisites can be assumed:

[0618] -AIMRF, AITMF, DSSF, AIMP and PCF have been registered with NRF.

[0619] -AIMP has discovered AIMRF, AITMF and PCF.

[0620] - The UE is registered to the 3GPP cellular network and can communicate with core network functions (such as AIMRF) via the AMF (not shown).

[0621] - Both UE and AIMP are registered with AIMRF.

[0622] -AIMP generates AI models.

[0623] We will now describe Fig.23 The service process in.

[0624] In step S2302 , AIMP 2305 sends a request to AIMRF 2303 to discover AIMU in order to deploy the AI ​​model to AIMU 2301 .

[0625] In step S2304 , the AIMRF 2303 sends a message to check if the PCF 2309 has any AIMU discovery policy applicable to the AIMP 2305 .

[0626] In step S2306 , PCF 2309 sends the AIMU discovery policy to AIMRF 2305 .

[0627] The AIMRF 2303 authorizes the request of the AIMP received in step S2302. If approved, the AIMRF 2303 will find one or more AIMUs 2301 from its locally maintained AIH record. In step S2308, the AIMRF 2303 sends the discovered AIMUs to the AIMP 2305 (i.e., the UE in this case).

[0628] In step S2310, AIMP 2305 sends a request message to UE 2301 to deploy the AI ​​model.

[0629] UE 2301 approves the received request. (If not approved, the service flow stops.) In step S2312, UE 2301 sends a request to AIMP 2305 to retrieve the AI ​​model.

[0630] In step S2314 , AIMP 2305 sends the content of the AI ​​model with the traceback instruction to UE 2301 .

[0631] In step S2316, UE 2301 may send a request to AITMF 2309 to retrieve a traceback instruction of the AI ​​model. In this case, AITMF 2309 sends the requested traceback instruction to UE 2301 in step S2318.

[0632] In step S2320, UE 2301 installs the AI ​​model.

[0633] In step S2322, UE 2301 requests user input for traceability options.

[0634] In step S2324, UE 2301 receives user input and uses it to configure the AI ​​model.

[0635] In step S2326, UE 2301 creates an AI model record for the installed AI model.

[0636] In step S2328 , UE 2301 sends the AI ​​model record to AIMRF 2303 , AIMP 2305 , AITMF 2307 and / or DSSF 2311 .

[0637] ETSI SAI Implementation

[0638] Fig.24 An example of a method for traceability-aware AI tasks and model deployment according to the present principles implemented in the framework of ETSI SAI is shown, the framework comprising the following logical entities:

[0639] -AIMU: with Figure 7The same AIMU as in.

[0640] -AIMP: with Figure 7 Same as AIMP in .

[0641] -AITM: with Figure 7 The same as AITM in.

[0642] -DSS: with Figure 7 The same as DSS in.

[0643] -AIRM: Figure 7 A combination of AIR and AIM.

[0644] In step 2402a, AIMU 2401 uses Fig.10 In step S1002, S1004 and S1006, AIMP 2405 registers itself with AIRM 2403, thereby indicating its Trace-Capability. In step 2402b, AIMP 2405 uses Fig.10 Steps S1002, S1004 and S1006 in the above process register themselves with AIRM 2403, thereby indicating their Trace-Capability.

[0645] In step 2404, AIRM 2403 generates an AI host record (ie, a registration record of AIMU and AIMP) to DSS2409.

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

[0647] In step 2408a, AIRM 2403 deploys AI tasks to AIMU 2401. In step 2408b, AIMR 2403 also deploys AI tasks to AIMP 2405. Fig.12 , Fig.13 , Fig.14 or Fig.15 The same steps can be used for steps 2408a and 2408b.

[0648] In step 2410, AIMP 2405 uses the deployed AI tasks to train and generate AI models.

[0649] In step 2412, AIMP 2405 registers the generated AI model, thereby indicating its Trace-Instructions. Fig.16 The same steps can be used for step 2412.

[0650] In step 2414, the generated AI model may be deployed to AIMU 2401 via AIRM 2403 by AIMP 2405. AIMP 2405 may directly install the AI ​​model to AIMU 2401. Alternatively, AIMU 2401 may discover and download the AI ​​model from AIRM 2403. Fig.17 , Fig.18 or Fig.19 The same steps can be used for step 2414.

[0651] In step 2416, AIMU 2401 installs the AI ​​model and configures the associated Trace-Instructions.

[0652] In step 2418, AIMU 2401 generates an AI model record for the installed AI model. AIMU 2401 sends the AI ​​model record to AIRM 2403 and / or DSS2409.

[0653] in conclusion

[0654] Although features and elements are provided above in a specific combination, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in the present application, which are intended to be illustrations of various aspects. Without departing from its spirit and scope, many modifications and changes can be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of the present application should not be interpreted as being critical or necessary to the present invention, unless explicitly provided as such. In addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure will be apparent to those skilled in the art according to the preceding description. Such modifications and changes are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents given by such claims. It should be understood that the present disclosure is not limited to specific methods or systems herein.

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

[0656] It will also be understood that the terms used herein are used only for the purpose of describing specific embodiments 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 a certain time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities (e.g., wearable) that is configured with some or all of the structure and functionality of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities that is configured with less than all of the structure and functionality of a WTRU; or (iv) a similar device. References herein to Figures 1A to 1D Details of an example WTRU are provided, which may be representative of any WTRU set forth herein. As another example, various disclosed embodiments herein are described above and below as utilizing a head mounted display. Those skilled in the art will recognize that devices other than a head mounted display may be utilized, and some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0657] In addition, the methods provided herein can be implemented in a computer program, software or firmware that is 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 non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs), processors associated with software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC or any host computer.

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

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

[0660] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may cause the final conversion or reduction of electrical signals and maintain the data bits in memory locations in the storage system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may support the provided methods.

[0661] The data bits may also be maintained on a computer-readable medium, including a magnetic disk, an optical disk, 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 cooperating or interconnected computer-readable media that reside only on a processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

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

[0663] There is little difference between hardware and software implementations of various aspects of the system. The use of hardware or software is usually (but not always, as in some cases, the choice of hardware or software may become important) a design choice that represents a cost-efficiency trade-off. There may be various vehicles (e.g., hardware, software, and / or firmware) with which the processes and / or systems and / or other technologies described herein can be implemented, and the preferred vehicle may change with the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may select a primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may select a primary software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0664] The foregoing detailed description has been described various embodiments of the apparatus and / or process by using block diagrams, flow charts and / or examples. Insofar as such block diagrams, flow charts 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, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or indeed any combination thereof. In an embodiment, several parts of the subject matter described herein may be implemented via an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and / or other integrated formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein may be equivalently implemented in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware or almost as any combination thereof, and according to the present disclosure, designing circuit systems and / or writing codes for software and / or firmware will be completely within the skill range of those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative examples of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually carry out the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.; and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

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

[0666] The subject matter described herein sometimes illustrates different parts that are included in different other parts or connected with different other parts.It should be understood that the architecture of such depiction is only an example, and many other architectures that realize the same function can actually be implemented.In a conceptual sense, any arrangement of parts for realizing the same function is effectively "associated" so that the desired function can be realized.Therefore, any two parts that are combined to realize a specific function in this article can be regarded as "associated" with each other so that the desired function is realized regardless of the architecture or the intermediate parts.Similarly, any two parts that are so associated can also be regarded as "operably connected" or "operably connected" to realize the desired function, and any two parts that can be so associated can also be regarded as "operably connected" to realize the desired function.The specific example of operably connectable includes (but is not limited to) parts that can be matched physically and / or physically interact, and / or parts that can be wirelessly interacted and / or wirelessly interacted, and / or parts that can be logically interacted and / or parts that can be logically interacted.

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

[0668] Those skilled in the art will understand that, in general, the terms used herein and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of an introduced claim statement is intended, such intent will be expressly stated in the claim, and in the absence of such a statement, no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce multiple claim statements. However, the use of such phrases should not be interpreted as implying that a claim recitation introduced by the indefinite article "a" or "an" will limit any particular claim including such introduced claim recitation to embodiments including only one such recitation, even if the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same is true for the use of definite articles to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited number (e.g., merely reciting "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those cases where a convention similar to “at least one of A, B, and C, etc.” is used, generally, such construction is intended to represent the convention that one skilled in the art would understand (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those cases where a convention similar to “at least one of A, B, or C, etc.” is used, generally, such meaning is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). One skilled in the art would further understand that any transitional words and / or phrases (whether in the specification, claims, or drawings) that actually give two or more alternatives should be understood to contemplate the possibility of including one of the items, either of the items, or both of the items. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B."Furthermore, as used herein, the term "any" followed by a plurality of items and / or a listing of items in a plurality of categories is intended to include "any," "any combination," "any plurality," and / or "any combination of plurality," either alone or in combination with other items and / or items in other categories. Furthermore, 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. And as used herein, the term "plurality" is intended to be synonymous with "multiple."

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

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

[0671] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. Furthermore, the use of the term "means for..." in any claim is intended to refer to or means-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

Claims

1. A device comprising: at least one processor, the at least one processor being configured to: 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 a traceability instruction based on a traceability standard of the AI ​​model requested by the device, wherein the traceability information corresponds to information for tracing one or more stages of an AI pipeline associated with the AI ​​model; Install the AI ​​model; Create records for installed AI models; and A message is transmitted to a recording device, the message including information indicative of at least a portion of the created recording.

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

3. The apparatus of claim 1, wherein the request further comprises an identifier of the AI ​​model.

4. The apparatus of claim 1 , wherein the at least one processor is configured to: receiving, from a first device among the at least one other device, information indicating a second device; The at least one processor is configured to receive the AI ​​model by downloading the AI ​​model from the second device.

5. The apparatus of claim 4, wherein the at least one processor is configured to: receiving information indicating a third device from the first device; and Information indicative of a request for the traceability instruction is transmitted to the third device.

6. The apparatus of claim 1, wherein the at least one processor is configured to: receiving information indicating a third device from the first device; and Information indicative of a request for the traceability instruction is transmitted to the third device.

7. The apparatus of claim 1, wherein the at least one processor is configured to: The record is created using a trace configuration based on the trace instruction.

8. The apparatus of claim 7, wherein the at least one processor is configured to: presenting the tracing instruction to a user; receiving input from the user; and The traceability configuration is generated based on the traceability instruction and the input from the user.

9. The apparatus of claim 8, wherein the input indicates a recipient of the message.

10. The apparatus of claim 1, wherein the created record for the installed AI model comprises: 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 a fully trained AI model to the device.

11. A method performed by an apparatus, the method comprising: receiving, from at least one other device, an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating a traceability instruction based on a traceability standard of the AI ​​model requested by the device, wherein the traceability information corresponds to information for tracing one or more stages of an AI pipeline associated with the AI ​​model; Install the AI ​​model; Creating a record for the installed AI model; and A message is transmitted to a recording device, the message including information indicative of at least a portion of the created recording.

12. The method of claim 11, further comprising: Information indicating a request for an AI model is transmitted to at least one of the at least one other device, the request including the criteria.

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

14. The method of claim 11, further comprising: receiving, from a first device among the at least one other device, information indicating a second device; Receiving the AI ​​model includes: downloading the AI ​​model from the second device.

15. The method of claim 14, further comprising: receiving, from the first device, information indicating a third device; as well as Information indicative of a request for the traceability instruction is transmitted to the third device.

16. The method of claim 11, further comprising: receiving information indicating a third device from the first device; as well as Information indicative of a request for the traceability instruction is transmitted to the third device.

17. The method of claim 11, further comprising: The record is created using a trace configuration based on the trace instruction.

18. The method of claim 17, further comprising: presenting the tracing instruction to a user; receiving input from the user; as well as The traceability configuration is generated based on the traceability instruction and the input from the user.

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

20. The method of claim 11, wherein the created record for the installed AI model comprises: 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 a fully trained AI model to the device.

21. An apparatus comprising: at least one processor, the at least one processor being configured to: Receiving, from another device, an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating a traceback instruction for the AI ​​model, the traceback instruction corresponding to information for tracing back one or more stages of an AI pipeline associated with the AI ​​model; Installing the AI ​​model; and A message is transmitted to the other device, the message including information indicating installation of the AI ​​model on the device.

22. The device of claim 21, wherein the at least one processor is configured to transmit to the other device information indicating a request for an AI model and resources at the device that can be used to trace the AI ​​model on the device.

23. The apparatus of claim 21, wherein the at least one processor is configured to: presenting the tracing instruction to a user; receiving input from the user; and A traceability configuration is generated based on the traceability instruction and the input from the user.

24. The apparatus of claim 23, wherein the input indicates a recipient of the message.

25. A method performed by an apparatus, the method comprising: Receiving, from another device, an artificial intelligence (AI) model for installation on the device to perform an AI task, and information indicating a traceback instruction for the AI ​​model, the traceback instruction corresponding to information for tracing back one or more stages of an AI pipeline associated with the AI ​​model; Installing the AI ​​model; and A message is transmitted to the other device, the message including information indicating installation of the AI ​​model on the device.

26. The method of claim 25, further comprising: Information indicating a request for an AI model and a resource usable at the device to trace the AI ​​model on the device is transmitted to the other device.

27. The method of claim 25, further comprising: presenting the tracing instruction to a user; receiving input from the user; as well as A traceability configuration is generated based on the traceability instruction and the input from the user.

28. The method of claim 27, wherein the input indicates a recipient of the message.

Images