Methods, Architectures, Devices, and Systems for Distributed Artificial Intelligence

The described method and system address the challenges of managing and executing distributed AI models by allowing a first device to select and execute AI model subsets based on received information, optimizing resource utilization and adapting to varying network conditions for improved AI service deployment.

JP2025516173APending Publication Date: 2025-05-27INTERDIGITALCE PATENT HLDG SAS
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024563072
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2022-11-08
Filing Date
2023-04-24
Publication Date
2025-05-27

AI Technical Summary

Technical Problem

Existing communication systems face challenges in efficiently managing and executing distributed artificial intelligence (AI) models across multiple devices, particularly in scenarios where resources are limited and network conditions vary.

Method used

A method and system where a first device receives information about multiple distributed AI models from a second device, selects a suitable AI model subset, and executes it based on received information, allowing for efficient distribution and execution of AI services across different devices and networks.

Benefits of technology

This approach enables flexible and efficient deployment of AI services by optimizing resource utilization and adapting to varying network conditions, thereby improving the overall performance and scalability of AI applications in communication systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025516173000001_ABST
    Figure 2025516173000001_ABST
Patent Text Reader

Abstract

Procedures, methods, architectures, devices, systems, devices, and computer program products for decentralized artificial intelligence, AI. A first device receives information indicating a plurality of decentralized artificial intelligence, AI, models from a second device, where each model of the plurality of decentralized AI models corresponds to the same AI service, and transmits to the second device a message including information indicating a selected decentralized AI model selected from among the plurality of decentralized AI models, the selected decentralized AI model including a plurality of model subsets that constitute an AI service, receives information corresponding to the model subset of the selected decentralized AI model, and executes the model subset of the selected decentralized AI model based on the information corresponding to the model subset.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

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

Summary of the Invention

[0002] In a first aspect, the present principle is directed to a method in which a first device receives, from a second device, information indicating a plurality of distributed artificial intelligence (AI) models, where each model of the plurality of distributed AI models corresponds to the same AI service, and transmits to the second device a message including information indicating a selected distributed AI model selected from the plurality of distributed AI models, the selected distributed AI model including a plurality of model subsets that constitute an AI service. The first device receives information corresponding to the model subset of the selected distributed AI model and executes the model subset of the selected distributed AI model based on the information corresponding to the model subset.

[0003] In a second aspect, the present principle is directed to a first device including a memory storing processor-executable program instructions and at least one hardware processor configured to execute the program instructions to receive, from a second device, information indicating a plurality of distributed artificial intelligence (AI) models, where each model of the plurality of distributed AI models corresponds to the same AI service, transmit to the second device a message including information indicating a selected distributed AI model selected from the plurality of distributed AI models, the selected distributed AI model including a plurality of model subsets that constitute an AI service, receive information corresponding to the model subset of the selected distributed AI model, and execute the model subset of the selected distributed AI model based on the information corresponding to the model subset.

Brief Description of the Drawings

[0004] A more detailed understanding may be provided from the following detailed description in conjunction with the accompanying drawings by way of example. The diagrams of such drawings, like the detailed description, are examples. Accordingly, the drawings and the detailed description should not be considered limiting, and other equally effective examples are possible and likely. Further, similar reference numerals (the “reference”) in the drawings indicate similar elements.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10A

Figure 10B

Figure 11

Mode for Carrying Out the Invention

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

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

[0007] FIG. 1A is a system diagram illustrating an exemplary communication system 100 in which one or more of the 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 a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS spread OFDM, ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filter type OFDM, filter bank multicarrier (FBMC), etc.

[0008] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, which may all be referred to as "stations" and / or "STAs", can be configured to transmit and / or receive wireless signals and can be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Thing (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated processing chain), home electronics devices, devices operating in commercial and / or industrial wireless networks, etc. (or be any of these). Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

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

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

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

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

[0014] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish the air interface 116 using New Radio (NR).

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

[0016] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., WiMAX (Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communication (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0017] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as, for example, an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (e.g., for use by a drone), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (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 shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

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

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

[0021] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, 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, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0022] The processor 118 can be a general-purpose processor, a dedicated 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 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together, for example, in an electronic package or chip.

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

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

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

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

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

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

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

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

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

[0032] RAN 104 may include eNodeBs 160a, 160b, 160c, but it will be understood that RAN 104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to WTRU 102a and receive wireless signals from WTRU 102a.

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

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

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

[0036] The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and transfer user data packets between the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as fixing the user plane during handover between eNode Bs, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c.

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

[0038] CN106 may facilitate communication with other networks. For example, CN106 may provide access to a circuit-switched network such as PSTN108 to WTRU102a, 102b, 102c to facilitate communication between the WTRU102a, 102b, 102c and a conventional landline communication device. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, 102c with access to other networks 112 that may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

[0041] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that conveys traffic within and / or outside the BSS. Traffic to an STA originating outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS may be sent to the AP so as to be delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, through the AP. The source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be regarded as and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS communication mode may also be referred to herein as the "ad hoc" communication mode.

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

[0043] A high throughput (HT) STA may use a 40 MHz wide channel for communication via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel to form, for example, a 40 MHz wide channel.

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

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

[0046] A WLAN system that supports a plurality of channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operating mode. In an example of 802.11ah, the primary channel is 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., supports only) the 1 MHz mode even when 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) setting may depend on the state of the primary channel. For example, due to an STA transmitting to an AP (supporting only the 1 MHz operating mode), when the primary channel is in operation, most of the frequency band remains in an inoperative state and, even if it may be available, the entire available frequency band may be considered to be in operation.

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

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

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

[0050] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or varying durations of absolute time of varying lengths).

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

[0052] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, 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. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

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

[0055] SMF183a and 183b can be connected to AMF182a and 182b within CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b within CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating 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, etc.

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

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

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

[0059] An emulation 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 emulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device and / or use terrestrial wireless communication for the purpose of testing and can perform the test.

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

[0061] Introduction Artificial Intelligence (AI), especially Machine Learning (ML), can be a very powerful tool in various devices, but it will be understood that the resource (e.g., processing) requirements can be too large for devices with relatively limited resources. Such devices are referred to as UEs in this description and can be end-user devices, especially mobile devices such as smartphones and tablets. For this reason, it is a common solution to have at least a part of the calculation executed by one or more other devices. Note that the "device" (also called "node") in this context can mean a plurality of devices that operate as one, for example, in the case of a server bank and cloud computing.

[0062] AI / ML inference can thus be split (i.e., partitioned) over different points (e.g., from a UE to an edge device or a cloud device) for a particular AI / ML application, which can be based on, for example, a Deep Neural Network (DNN). The AI / ML application can be split, for example, along the interface between two layers in a DNN, or one part (e.g., the part that detects facial features) can be split between different parts that can provide the results as input to subsequent parts (e.g., using the detected facial features for a person's mood). Thus, the corresponding AI / ML model, i.e., a computer program (e.g., trained, i.e., having appropriate parameters), can be split into several AI / ML model subsets that are executed on different devices / servers. Each AI / ML model subset is an independent software part that is executed on a partitioned node, such as a UE, an edge device, etc., within the cloud or within the access network.

[0063] Figure 2 illustrates different examples of the splitting of an AI / ML model. Exemplary AI / ML models can be split in different ways. For example, the split model M can include AI / ML model subsets {M0, M1, M2}. Similarly, the split model M' can include {M'0, M'1, M'2} and the split model M'' {M0'', M1'', M2'', M3''}. These three examples of split models M, M', M'' provide the same service and, as can be seen, can be split into different numbers of subsets. The boundaries between different subsets are referred to as split points (partition points) and are indicated by exemplary arrows in one example.

[0064] In addition, different subsets can be executed or intended to be executed on different devices. Which device the subset is executed on can depend on different conditions. Exemplary conditions include device capabilities, device load, and network load. Thus, a specific subset, for example, M0, can be executed on, for example, either an edge device or a UE.

[0065] Figure 3 illustrates an example of a split topology in which a UE captures sensed data and operates as an uplink data source.

[0066] Assume that the AI / ML model subset is obtained from a device such as a cloud or edge server node (e.g., downloaded, streamed). The sensed data is provided to subset M0 by a UE (e.g., an application that captures video). In this example, assume that M0 processes the sensed data and outputs AI data to subset M1. M1 can process the AI data (i.e., make inferences) to obtain results, or transfer the different AI data to M2, which processes different AI data to obtain results. The results are, in some cases, returned to the UE via the subset with the immediately lower number (e.g., M1 can provide the results via M0). The results can be provided to the application or used directly by the UE.

[0067] In example (a), M0 exists on the UE and M1 exists on the edge device (node).

[0068] In example (b), M0 exists on the UE and M1 exists within the cloud.

[0069] In example (c), M0 exists on the edge device and M1 exists within the cloud.

[0070] In example (d), M0 exists on the UE, M1 exists on the edge device, and M2 exists within the cloud.

[0071] The results can be rendered in various ways, e.g., as a video or as the text portion of the information.

[0072] Figure 4 illustrates an example of a split topology where sensed data arrives from a content provider / remote UE via a cloud / edge server operating as a downlink data source.

[0073] The AI / ML model subset can be obtained as described with reference to Figure 3.

[0074] The sensed data arrives from a content provider device (not shown).

[0075] As shown in Figure 3, the sensed data is processed (e.g., inferred) by M0, and then M0 provides the AI / ML data to the next subset M1 to obtain a result, or provides the AI data to the next subset M2, and the next subset M2 obtains the result.

[0076] Note that since the application on the UE is the intended target of the result, it is not returned as shown in Figure 3. However, also note that if the result can be of interest to other devices, e.g., the source, it can still be returned as shown in Figure 3.

[0077] The result can be rendered as shown in Figure 3.

[0078] In example (a), M0 exists on the edge device (node), and M1 exists on the UE.

[0079] In example (b), M0 exists in the cloud, and M1 exists on the UE.

[0080] In example (c), M0 exists in the cloud, M1 exists on the edge device (node), and M2 exists on the UE.

[0081] In example (d), M0 exists in the cloud, and M1 exists on the edge device (node).

[0082] Note that a device (i.e., a node) can execute two or more subsets. For example, M1 and M2 can be executed on the same device.

[0083] As shown, the split points can vary according to the model, the split model topology, the processing capabilities of each component (UE, edge, cloud device) operating in the split model topology, and the varying live network conditions for transmitting AI / ML data.

[0084] The diversity of the topology and the heterogeneity of the devices involved can raise several requirements and issues as follows. - When the UE determines the split model and the devices involved, the UE should know which AI / ML models are available for its device characteristics and how the model can be decomposed. For example, what are the possible split points and what is required to execute a model subset of the model? - How can the UE know which server (edge / cloud / proximity) can provide a specific service by executing a specific subset of the UE's model? - How can the UE interact with the application (control plane) and the edge device to apply the selected end-to-end split model and set up the links between the UE and the local split node (e.g., edge, cloud, and local links) and the intermediate links between the split nodes hidden from the UE? - How can the UE interact with the application (server) to establish the relevant data path? This can include the direct data path between the UE and the local split node.

[0085] Overview According to this principle, at a high level, the UE can select a split model topology from among multiple split model topologies available for a given AI / ML service (e.g., application). The split model configuration includes the selection of split nodes that execute one or several model subsets with split node connections.

[0086] The UE can also request the configuration of selected split nodes, including the configuration for identifying AI / ML specific metadata, and the establishment of a data transport session between the selected split nodes. Depending on the selected model, the data transport session between the split nodes can be a downlink or uplink (or both downlink and uplink).

[0087] The UE can further start a data streaming service to a split node that senses data in order to trigger data transport between selected split nodes, which may include AI / ML specific metadata with a global AI / ML model flow identifier and a specific data / stream identifier.

[0088] Model Selection FIG. 5, consisting of FIGS. 5A and 5B, illustrates an exemplary flowchart for distributed AI / ML according to one embodiment.

[0089] FIG. 5 shows a plurality of split node candidates in the network, namely, UE 52, edge device 54, and cloud (e.g., access network) device 56.

[0090] UE 52 includes an AI / ML application 52a and an AI / ML model session handler 52b. The AI / ML model session handler 52b is configured to interact with an AI / ML application function (AF) 51 to discover and select a model. The AI / ML application provider 55 is configured to interact with an AI / ML model application server (AS) 53 to provide AI / ML models and model subsets to the split node applications.

[0091] In step S501, the AI / ML application provider 55 sends messages related to service notification and provisioning that indicate, for at least one AI / ML service, an alternative architecture topology that the application provider can provide to the UE, for example, via 5GS. The message can include the AI / ML service name (e.g., split AI / ML image recognition, extended media recognition, media quality enhancement) and information regarding the split mode capability (i.e., an indicator of whether the split mode is permitted).

[0092] In step S502, the AI / ML AF 51 and the AI / ML AS 53 interact with the AI / ML application provider 55 to incorporate the AI / ML model and the related AI / ML subset that make up the proposed AI / ML model. As already mentioned, the AI / ML subset is the basic part of the software that can be executed independently on the UE, edge device, or cloud device. The UE, edge device, or cloud device can execute one or more AI / ML subsets. For example, the UE can host the AI / ML model subsets M0, M0’, or M0”, and each model subset is related to the same AI / ML model but is generated from different split points. The same technology is extended to the edge and the cloud. The main condition is that the subsets executed on the UE and / or on the edge and / or on the cloud are complementary.

[0093] In step S503, the UE 52 selects an AI / ML model service from among the AI / ML model services proposed by the AI / ML application provider in step S501. The UE 52 can select, for example, "split AI / ML image recognition".

[0094] In step S504, the AI / ML application 52a of the UE 52 starts the selection of the AI / ML model service using the AI / ML model session handler 52b. The selection can indicate, for example, one or more of the following.

[0095] For example, service request information including one or more of the following: - Service name, for example, split AI / ML image recognition, - Service-specific information, for example, the resolution scale required for an extended media recognition service, and the animals to be recognized for an object recognition service, - Service quality, for example, the required accuracy or precision, - Service requirements including, for example, the following: - End-to-end inference maximum predicted latency, for example, maximum predicted latency result: 20 ms, - UE-assigned specific tasks, for example, tasks to be executed by the UE such as a privacy protection service task or a latency-sensitive service task.

[0096] For example, model request information including one or more of the following: - Model type - Model identifier - Identified model parts self-assigned to the UE. The UE may know the model decomposition structure and, for example, send to the network the metrics of the model parts to be processed locally regarding the service requirements of the following UE-specific tasks: - UE minimum start model part up to a defined known split point, - UE end model part starting from a known split point, - Identified model parts assigned to the network. The UE may know the model decomposition structure and cannot process the identified model parts, for example, the following computationally intensive parts: - Network minimum start model part up to a defined known split point, - Network minimum end model part starting from a known split point.

[0097] UE AI / ML engine, that is, the engine used to execute an AI / ML application including the engine version.

[0098] For example, a UE profile including, for example, its OS and UE capabilities, such as the following maximum allocation, availability, average, and capacity: - Available memory allocated for AI / ML services, - Processing capabilities (CPU / GPU / TPU / NPU) available for UE inference, - Maximum available energy consumption, - Arithmetic performance capabilities (e.g., floating-point operations per second, aka flops).

[0099] Network capabilities, including, for example, the available bandwidth between the UE and network nodes (RAN / edge / cloud / application server / core network node).

[0100] Allocation configuration (preferred or available), for example: - Delivery modes including progressive download, DASH streaming, or real-time transport (e.g., RTP), - Delivery modes on the device such as unicast / multicast / broadcast, etc.

[0101] Split-mode UE support indicating whether the UE supports AI / ML subset inference.

[0102] Split-mode service support types: edge, cloud, or edge and cloud.

[0103] Perceived data estimation bandwidth (in the case of a UE source, as shown in Figure 3).

[0104] In step S505, the AI / ML model session handler 52b sends an AI / ML model service request including the information received from the AI / ML application 52a in step S504 to the AI / ML AF51.

[0105] In step S506, the AI / ML AF51 calculates an AI / ML model service response based at least on the information received in step S505. Information that can also include additional information can include, for example, the capabilities of the split nodes and network conditions (e.g., for at least one of the edge device and the cloud device, depending on the configuration). The network selects a set of adapted models for the UE. If no model is available, the network may build or incorporate a new model.

[0106] The information to be included in the response can include one or more of a service description, an alternative to the split configuration, and the conditions when inferring an AI / ML subset on a specific split node. Each of these will be described here.

[0107] Service description The service description can be a model identifier assigned directly by the AI / ML AF51 or on behalf of the AI / ML application provider 55.

[0108] Alternative to the split configuration These include alternatives of different AI / ML models corresponding to the request. It can enumerate a subset combination including different split nodes of different alternatives. Continuing with the example illustrated in FIG. 2, the models can be M, M', M'' as follows.

[0109] [Table 1]

[0110] The alternative to the split configuration can also include the capabilities of different split nodes for the execution of the AI / ML model subset. For example, the split nodes can serve model subsets from different models M, M', M'' as follows.

[0111] [Table 2]

[0112] An alternative to the split configuration can also include the AI / ML model subsets that the split node is currently serving. This means that there is no need to pre-provision for these subsets as follows.

[0113]

Table 3

[0114] An alternative to the split configuration can also include model subset information. This information can include information about the model such as, for example, direction (uplink / downlink), size, and bandwidth. This information can also include network information for downloading such as, for example, link and network addresses.

[0115] Conditions when inferring an AI / ML subset on a specific split node.

[0116] For each candidate selection pair (split node, AI / ML subset), the conditions can include one or more of the following (with exemplary units of measurement in parentheses). - Output data bandwidth (Mb / s): The bandwidth required to transmit the output AI / ML data, which can be the uplink or downlink (or both) depending on the selected topology. - Inference latency (ms): The latency from receiving the input AI / ML data to serving the output AI / ML data.

[0117] Inference setup time (ms): This can indicate the average time to download, and in some cases compile to the AI / ML engine, load into memory, and execute the inference. When the split node is already executing the AI / ML subset as described above, the setup may only need to be done once, so the setup can be immediate.

[0118] Energy consumption (mJ): This may indicate a quantitative estimate of the energy required to execute the inference. It can be said that this is particularly interesting for the UE to predict battery consumption.

[0119] [Table 4]

[0120] For example, the following delivery configurations for a model or model subset that includes each delivery average: - Delivery modes such as progressive download or DASH streaming, real-time transport (e.g., RTP), - Application server information such as information for connecting to the server to obtain a UE model subset. - Delivery modes such as unicast / multicast / broadcast

[0121] The following Table 1 depicts exemplary conditions required to execute a given AI / ML subset on a target split node for a selected service that includes any of the configurations of M, M', and M".

[0122] In step S507, the AI / ML AF51 sends the computed response to the AI / ML model session handler 52b.

[0123] In step S508, UE 52 processes the information from the AI / ML AF and selects (chooses) a segmentation model with a specific breakdown. The selection can be based on its own environmental conditions (e.g., bandwidth, latency requirements, energy requirements, and / or security / privacy considerations). For example, UE 52 can select model M (M0, M1, M2) such that UE segmentation node #504 infers subset M0, edge segmentation node #6 infers M1, and cloud segmentation node #1 infers M2. In addition to selecting the segmentation breakdown / composition candidates, the UE can also select the corresponding delivery configuration for the UE model subset. In other words, in this example, the following are selected.

[0124]

Table 5

[0125] As an example, assume that the UE selects to execute M0 locally on the UE, for example, for security or privacy reasons. Without these reasons, the UE might instead have selected to execute the M0 inference on edge server #6 to optimize performance criteria.

[0126] In step S509, the AI / ML model session handler 52b sends the selected configuration to the AI / ML AF 51.

[0127] In step S510, the AI / ML AF 51 triggers the AI / ML model AS 53 to provision the selected AI / ML model subset to each target segmentation point server.

[0128] The AF notifies the AI / ML application provider of the model selection, and the AI / ML application provider, in step S511, instructs the edge segmentation node 54 and the cloud segmentation node 56 to fetch the network AI / ML model subset.

[0129] In step S512, UE52 starts model delivery via the AI / ML model session handler 52a, and the AI / ML model session handler 52a establishes one or more transport sessions with the AI / ML model AS53 in step S513. The AI / ML model AS53 sends a UE model subset that can be divided into multiple parts (sent respectively in steps S514_1... S514_i... S514n) to the UE splitting node 52 in step S514.

[0130] In step S515, the AI / ML model session handler 52b notifies the AI / ML application 52a of the completion of delivery.

[0131] Continuing with the example, M0 is provided to UE52, M1 is provided to the edge device 54, and M2 is provided to the cloud device 56. Note that M0 can be provided to the UE at an earlier time, for example, in the response sent in step S507, by providing a link to download the subset, for example.

[0132] In one embodiment, UE52 may request the establishment of a transport session to download or stream the relevant AI / ML subset, such as M0.

[0133] In another embodiment, the AI / ML AF51 may provide UE identification, UE permission, and other features to the AS53.

[0134] In a further embodiment, in step S506, the AI / ML AF51 calculates a response to the UE according to a list of criteria ordered by, for example, latency, energy, or bandwidth. Examples of such a list are as follows. Low latency, low energy, UE BW = 1Mbps Default #0: {#504: M0, #6: M1, #1M2}, Alternative #1: {#6:M0, #6:M1, #1M2} Low latency, low energy, BW = 8 Mbps Default #0: {# <x> :M0、# <y> :M1、# <z>M2}、 Instead of #1: {# :M0、# <v> :M1、# <w>M2}、 High latency, low energy, BW = 15 Mbps Default #0: {# <x> :M0、# <y> :M1、# <z>M2}、 Replace #1: {# :M0、# <v> :M1、# <w>M2}、 Low latency, medium energy, BW = 4 Mbps Default #0: {# <x> :M0、# <y> :M1、# <z>M2}、 Replace #1: {# :M0、# <v> :M1、# <w>M2}、 Low latency, medium energy, BW = 12 Mbps Default #0: {# <x> :M0、# <y> :M1、# <z>M2}、 Instead of #1: {# :M0、# <v> :M1、# <w>M2}、 Medium latency, medium energy, BW = 4 Mbps Default #0: {# <x> :M0、# <y> :M1、# <z>M2}、 Replace #1: {# :M0、# <v> :M1、# <w>M2}、 Medium latency, medium energy, BW = 20 Mbps Default #0: {# <x> :M0、# <y> :M1、# <z>M2}、 Instead of #1: {# :M0、# <v> :M1、# <w>M2}、 High latency, medium energy, BW = 0.5 Mbps Default #0: {# <x> :M0、# <y> :M1、# <z>M2}、 Replace #1: {# :M0、# <v> :M1、# <w>M2} ...

[0135] In this embodiment, in step S508, the UE interprets the information received regarding its own environmental conditions (e.g., bandwidth, latency requirements, energy requirements) and selects an appropriate option, e.g., a formula that provides the best match for those conditions.

[0136] In yet another embodiment, the service notification step S501 can indicate which optimized criteria (e.g., latency, energy, bandwidth) the UE can select. The AI / ML application can be configured with preferred criteria such that the UE pre-selects its best criteria when requesting the model to the AI / ML AF in steps S504, S505.

[0137] Split Node Configuration and Session Establishment Embodiment with Service Provider Source FIG. 6 illustrates an example of a split node configuration. In this example, the AF is requesting the execution of the cloud, AI / ML subset M0 within split node #2, and the UE, subset M1 on split node #504. The AF is further requesting the establishment of two data transport sessions. The first session, session ID #0611, is established to enable data ingestion to the cloud application server (AS) (e.g., from an AI / ML application provider or another source). The second session, session ID #0622, is a downlink data session from the cloud to the UE for transporting AI / ML data, i.e., the data output from M0 that is used as input by M1. It should be noted that this example uses a cloud split node (see FIG. 4(b)), but it will be understood that an edge split node can also be used alternatively (see FIG. 4(a)) or additionally (see FIG. 4(c)).

[0138] FIG. 7 illustrates a flowchart for split node configuration and data session establishment according to one embodiment.

[0139] In step S702, the AI / ML AF74 sends a split node configuration request to the first selected split node, for example, the cloud split node #1. The request includes information for configuring and executing the selected and provisioned AI / ML subset M0, such as information for establishing a data session, as well as a metadata identifier for identifying data types (sensing data, AI / ML data, result data), and a model identifier.

[0140] In step S704, the cloud split node 76 configures and executes the provisioned AI / ML subset, for example, M0.

[0141] In step S706, the cloud split node 76 sends a split node configuration response to the AI / ML AF74 to notify the completion of the request.

[0142] Steps S708 - S712 are the same as steps S702 - S706, except for the UE split node.

[0143] In step S708, the AI / ML AF74 sends a split node configuration request to the second selected split node, for example, the AI / ML data session handler 72a of the UE split node #504. The request includes information for configuring and executing the selected and provisioned AI / ML subset M1, such as information for establishing a data session, as well as a metadata identifier for identifying data types (sensing data, AI / ML data, result data), and a model identifier.

[0144] In step S710, the UE split node 72 configures and executes the provisioned AI / ML subset, for example, M1.

[0145] In step S712, the AI / ML data session handler 72a sends a split node configuration response to the AI / ML AF74 to notify the completion of the request.

[0146] At this point, the AI / ML AF74 has received notification of a successful configuration notification from the participating split nodes.

[0147] An example of the configuration information is shown in the following table.

[0148]

Table 6

[0149] In step S714, the AI / ML AF74 sends a split node session establishment request to establish a transport session between the cloud split node 76 as the source split node and the UE 72 as the target split node. As understood, the source split node provides data to the target split node.

[0150] In an alternative embodiment, the AI / ML AF74 sends a split node session establishment request to the target split node instead of the source split node. In a further alternative, the AI / ML AF74 sends a split node session establishment request to both the target split node and the source split node to ensure, for example, the reliable identification and registration of peer split nodes.

[0151] In step S716, the source split node creates a data / streaming session with the target split node according to the split configuration received in step S702. In the example, one transport session, i.e., a downlink cloud-UE session for AI / ML data (session ID #0622, (see Figure 6).

[0152] In step S718, the target split node sends a message to the source split node to positively respond to the success of the data session establishment.

[0153] In step S720, upon receiving a "success message", the source splitting node returns a splitting node session establishment response to the AI / ML AF74 to signal successful session establishment.

[0154] In step S722, after receiving the successful establishment notification, the AI / ML AF74 sends a splitting model establishment notification to the source splitting node indicating that it can receive sensing data. This notification triggers the AI / ML application provider (or other source) to start sensing data.

[0155] Note that this method can be easily extended to include additional devices, for example when M0, M1, and M2 are inferred on different devices. It will be understood that a device, such as the device having M1, can serve as both a source and a target, receiving AI / ML data from one and sending AI / ML data to the other.

[0156] Embodiment with UE source Figure 8 illustrates a further example of a split node configuration. In this example, AF requests the execution of an AI / ML subset M0 on a UE, on split node #504, and a subset M1 within a cloud, within split node #6. AF further requests the establishment of three data transport sessions. The first session, session ID #0811, is established from the UE to enable data capture, for example from a camera. The second session, session ID #0822, is an uplink data session from the UE to the cloud split node for transporting AI / ML data, i.e., data output from M0 that is used as input by M1. The third session, session ID #0833, is a downlink data session from the cloud split device to the UE. Note that this example uses a cloud split node (see Fig. 3(b)), but it will be understood that an edge split node may also be used instead (see Fig. 3(a)) or in addition (see Fig. 3(d)).

[0157] Figure 9 illustrates a flowchart for split node configuration and session establishment according to a further embodiment.

[0158] In steps S902 and S910, AI / ML AF94 sends split node configuration requests to an AI / ML data session handler 92b within UE92 and an AI / ML data session inferencer 96a within cloud split node #1, respectively. It will be understood that this step is similar to steps S708 and S702 of Fig. 7. As used herein, an "inferencer" is an entity (e.g., a processor) that performs inferences, i.e., processes sensed or intermediate data using at least one AI / ML subset and executes AI / ML processing to obtain intermediate data or results.

[0159] An example of the configuration information is shown in the following table.

[0160] [Table 7]

[0161] In steps S904 and S910, the split node, UE92, and cloud split node 96 respectively configure and execute the provisioned AI / ML subset (M1 for the cloud AS and M0 for the UE).

[0162] In steps S906 and S912, the split nodes respectively send a split node configuration response to the AI / ML AF94 to notify the completion of the request.

[0163] As can be seen, steps S902 to S912 are the same as steps S702 to S712 in FIG. 7. At this point, the AI / ML AF94 has received a notification of a successful configuration notification from the participating split nodes.

[0164] In steps S914 and S922, the AI / ML AF94 respectively sends a split node session establishment request to the AI / ML data session inferencer 92c in the UE92 and the AI / ML data inferencer 96a in the cloud split server 96 to establish a transport session between the source split node in the UE and the target split node in the cloud split node. In this example, the request is sent to the source split node to create a transport data session to the target split node, that is, to send data. As described with reference to FIG. 7, the request can be sent to both the source split node and the target split node.

[0165] In steps S916 and S924, the source split node creates a data transport session with its corresponding target split node according to the split configuration received in steps S902 and S908, respectively. In this embodiment, according to FIG. 8, three established transport sessions are as follows: an uplink UE streamer-cloud (session ID #0822) for transporting AI / ML data, and a downlink cloud-UE player (session ID #0833) for result data. The data session ID of the running model is ID #0800.

[0166] In steps S918 and S926, the target split node respectively sends an affirmative response to the successful establishment of the data session to the source split node.

[0167] In steps S920 and S928, in response to the "success message" (in steps S918 and S926 respectively), the source split node respectively sends a split node session establishment response to AI / ML AF94.

[0168] In step S930, upon receiving the "success message", AI / ML AF94 sends a split model establishment notification to the source split node sensing data 92a, that is, the AI / ML application within the UE in this example. The notification triggers the AI / ML application 92a to start sensing and providing data.

[0169] Split Node Configuration and Session Establishment with Edge Devices Embodiment with UE Source This embodiment corresponds to what is illustrated in FIG. 3(d).

[0170] In this example, the AF requests the execution of AI / ML subsets M0 on the UE, M1 on the edge device, and M2 in the cloud. The AI / ML AF further requests the establishment of four data transport sessions. The first session, #1011, is for data ingestion from the UE. The second session, #1022, is an uplink data session from the UE to the edge device for transporting AI / ML data. The third session, #1033, is an uplink data session from the edge device to the cloud for transporting AI / ML data. The fourth session, #1044, is a downlink data session from the cloud AS to the UE for transporting the results.

[0171] FIG. 10, which consists of FIGS. 10A and 10B, illustrates a flowchart for split node configuration and session establishment according to a further embodiment.

[0172] In step S1002, the AI / ML subset is provisioned to the target split node by the AI / ML model AS.

[0173] In steps S1004 - S1008, respectively, the AI / ML AF1005 sends a split node configuration request to the AI / ML data session handler 1001b within the UE1001, and the AI / ML data session handler 1001b starts the AI / ML subset inference M0 and sends a split node configuration response to the AI / ML AF1005.

[0174] The request configures the provisioned AI / ML subset and provides information for its execution. The information includes data types (sensing data, AI / ML data, result data), data sessions (a path M0, M1, M2 that defines the model instance in use, global and common data identifiers for the entire M0, M1, M2, and metadata identifiers for identifying data such as specific session data session identifiers), which can be used to establish transport data sessions (see, for example, step S1022).

[0175] Steps S1004 to S1008 are the same as steps S902 to S906 in FIG. 9.

[0176] Steps S1010 to S1014 are essentially the same, but differ in that they include the edge splitting node 1003 and the subset M1.

[0177] Similarly, steps S1016 to S1020 are essentially the same, but differ in that they include the cloud splitting node 1005 and the subset M2.

[0178] An example of the configuration information can be found in the following table:

[0179]

Table 8

[0180] At this point, if all goes well, the AI / ML AF1005 has received successful configuration notifications from the three splitting nodes.

[0181] In steps S1022, S1030, and S1038, the AI / ML AF sends split node session establishment requests to the AI / ML data session inferencers 1001c, 1003b, and 1007a, respectively, to establish transport sessions between the respective source split nodes and target split nodes. In this embodiment, the requests are sent to the respective source split devices responsible for creating the transport data sessions to the next split device, i.e., for sending the data. As already explained, the requests can be sent to both the source split device and the target split device.

[0182] In this embodiment, the AI / ML AF plays a central role. In another embodiment, the "direct mode", a source split node, e.g., a UE, directly sends a split node session establishment request to the target split node before notifying the AI / ML AF. In another embodiment, the "recursive mode", the source split node sends a split node session establishment request to its target split node, and the target split node then functions as a source split node and sends a further split node session establishment request to its target split node until the end.

[0183] In steps S1024, S1032, and S1040, each source split node creates a data transport session with its respective target split node according to the received split configuration. In this example, three transport sessions are established. Uplink from UE to edge for the first AI / ML data (session ID #1022). Uplink from edge to cloud for the second AI / ML data (session ID #1033) Downlink from cloud to UE player for the result data (session ID #1044).

[0184] In steps S1026, S1034, and S1042, each target split node sends a message indicating the success of the data session establishment to the corresponding source split device.

[0185] In steps S1028, S1036, and S1044, upon receiving the success message, each source split device sends a split device session establishment response to the AI / ML AF 1005.

[0186] In step S1046, after receiving the successful establishment notification, the AI / ML AF1005 sends a split model establishment notification to the source server that senses the data, i.e., the UE in this example. The notification triggers the AI / ML application to start sensing the data.

[0187] AI / ML Data Transport including AI / ML Metadata The AI / ML specific metadata identifier can include, for example, one or more of the following. ● Model Flow Identifier: An identifier carried with all data transport sessions assigned to a model instance. ○ Model Identifier: A common identifier that identifies the model within each data transport session. ○ Input Model Rate: Indicates the input sensing data rate that can evolve, for example, to 50% or 100%. ● Data Transport Session Identifier: An identifier unique to an individual data transport session established between two split devices, for example: ○ AI / ML Subset Source Identifier ○ AI / ML Subset Target Identifier ○ AI / ML Data Transport Format, for example, 8, 16, or 32 bits ○ AI / ML Data Transport Type, for example ■ Sensed Media Data (e.g., image / video capture) ■ AI / ML Data, also known as intermediate data (e.g., image / video latent code) ■ Result Data: Output "readable" data and result data type, for example: ● Text Type (e.g., dog / cat text discrimination) ● Media Type (e.g., enhanced video AR, video overlay), for example:. ○ Video Type ○ Audio Type ○ Others ○Model rate adaptation: The partitioning device adjusts the frame rate output for resource allocation and can indicate that ratio, e.g., 50%, 100% along the entire flow. ○AI / ML data transport packages, e.g., ■ Compressed data indicator ■ Compression algorithm indicator

[0188] Note that the resulting data can originate from possible initial / intermediate exits of the AI / ML model. Such resulting data can supply another AI / ML subset and is thus also brought to the partitioning node.

[0189] Figure 11 illustrates an example of data transport between AI / ML partitioning devices. The AI / ML application provider (#8) sends sensed data to the cloud partitioning node #1. The metadata for the transmission are model ID #1100, stream ID #1111. The cloud partitioning node uses the AI / ML subset M0 to infer the received sensed data and obtains the AI / ML data to be sent to the AI / ML data session inferencer within the UE partitioning node #504. The metadata for the transmission are model ID #1100 (i.e., the same as the previous transmission), stream ID #1122. The UE then uses the AI / ML subset M1 to obtain the resulting data provided to the AI / ML application within the UE.

[0190] Note that in some descriptions, the AI ML application provider is mentioned as the source of the sensed data, but these data can be provided by another device.

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

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

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

[0194] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, 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 (DVD). A processor associated with the software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

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

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

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

[0198] 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 cooperative or interconnected computer-readable media that exist exclusively on the processing system or are distributed among a plurality of interconnected processing systems that are local or remote to the processing system. It should be understood that the embodiments are not limited to the memories mentioned above, and other platforms and memories may support the provided methods.

[0199] In an illustrative embodiment, any of the 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 body, a network element, and / or any other computing device.

[0200] There is little difference between the hardware implementation and the software implementation of the aspects of the system. Whether to use hardware or software is generally (although in some situations the choice between hardware and software may be crucial) a design choice representing a cost-effectiveness trade-off. There may be various vehicles (e.g., hardware, software, and / or firmware) through which the processes and / or systems and / or other technologies described herein may be effective, and the preferred vehicle may vary depending on the situation in which the process and / or system and / or other technology is deployed. For example, if the implementer determines that speed and accuracy are of utmost importance, the implementer may primarily select a hardware and / or firmware vehicle. If flexibility is of utmost importance, the implementer may primarily select a software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

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

[0202] Those skilled in the art will recognize that it is common in the art to describe a device and / or process in the manner described herein and then, using engineering techniques, integrate such described device and / or process into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally includes one or more of a system unit housing, a video display device, memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, operating systems, drivers, graphical user interfaces, and computing entities such as application programs, one or more interactive devices such as touch pads or screens, 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 as typically found in a data computing / communication system and / or a network computing / communication system.

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

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

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

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

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

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

Claims

1. A method comprising: In a first device, receiving, from a second device, information indicating a plurality of distributed artificial intelligence (AI) models, wherein each of the plurality of distributed AI models corresponds to the same AI service; Transmitting, from the first device to the second device, a message including information indicating a selected distributed AI model selected from the plurality of distributed AI models, the selected distributed AI model including a plurality of model subsets that constitute the AI service; In the first device, receiving information corresponding to the model subset of the selected distributed AI model; Executing, on the first device, the model subset of the selected distributed AI model based on the information corresponding to the model subset.

2. The method according to claim 1, further comprising transmitting, from the first device to the second device, information indicating a request for the AI service before the receiving.

3. The method according to claim 1 or 2, further comprising receiving, in the first device, information indicating the AI service.

4. The method according to claim 3, wherein the information indicating the AI service includes a service identifier and an indicator of whether the AI model for the service can be distributed across a plurality of devices.

5. The method according to claim 1, wherein the message further includes information indicating at least one of an AI engine used by the first device, whether the first device supports a distributed AI model, a type of device permitted to execute the model subset, and an estimated bandwidth of sensed data generated in the first device.

6. The method according to claim 1, wherein the information indicating the plurality of distributed AI models includes information indicating a device that already has a model subset.

7. The method according to claim 1, further comprising determining, by the first device, the selected distributed AI model based on at least one environmental condition of the first device.

8. The method according to claim 7, wherein the at least one environmental condition includes at least one of bandwidth, latency requirements, energy requirements, security considerations, and privacy considerations.

9. The model subset is executed using the sensed data as input to obtain an intermediate result, and the method The method according to claim 1, further comprising outputting, by the first device, the intermediate result to a third device for execution of a further model subset.

10. The method according to claim 9, further comprising receiving, by the first device, the final result of the selected distributed AI model from the device that inferred the final result.

11. The method according to claim 10, wherein the third device is the same as the device that inferred the final result.

12. The final result is received from the third device via an established transport session, and the method The method according to claim 10, further comprising receiving, by the first device, metadata related to the transport session.

13. The intermediate result is provided to the third device via an established transport session, and the method The method according to claim 9, further comprising receiving, by the first device, metadata related to the transport session.

14. The method according to claim 9, wherein the intermediate result includes intermediate data and metadata indicating the nature of the intermediate data.

15. The model subset is executed using the intermediate result as input to obtain a final result, the intermediate result is obtained from a third device that inferred the intermediate result using a further model subset, and the method The method according to claim 1, further comprising outputting, by the first device, the final result.

16. The method according to claim 1, wherein the model subsets of the distributed AI model are configured to execute on at least two different devices.

17. The method according to claim 16, wherein the boundary between the model subsets is defined by a split point.

18. The method according to claim 1, wherein the message further includes information indicating the selected model subset of the selected distributed AI model.

19. A first device, A memory storing processor-executable program instructions, and at least one hardware processor that executes the program instructions to receive, from a second device, information indicating a plurality of distributed artificial intelligence, AI, models, wherein each model of the plurality of distributed AI models corresponds to the same AI service, send to the second device a message including information indicating a selected distributed AI model selected from among the plurality of distributed AI models, the selected distributed AI model including a plurality of model subsets that make up the AI service, receive information corresponding to a model subset of the selected distributed AI model, and at least one hardware processor configured to execute the model subset of the selected distributed AI model based on the information corresponding to the model subset. A first device comprising

20. The at least one hardware processor is further configured to send, to the second device, information indicating a request for the AI service, prior to the receiving. The first device according to claim 19.

21. The at least one hardware processor is further configured to receive information indicating the AI service. The first device according to claim 19 or 20.

22. The information indicating the AI service includes a service identifier and an indicator of whether the AI model for the service can be distributed across a plurality of devices. The first device according to claim 21.

23. The message further includes information indicating at least one of an AI engine used by the first device, whether the first device supports a distributed AI model, a type of device permitted to execute a model subset, and an estimated bandwidth of sensed data generated at the first device. The first device according to claim 19.

24. The information indicating the plurality of distributed AI models includes information indicating devices that already have model subsets. The first device according to claim 19.

25. The at least one hardware processor is The first device according to claim 19, further configured to determine the selected distributed AI model based on at least one environmental condition of the first device.

26. The first device according to claim 25, wherein the at least one environmental condition includes at least one of bandwidth, latency requirements, energy requirements, security considerations, and privacy considerations.

27. The model subset is executed using sensed data as input to obtain an intermediate result, and the at least one hardware processor The first device according to claim 19, further configured to output the intermediate result to a third device for execution of a further model subset.

28. The at least one hardware processor The first device according to claim 27, further configured to receive the final result of the selected distributed AI model from the device that inferred the final result.

29. The first device according to claim 28, wherein the third device is the same as the device that inferred the final result.

30. The first device according to claim 28, wherein the final result is received from the third device via an established transport session, and the at least one hardware processor is further configured to receive metadata associated with the transport session.

31. The first device according to claim 27, wherein the intermediate result is provided to the third device via an established transport session, and the at least one hardware processor is further configured to receive metadata associated with the transport session.

32. The first device according to claim 27, wherein the intermediate result includes intermediate data and metadata indicating the nature of the intermediate data.

33. The model subset is executed using the intermediate result as input to obtain a final result, the intermediate result is obtained from a third device that inferred the intermediate result using a further model subset, and the at least one hardware processor The first device according to claim 19, further configured to output the final result.

34. The first device according to claim 19, wherein the model subset of the distributed AI model is configured to execute on at least two different devices.

35. The first device according to claim 34, wherein the boundary between the model subsets is defined by a splitting point.

36. The first device according to claim 19, wherein the message further includes information indicating a selected model subset of the selected distributed AI model.

37. The first device according to claim 19, wherein the first device is a wireless transmit / receive unit, a WTRU.