Method and apparatus for enabling service function chaining for split aiml computation in wireless systems

Abstract

In some implementations, a method can include detecting an event that triggers creation of a split artificial intelligence machine learning (AIML) procedure. Additionally, the method can include sending a service chain (SC) creation request to a network server, where the SC creation request includes SC characteristics to use in creating a SC profile and a SC. The method can include receiving a SC creation request response from the network server indicating a created SC and an associated SC profile, where the associated SC profile is based at least in part on the SC characteristics, and where the associated SC profile includes at least information about a first SC node that sends intermediate data and information about a second SC node from which an inference result of the SC will be received or to which the WTRU will subscribe to receive the inference result. The method can be performed by a WTRU.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 625,198, filed January 25, 2024, the contents of which are incorporated herein by reference. Background Technology

[0002] Artificial Intelligence Machine Learning (AIML) Split Inference (SI) is generally referred to as a technique for decentralizing the process of performing AIML inference using trained models. AIML-SI can include different AIML models that can be executed on different hardware to derive (multiple) inference results and / or (multiple) predictions. As an example, in a wireless environment, AIML-SI can offload computationally intensive operations to the network while keeping privacy-sensitive data within the wireless device (e.g., UE). Edge computing (EC) is a crucial component in mobile networks for enabling responsive AIML-SI applications. EC can deliver extremely low-latency services to the UE by providing these services near the network edge (i.e., close to the UE). Summary of the Invention

[0003] A system of one or more computers can be configured to perform specific operations or actions by means of software, firmware, hardware, or a combination thereof installed on the system, which, in operation, causes the system to perform actions. One or more computer programs can be configured to perform specific operations or actions by means of instructions that, when executed by a data processing device, cause the device to perform actions.

[0004] In one general aspect, a method may include detecting an event that triggers the creation of a split artificial intelligence machine learning (AIML) process. The method may also include sending a service chain (SC) creation request to a web server, wherein the service chain creation request includes SC features used when creating the SC profile and the SC. Furthermore, the method may include receiving from the web server an SC creation request response indicating the created SC and an associated SC profile, wherein the associated SC profile is at least partially based on SC features, and wherein the associated SC profile includes at least information about a first SC node that sends intermediate data and information about a second SC node from which it will receive inference results from the SC, or a WTRU that will subscribe to receive inference results. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each computer system, device, and computer program configured to perform actions of the method.

[0005] The implementation may include one or more of the following features. The method, wherein the network server includes an SC Management Function (SCMF). The method may include: discovering multiple SC nodes; and selecting one or more SC nodes from the discovered multiple SC nodes. The method, wherein discovering multiple SC nodes may include at least one of sending a Domain Name System (DNS) resolution request to an Edge Application Server Discovery Function (EASDF) or sending an Edge Application Server (EAS) discovery request to an Edge Enabler Server (EES). The method, wherein the SC creation request includes an indication of the selected one or more SC nodes. The method, wherein the event triggering the creation of the split AIML process is at least one of the following: an event triggered by an application client residing on a WTRU or a notification received from the network. The method, wherein the associated SC profile also includes one or more of the following: an SC identifier (SCID), an SC model (SCM), an SC size, or an SC node identifier (SCNID), and wherein each SC node is associated with an application as an AIML model. The method, wherein each SCNID includes at least one of the following: a corresponding SC node role (SCNR) identifier; a corresponding SC node location (SCNP) identifier; or a corresponding SC node application characteristic (SCNAC) identifier. This method, wherein SCNAC includes at least one of the following: application identifier, application type, application version information, application size identifier, or application capability requirement. Implementations of the described technology may include hardware, methods or processes, or tangible computer media. Attached Figure Description

[0006] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the drawings indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system that can implement one or more of the disclosed embodiments; Figure 1B The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram illustrates a system diagram of an example wireless transceiver unit (WTRU) used within a communication system. Figure 1C The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system. Figure 1D The illustration shows that, according to the embodiment, it is possible to... Figure 1A The illustrated system diagram shows yet another example RAN and yet another example CN used within the communication system; Figure 2The illustration shows an example of sequential AIML-SI, where models are linked to form a three-stage AIML-SI model; Figure 3 The illustration shows an example of data parallelism AIML-SI, where a model is used in parallel instances of application functionality; Figure 4 The illustration shows an example of model-parallel AIML-SI used for combined prediction; Figure 5 This illustration shows an example of a model-parallel AIML-SI used for distributed prediction; Figure 6 This diagram illustrates a high-level view of the SC lifecycle; Figure 7 The diagram illustrates an example process for creating a service chain; Figure 8 This diagram illustrates an example of the service chain management process; Figure 9 The illustration shows an example of service chain management functionality that links business forwarding and proxy system flows; and Figure 10 This is a flowchart of an example process for creating a service chain. Detailed Implementation

[0007] The following abbreviations may be referenced in the following descriptions: 5GC 5G core 5GS 5G system AC Application Client ACID application client identifier AIML (Artificial Intelligence Machine Learning) AS Application Server CAS Cloud Application Server CN Core Network DL downlink DN Data Network EAS Edge Application Server EASDF Edge Application Server Discovery Function ECS Edge Configuration Server EDC Edge Discovery Client EDN Edge Data Network EEC Edge Enabler Client EEL Edge Enable Layer EES Edge Enabler Server FQDN (Fully Qualified Domain Name) IE Information Elements LTE Long Term Evolution, such as from 3GPP LTE Release 8 and later. NEF Network Open Functions NF Network Functions PCF policy control function PDU (Packet Data Unit) PSA PDU Session Anchor RAN (Radio Access Network) SC service chain SC5PI Service Chain 5GC SFC Policy Information SCA Service Chain Analysis SCACID service chain allows consumer identifiers SCANID is the allowed node identifier in the service chain. SCAU service chain allowed UEs SCCCID Service Chain Current Consumer Identifier Current status of SCCS service chain SCER Service Chain Environment Rules SCID (Service Chain Identifier) SCMF Service Chain Management Function SCM Service Chain Model SCNAC Service Chain Node Application Features SCNC service chain node configuration SCNID Service Chain Node Identifier SCNP service chain node location SCNR Service Chain Node Role SCNSI Service Chain Node Subscription Information SCOID (Service Chain Owner Identifier) SCS Service Chain Size SCT Service Chain Type SCTD Service Chain Business Descriptor SI Decomposition Reasoning SFC Service Function Links SFF Service Function Forwarder SMF Session Management Function TSP Business Shift Strategy UE User Equipment UL uplink UPF User Plane Functions URI (Universal Resource Identifier) URL (Universal Resource Locator)

[0008] Figure 1AThis diagram illustrates an example 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, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing 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 Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0009] like Figure 1A As shown, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. Although it will be appreciated, 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. For example, WTRUs 102a, 102b, 102c, and 102d (any one of which may be referred to as a Station (STA)) may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, 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 industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0010] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (such as gNodeBs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are depicted as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0011] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area for radio services, which may be relatively fixed or may change over time. A 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 multiple transceivers may be used for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0012] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can 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 can be established using any suitable radio access technology (RAT).

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

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

[0015] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

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

[0017] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement the following radio technologies, such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0018] Figure 1A Base station 114b can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a commercial area, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0019] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data may have different 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 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions, such as user authentication. Although... Figure 1AAs not shown, but as will be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0020] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0022] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments.

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

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

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

[0026] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate, for example, via multiple RATs (such as NR and IEEE 802.11).

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

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

[0029] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0030] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

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

[0032] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to one embodiment. As indicated above, RAN 104 employs E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0033] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

[0035] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by the entity rather than by a CN operator.

[0036] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0037] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0039] CN 106 facilitates communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0042] In Infrastructure Basic Services Set (BSS) mode, a WLAN 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 carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be reached via the AP and delivered to the STA. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode can exist without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0043] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some representative embodiments, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0044] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0045] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is passed through a segment resolver that divides the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

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

[0048] In the United States, the available frequency band for 802.11ah is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. Depending on the country code, the total available bandwidth for 802.11ah ranges from 6MHz to 26MHz.

[0049] Figure 1D The diagram illustrates a system diagram of RAN 104 and CN 106 according to one embodiment. As indicated above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0050] RAN 104 may include gNBs 180a, 180b, and 180c, although it will be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each 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 gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0051] WTRUs 102a, 102b, and 102c can use transmissions associated with scalable digitization. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various or scalable lengths or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

[0052] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without access to other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, and simultaneously communicate with / connect to another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can act as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRU 102a, 102b, and 102c.

[0053] 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, network slicing support, networking between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0054] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0055] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the service types utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be built 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, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0056] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure service routes through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0057] UPF 184a and 184b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface. These gNBs can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184a 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 DL packets, and providing mobility anchoring.

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

[0059] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions may be performed by one or more emulation devices (not shown) to perform one or more of the functions described herein with respect to one or more of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0060] Simulation devices can be designed to perform tests on one or more other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more or all of their 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 simulation devices can perform one or more or all of their functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device and / or use over-the-air wireless communication to perform tests for testing purposes.

[0061] One or more emulation devices may perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used to test scenarios in a laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to enable testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0062] Edge computing in wireless cellular networks is a feature described in the 3GPP specifications; it was introduced in Rel-17 and subsequently enhanced in Rel-18 and Rel-19. Edge computing enables WTRUs (Wireless Transmission Units) to discover low-latency services offered in their vicinity; it also defines the service continuity capability to maintain low-latency service connectivity during WTRU mobility incidents. 3GPP specifies two different edge computing frameworks.

[0063] The edge computing framework is available within the 5G core network and is described in 3GPP TS 23.548 – 5G System Enhancements for Edge Computing (Release 18). This framework is primarily network-based and provides a basic set of edge computing capabilities, designed to have minimal impact on the WTRU implementation. On the WTRU, an optional Edge Discovery Client (EDC) is defined as a supporting function to assist in DNS discovery for edge servers. On the network side, the Edge Application Server Discovery Function (EASDF) can act as a DNS server to help resolve DNS requests used to discover Edge Application Servers (EAS). The framework's main functions include EAS discovery and EAS relocation.

[0064] Different edge computing frameworks are available as Application Edge Enablement Layers (EELs) above the 5G core network and below the application layer. This framework is described in 3GPP TS 23.558 – Architecture for Enabling Edge Applications (Version 18) and follows the Service Enablement Architecture Layer (SEAL) principles, providing a richer set of edge computing capabilities. On the WTRU, the Edge Enabler Client (EEC) acts as a proxy interacting with edge functional entities located in the network to provide edge functionality to the Application Client (AC). On the network side, the Edge Configuration Server (ECS) and Edge Enabler Server (EES) functional entities provide the necessary functionality for the EEC to discover and utilize edge services offered throughout the network. Key framework functions include service provisioning, EAS discovery, service continuity and planning, dynamic EAS instantiation, and support for various group use cases (e.g., groups of WTRU instances using EAS, bundles of EAS providing services, etc.).

[0065] These two frameworks can coexist and have different functional entities and capabilities. In contrast, the EAS discovery provided in each framework is different; for example, in the 5G core network, EAS discovery is based on the DNS protocol and uses EASDF, while in the edge enablement layer, EAS discovery is implemented using a dedicated HTTP procedure between the EEC (UE) and EES.

[0066] End-to-end service delivery typically requires the use of multiple services; the service forwarding over these services is called Service Function Link (SFC). In 3GPP radio networks, SFC is a capability provided by the 5G core network that allows Application Functions (AFs) to use the Network Open Functions (NEF) Service Impact API to indicate an SFC policy identifier in order to activate a service classifier in the data path. It is important to note that the SFC functionality defined in 3GPP is limited to service classification and does not include the service function forwarding functionality associated with SFC.

[0067] The SFC policy is (pre-)provided in the Policy Control Function (PCF) and indicates the set of Service Redirection Policies (TSPs); when the SFC policy is activated, the PCF requests the Session Management Function (SMF) to configure service redirection rules for the UPF according to the defined TSPs(s). The AF is pre-configured with available SFC policy identifiers.

[0068] SFC (Service Controller) in a wireless network requires a service agreement between the operator and the Application Service Provider (ASP) to provide SFC policies in the PCF (Programmable Provider Function). The operator needs to provide SFC policies in the PCF, and the ASP needs to configure SFC policy identifiers in the AF (Application Function) according to the SFC policies provided by the operator.

[0069] Operational decomposition between AIML endpoints has been identified as a promising technique that should be supported in wireless systems. AIML decomposition inference is a technique for decentralizing the execution of AIML inference using trained models. AIML decomposition inference (AIML-SI) involves using different AIML models, typically executed on different hardware, to derive (multiple) inference results and / or (multiple) predictions. For example, in a wireless environment, the benefit might be keeping privacy-sensitive data in the UE while offloading computationally intensive data to the network.

[0070] Figure 2 The diagram illustrates an example of sequential AIML-SI, where models are linked to form a three-stage AIML-SI model. Stage 1 202 can reside on WTRU 204 as an application client or service, and Model A 206 can represent the head of the chain. Model A 206 can generate Stage 1 intermediate results 210 (e.g., Stage 1 intermediate datasets) based on analytics 208 available at WTRU 204. Stage 1 intermediate datasets 210 can be passed to Stage 2 inference 212. AF can provide Stage 2212 inference as a service, and Stage 2 can perform inference using Model B 214 based on the Stage 1 intermediate datasets 210 and analytics 216 available in the network. Stage 2 inference 212 can generate Stage 2 intermediate datasets 218, which can be passed to Stage 3 inference 220. Phase 3 inference 220 can be provided as a service by AF. Phase 3 inference 220 can represent the tail of AIML-SI. Phase 3 can perform inference using model C 222 based on the intermediate dataset 218 of Phase 2, and Phase 3 inference can derive results 224. The results of AIML-SI can be consumed by WTRU 204 or AF 226 to perform actions based on the AIML-SI results.

[0071] Figure 3 The illustration shows an example of data-parallel AIML-SI, where a model is used in parallel instances of applied functionality. In this example, the intermediate datasets from Stage 1 provided to each Stage 2 model may differ; a data-parallel AIML-SI model can be used when results are required in a time-sensitive manner. The results of AIML-SI can be consumed by WTRU or AF to perform actions based on the AIML-SI results.

[0072] like Figure 3As illustrated, Phase 1 302 can reside on WTRU 304 as an application client or service, and Model A 306 can represent the chain head. Model A 306 can generate Phase 1 intermediate results 310a, 310b, and 310c (e.g., Phase 1 intermediate datasets) based on analytics 308 available at WTRU 304. Phase 1 intermediate dataset 310a can be passed to Phase 1 2 inference 312a, Phase 2 inference 312b, and Phase 2 inference 312c. Phase 1 2 inference 312a can use Model B 314a to perform inference based on the Phase 1 intermediate dataset 310a and analytics 316a available in the network. Phase 1 2 inference 312a can produce result 318a.

[0073] The Stage 1 intermediate dataset 310b can be passed to the Stage 2 inference dataset 312b. The Stage 2 inference dataset 312b can use Model B 314b to perform inference based on the available Stage 1 intermediate dataset 310b and analysis 316b in the network. The Stage 2 inference dataset 312b can produce a result 318b. The Stage 1 intermediate dataset 310c can be passed to the Stage 2 inference dataset 312c. The Stage 2 inference dataset 312c can use Model B 314c to perform inference based on the available Stage 1 intermediate dataset 310c and analysis 316c in the network. The Stage 2 inference dataset 312c can produce a result 318c. Model 314c can represent the chain tail. Each dataset 310a, 310b, and 310c can be different. The AIML-SI results 320a and / or 320b can be consumed by WTRU 304 or AF322 to perform actions based on the AIML-SI results.

[0074] Figure 4 An example of model-parallel AIML-SI used for combined prediction is illustrated. Figure 4 In the example, different AIML models are used in parallel instances of the application functionality. Figure 4 The illustrated model-parallel AIML-SI can consume intermediate results from different domains (e.g., from UE, RAN, and CN) to produce combined inference results or predictions.

[0075] like Figure 4As illustrated, the first stage 402 of inference can reside on WTRU 404 as an application client or service, and model A 406 can represent the head of the chain. Model A 406 can generate a stage 1 intermediate result 410 (e.g., a stage 1 intermediate dataset) based on analytics 408 available at WTRU 404. The stage 1 intermediate dataset 410 can be passed to the fourth stage 428 of inference. The second stage 412 of inference includes model B 414, which can generate a stage 2 intermediate result 418 based on analytics 416 available at the second stage 412. The second stage 412 can pass the stage 2 intermediate result 418 to the fourth stage 428.

[0076] The third stage of inference 420 includes model C 422, which can produce a stage 3 intermediate result 426 based on the analysis 424 available at the third stage 420. The third stage 420 can pass the stage 3 intermediate result 426 to the fourth stage 428. The fourth stage of inference 428 includes model D 430, which can produce a stage 4 result 434 based on intermediate results 410, 418, and 426. Model 430 can represent the tail of the chain. Stage 4 results 434a and / or 434b can be provided to WTRU 404 or AF 436.

[0077] Figure 5 The illustration shows an example of a model-parallel AIML-SI used for distributed prediction.

[0078] exist Figure 4 and Figure 5 In the example, different AIML models are used in parallel instances of the application functionality. Figure 5 The illustrated model-parallel AIML-SI can consume intermediate results from a single domain (e.g., from the UE) to produce distributed inference results or predictions. The AIML-SI results(s) can be consumed by WTRU or AF to perform actions based on the AIML-SI results.

[0079] like Figure 5 As illustrated, Phase 1 502 can reside on WTRU 504 as an application client or service, and Model A 506 can represent the chain head. Model A 506 can generate Phase 1 intermediate results 510a, 510b, and 510c (e.g., Phase 1 intermediate datasets) based on analytics 508 available at WTRU 504. Phase 1 intermediate dataset 510a can be passed to Phase 2 512, Phase 3 514, and Phase 4 516 of inference. Phase 2 inference 512 can use Model B 518 to perform inference based on Phase 1 intermediate dataset 510a and analytics 520 available in Phase 2 512. Phase 2 inference 512 can produce result 522.

[0080] The intermediate dataset 310b from stage 1 can be passed to the third stage of inference 514. The third stage of inference 514 can use model C 542 to perform inference based on the intermediate dataset 510b from stage 1 and the analytics 526 available in stage 3. Stage 3 inference 514 can produce a result 528. The intermediate dataset 310c from stage 1 can be passed to the fourth stage of inference 516. The fourth stage of inference 516 can use model D 530 to perform inference based on the intermediate dataset 310c from stage 1 and the analytics 532 available in stage 4. Stage 4 inference 516 can produce a result 534. Model D 530 can represent the tail of the chain. Each dataset 510a, 510b, and 510c can be different. The AIML-SI results 536a and / or 536b can be consumed by WTRU 504 or AF 538 to perform actions based on the AIML-SI results.

[0081] It should be understood that in the AIML-SI example above, the (multiple) consumers of the AIML-SI result can be the tail of the AIML-SI chain and can be a single entity, such as WTRU or AF, or can be multiple consumers.

[0082] The 5G core network (5GC) EEL framework provides the ability to discover EAS groups (called EAS bundles). The EEL supports two types of EAS bundles: direct EAS bundles and composite EAS bundles.

[0083] A direct EAS bundle is represented by a group of EAS instances (e.g., AFs) that are directly accessed by the WTRU and managed as a group; an example of a topology similar to a direct bundle is... Figure 3 and Figure 5 The topology shown.

[0084] A composite EAS bundle is represented by a set of EAS instances, where only one instance can be accessed by a WTRU. Figure 2 An example of a topology similar to a composite bundle is shown.

[0085] The EAS bundle may be similar to the split AI / ML model in terms of topology, but it has limitations that prevent the implementation of split AI / ML computation scenarios.

[0086] To benefit from the use of AIML technology, wireless networks need the capability to support AIML applications that can be implemented using various AIML models. As AIML models become increasingly complex, it is necessary to support decentralized AIML models to minimize power consumption on the WTRU (e.g., by limiting inference processing and data transmission) and protect the privacy of sensitive information. Supporting applications using split AIML models provides mobile network operators with an opportunity to allow users to benefit from complex AIML models while preserving battery life and protecting privacy.

[0087] Supporting applications using split AIML models in mobile networks presents several challenges. The first challenge relates to discovering and linking application capabilities to form an AIML split inference pipeline. Specifically, it requires enhancing the discovery capabilities of existing Edge Application Servers (EAS) to support different split AIML models, and SFC is a CN capability that may not be available (e.g., it is optional, not supported during roaming, and requires a pre-provided SFC policy from the operator).

[0088] The second challenge involves identifying and informing entities participating in splitting the AIML inference chain about the chain structure and configuration (e.g., head, tail, result consumers, next stage, and (multiple) associated WTRUs). For example, it's necessary to inform (multiple) result consumers (e.g., WTRUs, AFs, or both) to split the AIML chain tail to subscribe for inference results; in another example, splitting the AIML chain middle node or tail requires knowing (multiple) WTRUs to which the results apply. The third challenge relates to supporting SFC-aware and non-aware AFs, or a combination of both.

[0089] Therefore, service function linking and edge computing enhancements are driven by the needs of AIML applications. Due to the limited capabilities of WTRUs, such as reduced WTRU compute power, limited battery life, and limited network analytics availability, using complex AIML models on WTRUs may be impractical. Split AIML inference is a technique that can be used to run complex AIML models on WTRUs with such capability limitations. WTRU AIML inference is a use case that can leverage existing network capabilities such as edge computing (EC) and service function linking (SFC). EC can allow offloading computationally heavy inference while maintaining low communication latency; SFC can allow dynamic formation of service chains, which may be necessary when AIML models need updating. Service Chain Management Function (SCMF) capabilities can be provided as a service. In one example, SCMF can be implemented as a standalone service, such as an application function (AF) or network function (NF). In another example, SCMF can be implemented as an extension of an existing service. The SCMF framework may not be limited to AIML split inference; it can be applied to other split compute use cases.

[0090] Service Chain Management Function (SCMF) allows a WTRU or Application Function (AF) to configure and manage multiple service chains within a mobile network. SCMF can provide services for managing SC chains, which can be offered to SC users via an Application Programming Interface (API). SCMF functionality can be implemented as a standalone Application Function (AF) or Network Function (NF). SCMF functionality can be combined with existing AFs or NFs, and the API can be provided as an extension of existing APIs.

[0091] SCMF services can be provided using communication protocols, such as the Hypertext Transfer Protocol (HTTP) used in 5G systems or Non-Access Stratum (NAS) protocols, which can provide the ability to provide SCMF services.

[0092] SCMF can create SC profile resources and provide the ability to manage them. Each SC managed by SCMF may have one SC profile. SC profile resources can be created, discovered, enabled, disabled, modified, or deleted at SCMF. SCMF can enable concurrent management of multiple SC profiles (such as SC chains) and can provide SCMF services to multiple concurrent SC owners and SC consumers.

[0093] Figure 6 The diagram illustrates a high-level view of the service chain lifecycle. The service chain (SC) owner can be either a WTRU or an AF, and the SC lifecycle can consist of three phases. In section 602, the SC owner can request the SCMF to create the SC, and the SCMF can create an SC profile based on information provided by the SC owner. The SC profile can include information that uniquely identifies the SC and may include information describing the SC's structure and operations.

[0094] In clause 604, the SC owner can request the SCMF to perform administrative actions on the service chain, and the SCMF can provide the requested information or information related to SC events to the SC owner or SC consumer. Administrative actions can include creating, configuring, enabling, disabling, or modifying the SC. The requested or notified information can include SC discovery information, SC outcome information, SC usage information, or SC analysis information. In clause 606, the SC owner can request the SCMF to terminate the SC, and the SCMF can release resources associated with the SC.

[0095] An SC profile describes how services are linked together and reflects the operational status of an SC. An SC profile may consist of multiple Information Elements (IEs) reflecting both static and dynamic aspects of the SC. For example, static aspects may include SC nodes (e.g., head, tail, intermediate nodes), SC owners, and SC consumers. Dynamic IEs may include current SC consumers or SC analytics, such as average combined SC inference time or average inference time per SC stage.

[0096] A Service Chain Type (SCT) uniquely identifies the type of service chain. An SCT can be associated with a pre-provided Service Chain (SC), or in other words, with an SC template. An SCT can indicate a predefined IE (Information Provider) for the SC profile. For example, a given SCT can provide the SC model, SC size, SC node information, SC 5G SFC policy information, 5G service descriptors, etc. SCTs can be used to facilitate SC owners in discovering or creating SCs. The system can be pre-provided with a set of predefined SCTs. Custom SCs can be created by the SC owner; the SCT for a custom SC should be globally unique. An SCT can be associated with a subset of the IEs of the SC profile, allowing the SCMF (Service Chain Manager) to use information determined from the SCT and information provided at the time of SC creation to form a complete SC profile.

[0097] A Service Chain Identifier (SCID) uniquely identifies a service chain instance. An SCID can be provided by the SC owner when the SC profile is created, or assigned by the SCMF when the chain is provided. An SC profile can include an external SCID assigned by the SC owner and an internal SCID assigned by the SCMF. SC owners, SC users, SC consumers, or SCMFs can use the SCID to identify an instance of an SC.

[0098] A Service Chain Model (SCM) can identify the model of a Service Chain (SC). An SC model can indicate the structure of the SC; for example, an SC model can indicate whether the SC is a sequential SC or a parallel SC. Further, an SC model can indicate whether the SC is used for data-parallel or model-parallel processing. It is understood that the examples provided represent common SC models, and additional SC models may exist. SC models can be used by SC owners to indicate the general structure expected of the SC, and by SC users, SC consumers, or SCMFs to understand the general structure of the SC. SC models can be used to influence interactions with the SC.

[0099] The Service Chain Size (SCS) identifies the number of stages within a service chain. If the chain is sequential, the SC size can represent the number of stages that occur before a result is available, or, in the case of AIML, the inference process. This parameter can also indicate the capabilities of SCMF; for example, the SC profile provided to the SC owner after SC creation can indicate the minimum and maximum chain sizes supported by SCMF; the SC owner can use these values ​​when modifying the SC.

[0100] A Service Chain Node Identifier (SCNID) uniquely identifies each node within a service chain and can be associated with information that allows communication with that node. For example, a node can be an Application Client (AC) of a WTRU or an Application Function (AF) of a network (e.g., Application Function (AF), Application Server (AS), Edge Application Server (EAS), or Cloud Application Server (CAS)). An AC's SCNID can indicate, for example, an ACID identifying the AC and a UE / WTRU identifier (e.g., GPSI) or UE IP address to uniquely identify the node. For example, an AF's SCNID can include a Fully Qualified Domain Name (FQDN), a Generic Resource Locator (URL), a Uniform Resource Identifier (URI), and an IP address that uniquely identifies the node. It can be understood that an SCNID can be a complex type composed of identifiers published by the SCMF and node connectivity information (e.g., GPSI, FQDN, IP address, etc.). SCNIDs can be used by the SCMF when managing the SC chain, or by SC owners, users, or consumers to access SC nodes.

[0101] For each SCNID, the Service Chain Node Role (SCNR) identifies the role of a node instance within the chain. The first node in the chain may have the SC head role; the SC head is likely where the first inference in the chain occurs and is where the first intermediate dataset may originate. The last node in the chain may have the SC tail role; the SC tail is likely where the last inference in the chain occurs and is where results or predictions can be produced. Nodes that are neither head nor tail may be intermediate nodes that consume and produce intermediate datasets. SCs typically have a single head and a single tail; however, data-parallel or model-parallel chains may have several heads and / or several tails.

[0102] For each SCNID, the Service Chain Node Position (SCNP) identifies the position (e.g., stage) of a node instance within the chain. The SC head can have the first node position in the chain; the SC tail can have the last node position; intermediate nodes can be ordered between the SC head and SC tail positions. SC node positions can be numerical or indicated using chained SCNIDs (e.g., previous SCNID, next SCNID). For example, the SC head node can have a next SCNID but no previous SCNID, the SC tail node can have a previous SCNID but no next SCNID, and intermediate nodes can have both a previous SCNID and a next SCNID.

[0103] For each SCNID, the Service Chain Node Application Characteristics (SCNAC) can identify the application or service executed by the SC node, including application characteristics. For example, application characteristics can indicate the application identifier, application type (e.g., AIML model for communication, AIML model for video, AIML model for voice, AIML model for energy efficiency, etc.), application version information (e.g., application version, API version, training model version, etc.), application size, and application capabilities (e.g., SFF requirements, SFC proxy requirements, etc.). It should be understood that the application can be an AI / ML model, and the application identifier / version / size / capabilities can be used interchangeably with the AI / ML model identifier / version / size / capabilities.

[0104] For each SCNID, the Service Chain Node Configuration (SCNC) identifies the configuration of a node instance within the chain. An SC node instance can participate in multiple SCs, handle services related to multiple WTRUs, and have the ability to perform different types of processing. The SC node configuration represents the configuration or parameters that can be provided to the SC node instance when processing data related to the SC profile.

[0105] For each SCNID, the Service Chain Node Subscription Information (SCNSI) identifies the notification endpoints and capabilities of AF nodes within the SC. This information can be used to notify AFs participating in the SC of SC-related events. SCMF can use this information to notify AFs that an AF has been added to the SC or that the SC has been modified.

[0106] The Service Chain 5GC SFC Policy Information (SC5PI) indicates whether the 5GC's SFC capability is used. This information element can indicate to the Service Chain Manager (SCMF) that an SFC policy is provided in the Service Processing Function (PCF) and that the SFC policy should be used. The SCMF can use the SFC policy information to invoke the Nnef_TrafficInfluence API to request the Service Chain Manager (SMF) to apply the policy in the Service Processing Function (UPF). The 5G CSFC policy information may include an SFC policy identifier, which indicates the provided policy that can be used, the service descriptor to which the policy applies, the WTRU identifier to which the policy applies, the space validity conditions, and may contain information about the AF that supports SFC. It is understood that the 5GC SFC policy can be used in conjunction with the SCMF.

[0107] The Service Chain Owner Identifier (SCOID) identifies the SC administrator. The SC owner can perform administrative operations on the SC, including providing SC profiles, controlling the SC's status, and terminating the SC. Based on the SC owner, the SCMF can authorize operations on the service chain.

[0108] Service Chain Descriptor (SCTD) identifies services that can be provided to the Service Chain Provider (SC). The Service Chain Provider MF (SCMF) can use the SCTD to enable the 5GC SFC policy, accepting or rejecting services sent to the SCMF. AFs participating in the SC can use the SCTD to accept or reject services sent to them.

[0109] A service chain-permitted UE (SCAU) can identify multiple WTRUs that are permitted to use the SC. Based on the permitted WTRUs, the SCMF can authorize WTRUs to use the SC; the permitted WTRUs of the SC can indicate all WTRUs, a group of WTRUs, or a single WTRU. The permitted WTRUs can provide inference input in the SC.

[0110] The Service Chain Allowed Consumer Identifier (SCACID) identifies allowed consumers of SC information. Based on the allowed consumer identity, SCMF can authorize consumers to access information about the service chain, including results, node information, and key performance indicators. When the same WTRU provides inference input and consumes the inference results of the SC, allowed consumers can include allowed WTRUs.

[0111] The service chain allowed node identifier (SCANID) indicates the allowed nodes that can participate in the Service Chain. Based on the allowed node identifier, the Service Chain Management Function (SCMF) can authorize allowed nodes to participate in (e.g., insert) the Service Chain, and can authorize allowed nodes to obtain or generate information about the service chain, including node information and analytics.

[0112] The Service Chain Current Consumer Identifier (SCCCID) identifies a consumer currently subscribed to receive SC information. The list of current consumers is updated as consumers subscribe or unsubscribe from receiving SC information. SCMF can use current SC consumers to notify them of available information related to the SC chain (e.g., new results available, SC state changes, etc.).

[0113] The Service Chain Current State (SCCS) indicates whether a Service Chain (SC) is enabled or disabled. An enabled SC pipeline is configured and allows the exchange of information to deliver results. A disabled SC pipeline is configured and does not allow the exchange of information to deliver results. The Service Chain Current State (SCMF) can change the SC state based on requests from the SC owner or other environmental factors such as time, location, etc.

[0114] Service Chain Analysis (SCA) can provide analytics related to SC operations. For example, analytics could include the total processing time of the SC, the processing time of each SC node, the bandwidth consumed between SC nodes (e.g., the bandwidth required for intermediate data), the time since the latest processing result, and transmission latency. SCMF and nodes can compute SC analytics and provide them to SC owners or SC consumers.

[0115] Service Chain Environment Rules (SCERs) provide rules for managing SC chains based on environmental conditions. SCMFs can associate conditional environment rules with SC profiles, allowing SCs to be conditionally enabled, disabled, or deleted. For example, SCMFs can associate location rules with SC profiles, ensuring that an SC can exist only at (or more) given locations. Similarly, SCMFs can associate time validity rules with SC profiles, ensuring that an SC can exist at a specific time. SCMFs can also associate slice validity rules with SC profiles, ensuring that an SC can only exist if all SC nodes are within a given slice. Additional conditional environment rules are possible, such as rules based on SC analysis (e.g., idle time, processing time), rules based on WTRU existence, and rules based on AC or AF availability.

[0116] In one example, an application in WTRU might need a Service Chain (SC). The application can inform WTRU that it needs to create an SC, and it can specify the services required to form the chain, as well as the requirements for the services and / or the chain.

[0117] The WTRU can perform the discovery of services required to form an SC. The WTRU can send DNS resolution requests or EAS discovery requests, or a combination of both, to a DNS server, EASDF, or EES server.

[0118] The WTRU can receive DNS resolution responses or EAS discovery responses containing a list of (edge) application services that can be used to form an SC. These responses(s) can indicate the services requested for forming the SC.

[0119] WTRU can perform service selection based on SC requirements. Based on the service selection, WTRU can send an SC creation request to the Service Chain Management Function (SCMF). This request can include SC features or SC profiles required to form an SC profile.

[0120] The WTRU can receive an SC creation response from the SCMF. This response can indicate that an SC has been created and may provide an SC profile or SC profile identifier. The WTRU can obtain information required by the application from the SC profile, such as SC header or footer information. The WTRU can then inform the application that needs the SC of the information obtained.

[0121] On WTRU, applications can use information about the SC. As an example, an application can send intermediate data to the SC header. As another example, an application can subscribe to the SC tail to obtain the SC result.

[0122] In one example, SCMF can receive an SC creation request from WTRU. This request may include SC characteristics or an SC profile required to form the SC profile. SCMF can verify whether the SC characteristics include SC node information. If the request does not include SC node information, SCMF performs the discovery of services required to form the SC. SCMF may send DNS resolution requests or EAS discovery requests, or a combination of both, to a DNS server, EASDF, or EES server.

[0123] The SCMF can perform service selection based on the SC characteristics received in the request. The SCMF can create an SC profile based on the SC characteristics received in the request and the discovery service required by the SC. The SCMF can send a notification to the subscribing service regarding participation in the SC. This notification may include the SC profile or an SC profile identifier. The SCMF can receive a notification response from the service. The notification response indicates whether the service accepts participation in the SC. The SCMF sends an SC creation response to the WTRU. This response may indicate the SC profile or an SC profile identifier. The WTRU uses the information from the SC profile to send intermediate information to the SC and obtains the SC result.

[0124] Figure 7The diagram illustrates an example process for creating a service chain. In 712, an AF 710 that can participate in the SC can send a registration request to the SCMF 704 to obtain services. The registration request may include the identifier of the AF 710 and the notification endpoint that the SCMF 704 can use to notify the AF 710. Additionally, the request may include notification filters indicating which notification events can be sent to the AF 710 and information related to the capabilities of the AF 710, such as supporting SFC encapsulation or the number of simultaneous SC sessions allowed. Upon receiving the request, the SCMF 704 creates a subscription resource for registering the AF, and the resource information may be based on the information provided in the request.

[0125] In 714, an event requiring the creation of an SC may occur in SC owner 702. In the first example, SC owner 702 can be an AC located on a WTRU; the triggering event can be a user initiating an AC; the AC can be an AIML application that needs to split AIML inference; the AC can trigger an SC creation request for splitting the AIML SC using SCMF 704, and this request can be sent directly with the SCMF or triggered via an enablement layer application such as an Edge Enabler Client (EEC) 708. In the second example, SC owner 702 can be an AF located in the data network of a wireless network; the triggering event can be a notification sent from the 5G core network to the AF, indicating WTRU registration; the AF can be an AIML application that needs to split AIML inference; the AF can create a split AIML SC using SCMF, and the request can be sent directly to the SCMF or triggered via Network Open Function (NEF).

[0126] The SC owner can perform service selection for the service instances required to form the SC. If the SC owner is provided with the information required to request SC creation (such as service instance, SCID, etc.), the SC owner can proceed directly to step 724. If the SC owner is configured with the service identifiers required to form the SC (such as service type), the SC owner can perform service discovery and service selection.

[0127] If the SC owner is able to discover service instances using DNS functionality or via an Edge Discovery Client (EDC), the SC owner can send a DNS request to the DNS 706 server or Edge Application Server Discovery Function (EASDF) in section 716. This request can include the FQDN of the services included in the SC. If the SC to be formed requires several services, the SC owner can repeat the request to discover different services (e.g., different FQDNs). For use cases requiring several service instances of the same service (e.g., the data-parallel SI model), the SC owner can repeat the request using the same FQDN, which may result in different service instances if DNS round-robin is enabled in the DNS server. If DNS round-robin is not supported, enhancements to the DNS protocol can allow DNS clients to indicate to the server how many instances of the requested service are needed in the DNS response. The DNS server or EASDF 706 can send a DNS response to the requester in section 718, including connectivity information (e.g., endpoint addresses) for the requested service; the response can include connectivity information to multiple instances of the service.

[0128] If the SC owner 702 is able to discover service instances using EAS discovery functionality or via an Edge Enabler Client (EEC), the SC owner can send an EAS discovery request 720 to the Edge Enabler Server (EES) 708. This request may include multiple EAS identifiers (EASIDs) of the services included in the SC. If the SC to be formed requires several services, the request may include several EASIDs. Alternatively, if available, the EAS discovery capabilities of EAS bundles (e.g., direct bundles or composite bundles) may be used. For use cases requiring several service instances of the same service (e.g., a data-parallel SI model), the SC owner may obtain several EAS instances in the response, depending on the EES server implementation. Otherwise, enhancements to EAS discovery may allow the EAS discovery client to specify the number of requested instances in the EAS discovery response. The EES 708 may send an EAS discovery response to the requester in 722, including connectivity information (e.g., the endpoint address of the requested service); the response may include connectivity information to multiple instances of the service.

[0129] In 724, SC owner 702 can select the discovered service instance that can be used in the SC.

[0130] It should be understood that the SC owner can be provided in advance with the information required to request SC creation, thus avoiding execution steps 716 to 724. It should also be understood that the SC owner can be provided in advance with a pre-existing SCT or SCID available in the network, thus avoiding execution steps 716 to 724. Furthermore, it should be understood that the SC owner 702 can retrieve an existing SCR or SCID available in the 5GS. These examples are not shown in the accompanying drawings.

[0131] In section 726, the SC owner 702 can send an SC creation request to the SCMF 704. This request may include one or more information elements described in the preceding paragraphs. The request may include the SC type, the SCID identifying the SC, the SC model indicating the SC structure, the SC size indicating the number of stages, the SCNID(s) indicating the services(s) within the SC, the SC node roles and locations defining the SC structure, the SC node configuration defining the parameters or configurations of the SC nodes within the SC, SC node subscription information indicating how nodes are notified, 5GC SFC policy information indicating whether 5GC SFC is used, the SC owner identifier identifying the SC owner, the consumers and nodes allowed to use or participate in the SC, and the SC environment rules indicating the validity conditions of the SC. In section 730, parameters not included in the request may be provided by the SCMF and included in the SC profile.

[0132] In section 728, upon receiving an SC creation request, if the request does not include connectivity information for all services required by the SC, then SCMF 704 can perform the service discovery and selection described in sections 716 to 724. Otherwise, if connectivity information exists, SCMF 704 proceeds to section 730.

[0133] In 730, SCMF 704 creates an SC profile resource based on the information provided in the SC creation request and the service selections that SCMF 704 performs when necessary.

[0134] In section 732, SCMF 704 sends a notification to the service instance selected for the SC chain. AF notification information can be obtained from AF subscriptions in section 712. If an AF is not subscribed to in section 712, it can be automatically subscribed to in section 728 based on the AF notification information provided in the SC creation request or from the service selected by SCMF. The notification may include information from the SC profile, indicating that an AF has been added to the SC, and may provide information about the SC structure (e.g., previous node, next node, SC tail). Upon receiving this notification, AF 710 can prepare to participate in the SC; for example, the AF can create the necessary resources for processing intermediate datasets of the SC, initialize the AIML model, create resources for storing analyses related to the SC chain, and establish connectivity with other AFs.

[0135] In 734, AF 710 can send an SCMF notification response to SCMF 704 to indicate whether the AF can participate in the SC. If the AF cannot be added to the SC, the SCMF notification response can indicate the failure and the reason.

[0136] In section 736, SCMF 704 sends an SC creation response to the SC owner 702. The response can indicate whether the SC creation request was successful and can include the SC profile. When an event associated with the SC occurs, the SC owner can automatically subscribe to receive notifications from SCMF. Upon receiving the SC creation response, if the SC owner is a consumer of the SC result, the SC owner can subscribe to the SC tail node, as indicated in the SC profile, to receive the SC result and can take actions based on the received result.

[0137] It should be understood that SCMF can be a function; SCMF functions can provide services; SCMF functions can be implemented as standalone application servers; and / or SCMF can be implemented as part of any existing application server (such as EES or EASDF).

[0138] When SCMF is implemented in EES or EASDF, it is also understood that the AF registration (712) of the SCMF service (e.g., registration between AF and SCMF) may be a registration process that occurs between EAS and EES or EASDF; and it is also understood that the process in 728 (e.g., a process between SCMF and EES or EASDF) may be internal to EES or EASDF.

[0139] Figure 8 The illustration shows an example service chain management process.

[0140] In step 808, requester 802 (e.g., SC owner or SC consumer) can discover information about existing SC instances. Requester 802 can send an SC discovery request 808 to SCMF 804; the SC request can include SC discovery information based on information elements of the SC profile, such as the SC type, which can be included in the discovery request to discover SC instances of that type, and other IEs of the SC profile can be included to discover SC instances. SCMF 804 can use the SC discovery information to filter existing SC profiles for discovery. For example, the SC discovery request can include SCIDs used by SCMF 804 to identify SC profiles(s) that match the SCID. For example, the SC discovery request can include SCIDs used by SCMF to identify SC profiles(s) containing such SCNIDs, or expressed differently, identifying which SC(s) can participate in. Any information element described in the SC profile can be included as a discovery filter in the SC discovery request.

[0141] Upon receiving an SC discovery request, SCMF 804 can identify SC profiles that match the parameters of the discovery filters included in the request. SCMF can send a successful SC discovery response 810 to the requester; the response may include the SC profiles that match the received discovery filters. If SCMF 804 does not find any SC profiles, the response may indicate failure and may include a reason for the failure.

[0142] A requester 802 (e.g., an SC owner) can enable or disable an SC. The requester can send an SC enable request or an SC disable request 812 to SCMF 804; this request may include information identifying (e.g., multiple SCIDs) of the SC chain(s); the SCMF can use the multiple SCIDs to identify the multiple SC profiles(s). After identifying the multiple SC profiles(s), SCMF 804 can send multiple SC enable or SC disable notifications 814 to the multiple AFs (e.g., multiple SC nodes) 806 participating in the SC chain. The notification may include multiple SCIDs; and the AF 806 can use the SCIDs included in the notification to identify services associated with those SCIDs, and can start or stop processing the identified services respectively. In 816, SCMF 804 can send an SC enable response or an SC disable response to the requester; if the SC chain is successfully enabled or disabled, the response may include a success indication, otherwise it may include a failure indication and a reason for failure.

[0143] Requesters 802 (e.g., SC owners or SC consumers) may obtain reporting information about (multiple) existing SCs; reports may be initiated by any of (multiple) AFs 806 that participate in the SC or by SCMF 804.

[0144] When an AF participating in the SC initiates a report, AF 806 may send an SC report request 818 to SCMF 804. The report request may include (multiple) SCIDs and information about the analysis or status of the AF. For example, the request may include analysis of the latest dataset processed using and associated with the provided SCID (e.g., time, size, processing latency, etc.), or may include information about experienced transmission latency or processing overload associated with the provided SCID, or may include information about the latest generated data associated with the SCID (e.g., intermediate data or results). Upon receiving an SC report request, SCMF may store the analysis data locally or in an analysis service (such as the Applied Data Analytics Enablement Framework (ADAES)), modify the SC chain, or notify the subscriber in 826. SCMF 804 may send an SC report response 820 to the reporting AF 806 to indicate that the report has been successfully received, or may indicate a fault and its cause to the AF.

[0145] When a report is initiated by the SCMF (e.g., polling), the SCMF 804 may send an SC report notification 822 to the AF 806. The SC report notification may include (multiple) SCIDs and information requested from the AF. For example, the request may instruct the SCMF to retrieve analysis (e.g., time, size, processing latency, etc.) of the latest dataset processed using and associated with the provided SCID, or it may instruct the SCMF to retrieve information about experienced transmission delays or processing load, or it may instruct the SCMF to retrieve information about the latest generated data (e.g., intermediate data or results). Upon receiving the notification, the AF 806 may send an SC report notification response 824 to the SCMF 804. The notification response may include information indicated by the SCMF 804 in the notification and associated with (multiple) SCIDs provided in the notification.

[0146] If the SCMF has subscribers (e.g., SC owners or SC consumers) for receiving report information, SCMF 804 can send an SC report notification 826 to subscriber 802; the SC report notification may include the report information received in 818 or 824. Upon receiving the notification, the subscriber can store the report information or use the report information to perform actions, such as storing analytical data, modifying the SC chain, or using the results of the report.

[0147] A requester (e.g., an SC owner) 802 can modify an SC. Requester 802 can send an SC modification request 828 to SCMF 804; this request may include information identifying the SC chain(s) (e.g., multiple SCIDs) and information indicating the SC change; the SCMF can use the multiple SCIDs to identify the multiple SC profiles, and the information indicating the change can be used by the SCMF to update the SC profile. For example, the information provided in the request may indicate that an SC node instance needs to be removed or replaced from the SC identified by its SCID. The SCMF can send multiple SC modification notifications 830 to the multiple AFs 806 (e.g., multiple SC nodes) participating in the SC chain. The notification may include the updated SC profile; and the AF 806 can use the updated SC profile to reconfigure AF operations. Not shown in the accompanying drawings, in addition to notifying the AFs participating in the SC, the SCMF may also notify other subscribers (e.g., SC consumers) of the modified SC profile. SCMF 804 can send an SC modification response to the requester in 832; if the SC chain is successfully modified, the response can include a success indication and an updated SC profile; otherwise, it can include a failure indication and a reason for failure. SC modification may be triggered by changes in application requirements or by detecting changes in the availability of SC nodes. For example, an application on WTRU may detect a change in application requirements and decide to remove an SC node from the chain; in another example, an SC node may become unavailable, which may be detected by the SC owner or SCMF and trigger a re-election of another SC node instance. In both cases, the SC profile needs to be modified to reflect the changes in the SC chain.

[0148] A requester (e.g., the SC owner) can delete an SC. Requester 802 can send an SC deletion request 834 to SCMF 804; this request may include information identifying (e.g., multiple SCIDs) of the SC chain(s); the SCMF can use the multiple SCIDs to identify the multiple SC profiles(s). After identifying the multiple SC profiles(s), SCMF 804 can send multiple SC deletion notifications 836 to the multiple AFs(s) (e.g., multiple SC nodes) participating in the SC chain(s). The notification may include the multiple SCIDs and a reason; the AF can use the SCIDs included in the notification to identify the SC profiles and the services associated with those SCIDs, and can respectively stop processing the identified services, delete the SC profiles, and any other associated resources; the reason can provide further information about the SC deletion, which can help the AF manage resources. SCMF 804 can send an SC deletion response to the requester in 838; if the SC chain is successfully deleted, the response may include a success indication; otherwise, it may include a failure indication and a failure reason.

[0149] Service chain creation can be performed by providing connectivity capabilities; that is, the 5G core network can support WTRU requests to create SCs by providing connectivity capabilities. For example, when requesting the establishment of a PDU session or the modification of an existing PDU session, the WTRU can provide connectivity capability information.

[0150] In one example, WTRU can provide connectivity information in the NAS message; the connectivity information can be either the connectivity value or the connectivity modifier.

[0151] A connectivity capability value can indicate that a specific SFC policy configuration has been requested. For example, a WTRU can provide a connectivity capability value (e.g., connectivity capability 'X') that corresponds to a specific SFC policy available in the PCF and causes the SFC policy to be applied.

[0152] Connectivity modifiers can indicate whether SC capabilities are requested based on the configuration specified by the modifier. Connectivity modifiers can be associated with connectivity values, such that the connectivity value can indicate whether SC capabilities are requested based on the connectivity modifier.

[0153] Connectivity modifiers can include Service Chain Type (SCT), which can uniquely identify the type of service chain.

[0154] Connectivity modifiers may include a Service Chain Identifier (SCID) that can uniquely identify a service chain instance.

[0155] Connectivity capability modifiers can include an SFC policy identifier, which uniquely identifies an SFC policy provided in the PCF. The WTRU can include the SFC policy identifier in its connectivity capabilities to indicate to the AMF that it wants to use this policy. The AMF can pass the SFC policy identifier to the SFM, allowing the SMF to obtain the PCC rule associated with the SFC policy identifier from the PCF.

[0156] Connectivity capability modifiers can include SFC metadata, which is information that can be added to SFC-encapsulated services. WTRU can include SFC metadata in its connectivity capabilities to indicate to AMF that it wants to add metadata information to the services indicated by the SFC policy identifier. AMF can then pass the SFC metadata to SFM to configure SFC service encapsulation accordingly.

[0157] Connectivity capability modifiers can include service chain service descriptors, which describe the service characteristics included in the SC. The WTRU can include (multiple) SC service descriptors in its connectivity capabilities to indicate to the AMF that it wants to send a subset (e.g., not all) of the services for PDU sessions via the SC. The AMF can pass (multiple) SC service descriptors to the SMF to configure the service classifier accordingly.

[0158] Connectivity information may include either the connectivity value or its associated connectivity modifier.

[0159] Figure 9 The illustration shows an example of service chain management functionality that links business forwarding and proxy system flows.

[0160] In 922, AC 904, located on WTRU 902, can request the establishment of a PDU session via RAN 920; this request may indicate that AC 904 requires the use of the network's SC capabilities. The AC request may trigger WTRU (e.g., the WTRU's Terminal Equipment (TE) and Mobile Terminal (MT) components) to send a PDU session establishment request to AMF 906 associated with WTRU 902. The PDU session establishment request message may include connectivity capability information indicating that the created PDU session requires SC capabilities from the network.

[0161] In 924, AMF 906 can perform SMF selection and can send a PDU session creation request to the selected SMF 908, including connectivity capability information provided by WTRU 902.

[0162] In 926, after receiving a PDU session creation request from AMF 906, SMF 908 can send a message to PCF 910 indicating that a given WTRU requires SC support from the network; this message can include the connectivity capability information received from the WTRU in 922. Based on the message from SMF 908 and the connectivity capability information, PCF 910 can identify SFC policy 912. PCF can also identify subscribed AFs (such as SCMF) and can notify the AFs of PDU session creation requiring SC support. For example, the message sent from SMF 908 to PCF 9910 can be a new message or an existing message, such as an SM policy association establishment.

[0163] In 928, PCF 910 can determine that the requested SC support needs to be notified to at least one AF 916. PCF 910 can invoke the NEF API and provide the connectivity capability information received from SMF 908 in 926. NEF 914 can notify subscribed AF 916 instances in 930, providing connectivity capability information. For example, application functions (such as SCMF) can use this information to create an SC.

[0164] It is understood that the Trusted Network Functionality (TNF) that enables SCMF functionality can be registered to PCF 910 and may not require NEF intermediate nodes.

[0165] In 932, if PCF 908 may have already determined the SFC policy in 926, then PCF 910 can provide Policy and Charging Control (PCC) rules to SMF 908. SMF 908 can then configure UPF 918 based on the received PCC rules.

[0166] In 934, SMF 908 can notify AMF 906 of SC policy chain establishment based on information received from PCF 910 or NEF 914. This notification may include information indicating successful SC creation and may include information required by WTRU 902 to use the SC. For example, this information may indicate that the SC has been successfully created and may include the SCMF identifier or connectivity information to the SCMF (e.g., IP address, endpoint, etc.). For example, the message sent from SMF to AMF may be a new message or an existing message, such as a communication N1N2 message transmission.

[0167] In 936, AMF 906 can send a PDU session establishment accept message to WTRU 902 via RAN 920; this message can indicate to WTRU 902 that the PDU session can be used for transmitting services. If WTRU 902 indicates SC support in 922, the message can also indicate that the SC can be used for receiving services and can include the SC information described in 934.

[0168] In 938, the AC 904 connection existing on WTRU 902 can be notified as available, and service flows can be sent to the network using PDU sessions established with SC capabilities. Based on the configured service chain information received from AMF 906, application functions (such as SCMF) can be informed to AC904, and information can be requested from AF 916. For example, AC904 can request SCMF 916 to provide SC profiles, discover SC tails, and obtain inference results.

[0169] Figure 10This is a flowchart of example process 1000 for creating a service chain. In some implementations, Figure 10 One or more process frames can be executed by WTRU.

[0170] like Figure 10 As shown, process 1000 may include detecting, in 1002, an event that triggers the split Artificial Intelligence Machine Learning (AIML) process. For example, WTRU can detect an event that triggers the split AIML process, as described above. Also as Figure 10 As shown, process 1000 may include sending a service chain (SC) creation request to the network server in 1004, wherein the service chain creation request includes SC features used when creating the SC profile and the SC. For example, a WTRU may send an SC creation request to the network server, wherein the service chain creation request includes SC features used when creating the SC profile and the SC, as described above. Also as Figure 10 As shown, process 1000 may include, in 1006, receiving an SC creation request response from a network server indicating the creation of an SC and an associated SC profile, wherein the associated SC profile is at least partially based on SC characteristics, and wherein the associated SC profile includes at least information about a first SC node that sends intermediate data and information about a second SC node from which it will receive inference results of the SC, or which the WTRU will subscribe to receive inference results. For example, the WTRU may receive the SC creation request response indicating the creation of an SC and an associated SC profile from a network function, wherein the associated SC profile is at least partially based on SC characteristics, and wherein the associated SC profile includes at least information about an SC node that sends intermediate data and information about a second SC node from which it will receive inference results of the SC, or which the WTRU will subscribe to receive inference results, as described above.

[0171] Process 1000 may include additional implementations, such as any single implementation or any combination of implementations of one or more other processes described below and / or in conjunction with those described elsewhere herein. In a first implementation, the network server includes SC Management Functions (SCMF).

[0172] In the second implementation, either alone or in combination with the first implementation, process 1000 further includes discovering a plurality of SC nodes; and selecting one or more SC nodes from the discovered plurality of SC nodes.

[0173] In the third implementation, discovering multiple SC nodes, either alone or in combination with the first and second implementations, may include at least one of sending a Domain Name System (DNS) resolution request to the Edge Application Server Discovery Function (EASDF) or sending an Edge Application Server (EAS) discovery request to the Edge Enabler Server (EES).

[0174] In the fourth implementation, either alone or in combination with one or more of the first to third implementations, the SC creation request includes an indication of one or more selected SC nodes.

[0175] In the fifth implementation, the event that triggers the creation of the split AIML process, either alone or in combination with one or more of the first to fourth implementations, is at least one of the following: an event triggered by an application client residing on the WTRU or a notification received from the network.

[0176] In the sixth implementation, either alone or in combination with one or more of the first to fifth implementations, the associated SC profile also includes one or more of the following: SC identifier (SCID), SC model (SCM), SC size or SC node identifier (SCNID), and each SC node is associated with an application as an AIML model.

[0177] In the seventh implementation, each SCNID, either alone or in combination with one or more of the first to sixth implementations, includes at least one of the following: a corresponding SC node role (SCNR) identifier; a corresponding SC node location (SCNP) identifier; or a corresponding SC node application characteristic (SCNAC) identifier.

[0178] although Figure 10 The example box for process 1000 is shown, but in some implementations, it differs from... Figure 10 Compared to the depicted boxes, process 1000 may include additional boxes, fewer boxes, different boxes, or boxes arranged differently. Alternatively or concurrently, two or more boxes of process 1000 may be executed in parallel.

[0179] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer-readable medium incorporating a computer program, software, or firmware 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-ROMs and digital multifunction discs (DVDs)). Radio frequency transceivers can be implemented using a processor associated with software for use in WTRUs, terminals, base stations, RNCs, or any host computer.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Detect events that trigger the creation of the split Artificial Intelligence Machine Learning (AIML) process; Send a Service Chain (SC) creation request to the network server, wherein the service chain creation request includes SC features used when creating the SC profile and the SC; and The network server receives an SC creation request response indicating the creation of an SC and an associated SC profile, wherein the associated SC profile is at least partially based on the SC characteristics, and wherein the associated SC profile includes at least information about a first SC node that sends intermediate data and information about a second SC node from which it will receive inference results of the SC, or the WTRU will subscribe to receive the inference results.

2. The method according to claim 1, wherein the network server includes SC management function (SCMF).

3. The method according to claim 1 or 2, further comprising: Multiple SC nodes were discovered; as well as Select one or more SC nodes from the discovered plurality of SC nodes.

4. The method of claim 3, wherein discovering the plurality of SC nodes includes at least one of sending a Domain Name System (DNS) resolution request to the Edge Application Server Discovery Function (EASDF) or sending an Edge Application Server (EAS) discovery request to the Edge Enabler Server (EES).

5. The method of claim 4, wherein the SC creation request includes an indication of the selected one or more SC nodes.

6. The method according to any one of claims 1 to 5, wherein the event that triggers the creation of the split AIML process is at least one of the following: an event triggered by an application client residing on the WTRU or a notification received from the network.

7. The method according to any one of claims 1 to 6, wherein the associated SC profile further comprises one or more of the following: SC identifier (SCID), SC model (SCM), SC size or SC node identifier (SCNID), and wherein each SC node is associated with an application as an AIML model.

8. The method of claim 7, wherein each SCNID includes at least one of the following: a corresponding SC node role (SCNR) identifier; a corresponding SC node location (SCNP) identifier; or a corresponding SC node application characteristic (SCNAC) identifier.

9. The method of claim 8, wherein the SCNAC comprises at least one of the following: application identifier, application type, application version information, application size identifier, or application capability requirement.

10. A wireless transmit / receive (WTRU) unit, comprising: The processor circuitry is configured to detect events that trigger the creation of the split artificial intelligence machine learning (AIML) process; as well as The transceiver is configured as follows: Send a Service Chain (SC) creation request to the network server, wherein the service chain creation request includes SC features used when creating the SC profile and the SC; and The network server receives an SC creation request response indicating the creation of an SC and an associated SC profile, wherein the associated SC profile is at least partially based on the SC characteristics, and wherein the associated SC profile includes at least information about a first SC node that sends intermediate data and information about a second SC node from which it will receive inference results of the SC, or the WTRU will subscribe to receive the inference results.

11. The WTRU of claim 10, wherein the transceiver is further configured to: send a Domain Name System (DNS) resolution request to the Edge Application Server Discovery Function (EASDF) or send an Edge Application Server (EAS) discovery request to the Edge Enabler Server (EES).

12. The WTRU of claim 11, wherein the transceiver is further configured to receive DNS resolution responses; and The processor circuitry is configured to select one or more SC nodes based on the DNS resolution response.

13. The WTRU of claim 11, wherein the transceiver is further configured to receive an EAS discovery response; and The processor circuit system is also configured to: Multiple SC nodes were discovered; and Based on the received EAS discovery response, select one or more SC nodes from the discovered plurality of SC nodes.

14. The WTRU according to any one of claims 10 to 13, wherein the SC creation request includes an indication of the selected one or more SC nodes.

15. The WTRU according to any one of claims 10 to 14, wherein the event that triggers the creation of the split AIML process is at least one of the following: an event triggered by an application client residing on the WTRU or a notification received from the network.

16. The WTRU according to any one of claims 11 to 15, wherein the associated SC profile further comprises one or more of the following: SC identifier (SCID), SC model (SCM), SC size or SC node identifier (SCNID), and wherein each SC node is associated with an application as an AIML model.

17. The WTRU of claim 16, wherein each SCNID comprises at least one of the following: a corresponding SC node identifier; a corresponding SC node role (SCNR) identifier; a corresponding SC node location (SCNP) identifier; a corresponding SC node application characteristic (SCNAC) identifier; or a corresponding SC node subscription information (SCNSI).

18. The WTRU of claim 17, wherein the SCNAC includes at least one of the following: application identifier, application type, application version information, application size, and application capabilities.

19. A method performed by a network server, the method comprising: A registration request is received from one or more Service Chain (SC) nodes that are able to participate in the SC, wherein the registration request includes SC node information from each of the corresponding one or more SC nodes that are able to participate in the SC, and wherein the SC node information includes a corresponding SC node identifier and the capability of a corresponding application function (AF) associated with each of the one or more SC nodes. By registering the one or more SC nodes that can participate in the SC according to the SC node information of each corresponding one or more SC nodes, a subscription resource is created for each of the one or more SC nodes; Receive an SC creation request from a wireless transceiver unit (WTRU), the SC creation request including SC features used when creating an SC profile; The SC profile is created based on the SC characteristics and the SC node information associated with each of the corresponding one or more SC nodes registered. Notify each of the one or more SC nodes that it is included in the SC associated with the created SC profile; and Send an SC creation response to the WTRU, wherein the SC creation response includes an SC creation success indication and an indication of the created SC profile or an SC creation request failure indication.

20. The method of claim 19, wherein the network server includes a Service Chain Management Function (SCMF), and wherein the SCMF creates the SC profile by selecting one or more corresponding SC nodes based on the SC characteristics.

Images