Method, architecture, device and system for implementing artificial intelligence application in network

Abstract

A process, method, architecture, apparatus, system, apparatus, and computer program product for implementing AI applications in a network. An apparatus that: receives a first request for a first registration from an artificial intelligence (AI) entity; creating a record for the AI entity, the record comprising information indicating the first registration; and transmitting a second request for a second registration of an AI client on the device and of at least one AI entity comprising the AI entity to another device.

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 artificial intelligence (AI) applications in networks. Summary of the Invention

[0002] In a first aspect, the present principles relate to an apparatus comprising at least one processor configured to: receive a first request for a first registration from an artificial intelligence (AI) entity; create a record for the AI ​​entity, the record comprising information indicative of the first registration; and transmit a second request for a second registration of an AI client on the apparatus and at least one AI entity including the AI ​​entity to another apparatus.

[0003] In a second aspect, the present principles relate to a method performed by a device, the method comprising: receiving a first request for a first registration from an artificial intelligence (AI) entity; creating a record for the AI ​​entity, the record comprising information indicative of the first registration; and transmitting a second request for a second registration of an AI client on the device and at least one AI entity including the AI ​​entity to another device. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding can 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:

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

[0006] Figure 1B It shows that you can Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0007] Figure 1C It shows that you can Figure 1A a system diagram illustrating an example radio access network (RAN) and an example core network (CN) for use within the illustrated communication system;

[0008] Figure 1D It shows that you can Figure 1A A system diagram of yet another example RAN and yet another example CN used within the illustrated communication system;

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

[0010] Figure 3 shows a general AI workflow for supervised learning;

[0011] Figure 4 The general federated learning (FL) process is shown;

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

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

[0014] Figure 7 shows an AI-enabled service architecture according to a first embodiment of the present principles;

[0015] Figure 8 shows an AI-enabled service architecture according to a second embodiment of the present principles;

[0016] Figure 9 A method for indirect AIAPP registration according to an embodiment is shown;

[0017] Figure 10 A method of direct AIAPP registration according to an embodiment of the present principles is shown;

[0018] Figure 11 A method of AIA registration according to an embodiment of the present principles is shown;

[0019] Figure 12 A method of AIA deployment according to an embodiment of the present principles is shown;

[0020] Figure 13 A method for AI task deployment according to an embodiment of the present principles is shown;

[0021] Figure 14 A method of AI task migration according to an embodiment of the present principles is shown;

[0022] Figure 15 A method of FL task migration according to an embodiment of the present principles is shown;

[0023] Figure 16 A method of AI model registration according to an embodiment of the present principles is shown; and

[0024] Figure 17 A method of AI model discovery and deployment according to an embodiment of the present principles is shown. DETAILED DESCRIPTION

[0025] 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 put into practice without some or all of the specific details set forth herein. In other cases, well-known methods, procedures, components and circuits are not described in detail to avoid making the following description vague. In addition, the embodiments and examples not specifically described herein can replace the embodiments and other examples that are explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein to practice or practice with their combination. Although various embodiments in which devices, 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 device, system, device etc. and / or any of its elements are configured to perform any operations, processes, algorithms, functions etc. and / or any part thereof.

[0026] Example Communication System

[0027] The methods, devices, and systems provided herein are well-suited for communications involving 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 may utilize, perform, be arranged according to, and / or be adapted and / or configured for the methods, devices, and systems provided herein.

[0028] Figure 1A 1 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.

[0029] like Figure 1AAs 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. However, 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 smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable 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 industrial and / or automated process chains), a consumer electronics 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.

[0030] 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, e.g., 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 master Node B (HNB), a master 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.

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

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

[0033] 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, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may 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).

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

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

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

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

[0038] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a master Node-B, a master eNode-B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, 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, base station 114b may be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0039] 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 calling, 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 NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

[0040] 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), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 114 or a different RAT.

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

[0042] 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 supply 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 subcombination of the foregoing elements while remaining consistent with an embodiment.

[0043] 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 transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together, such as in an electronic package or chip.

[0044] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over 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, the transmit / receive element 122 may be an emitter / 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 light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0046] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and 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 to enable the WTRU 102 to communicate via multiple RATs (e.g., such as NR and IEEE 802.11).

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

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

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

[0050] 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 video), 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 one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geo-location sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0051] The WTRU 102 may include a full-duplex radio in which some or all of the transmission and reception of 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., a 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 some or all of the transmission and reception of 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.

[0052] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to 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.

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

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

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

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

[0057] 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 and 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 downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

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

[0060] Even though 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 communication interface with a communication network.

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

[0062] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS or have an interface thereto. Traffic originating from outside the BSS destined for a STA may reach the AP and may be delivered to the STA. Traffic from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between a source STA and a destination STA using a direct link setup (DLS) (e.g., sent directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled 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.

[0063] When using 802.11ac infrastructure operation mode or a similar operation mode, 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 the 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 with 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.

[0064] High throughput (HT) STAs 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.

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

[0066] 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 used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a 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).

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

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

[0069] Figure 1D1 is a system diagram illustrating 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.

[0070] The RAN 113 may include gNBs 180a, 180b, and 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, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the WTRUs 102a, 102b, and 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, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located on unlicensed spectrum, while the remaining component carriers may be located on licensed spectrum. In an embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

[0072] 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 anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may serve as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

[0073] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, 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 user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0074] 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. While each of the aforementioned 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.

[0075] 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 WTRUs 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 WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro) and / or non-3GPP access technologies (such as Wi-Fi).

[0076] The SMFs 183a and 183b can connect to the AMFs 182a and 182b in the CN 115 via the N11 interface. The SMFs 183a and 183b can also connect to the UPFs 184a and 184b in the CN 115 via the N4 interface. The SMFs 183a and 183b can select and control the UPFs 184a and 184b and configure traffic routing through the UPFs 184a and 184b. The SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, and so on.

[0077] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, 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.

[0078] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. Additionally, 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 connect to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local data networks (DNs) 185a, 185b.

[0079] Given that Figures 1A to 1D and Figures 1A to 1D

[0045] As described above, one or more or all of the functions described herein with respect to any of the following may be performed by one or more simulation elements / devices (not shown): the WTRUs 102a-102d, base stations 114a-114b, eNode-Bs 160a-160c, MME 162, SGW 164, PGW 166, gNBs 180a-180c, AMFs 182a-182b, UPFs 184a-184b, SMFs 183a-183b, DNs 185a-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.

[0080] 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 coupled to another device for testing purposes and / or can use over-the-air wireless communication to perform testing.

[0081] One or more simulation devices can perform one or more (including all) functions when not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test lab and / or a wired and / or wireless communication network that is not deployed (e.g., testing) to enable testing of one or more components. One or more simulation devices can be test equipment. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas).

[0082] introduce

[0083] Blockchain technology

[0084] Blockchain technology leverages and builds upon existing technologies such as encryption, hashing, Merkle trees, distributed ledgers, peer-to-peer networking, and consensus protocols. Blockchain technology integrates these technologies into a single 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. A blockchain system is 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 engage in peer-to-peer networking to broadcast blockchain transactions and blocks among themselves. Blockchain nodes also execute consensus protocols to achieve distributed trust without relying on a centralized party. 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 action in an information system, digital payments, and / or digital smart contracts. A block groups multiple blockchain transactions. A blockchain is a data structure that links together an increasing number of blockchains. 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].

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

[0086] Step 1: Initiate a transaction. Each blockchain client or blockchain user independently generates a new transaction. Each blockchain user has a user or account identifier, typically 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.

[0087] Step 2: Broadcast and Verify the Transaction. A small number of blockchain nodes first receive the new transaction. These nodes use the user's public key included in the transaction to verify its integrity. If the new transaction's validity is successfully verified, it is relayed and broadcast within the blockchain network. Ultimately, all blockchain nodes will receive and possess a copy of any newly generated valid transaction.

[0088] Step 3: Construct 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 produce a new block. The new block consists of a block header and a block body. The block header typically includes the hash of the previously confirmed block and the hashes of all included transactions (e.g., a Merkle tree). Depending on the consensus protocol, the block header may contain additional information. The block body contains the contents of all included transactions. Each blockchain-building node independently attempts to create a new block.

[0089] Step 4: Validate the new block based on the consensus protocol. In step 3, the blockchain-building nodes independently attempt to create a new block. They run the same consensus protocol (e.g., proof-of-work in Bitcoin) and reach a consensus on who (the winner) is allowed to insert the block into the existing blockchain. The winner of the consensus protocol sends their newly generated block to the blockchain network. This new block is broadcast and received and validated by all blockchain-building nodes.

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

[0091] Introduction to AI

[0092] The AI ​​system includes one or more AI agents that learn and / or utilize AI models based on at least one AI solution (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 (AIHs). Each AI agent typically hosts and runs AI tasks, such as tasks that learn AI models based on AI algorithms (e.g., deep learning algorithms, federated learning algorithms, reinforcement learning algorithms), or tasks that use AI models to reason about knowledge. 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.

[0093] 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 referred to as "AI task deployment," while "AI model deployment" refers to the process of transferring and / or (re)installing an AI model onto an existing AI task. It should be noted that when an AI task is deployed on an AI agent, the terms "AI agent" and "AI task" are used interchangeably in this description.

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

[0095] Figure 3 The general AI workflow for supervised learning is shown. This workflow typically includes multiple stages: 1) task configuration, which includes deploying an AI agent / task by an AI application or user; 2) data preparation, which includes data collection and optional feature engineering / extraction; 3) training to learn the AI ​​model; 4) validation to test and verify the learned AI model; 5) model deployment, which is used to deploy and transfer the validated AI model; 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 from inference (e.g., outcomes) can be used to take action or trigger a return to training to retrain the AI ​​model.

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

[0097] Deep Learning

[0098] Deep learning (DL) is a specialized supervised machine learning (ML) that uses deep neural networks (DNNs), which 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 a DNN involves repeated feedforward and backpropagation.

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

[0100] Backpropagation: The generated output is used to calculate the loss based on 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 neurons in the DNN. Deep learning systems can be deployed as a single AI agent (i.e., AIA4LI) or multiple separate AI agents (e.g., one AIA4L and multiple AIA4Is).

[0101] DNNs can provide excellent methods for learning or approximating nonlinear functions that map inputs to outputs. However, the data items used to train DNNs should have little or no correlation 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.

[0102] Federated Learning

[0103] 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 the 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 because the training data remains at the FLCs; 2) reduced communication overhead because the training data does not need to be collected / transmitted to a 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 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. Furthermore, 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 inference (i.e., AIA4LI). It should be noted that both FLS and FLC are AIHs.

[0104] Figure 4The 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.

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

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

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

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

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

[0110] 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 can start aggregation after receiving local model updates from a subset of participating FLCs.

[0111] 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, for example, retaining one or more FLCs in the previous set.

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

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

[0114] AI-related 3GPP standards

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

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

[0117] TR 23.700-80 has a number of main 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 the AF and UE so that the AF and UE manage FL operations and model distribution / redistribution (such as FL member selection) to facilitate collaborative application AI based on federated learning operations between application clients running on the UE (i.e., FLC) and application servers (i.e., FLS).

[0118] 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 the 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 security aspects.

[0119] ETSI SAI

[0120] ETSI GR SAI 0010 [ETSI GR SAI 0010 V0.0.1 (2022-01); Securing Artificial Intelligence (SAI); Traceability of AI Models] aims to examine the role of AI traceability in securing AI and explore potential issues related to sharing and reusing models across different tasks or various industry-related applications. The scope of AI traceability includes, but is not limited to, identifying potential threats and their associated remediation measures. Further AI traceability can improve the decisions to which AI traceability applies, protect the ownership of AI creators, and protect the provenance of model verification, ensuring model integrity, or discovering its purpose.

[0121] Wireless AI Use Cases

[0122] 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 important to provide traceability for deployed AI tasks and AI models. This requires tracking AI tasks and AI models throughout their lifecycle, which can serve as the foundation for building auditable, explainable, and trustworthy AI.

[0123] Figure 5 Two examples of DL applications for wireless networks are shown, where the UE hosts a DL agent that hosts AI tasks. The AI ​​tasks use DL models, learned DL models, or both. The DL agent at each UE is pre-installed or deployed at runtime. 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.

[0124] DL is used 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 the radio resource allocation strategy. 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 the wireless channel more quickly and accurately, and in turn lead to improved radio resource utilization.

[0125] 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 equipped with a DL agent (i.e., DLA4LI), for example, to learn social relationships and content popularity.

[0126] Figure 6 This paper shows an example of a FL application for a wireless network, 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 the edge server are AIHs.

[0127] 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 the UE to generate global model updates. The global model update is sent to the UE 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.

[0128] 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 engages in both. To deploy a specific AI solution for a wireless network, you first need to install an AI agent (e.g., a piece of 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 typically tests and validates the AI ​​model based on test data and validation data before deploying the AI ​​model (e.g., transferring the AI ​​model from one AI agent to another). Finally, the deployed or transferred AI model can be used to infer and predict future knowledge from real data and take action.

[0129] It is envisioned that future wireless systems will have native AI capabilities. In other words, AI agents / tasks / models will become an integral part of future wireless systems, for example, deployed as services at different network nodes to support various applications as shown in the Wireless AI use case. At the same time, the Wireless AI use case also demonstrates the following characteristics of native AI in future wireless systems: 1) There are different types of AI agents / tasks / models; 2) There are decentralized AI agents / tasks / models in the UE; 3) The wireless applications that support AI are diverse; 4) AI agents / tasks / models may be able to support multiple wireless applications; 5) Wireless applications may need to use multiple applications; and 6) Wireless applications may need different AI agents / tasks / models at different times and / or in different situations (e.g., locations).

[0130] In order to efficiently coordinate between wireless applications and AI agents / tasks / models, a standardized AI enabling layer may be required to take these characteristics into account, especially in wireless AI use cases. As a result, the interaction between wireless applications and AI agents / tasks / models may be more efficient. For example, wireless applications can rely on this AI enabling layer to easily find suitable AI models. This AI enabling layer is intended to provide some common functions and services for both wireless applications and AI agents / tasks / models. On the one hand, wireless applications use these services to access AI agents / tasks / models, and on the other hand, AI agents / tasks / models can expose themselves to the AI ​​enabling layer and be managed by it. However, there is no such standardized AI enabling layer in 3GPP.

[0131] Therefore, an AI enabling layer that considers unique characteristics in wireless AI use cases can provide common services, for example, in the following cases.

[0132] AI application management Before an AI application (AIAPP) can use the common services provided by the AI ​​enabling layer, it must register the AIAPP with the AI ​​enabling layer and be authenticated. Different registration procedures may be required depending on whether the AIAPP is hosted by the UE or is just a network application.

[0133] AI Agent Management :The AI ​​agent (AIA) relies on the AI ​​enabling layer so that the AI ​​agent can be accessed and interact with other AIAs and / or AIAPPs. The AIAs can be deployed by the AI ​​enabling layer. Alternatively, existing AIAs can be registered with the AI ​​enabling layer and managed by it.

[0134] AI Task Management The AI ​​enablement layer can coordinate the deployment of AI tasks to AIAs by matching the AI ​​requirements of the AI ​​tasks with the AI ​​capabilities of the AIAs. AI enablement can also facilitate the migration of deployed AI tasks from one AIA to another.

[0135] AI model management The AI ​​enablement layer also needs to manage AI models. To enable efficient AI model sharing and transfer between different entities (e.g., AIAPP, AIA), the AI ​​enablement layer can maintain an AI model repository to record all available AI models. The AI ​​enablement layer can also use the AI ​​model repository to provide services for AI model discovery and deployment.

[0136] This principle provides two AI-enabled service architectures, which include two new entities: AI-enabled Client (AIEC) and AI-enabled Server (AIES). In general, AIEC registers with AIES and uses the services provided by AIES. The proposed AI-enabled service architecture can provide the following. The following key points are proposed:

[0137] For AI application management, AI applications (AIAPPs) on the UE can register with the AIES indirectly via the local AIEC. AIAPPs can also register directly with the local AIEC. The AIES and / or local AIEC create an AIAPP record for each registered AIAPP and store the record in the AIAPP repository. AIAPPs in the network register directly with the AIES.

[0138] For AI agent management, an AI agent (AIA) can register its AI capabilities and AI tasks indirectly with the AIES via the local AIEC. AIAs can also register with the local AIEC. The AIES and / or local AIEC create an AIA record for each registered AIA and store the record in the AIA repository. The AIES exposes the AIA repository to other entities to discover any suitable AIAs.

[0139] For AI task management, AIES facilitates the AIAPP (and / or other entities) to deploy AI tasks to the appropriate AIA. AIES may help find the appropriate AIA from its AIA repository. In order to deploy the AI ​​task to the AIA, AIES also finds the corresponding AIEC that interacts with AIES on behalf of the AIA. Finally, AIES sends the AI ​​task to the AIA via the corresponding AIEC. AIES can find a new AIEC and a new AIA to migrate the AI ​​task from the previous AIEC / AIA to the new AIEC / AIIA. AIES maintains an AI task repository to record each deployed AI task.

[0140] For AI model management, after an AIA trains an AI model, it can register the AI ​​model with AIES via its AIEC. The AIEC can specify some model usage constraints on the AI ​​model on behalf of the AIA. AIES maintains an AI model repository to store all registered AI models, which can then be discovered and deployed to other entities (such as AIs that use AI models to reason about knowledge).

[0141] The following terms are defined below:

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

[0143] -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 some relevant information (e.g., an initial AI model, training data, and / or input data).

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

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

[0146] AI workflow: A set of stages used to perform one or more AI tasks toward a goal. An AI workflow can consist of the following stages: a task configuration stage, a data preparation stage, a training stage for learning an AI model, a validation stage for testing and validating the learned AI model, a model deployment stage for deploying and transferring the validated AI model, and an inference stage for inferring and predicting future knowledge using new data as input.

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

[0148] -AI Application (AIAPP): An application entity that utilizes AI functions provided by an AI-enabled server and / or AI agent.

[0149] AI Enablement Server (AIES): An entity that coordinates interactions between AI applications and AI hosts (including AI agents). AIES provides services to AI applications. AIES interacts with and manages AI agents via one or more AI Enablement Clients.

[0150] -AI Enablement Client (AIEC): An entity that interacts with AIES on behalf of an AI agent. The AIEC can reside in a separate AI host or co-located with the AI ​​agent in the same AI host.

[0151] In this document, an identifier or address of an entity may refer to, but is not limited to, one or more of the following information items:

[0152] - The endpoint of the entity used for communication (e.g., URI, FQDN, IP address, etc.)

[0153] - Transport information of the entity, such as protocol type (e.g., REST / HTTP, CoAP, Topic-based, Pub Sub, RPC, WebSocket, etc.), security-related information (e.g., security credentials, certificates, public keys, etc.), version, etc.

[0154] -The entity’s blockchain address (e.g., a hash of its public key).

[0155] AI-enabled service architecture

[0156] Basic AI-enabled service architecture

[0157] Figure 7 The AI-enabled service architecture according to the first embodiment of the present principles is shown, and the AI-enabled service architecture mainly includes an AI enabling layer. The architecture contains a set of logical entities, including AI-enabled servers (AIES), AI-enabled clients (AIEC), distributed storage systems (DSS), AI applications (AIAPPs), and AI agents (AIA). It should be noted that the AI ​​agent can be an AI learning agent (AIA4L) hosted by AIMP and / or an AI reasoning agent (AIA4I) hosted by AIMU. In addition, the AI ​​host (AIH) can be an AI model producer (AIMP) such as a UE with AIA4L and / or an AI model user (AIMU) such as a UE with AIA4I. In this architecture, AIES and AIEC essentially form an AI enabling layer, which provides AI management and services to AIAPP and AIA.

[0158] AI Enabled Server (AIES) AIES can maintain six repositories: an AI task repository, an AI model repository, an AIA repository, an AIH repository, an AIFC repository, an AlAPP repository, and a knowledge repository. These repositories can be accessed by AIECs and / or AIAPPs in the edge, core, or cloud. AIAPPs on UEs can also access these repositories indirectly via AIECs on the same UE. An AIES can connect to another AIES to exchange any information stored in its repositories.

[0159] The AI ​​task repository stores AI tasks that have been deployed and / or will be deployed to the AIH. For example, an AI app in the edge / core / cloud can discover AI tasks from the AI ​​task repository and trigger the AIES to install the discovered AI tasks to the AIA at the UE.

[0160] The AI ​​model repository stores AI models that have been generated, deployed, and / or will be deployed to the AIH. For example, the AIAPP at UE-3 (or the AIAPP in the edge / core / cloud) can discover AI models from the AI ​​model repository and trigger the AIES to install the discovered AI tasks to the AIA at UE-3. In addition, when the AIA at UE-1 generates a new AI model, it can submit and register the new AI model to the AI ​​model repository.

[0161] The AIA repository stores a list of AIAs that have registered with AIES. An AIA needs to be registered with AIES before AI tasks and / or AI models can be installed on it, or before the AIA can register a new AI model with AIES.

[0162] The AIH repository stores a list of AIHs. When an AIEC (or AIA, AIAPP) registers with AIES, the corresponding AIH hosting the AIEC (or AIA, AIAPP) will also register with AIES. Therefore, AIES maintains all registered AIHs.

[0163] The AIEC repository stores a list of AIECs that have registered with AIES. The AIEC at the UE registers with AIES so that it can use the services provided by AIES. After the AIEC registers with AIES, AIES creates a new AIEC registration record in the AIEC repository.

[0164] The AIAPP repository stores a list of AIAPPs that have been registered with AIES. AIAPPs must first register with AIES before they can utilize the services provided by AIES. For example, an AIAPP in the edge / core / cloud must first register with AIES before requesting AIES to install AI tasks on AIA.

[0165] The knowledge base stores the knowledge inferred and reported by AIA. When an AIA (especially AIA4I) infers or derives some knowledge from an AI model, it can submit the knowledge to AIES, which stores the knowledge in the knowledge base and makes it accessible to other AIAs and / or AIAPPs.

[0166] AI Enabled Client (AIEC): AIEC provides services to AIAs and AIAPPs to facilitate their interaction with AIES. AIEC is an intermediary or agent between AIAs and AIES, and between AIAPPs and AIES. For example, when the AIA at UE-1 needs to register a new AI model with AIES, it sends the new AI model to AIEC, which then forwards the AI ​​model to AIES. In another example, when the AIAPP at UE-4 requests AIES to install an AI task on the AIA at UE-1, the AIAPP sends such a request to the AIEC at UE-4, which then forwards the request to AIES. AIES receives the request and finds a suitable AI task. AIES sends the AI ​​task, including its software code, to the AIEC at UE-1, which passes the AI ​​task to the AIA at UE-1. Each UE will have at least one AIEC, which can support one or more AIAs and / or AIAPPs at the same UE. AIECs at different UEs can communicate with each other to enable more direct and efficient AI-related interactions between two UEs (e.g., direct model and / or knowledge transfer from one UE to another).

[0167] AI Agent (AIA) :AIA runs AI tasks to generate AI models and / or infer some knowledge based on AI models. AIA is hosted by UE. Alternatively, AIA can be hosted in edge / core / cloud. The AIA at the UE directly interfaces with the local AIEC, which facilitates the interaction of AIA with other entities in the edge / core / cloud and / or other UEs. Taking UE-3 as an example, the AIAPP at UE-3 can directly instruct the local AIA (for example, feed training data to AIA, stop or resume tracking AIA, stop or resume AI learning or reasoning process at AIA, retrieve inferred knowledge from AIA).

[0168] AI Application (AIAPP) :AIAPP may exist in the edge / core / cloud or at the UE. The AIAPP in the edge / core / cloud interacts directly with the AIES, for example, requesting to install AI tasks to the AIA, requesting to install AI models to the AIA, requesting to retrieve AI models from the AIA, requesting to retrieve reasoned knowledge from the AIA, etc. The AIAPP in the edge / core / cloud can also directly access the repository maintained at the AIES. The AIAPP at the UE can make similar requests to the AIES, but those requests are processed by the local AIEC at the same UE and forwarded to the AIES. The AIAPP at the UE can interact directly with the local AIA at the same UE (e.g., UE-3).

[0169] Blockchain-based AI-enabled service architecture

[0170] Figure 8 An AI-enabled service architecture according to a second embodiment of the present principles is shown. In this architecture, seven repositories are maintained within a DSS (e.g., a distributed ledger). Each record in a repository can be created by an AIES and / or by an AIEC. An AIES can simply publish information about itself, any AIEC, any AIA, any AIAPP, any AI task, any generated model, and / or any generated knowledge to the DSS. This publishing process can be completely transparent to the AIEC, and in this case, the AIEC does not interact with the AIES.

[0171] As an alternative, AIES can also enable AIECs to interact directly with DSSs. AIES can first configure each AIEC with the address of the DSS and any access-related information (for example, the addresses of one or more distributed ledger nodes, distributed ledger protocol specifications (such as how to join a distributed ledger system and how to create and send transactions to a distributed ledger system), such as prompt selection policies in IoTA systems). Once the AIEC receives such DSS information, the AIEC can directly publish any information about itself, the AIA, the AI ​​tasks hosted by the AIA, the AIAPP, any generated models, and / or any generated knowledge to the DSS. The AIEC can also directly find and search for information about other AIECs from the DSS and those repositories. After the AIEC discovers such information, the AIEC can forward the discovered information to AIES.

[0172] AIAPP Management

[0173] Indirect AI APP registration

[0174] The AIAPP on the UE can register with the AIES indirectly via the AIEC on the same UE (or different UE).

[0175] Figure 9 A method of indirect AI APP registration according to an embodiment is shown.

[0176] In step S902, the AI ​​application (AIAPP) 901 sends a registration request to the AI ​​enabling client (AIEC) 903. The AIAPP registration request may include:

[0177] -AIAPP-Type: The type or purpose of the AIAPP (e.g., discovering and / or deploying AI tasks, discovering and / or deploying AI models, discovering any inferred knowledge, etc.).

[0178] -AIAPP-ID: identifier and / or address of the AIAPP.

[0179] -UE-ID: The identifier and / or address of the UE hosting the AI ​​APP.

[0180] -AI-Task-List: A list of AI tasks that the AIAPP hopes to deploy to certain AIs in the future, including their task identifiers (i.e., AI-Task-ID) and their task types (i.e., AI-Task-Type).

[0181] -AIAPP-Registration-Type: Indicator of whether the request is for local registration with AIEC or remote registration with AIES.

[0182] -AIES-ID: The identifier or address of the AIES used for remote registration. Note that the AIES-ID is optional even for remote registration. In many cases, the AIAPP and AIEC are hosted at the same UE.

[0183] It should be noted that AI-Task-Type can indicate whether the corresponding task is used to train a model, reason about knowledge, or both. AI-Task-Type can also indicate whether the corresponding AI task is a DL task, FL task, RL task, or other type. AI-Task-Type can also indicate the purpose of the corresponding AI task (for example, regression, classification, clustering, etc.). AI-Task-Type can also indicate the application category of the corresponding AI task (for example, natural language processing, text processing, image processing, video processing, etc.).

[0184] The AIAPP registration request is received by the AIEC 903. The AIEC 903 then authenticates the registration request, particularly when the registration request comes from another UE and contains the identifier of the UE (ie, UE-ID).

[0185] It should be noted that, for example, a list of allowable UEs may have been provided to AIEC 903 by AIES 905. AIEC 903 then simply checks whether the UE-ID included in the AIAPP Registration Request is on the list. If it is, authentication is successful, and therefore, AIEC 903 can assign a unique identifier to AIAPP 901, referred to as AIAPP-ID.

[0186] If AIEC 903 cannot authenticate AIAPP by itself, it can pass the UE-ID and / or other parameters received from AIAPP 901 in step S902 to AIES 905 using the Register AIEC message (see step S908 ), which will help AIES 905 authenticate AIAPP 901 .

[0187] In step S904, AIEC 903 may create a local AIAPP record for the registered AIAPP 901, particularly when the AIAPP requested local registration in the request in step S902. The local AIAPP record may include AIAPP-Type, AIAPP-ID, UE-ID, registration time, and / or other parameters received in the request.

[0188] In step S906, AIEC 903 may send a response to AIAPP 901, especially when AIAPP 901 requests local registration with AIEC 903. This response message may include AIAPP-ID.

[0189] Alternatively, the response may be sent to the AIAPP 901 as a quick confirmation of receipt of the request message, for example, without including the AIAPP-ID. In this case, the AIAPP-ID will be included in a later notification sent to the AIAPP 901 (see step S916).

[0190] However, in the event that the response includes an AIAPP-ID, the notification in step S916 may be omitted; in fact, the entire step may then be skipped.

[0191] In step S908, AIEC 903 sends a request to AIES 905 to register itself and one or more AIAPPs. It is assumed that AIEC 903 is hosted by the UE (i.e., AIH). It is also assumed that AIEC 903 has been provided with or has discovered the address of AIES 905. It should be noted that AIEC 903 can also receive the AIES 905 address from the request in step S902. The registration request may include:

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

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

[0194] -AIH-AI-Capability: The capabilities and affordable resources that the AIH can allocate for hosting AI agents / tasks. This parameter may indicate, but is not limited to: 1) the computing resource budget for running AI tasks; 2) the storage resource budget for running AI tasks; 3) training data attributes, such as the number of data samples and the number of features in the data samples; and 4) input data attributes (for knowledge reasoning), such as the number of data samples and the number of features in the data samples. In the case where the AIH has hosted an AI task, AI-Capability may indicate additional information about the AI ​​task, including but not limited to: 1) a unique identifier for the hosted AI task (AI-Task-ID); 2) the type of the hosted AI task (AI-Task-Type); and 3) the address of the AI ​​model used to access / manage the AI ​​task.

[0195] -AIEC-ID: Address or temporary identifier of the AIEC.

[0196] -Requested-Service-List: Indicates the list of services that AIEC wants to request (e.g., a service for accessing an AI task repository, a service for accessing an AI model repository, a service for discovering AIA via AIES, a service for tracking AI tasks and / or AI models via AIES, etc.).

[0197] -AIAPP-List: A list of AIAPPs and their UE-IDs that have been sent to the AIEC via the AIAPP registration request (e.g., as in step S902). Each item in the AIAPP-List may also include parameters received in the request in step S902. Alternatively, each item in the AIAPP list may correspond to an AIAPP record created in step S904. Each item in the AIAPP-List may include an AIAPP registration flag (AIAPP-Registration-Flag) to indicate whether the corresponding AIAPP needs to be registered with AIES and / or whether AIEC needs AIES to authenticate the AIAPP; for example, if AIAPP-Registration-Flag is true, the corresponding AIAPP should be registered with AIES and / or AIES should authenticate the AIAPP. The AIAPP-Registration-Flag can be derived from the AIAPP-Registration-Type in the request in step S902.

[0198] In the case where the AIAPP 901 requests local registration with the AIEC 903 , the AIEC 903 may still include the AIAPP 901 in the request to simply report the AIAPP 901 to the AIES 905 .

[0199] In step S910, AIES 905 receives a registration request from AIEC 903. It authenticates AIEC 903 and, for example, approves the services assigned to the AIEC based on preconfigured policies. AIES 905 may approve one or more services, as requested in the Requested-Service-List. All approved services are included in the Approved-Service-List. AIES 905 may (re)assign a unique identifier, referred to as an AIEC-ID, to AIEC 903. AIES 905 may create a new AIEC record for the registered AIEC 903. This AIEC record may include the AIEC-ID, the Approved-Service-List, and / or other parameters received in the request in step S908. This new AIEC record is added to the AIEC repository. If an AIH-ID is received in the request, AIES 905 may create a new AIH record. This AIH record includes the AIH-ID, AIH-Type, and AIH-AI-Capability included in the request in step S908. This new AIH record is stored in the AIH repository.

[0200] In the event that the AIAPP-List is received in step S908, and in particular when the AIEC 903 requires the AIES 905 to authenticate one or more AIAPPs 901 (e.g., the AIAPP-Registration-Flag is true), if the AIAPPs 901 are hosted at different UEs, the AIES 905 may, for example, authenticate each AIAPP 901 and its UE-ID based on a pre-configured policy. The policy may specify that a UE-ID cannot host more than a certain number of AIAPPs. If the authentication is successful (i.e., positive authentication), the AIES 905 may (re)assign an AIAPP-ID to each AIAPP 901. Then, in step S912, the AIES 905 may create a new AIAPP record for each authenticated AIAPP 901, which may include the AIAPP-ID and / or other parameters related to the AIAPP included in the AIAPP list. The new AIAPP record will be added to the AIAPP repository.

[0201] In step S914, AIES 905 sends a response message to AIEC 903. The response message may include:

[0202] -AIEC-ID: allocated in step S910.

[0203] -Approved-Service-List: determined in step S910.

[0204] -Approved-AIAPP-List: List of AIAPs approved in step S912.

[0205] AIEC 903 receives the response message from AIES 905. AIEC 903 extracts the Approved-AIAPP-List to determine which AIAPPs 901 have been approved. AIEC 903 then creates (e.g., generates) a new notification message for each approved AIAPP 901 whose AIAPP-ID is included in the Approved-AIAPP-List. In step S916, AIEC 903 sends a new notification to each approved AIAPP 901.

[0206] Implementation Figure 9 The options of the method shown are: 1) using steps S902 to S906 to register AIAPP 901 with AIEC 903; 2) using steps S902 to S904 and S908 to S916 to register AIAPP 901 with AIEC 903 and / or AIES 905; 3) using steps S908, S910 and S914 to register AIEC 903 with AIES 905; and 4) using steps S908 to S914 to register AIEC 903 and its AIAPP 901 with AIES 905.

[0207] Direct AIAPP registration

[0208] AIAPP can register directly with AIES without registering in Figure 9 AIEC is involved as in.

[0209] Figure 10 A method of direct AIAPP registration according to an embodiment of the present principles is shown.

[0210] In step S1002, the AI ​​application (AIAPP) 1001 sends a registration request to the AIES 1003. The AIAPP registration request may include, for example:

[0211] -AIAPP-Type: The type or purpose of the AIAPP (e.g., discovering and / or deploying AI tasks, discovering and / or deploying AI models, discovering any inferred knowledge, etc.).

[0212] -AIAPP-ID: identifier and / or address of the AIAPP.

[0213] -UE-ID: The identifier and / or address of the UE hosting the AI ​​APP.

[0214] -AI-Task-List: A list of AI tasks that the AIAPP hopes to deploy to certain AIs in the future, including their task identifiers (i.e., AI-Task-ID) and their task types (i.e., AI-Task-Type).

[0215] In step S1004, if the AIAPP is hosted at a different UE, the AIES 1003 may authenticate the AIAPP 1001 and its UE-ID, for example, based on some pre-configured policies. The policy may specify that a UE-ID cannot host more than a certain number of AIAPPs. If the authentication is successful, the AIES may (re)assign an AIAPP-ID to the AIAPP 1001. It may then create a new AIAPP record for the authenticated AIAPP, which may consist of the AIAPP-ID and / or other parameters contained in the AIAPP list and related to the AIAPP. The new AIAPP record will be added to the AIAPP repository.

[0216] In step S1006, AIES 1003 sends a response message to AIAPP 1001. The response message may include:

[0217] - AIAPP-ID as allocated in step S1004.

[0218] - Approved-Service-List as determined in step S1004.

[0219] AI Agent Management

[0220] AI Agent Registration

[0221] The AIA may need to register with the AIEC and / or AIES, regardless of whether the AIA and AIEC are co-located in the same UE or other node. In many cases, the AIA and AIEC are hosted at the same UE.

[0222] Figure 11 A method of AIA registration according to an embodiment of the present principles is shown.

[0223] In step S1102, AIA 1101 sends a registration request to AIEC 1103 for registration. The registration request may include:

[0224] -AIA-Type: The type of AIA (ie, AIA4L, AIA4I, or AIA4LI).

[0225] -AIA-AI-Capability: The AI ​​capabilities of the AIA. This may indicate, but is not limited to: 1) the computing resource budget for the AIA; 2) the storage resource budget for the AIA; 3) training data attributes, such as the number of data samples and the number of features in the data samples; and 4) input data attributes (for knowledge reasoning), such as the number of data samples and the number of features in the data samples. In the case where the AIH has hosted an AI task, AI-Capability may indicate additional information, including but not limited to: 1) a unique identifier for the hosted AI task (AI-Task-ID); 2) the type of the hosted AI task (AI-Task-Type); and 3) the address of the AI ​​model used to access / manage the AI ​​task.

[0226] -AIA-Registration-Type: Indicates whether the registration request is for local registration with AIEC or remote registration with AIES.

[0227] -UE-ID: Identifier of the UE hosting AIA.

[0228] -AIES-ID: The identifier or address of the AIES used for remote registration. Note that the AIES-ID is optional even for remote registration.

[0229] The AIA registration request is received by the AIEC 1103. The AIEC 1103 authenticates the registration request, particularly when the registration request comes from another UE and includes the identifier of the UE (ie, UE-ID).

[0230] For example, a list of allowable UEs may have been provided to AIEC 1103 by AIES 1105. AIEC 1103 may then check whether the UE-ID included in the registration request is on the list of allowable UEs. If the UE-ID is on the list, authentication is successful.

[0231] In the case of authenticating the registration request, AIEC 1103 may assign a unique identifier, called AIA-ID, to AIA 1101. In the case that AIEC 1103 is unable to authenticate AIA 1101 itself, AIEC 1103 may pass the UE-ID and / or other received information to AIES 1105 in the registration message (see step S1108), which will help AIES 1105 authenticate AIA 1101.

[0232] In step S1104, AIEC 1103 may create a local AIA record for the registered AIA 1101, particularly when AIA 1101 requests local registration. The local AIA record may include AIA-ID, UE-ID, registration time, and / or other information received in the AIA registration request.

[0233] In step S1106, AIEC 1103 may send a response message to AIA 1101, especially when AIA 1101 requests local registration with AIEC. The response message may include AIA-ID; in this case, step S1116 may be skipped.

[0234] Alternatively, the response message may be sent as a simple acknowledgement of receipt of the AIA registration request. In this case, the information mentioned in the response message may be omitted, and the AIA-ID may be sent to the AIA 1101 in a later step (see step S1116).

[0235] In step S1108, AIEC 1103 sends an AIEC Registration Request to AIES 1105 to register itself and one or more AIAs 1101. It is assumed that AIEC 1103 is hosted by the UE (i.e., the AIH). It is also assumed that AIEC 1103 has already provided or discovered the address of AIES 1105. It should be noted that AIEC 1103 may also receive the AIES address in the AIA Registration Request message received in step S1102.

[0236] The AIEC registration request message sent to AIES 1105 may include:

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

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

[0239] -AIH-AI-Capability: The AI ​​capabilities of the AIH hosting the AIEC 1103. This may indicate, but is not limited to: 1) the computing resource budget for the AIH; 2) the storage resource budget for the AIH; 3) training data attributes, such as the number of data samples and the number of features in the data samples; and 4) input data attributes (for knowledge inference), such as the number of data samples and the number of features in the data samples.

[0240] -AIA-AI-Capability: The AI ​​capabilities of the AIA 1101. This may indicate, but is not limited to: 1) the computational resource budget for the AIA; 2) the storage resource budget for the AIA; 3) training data attributes, such as the number of data samples and the number of features in the data samples; and 4) input data attributes (for knowledge inference), such as the number of data samples and the number of features in the data samples. If the AIA 1101 has hosted an AI task, AI-Capability may indicate additional information, including, but not limited to: 1) a unique identifier for the hosted AI task (AI-Task-ID); 2) the type of the hosted AI task (AI-Task-Type); and 3) the address of the AI ​​model used to access / manage the AI ​​task.

[0241] - AIEC-ID: AIEC 1103 address or temporary identifier.

[0242] -Requested-Service-List: A list of services that AIEC 1103 wants to request (e.g., a service for accessing an AI task repository, a service for accessing an AI model repository, a service for discovering AIA via AIES 1105 , a service for tracking AI tasks and / or AI models via AIES, etc.).

[0243] -AIA-List: A list of AIAs 1101 that have sent AIA registration requests to AIEC 1103, their UE-IDs, and AIA-AI-Capabilities (e.g., in step S1102). AIA-AI-Capabilities are as defined above. Each item in the AIA-List may also include information received in the AIA registration message. Each item in the AIA-List may include an AIA registration flag (AIA-Registration-Flag) to indicate whether the corresponding AIA 1101 needs to be registered with AIES 1105 and / or whether AIEC 1103 needs AIES 1105 to authenticate the AIA 1101. For example, if AIA-Registration-Flag is true, the corresponding AIA 1101 should be registered with AIES 1105 and / or AIES 1105 should authenticate the AIA 1101. The AIA-Registration-Flag can be derived from the AIA-Registration-Type received in the AIA registration message.

[0244] - Information about the local data hosted by the corresponding UE. This information may be useful when the AIES 1105 needs to select an appropriate AIEC 1103 for a specific AI task. For example, one case is when the AI ​​task is a federated learning (FL) task, and the UE may be selected by the AIES 1105 as a potential FL client for local training using its local data.

[0245] Even in the case where the AIA 1101 requests local registration with the AIEC 1103 in its AIA Registration message, the AIEC 1103 may include the AIA 1101 in the AIEC Registration message to simply report the AIA 1101 to the AIES 1105 .

[0246] AIES 1105 receives the AIEC Registration Request message. It authenticates AIEC 1103 and, for example, approves the services assigned to AIEC 1103 based on preconfigured policies. AIES 1105 may approve one or more services as requested in the Requested-Service-List. All approved services are included in the Approved-Service-List. AIES 1105 may (re)assign a unique identifier, called an AIEC-ID, to AIEC 1103.

[0247] In step S1110, AIES 1105 may create a new AIEC record for the registered AIEC 1103. The AIEC record may consist of the AIEC-ID, Approved-Service-ID, and / or other information received in the AIEC Registration Request message. The new AIEC record will be added to the AIEC repository. If the AIH-ID is included in the AIEC Registration Request message, the AIES may also create a new AIH record. The new AI record includes the AIH-ID, AIH-Type, and AIH-AI-Capability as received in the AIEC Registration Request message, and the new AIH record is stored in the AIH repository.

[0248] When the AIA-List is included in the AIEC Registration Request message, and in particular when the AIEC 1103 requires the AIES 1105 to authenticate one or more AIAs 1101, if the AIAs 1101 are hosted at different UEs, the AIES 1105 may authenticate each AIA 1101 and its UE-ID, for example, based on a pre-configured policy. The policy may, for example, specify that a UE-ID cannot host an AIA4L-type proxy, or that a UE-ID cannot host more than a certain number of proxies. If authentication succeeds, the AIES 1105 may (re)assign an AIA-ID to each AIA 1101. In step S1112, the AIES 1105 may create a new AIA record for each authenticated AIA 1101. The AIA record may include the AIA-ID and / or other information related to the AIA 1101 included in the AIA List. The new AIA record will be added to the AIA repository.

[0249] In step S1114, AIES 1105 sends a response to the AIEC registration request message to AIEC 1103. The response message may include:

[0250] - AIEC-ID assigned in step S1110.

[0251] -Approved-AIA-List: The list of approved AIAs from step S1112.

[0252] - Approved-Service-List determined in step S1110.

[0253] AIEC 1103 receives the response message and extracts AIA-List to know which AIA 1101 has been approved. In step S1116, AIEC 1103 generates (creates, writes) a new notification message including its identifier AIA-ID for each approved AIA 1101 and sends the new notification to each approved AIA 1101.

[0254] Figure 11 The method shown can be implemented in different ways, for example, 1) using steps S1102 to S1106 to register the AIA with the AIEC; 2) using steps S1102 to S1104 and steps S1108 to S1116 to register the AIA with the AIEC and / or AIES; 3) using steps S1108, S1110 and S1114 to register the AIEC with the AIES; and 4) using S1108 to S1114 to register the AIEC and its AIA with the AIES.

[0255] AI Agent Deployment

[0256] In some cases, an AIH (eg, UE) may initially be equipped with only an AIEC, and different AI tasks may need to be performed by different types of AIAs. Therefore, the AIA may be dynamically deployed or configured, or installed on the AIH.

[0257] Figure 12 A method of AIA deployment according to an embodiment of the present principles is shown.

[0258] AIAPP 1205 intends to run AI Task-1, which requires a specific type of AIA. However, after communicating with AIES 1203, AIAPP 1205 discovers that there is no AIA available to run AI Task-1. Therefore, AIAPP 1205 determines to dynamically install the AIA on the selected AIH.

[0259] In step S1202, AIAPP 1205 sends an AIA deployment request to AIES 1203. In this request, AIAPP 1205 can directly indicate the AIH where the desired AIA should be installed by indicating the AIH-ID, or indicate AIH selection criteria (e.g., the location of the AIH / UE, the AIH-AI-Capability that the AIH / UE should have), and rely on AIES 1203 to find a qualified AIH. In addition, AIAPP 1205 can specify AIA requirements, such as: 1) AIA-Type: the type of AIA to be installed (i.e., AIA4L, AIA4I, or AIA4LI); 2) AIA-AI-Capability: the capabilities or performance that the desired AIA to be installed must meet; 3) AIA-Software-Handling: the AIA installation software to be prepared / provided by AIES 1203, to be downloaded, or the AIA installation software itself; etc. The AIA deployment request may also include:

[0260] -AIAPP-Type: The type or purpose of the AIAPP 1205 (eg, discovering and / or deploying AI tasks, discovering and / or deploying AI models, discovering any inferred knowledge, etc.).

[0261] -AIAPP-ID: identifier and / or address of AIAPP 1205 .

[0262] -UE-ID: The identifier and / or address of the UE hosting the AIAPP 1205.

[0263] -AI-Task-List: A list of AI tasks that the AIAPP 1205 hopes to deploy to the AI ​​in the future, including its task identifier (ie, AI-Task-ID) and its task type (ie, AI-Task-Type).

[0264] AIES 1203 receives the AIA deployment request and decides whether to approve the request in step S1204 (e.g., based on the AIAPP-ID and checking the approved list of AIAPPs 1205). If the request is approved, AIES 1203 searches the AIH repository to identify qualified AIHs that match the AIA requirements and can install the AIA as requested in the AIA deployment request. For example, the AIA requirements from AIAPP 1205 may require a certain type of training data; therefore, AIES 1203 can only select AIHs that provide such training data as qualified AIHs.

[0265] In step S1206, the AIES 1203 prepares an AIA installation software package based on the AIA requirements indicated by the AIAPP 1205. Alternatively, the software package is provided in an AIA deployment request.

[0266] In step S1208 , the AIES 1203 sends the AIA installation software package to the AIEC 1201 of the selected AIH.

[0267] In step S1210 , the AIEC 1201 installs the AIA software package and starts running the desired AIA. The AIH may generate an identifier or address (ie, AIA-ID) for the installed AIA and pass the AIA-ID to the AIEC 1201 .

[0268] In step S1212, AIEC 1201 sends a response to AIES 1203 regarding the successful (or unsuccessful) installation of the desired AIA. This response can also be considered as a request to register the installed AIA. In other words, this step can be compared to Figure 11 Same as step 1108 in .

[0269] In step S1214, AIES 1203 sends a response to AIAPP 1205. The response may include:

[0270] - AIH-ID: The identifier or address of the AIH selected in step S1204.

[0271] -AIEC-ID: Identifier or address of AIEC 1201.

[0272] -AIA-ID: an identifier or address of the AIA installed in step S1210.

[0273] AI Task Management

[0274] AI task deployment

[0275] AI AIAPP can use AIES to deploy AI tasks to AIA. AIES only needs AIAPP to upload AI tasks and then find a suitable AIA to host the AI ​​tasks to be deployed.

[0276] Figure 13 A method for AI task deployment according to an embodiment of the present principles is shown.

[0277] In step S1302, the AIAPP 1307 in the network sends a request to install an AI task to the AIES 1305. The request may include:

[0278] -AIAPP-ID: the identifier and / or address of the AIAPP 1307 assigned when registering at the AIES 1305 .

[0279] - AIEC-ID: Identifier and / or address of one or more AIECs 1303 on which the AIAPP 1307 wants to install the AI ​​tasks. The AIAPP 1307 may have discovered the AIECs 1303 from the AIES 1305 using a separate process.

[0280] -Num-of-AIECS: The number of AIEC 1303s on which the AI ​​task should be deployed.

[0281] -AI-Task-Content: software code of the AI ​​task. If this parameter is not included in step S1302, AIES 1305 can use the AI-Task-ID to identify the corresponding AI task and find the AI-Task-Content from the AI ​​task repository or download it from other places (e.g., DSS).

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

[0283] -AI-Model-ID: The identifier of an existing AI model that the AIAPP wants the AIA to retrieve and install with the AI ​​task. This information may not be required when the AI ​​task is used for learning. If the AI-Model-ID is included in the request, the AI-Model-Content may be omitted.

[0284] -AI-Model-Content: The content of the AI ​​model. If the AI ​​task is for learning, this information may be optional. Even if the AI ​​task is for inferring knowledge, this information may be optional because the AIA 1301 can use the AI-Model-ID to retrieve the AI ​​model. When AI-Model-Content is included in the request, the AI-Model-ID is not required. If the AI ​​task is a semi-supervised learning task, either AI-Model-Content or AI-Model-ID is required.

[0285] -Data-Properties: Properties of the data used to run AI tasks (e.g., training data, input data for knowledge inference)

[0286] AIES1305 receives and authenticates the request (e.g., checks whether the AIAPP-ID is a valid ID stored in the AIAPP repository). If authentication succeeds, then in step S1304, AIES1305 can find one or more suitable AIECs 1303 from its AIEC repository. In the case where the AIEC-ID is included in the request, AIES1305 may not need to find any new AIECs. AIES1305 can determine multiple AIECs 1303 as indicated by Num-of-AIECs and on which the same AI task is installed. For each AIEC 1303, AIES1305 can identify the appropriate AIA 1301 (i.e., find the AIA-ID for each AIEC 1303 from the AIA repository).

[0287] Steps S1306 to S1316 are performed for each AIEC 1303 determined in step S1304 and / or indicated in the request in step S1302.

[0288] In step S1306, AIES 1305 sends a request to AIEC to install the AI ​​task. The request may include:

[0289] -AI-Task-Content: as in step S1302, or AIES searches from the AI ​​task repository or downloads from other places (eg, DSS).

[0290] -AI-Task-ID: as in step S1302.

[0291] -AI-Model-ID: as in step S1302.

[0292] -AI-Model-Content: as in step S1302.

[0293] - AIES-ID: Identifier and / or address of AIES 1305.

[0294] -AIA-ID: determined in step S1304.

[0295] In step S1308 , AIEC 1303 forwards the AI ​​Task Content (and AI-Model-Content, if any) in the message to AIA 1301 , as indicated by the AIA-ID received in the request in step S1306 .

[0296] In step S1310, the AIA 1301 installs the AI ​​task and generates an AI-Task-Address. The AI-Task-Address (e.g., an application programming interface (API), a fully qualified domain name (FQDN), a uniform resource locator (URL), an IP address, an IP address, and a TCP / UDP port number) allows other entities (e.g., AIEC 1303, AIAPP 1307, AIES 1305) to manage the AI ​​task (e.g., pausing the AI ​​task, resuming the AI ​​task, updating the AI ​​task with new software code, retrieving the output of the AI ​​task, updating the AI ​​model of the AI ​​task, downloading the AI ​​model of the AI ​​task, changing other properties of the AI ​​task, etc.).

[0297] In step S1312 , the AIA 1301 sends a response including the AI-Task-Address to the AIEC 1303 .

[0298] In step S1314, AIEC 1303 sends a response to AIES 1305. The response may include AIEC-ID and AI-Task-Address. It should be noted that AIEC-ID is an identifier and / or address of AIEC 1303.

[0299] In step S1316, AIES 1305 generates an AI task record, which may include:

[0300] -AIEC-ID: determined in step S1304.

[0301] -AIA-ID: determined in step S1304.

[0302] -AI-Task-Address: Received from AIEC in the response of step S1314.

[0303] - Information received from the AIAPP 1307 in the request of step S1302.

[0304] AIES 1305 may publish AI task records to a DSS (e.g., a distributed ledger) or store installed AI tasks in an AI task repository.

[0305] In step S1318, AIES 1305 sends a response to AIAPP 1307. The response may include one or more pieces of information in the created AI task record.

[0306] AI task transfer

[0307] Some AI tasks may require migration for various reasons (e.g., the need for more computing power), especially for AI training tasks that last for a long time.

[0308] Figure 14 A method of AI task migration according to an embodiment of the present principles is shown.

[0309] The triggering event (not shown) for AI task migration can occur on the AIAPP or on the source AIA / AIH running the AI ​​task. For example, the source AIA / AIH may experience a sudden decrease in computing power or unavailability of training data and send an AI task migration trigger to the source AIEC, which then requests the AI ​​task to be migrated from the AIES. The triggering event causes an AI task migration request to be sent from the entity that experienced the triggering event (or is associated with the entity that experienced the triggering event). In other words, steps 1402a or S1402b are typically executed.

[0310] In step S1402a, AIAPP 1411 sends an AI task migration request to AIES 1409. The request may include:

[0311] -AIAPP-ID: identifier or address of AIAPP 1411.

[0312] - AI-Task-ID: The identifier or address of the AI ​​task to be migrated from the source AIA / AIH (connected via the source AIEC 1407) to the destination AIA / AIH (connected via the destination AIEC 1403).

[0313] - Source-AIEC-ID: Identifier or address of the source AIEC 1407 that connects the source AIA 1405 to the AIES 1409. This information is omitted if the AIAPP 1411 does not know where to migrate the AI ​​task from.

[0314] - Destination-AIEC-ID: an identifier or address of the destination AIEC 1403 that connects the destination AIA 1401 to the AIES 1405. If the AIAPP 1411 does not know where to migrate the AI ​​task, this information is omitted.

[0315] -Destination-AIEC-Selection-Criteria: AIES 1409 identifies and selects the criteria for eligible destinations AIEC 1403 (and / or eligible destinations AIA 1401) to which AI tasks can be migrated. This criteria can be related to AIA-AI-Capability and / or AIH-AI-Capability. If the request includes Source-AIEC-ID and / or Destination-AIEC-ID, this information can be omitted.

[0316] In step S1402b, the source AIEC 1407 sends an AI task migration request to the AIES 1409. The request may include:

[0317] - Source AIEC-ID: Identifier or address of the source AIEC 1407.

[0318] -Source-AIA-ID: Identifier or address of the source AIA 1405 .

[0319] -Source-AIH-ID: Identifier or address of the source AIH.

[0320] - AI-Task-ID: the same as in step S1402a.

[0321] -Destination-AIEC-ID: the same as in step S1402a.

[0322] -Destination-AIEC-Selection-Criteria: Same as in step S1402a.

[0323] AIES1409 receives the AI ​​task migration request, checks the received request and decides whether to approve the request. If the request is approved, then in step S1404, AIES1409 determines where to migrate the AI ​​task. AIES1409 can use the Destination-AIEC-Selection-Criteria received from AIAPP 1411 or source AIEC 1407 to identify a suitable destination AIEC / AIA / AIH. For example, AIES1409 can search the AIEC repository (or AIA repository, or AIH repository) to compare the Destination-AIEC-Selection-Criteria with the AIA-AI-Capability and / or AIH-AI-Capability of each AIEC record (or AIA record, or AIH record) to find a suitable and qualified destination AIEC1403 (and / or qualified destination AIA).

[0324] The AIES 1409 confirms that the AI ​​task migration request has been approved by sending a message to the relevant entity or device, ie, the source AIEC 1407 (step S1406b) or the AIAPP (step S1406a).

[0325] In step S1406a, this is only necessary if the AI ​​task migration request comes from AIAPP 1411 (i.e., step 1402a). The message may include:

[0326] - Source AIEC-ID: Identifier or address of the source AIEC 1407.

[0327] -Source-AIA-ID: Identifier or address of the source AIA 1405 .

[0328] -Source-AIH-ID: The identifier or address of the source AIH hosting the source AIA 1405 .

[0329] - Destination-AIEC-ID: the identifier or address of the destination AIEC 1403 determined in step S1404.

[0330] - Destination-AIA-ID: The identifier or address of the destination AIA 1401 determined in step S1404.

[0331] - Destination-AIH-ID: the identifier or address of the destination AIH hosting the destination AIA 1401 determined in step S1404.

[0332] In the case where the AI ​​task migration request is sent from the AIAPP 1411 (ie, in step S1402a), the AIAPP 1411 may further contact the source AIEC 1407 to start the migration.

[0333] In step S1406b, AIES1409 sends a message to the source AIEC 1405. If the AI ​​task migration request comes from AIAPP 1411 (i.e., step 1402a), AIES1409 uses the message to notify AIEC 1405 to perform the AI ​​task migration. If the AI ​​task migration request comes from the source AIEC 1405 (i.e., step S1402b), AIES1409 uses the message to indicate that the request is approved. The message in step S1406b may include:

[0334] - AIAPP-ID: If the AI ​​task migration request comes from the AIAPP 1411 (ie, step 1402 a ), it is the identifier or address of the AIAPP 1411 .

[0335] - AI-Task-ID: the same as in step S1402a.

[0336] - Destination-AIEC-ID: the identifier or address of the destination AIEC 1403 determined in step S1404.

[0337] - Destination-AIA-ID: The identifier or address of the destination AIA 1401 determined in step S1404.

[0338] - Destination-AIH-ID: the identifier or address of the destination AIH determined in step S1404.

[0339] The source AIEC prepares for AI task migration. It sends an AI task migration request to the destination AIEC 1403 via step S1408. The request may include parameters such as AI-Task-Content, AI-Task-ID, AI-Model-ID, AI-Model-Content, AIES-ID, AIA-ID, and AI-Task-Migration-Instructions. The AI-Task-Migration-Instructions may specify more AI-specific migration information and / or policies; for example, one of the main differences between normal software migration and AI task migration is that in addition to migrating the software instance context, the data required for configuring the AI ​​task may also need to be configured. Therefore, the AI-Task-Migration-Instructions may contain the following information:

[0340] If the AI ​​task being migrated is an AI training task, the destination AIEC needs to know where the training data comes from. For example, it can only use local training data hosted by the destination AIEC. Alternatively, data hosted by the source AIEC may also need to be migrated to the destination AIEC.

[0341] If the transferred AI task is an AI reasoning task, the target AIEC needs to know where the input data comes from in order to reason about the input data.

[0342] In step S1410 , the destination AIEC 1403 forwards the AI ​​task migration request to the destination AIA 1401 associated with the destination AIEC 1403 .

[0343] In step S1412 , the destination AIA 1401 installs the migrated AI task.

[0344] In step S1414 , the destination AIA 1401 configures input for the migrated AI task (eg, what training data should be used for the AI ​​training task, or what input data should be used for the AI ​​reasoning task).

[0345] In step S1416 , the destination AIA 1401 sends a response indicating the completion of the AI ​​task migration to the destination AIEC 1403 .

[0346] In step S1418, the destination AIEC 1403 sends a response indicating the completion of the AI ​​task migration to the source AIEC 1407. In step S1420, the source AIEC 1407 may forward the response to the AIES 1409 and / or the AIAPP 1411.

[0347] Federated Learning (FL) task deployment

[0348] A specific type of AI task is federated learning (FL). In a typical FL learning scenario, there is a single FL server and multiple FL clients. In each round of training, the FL clients perform local training using their local data to generate local model updates, which are then submitted to the FL server for aggregation to generate a global model update. The aggregated global model update is then distributed to the FL clients for the next round of local training at the FL clients.

[0349] Figure 15 A method of FL task migration according to an embodiment of the present principles is shown.

[0350] AIAPP 1507 will deploy a FL task, i.e., FL Task-1. In step S1502, AIAPP 1507 sends a FL task deployment request and requirements for the FL task to AIES 1505. For example, the requirements may be FL client selection criteria (e.g., AIA-AI-Capability, such as training data attributes). AIAPP 1507 may include in the request an initial FL global model that will be used by the FL client to start local training. In addition, AIAPP 1507 may indicate the training instructions (e.g., some AI model hyperparameters) that each FL client is to follow during local training. In addition, the request may include reference Figure 13 The information described in the request in step S1302.

[0351] In step S1504, the AIES 1505 selects one or more suitable FL clients based on the FL client selection criteria sent from the AIAPP 1507. For example, a suitable AIEC and / or a suitable AIA with the required AIH-AI-Capability or AIA-AI-Capability may be considered as a candidate FL client.

[0352] Execute steps S1506 to S1518 for each selected FL client (e.g., AIEC-1 and AIA-1)

[0353] In step S1506, AIES 1505 sends an invitation request to AIEC-1 1503 (ie, one of the selected FL clients) to join FL Task-1. The request may include Figure 13 Similar information (e.g., Data-Properties, AI-Task-Type) in the request in step S1302.

[0354] In step S1508 , AIEC-1 1503 sends a confirmation of joining FL Task-1 to AIES 1505 .

[0355] In step S1510, AIES 1505 sends a deployment request to AIEC-1 1503 to deploy the software code and training instructions related to FL Task-1 to AIEC-1. The deployment request may include the information in the request in step S1502.

[0356] In step S1512 , AIEC-1 1503 forwards the request to AIA-1 1501 .

[0357] In step S1514, AIA-1 1501 installs the relevant software code of FL Task-1 and completes the configuration.

[0358] AIA-1 1501 generates AI-Task-address to be included in the response it sends to AIEC-1 1503 in step S1516.

[0359] In step S1518, AIEC-1 1503 forwards the response to AIES 1505. The response may include AIEC-1-ID and AI-Task-Address. It should be noted that AIEC-1-ID is the identifier and / or address of AIEC-1 1503.

[0360] In step S1520, AIES 1505 configures its own configuration if it needs to act as the FL server in FL Task-1. Alternatively, AIES 1505 may select another AIEC to act as the FL server in FL Task-1. In this case, the FL server sends relevant software code and FL instructions to the selected AIEC that will act as the FL server. For example, AIES 1505 may use FL instructions to indicate to the AIEC (that will act as the FL server) that the AIEC has been selected as the FL client in this task. AIES 1505 generates an AI task record, which may include:

[0361] - AI-Task-Address received in step S1518.

[0362] - Information received in step S1502.

[0363] - The address or identifier of each AIEC / AIA that successfully installed FL Task 1.

[0364] – The address or identifier of the selected FL server.

[0365] In step S1522, AIES 1505 sends a response confirming that FL Task-1 has been deployed to AIAPP 1507. The response may include AI-Task-Address, an identifier of AIA-1, an identifier of AIEC-1, an identifier of AIES, and / or an identifier of the AIEC selected as the FL server.

[0366] AI model management

[0367] AI model registration

[0368] After learning the AI ​​model, AIA can register the AI ​​model with AIES. AIA uses AIEC to register the AI ​​model with AIES. After the AI ​​model is registered with AIES, AIES creates an AI model record and stores the AI ​​model record in the AI ​​model repository.

[0369] Figure 16 A method of AI model registration according to an embodiment of the present principles is shown.

[0370] In step S1602 , the AIA 1601 that has completed AI training generates an AI model.

[0371] In step S1604, the AIA 1601 sends a message with the generated AI model to the AIEC 1603. The message may include:

[0372] -AI-Model-ID: Identifier of the generated AI model. It can be the identifier of a previously registered AI model, as AI-Model-Content (see below) is an indication of an update to the previously registered AI model indicated by AI-Model-ID.

[0373] -AI-Model-Content: If the AI ​​model is fully trained, this parameter contains the 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, AIA can skip this parameter and decide not to upload the model content to AIES; instead, other entities can only discover AI-Model-Address and retrieve the AI ​​model content directly from AIA using a separate step.

[0374] -AI-Model-Address: The address of the fully trained or still-training AI model at AIA 1601. Through AI-Model-Address, other entities (e.g., AIES, AIH, AIAPP) can check the status of the AI ​​model (e.g., fully trained or partially trained) from AIA 1601 and download the AI ​​model from AIA 1601 after it is fully trained. If AI-Model-Content is not included in step S1604, other entities can use AI-Model-Address to access the AIA later to retrieve the model content.

[0375] -AIA-ID: identifier and / or address of AIA 1601.

[0376] -AI-Model-Registration-Type: Indicates whether the AI ​​model should be registered with AIEC, AIES, or both.

[0377] In step S1606 , AIEC 1605 may send an acknowledgement of the message to AIA 1601 .

[0378] AIEC 1603 may determine to register the AI ​​model with AIES 1605 based on, for example, local policy or an explicit indication (i.e., AI-Model-Registration-Type) that the AIA may attach in step S1404. In this case, in step S1608, AIEC 1603 sends a request message to AIES 1605 to register the AI ​​model. The request may include:

[0379] -AI-Model-Content: received in the message in step S1604.

[0380] -AI-Model-Usage-Constraints: Constraints on AI model usage, such as when and by which entities the registered model can be discovered and / or used. For example, this can include a list of allowed AIAs, indicating that only AIAs on this list can discover and use the AI ​​model.

[0381] -AI-Model-ID: received in the message in step S1604.

[0382] -AI-Model-Address: received in the message in step S1604.

[0383] -AIA-ID: Received in the message in step S1604.

[0384] -AIEC-ID: Identifier or address of AIEC 1603.

[0385] AIES 1605 receives the request message. If the message includes AI-Model-Content, AIES 1605 stores the AI ​​model in the AI ​​model repository in step S1610. If AIA 1601 requests an update to the previously registered AI model in the message in step S1604, AIES 1605 uses the new AI-Model-Content included in the message and forwards it to AIES 1605 to replace the previous version of the AI ​​model. AIES 1605 can publish the AI ​​model content to a DSS (e.g., a distributed ledger).

[0386] In step S1612, AIES 1605 creates an AI model record for the AI ​​model indicated in the message in step S1608. AIES 1605 may publish the AI ​​model to a DSS (e.g., a distributed ledger). For example, AIES 1605 may create a transaction containing the AI ​​model and send the transaction to the distributed ledger. The AI ​​model record may include the following information, which may be discovered and / or exposed to other entities (such as an AIMU):

[0387] - AI-Model-ID: If included in step S1608, the same as step S1608. If step S1608 does not include AI-Model-ID, it means that the AI ​​model is the first registration, and AIES will create an AI-Model-ID for the registered AI model. Later, AIA can use AI-Model-ID to update the registered AI model.

[0388] AI-Model-Usage-Constraints: If included in step S1608, it is the same as step S1608. If step S1608 does not include this parameter, AIES itself can determine some AI model usage constraints.

[0389] AI-Model-Address: If included in step S1608, it is the same as step S1608; otherwise, this parameter is not required.

[0390] AI-Model-Content: If included in step S1608, it is the same as step S1608; otherwise, this parameter is not required.

[0391] AI-Model-Mode: Indicates that the AI ​​model is registered.

[0392] AIA-ID: the same as in step S1608.

[0393] AIEC-ID: Same as in step S1608.

[0394] In step S1614, AIES 1605 sends a response to AIEC 1603. The response may include:

[0395] -AI-Model-ID: the same as in step S1612.

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

[0397] In step S1616 , the AIEC 1603 may forward the response received in step S1614 to the AIA 1601 .

[0398] AI model discovery and deployment

[0399] Entities (eg, AIAPP and AIA) may discover registered AI models from AIES and deploy the discovered AI models to AIA.

[0400] Figure 17A method for AI model discovery and deployment according to an embodiment of the present principles is shown. In this method, AIAPP 1707 or AIEC 1703 discovers AI models from AIES 1705.

[0401] In step S1702, AIEC 1703 or AIAPP 1707 sends a request message to AIES 1705 to discover an AI model. The request may include an AIEC-ID (if the request is from AIEC 1703) or an AIAPP-ID (if the request is from AIAPP 1707). The request may include AI model discovery criteria, indicating one or more of the following attributes of the AI ​​model to be discovered:

[0402] -AI-Model-Type: The type of AI model to be discovered. 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 DNN layers and neurons.

[0403] -AI-Model-ID: The identifier of a previously downloaded AI model. AIA 1701 can use the AI-Model-ID to download new versions of the AI ​​model from AIES.

[0404] The AIAPP 1707 may also include the AIA-ID or AIEC-ID to which the discovered AI model should be deployed.

[0405] In step S1704, AIES 1705 finds at least one AI model that matches the received standard (eg, AI-Model-Type) in its AI model library. AIES 1705 uses AI-Model-Address1 to indicate where the AI ​​model was found.

[0406] In step S1706, AIES 1705 retrieves the AI ​​model. The AI ​​model can be retrieved, for example, from a DSS (e.g., a distributed ledger) or from another AIEC / AIA (i.e., other than AIA 1701 and AIEC 1703) that acts as an AIMP and generates AI models. AIES 1705 uses AI-Model-Address2 to indicate where to retrieve the AI ​​model.

[0407] In step S1708, AIES 1705 sends a message with the determined AI model to AIEC 1703. If the request message in step S1702 was sent from AIEC 1703, AIES 1705 knows its address. If the request message was sent from AIAPP 1707, AIAPP 1707 may have indicated the AIA-ID or AIEC-ID in the request message. If only the AIA-ID is included, AIES 1705 can use the AIA-ID to search its AIA repository to find AIEC 1703 that can reach AIA 1701. The message may include:

[0408] -AIAPP-ID: If the request message in step S1702 is sent from AIAPP 1707, it is the identifier and / or address of AIAPP 1707.

[0409] - AIEC-ID: Identifier and / or address of AIEC 1703.

[0410] -AIA-ID: identifier and / or address of AIA 1701.

[0411] -AI-Model-ID: The identifier of the AI ​​model sent to be deployed at the AIA 1701.

[0412] -AI-Model-Content: Content of the AI ​​model sent to be deployed at the AIA 1701.

[0413] AI-Model-Address1: Same as step S1704.

[0414] AI-Model-Address2: Same as step S1706.

[0415] In step S1710 , the AIEC 1703 forwards the AI ​​model to the AIA 1701 .

[0416] In step S1712 , the AIA 1701 installs the AI ​​model.

[0417] In step S1714, AIA 1701 sends a response to AIEC 1703. The response may include:

[0418] -AIA-ID: Identifier of AIA 1701.

[0419] -AI-Model-Push-Address: The address that AIES 1705 or other entities can use to push the contents of a new fully trained AI model to AIA 1701.

[0420] In step S1716, AIEC 1703 sends a response to AIES 1705. The response may include:

[0421] -AIEC-ID: Identifier or address of AIEC 1703.

[0422] -AIA-ID: as received from AIA 1701.

[0423] -AI-Model-Push-Address: as received from AIA 1701.

[0424] The AIES receives the response and creates an AI model record based on the information in the response in step S1718. The AI ​​model record may include the information received from the response in step S1716. The AI ​​model record may also include:

[0425] -AIAPP-ID: received in step S1702.

[0426] -AI-Model-Address1: determined in step S1704.

[0427] -AI-Model-Address2: determined in step S1706.

[0428] -AI-Model-ID: the same as in step S1708.

[0429] In step S1720, AIES 1705 may send a notification to AIAPP 1707. The notification may include information recorded from the AI ​​model.

[0430] in conclusion

[0431] Although features and elements are provided above in specific combinations, 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 this application, which are intended to be illustrative of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Any element, action, or instruction used in the description of this application should not be construed as being critical or essential to the present invention unless explicitly so provided. In addition to those enumerated herein, functionally equivalent methods and devices within the scope of this disclosure will be apparent to those skilled in the art from the foregoing 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 to which such claims are entitled. It should be understood that the present disclosure is not limited to the specific methods or systems herein.

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

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

[0434] 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). A processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0435] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments that may be applied, it should be understood that the embodiments shown are merely examples and should not be considered as limiting 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.

[0436] In addition, in the embodiments provided above, reference is made to processing platforms, computing systems, controllers, and other devices including processors. 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."

[0437] Those skilled in the art will appreciate that the actions and symbolic representations of operations or instructions comprise the manipulation of electrical signals by the CPU. The electrical system represents data bits, which can cause the resulting conversion or reduction of the electrical signal and maintain the data bits in memory locations within the storage system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of the signal. 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 aforementioned platforms or CPUs, and that other platforms and CPUs may support the provided methods.

[0438] The data bits may also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium may include cooperating or interconnected computer-readable media that reside solely on the processing system or distributed across 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 aforementioned memories, and that other platforms and memories may support the provided methods.

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

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

[0441] The foregoing detailed description has been described using block diagrams, flow charts and / or examples to illustrate various embodiments of the apparatus and / or process. To the extent that 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 portions of the subject matter described herein can be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein can 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 any combination thereof, and that designing circuit systems and / or writing code for software and / or firmware will be entirely within the skill of those skilled in the art according to the present disclosure. 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 perform 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, and the like; and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, and the like).

[0442] 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, 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 program, one or more interactive devices such as a touchpad or screen and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or velocity; control motors 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.

[0443] The subject matter described herein sometimes illustrates the different components that are included in or connected with different other components.It should be understood that the architecture of this type of description is merely an example, and in fact many other architectures that realize the same function can be implemented.In a conceptual sense, any arrangement of the components for realizing the same function is effectively "associated" so that the desired function can be realized.Therefore, any two components that are combined to realize a specific function in this article can be considered to be "associated" with each other so that no matter how the architecture or intermediate components realize the desired function.Similarly, any two components that are associated in this way can also be considered to be "operably connected" or "operably coupled" to realize the desired function, and any two components that can be associated in this way can also be considered to be "operably coupled" to realize the desired function.The specific example of operable coupling includes, but is not limited to, physically cooperable and / or physically interacting components, and / or wirelessly interacting and / or wirelessly interacting components, and / or logically interacting and / or logically interacting components.

[0444] 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 permutations may be expressly set forth herein.

[0445] 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 that includes such introduced claim recitation to embodiments that include 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 to mean "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 an introduced claim recitation is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., reciting "two recitations" alone without other modifiers means at least two recitations or two or more recitations). Furthermore, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, generally, such construction is intended to represent what one skilled in the art would understand as the convention (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 instances 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.). Those 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, either, 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 list of multiple items and / or categories of items is intended to include "any," "any combination," "any plurality," and / or "any combination of multiples," either alone or in combination with other items and / or categories of items. 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."

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

[0447] 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 subranges and combinations thereof. Any listed range can be easily identified as fully describing and capable of breaking down the same range into at least equal halves, thirds, quarters, fifths, tenths, etc. As non-limiting examples, each range discussed herein can be easily broken down into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all language such as "at most," "at least," "greater than," "less than," etc. includes the enumerated numbers and refers to a range that can subsequently be subdivided into subranges as discussed above. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, and so on.

[0448] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. Additionally, use of the term "means for..." in any claim is intended to invoke 35 U.S.C. § 112, 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 a first request for a first registration from an artificial intelligence (AI) entity; creating a record for the AI ​​entity, the record comprising information indicating the first registration; and A second request for a second registration of the AI ​​client on the device and at least one AI entity including the AI ​​entity is transmitted to another device.

2. The device according to claim 1, wherein: The AI ​​entity is an AI application.

3. The device according to claim 2, wherein: The information indicating the first registration includes at least one of the following items: registration time, type of the AI ​​application, purpose of the AI ​​application, identifier of the AI ​​application, address of the AI ​​application, identifier of the hosting device of the AI ​​application, address of the hosting device of the AI ​​application, list of AI tasks to be deployed by the AI ​​application, the registration request is to register with the device, the registration request is to register with the other device, and an identifier or address of the other device.

4. The device according to claim 3, wherein: The first request for a first registration includes information indicating at least one of the following items: the type of the AI ​​application, the purpose of the AI ​​application, the identifier of the AI ​​application, the address of the AI ​​application, the identifier of the hosting device of the AI ​​application, the address of the hosting device of the AI ​​application, the list of AI tasks to be deployed by the AI ​​application, the registration request is to register with the device, the registration request is to register with the other device, and the identifier or address of the other device.

5. The device according to claim 2, wherein: The second request for a second registration includes information indicating at least one of: an identifier of the device, an address of the device, a blockchain address of the device, resources that the device can allocate for AI tasks, at least one service requested by the device, and a list of AI applications from which the device has received registration requests.

6. The device according to claim 1, wherein: The at least one processor is configured to: Information indicating at least one of an identifier of the device, a service approved for use by the device, and an approved AI application is received from the other device.

7. The device according to claim 1, wherein: The AI ​​entity is an AI agent hosted by an AI host and having at least one of the following capabilities: training an AI model and using the trained AI model to infer results.

8. The device according to claim 7, wherein: The information indicating the first registration includes at least one of: a registration time, an identifier of the AI ​​agent, an identifier of the AI ​​host, the registration request is to register with the device, the registration request is to register with the other device, and an identifier or address of the other device.

9. The device according to claim 8, wherein: The second request for a second registration includes information indicating at least one of an identifier of the AI ​​host, an address of the AI ​​host, a blockchain address of the AI ​​host, resources that the AI ​​host can allocate for AI tasks, at least one service requested by the device, and a list of AI agents from which the device has received registration requests.

10. A method performed by an apparatus, the method comprising: receiving a first request for a first registration from an artificial intelligence (AI) entity; creating a record for the AI ​​entity, the record comprising information indicating the first registration; as well as A second request for a second registration of the AI ​​client on the device and at least one AI entity including the AI ​​entity is transmitted to another device.

11. The method according to claim 10, wherein: The AI ​​entity is an AI application.

12. The method according to claim 11, wherein: The information indicating the first registration includes at least one of the following items: registration time, type of the AI ​​application, purpose of the AI ​​application, identifier of the AI ​​application, address of the AI ​​application, identifier of the hosting device of the AI ​​application, address of the hosting device of the AI ​​application, list of AI tasks to be deployed by the AI ​​application, the registration request is to register with the device, the registration request is to register with the other device, and an identifier or address of the other device.

13. The method according to claim 12, wherein: The first request for a first registration includes information indicating at least one of the following items: the type of the AI ​​application, the purpose of the AI ​​application, the identifier of the AI ​​application, the address of the AI ​​application, the identifier of the hosting device of the AI ​​application, the address of the hosting device of the AI ​​application, the list of AI tasks to be deployed by the AI ​​application, the registration request is to register with the device, the registration request is to register with the other device, and the identifier or address of the other device.

14. The method according to claim 11, wherein: The second request for a second registration includes information indicating at least one of: an identifier of the device, an address of the device, a blockchain address of the device, resources that the device can allocate for AI tasks, at least one service requested by the device, and a list of AI applications from which the device has received registration requests.

15. The method according to claim 10, further comprising: Information indicating at least one of an identifier of the device, a service approved for use by the device, and an approved AI application is received from the other device.

16. The method according to claim 10, wherein: The AI ​​entity is an AI agent hosted by an AI host and having at least one of the following capabilities: training an AI model and using the trained AI model to infer results.

17. The method according to claim 16, wherein: The information indicating the first registration includes at least one of: a registration time, an identifier of the AI ​​agent, an identifier of the AI ​​host, the registration request is to register with the device, the registration request is to register with the other device, and an identifier or address of the other device.

18. The method according to claim 17, wherein: The second request for a second registration includes information indicating at least one of an identifier of the AI ​​host, an address of the AI ​​host, a blockchain address of the AI ​​host, resources that the AI ​​host can allocate for AI tasks, at least one service requested by the device, and a list of AI agents from which the device has received registration requests.

Images