Method and apparatus for native 3GPP support of artificial intelligence and machine learning operations

Abstract

A method and apparatus are provided for supporting artificial intelligence and machine learning operations in a 3GPP communication network. The method may include receiving, by a WTRU, an indication of requirements and / or constraints associated with one or more WTRU applications. Based on the requirements and / or constraints associated with the one or more WTRU applications, the method may include determining one or more machine learning (ML)-based analyses, data, and / or predictions to request from a network and / or an internal WTRU ML module. The method may then include sending a request or subscription for the one or more ML-based analyses, data, and / or predictions to the network and / or internal WTRU ML module, and receiving a response or notification of the one or more ML-based analyses, data, and / or predictions from the network and / or internal WTRU ML module.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 303,772, filed January 27, 2022. The contents of this earlier filed application are incorporated herein by reference in their entirety for all purposes.

[0002] FIELD OF THEINVENTION Some embodiments may relate, for example, to methods and apparatus for supporting at least artificial intelligence (AI) and machine learning (ML) operations in a 3GPP compliant wireless communication network. [Background technology]

[0003] Machine learning (ML) may be considered an area of ​​artificial intelligence (AI) where algorithms build models based on training data to make predictions without being specifically programmed to do so. Federated learning (FL) is an ML technique that trains algorithms across multiple distributed servers or edge devices with unshared local data samples. In a communication system or network, FL may be considered a method for performing distributed machine learning tasks among wireless transmit / receive units (WTRUs) that may have access to local data that may be suitable for learning a model. For example, a WTRU may use local training data to compute updates to a global model and send the updates over a wireless network to a central server. Some embodiments described herein are designed with the above in mind. Summary of the Invention

[0004] Embodiments may be directed to a wireless transmit / receive unit (WTRU) comprising a transceiver and / or processor configured to receive an indication of at least one of requirements or constraints associated with one or more WTRU applications. Based on the at least one of the requirements or constraints associated with the one or more WTRU applications, the processor may be configured to determine one or more machine learning (ML)-based analyses, data, or predictions to request from at least one of a network or an internal WTRU ML module. The transceiver and / or processor may be configured to send a request or subscription for the one or more ML-based analyses, data, or predictions to the network or the internal WTRU ML module, and receive a response or notification of the one or more ML-based analyses, data, or predictions from the network or the at least one of the internal WTRU ML modules.

[0005] One embodiment may be directed to a method implemented by a wireless transmit / receive unit (WTRU). The method may include receiving an indication of at least one of requirements or constraints associated with one or more WTRU applications and determining one or more machine learning (ML)-based analyses, data, or predictions to request from at least one of a network or an internal WTRU ML module based on the at least one of the requirements or constraints associated with the one or more WTRU applications. The method may also include sending a request or subscription for the one or more ML-based analyses, data, or predictions to the network or the internal WTRU ML module and receiving a response or notification of the one or more ML-based analyses, data, or predictions from the network or the at least one of the internal WTRU ML modules. [Brief description of the drawings]

[0006] A more detailed understanding may be had from the following detailed description, given in conjunction with the drawings that accompany this specification by way of example. Such drawing figures, like the detailed description, are illustrative. Thus, the figures and detailed description should not be considered as limiting, as other equally effective embodiments are possible and likely to be. Moreover, like reference numbers ("ref") within the drawings ("FIG") indicate like elements. [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 2 is a block diagram of a WTRU architecture for supporting AI / ML, according to one embodiment. [Diagram 3] FIG. 3 is a block diagram illustrating NAS signaling between a WTRU and a 5G core network, in accordance with one embodiment. [Figure 4] FIG. 4 is a block diagram illustrating PEC and PSM interaction with a 5G core network according to one embodiment. [Figure 5-1] FIG. 5-1 is a signal flow diagram illustrating signal flow interactions between a PE module, a PSM, a WTRU data provider, and a 5GC NF according to one embodiment. [Figure 5-2]FIG. 5-2 is a signal flow diagram illustrating signal flow interactions between a PE module, a PSM, a WTRU data provider, and a 5GC NF according to one embodiment. [Figure 6] FIG. 6 is a flow chart of a method according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. It will be understood, however, that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided herein (collectively "provided").

[0008] Exemplary Communication System 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. Communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communications system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communications system 100 may use 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 DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0009] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, wireless paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (loT) devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d, or any other WTRUs referenced herein, may be referred to interchangeably as a UE.

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

[0011] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, 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 the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell, for example, using beamforming to transmit and / or receive signals in a desired spatial direction.

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

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

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

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

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

[0017] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0018] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

[0020] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as transmission control protocol (TCP), user datagram protocol (UDP), and / or internet protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RANs 104 / 113 or a different RAT.

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

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

[0023] The 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) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B illustrates the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

[0028] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, 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) regarding the current location of the WTRU 102. In addition to, or in lieu of, information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location determination method while remaining consistent with an embodiment.

[0030] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0032] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

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

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

[0036] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

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

[0040] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, in certain representative embodiments, it is contemplated that such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

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

[0042] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or 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 from outside the BSS to the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) the source STA and the destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

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

[0044] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0045] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining multiple contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to the Medium Access Control (MAC).

[0046] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including certain capabilities, for example, support for (e.g., support only for) certain and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0047] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration may depend on the status of the primary channel. For example, if the primary channel is active due to a STA (that only supports the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active even though most of the frequency band may remain dormant and available.

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

[0049] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

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

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

[0052] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0054] 1D 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 each of the foregoing elements is illustrated as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

[0061] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0062] Examples of native 3GPP support for artificial intelligence and machine learning operations Federated Learning In the federated learning (FL) training model, an AI / ML application server (AS) selects a set of WTRUs / devices to participate in a distributed training session. Each training session includes several training cycles. During each cycle, a set of WTRUs is selected by the AS responsible for training the global model. In an ideal scenario, the AS should repeatedly reselect a group of well-performing WTRUs. However, it may be necessary to shuffle the participants (WTRUs) to obtain better training results. In particular, increasing the diversity of participants in a training session means more diverse environments (input datasets) to be used in training, which should ultimately result in more accurate ML models.

[0063] To that end, it is difficult to select a set of WTRUs for a given training session, since the AI / ML application server needs to know the state and / or condition of each participant in advance. If the selected set of WTRUs does not perform well within the training cycle (e.g., they cannot deliver their local computations to the AS in time), two problems may arise: (1) waste of resources of several 3GPP entities (e.g., WTRUs, Radio Access Network (RAN), and Core Network (CN)); and (2) increase in the time it takes for the neural network model to converge to a stable point (e.g., a point that minimizes error while maximizing accuracy).

[0064] The decision as to which WTRUs should participate in a training session is made by the AS, but making such a decision may require assistance directly from the 3GPP system, in particular from the WTRU and / or the 5G Core Network (5GC). For example, if a WTRU is moving, it may be prudent to predict its mobility pattern and / or other conditions and inform the AS of the WTRU's predicted mobility or other conditions, because the predicted mobility or other conditions may indicate that the WTRU signal quality and / or strength may soon become very weak or that the WTRU will be heavily engaged in other computationally intensive activities. In such a case, this may help the AS decide, for example, to wait for the WTRU to enter more suitable conditions for training rather than selecting this WTRU for the next training cycle.

[0065] Some useful potential predictions that the WTRU may provide to the AS may include, for example, (i) availability of computational resources such as graphics processing unit (GPU) and / or central processing unit (CPU) resources, which may allow for prediction of potential processing delays, (ii) network capacity, e.g., available bit rate, (iii) mobility patterns in the form of prediction of poor signal strength / quality, and / or (iv) battery status.

[0066] These predictions can assist WTRU applications and ASs by providing some indication regarding the likely state and / or condition of the WTRU in the future (e.g., near future). Combining such information with the current WTRU state, these applications can intelligently adapt their behavior. Note that an AS may also utilize an Application Function (AF) Server to manage its session-level aspects. An AF may be hosted in a trusted or untrusted domain [5].

[0067] A similar set of predictions may be fed back from the 3GPP CN (e.g., via the NWDAF [5]) to the AF / AS and the WTRU. These predictions may also be used by other entities in the 3GPP system, such as the User Plane Function (UPF) to better handle FL traffic. To obtain such predictions, a set of key parameters in the CN may be monitored, such as downlink data delivery status from the UPF and / or Session Management Function (SMF), the number of registered WTRUs and / or established Protocol Data Unit (PDU) sessions for a network slice subject to network slice admission control from the Network Slice Access Control Function (NSACF), the number of WTRUs present in a geographical area from the Access and Mobility Management Function (AMF), PDU session status from the SMF, location reports from the AMF and / or Gateway Mobile Location Center (GMLC), and / or availability after a downlink data notification failure from the AMF.

[0068] It may be advantageous to utilize state-of-the-art AI / ML techniques within the 3GPP system (e.g., in the WTRU and 5GC) to handle traffic for federated learning (FL) applications and other emerging applications with similar traffic patterns. These intelligent techniques are known to produce near-optimal results very quickly, outperforming traditional optimization algorithms that are known to perform poorly or slowly under complex conditions. The 3GPP system already provides such capabilities within the 5GC by utilizing the Network Data Analysis Function (NWDAF) [7]. However, such capabilities are not provided for the WTRU. That said, these AI / ML techniques (both hosted in the 5GC and with the WTRU) are often required to communicate with each other, e.g., to exchange analysis, data, and / or predictions. For example, the NWDAF running in the 5GC may need some predictions from the WTRU, or the prediction module running in the WTRU may need to consume some analysis from the NWDAF running in the 5GC.

[0069] Such a two-way communication channel does not currently exist in the 3GPP standards.

[0070] Also, once these AI / ML-based components are in both the WTRU and the CN (in a standardized manner), it will be beneficial to use their results to adjust the behavior of applications (e.g., WTRU applications and ASs) and optimize 3GPP resources.

[0071] Some example embodiments may address at least the following shortcomings: lack of a unified and flexible architecture for utilizing AI / ML techniques to generate intelligent event predictions in the WTRU, lack of a unified communication model between AI / ML-based entities in the WTRU and Network Functions (NFs) in 5GC, and / or lack of an ML-based optimization mechanism in the WTRU to dynamically help WTRU applications meet their Quality of Service (QoS) requirements by attempting to rebalance 3GPP resources.

[0072] For example, some embodiments may address, among other things, (i) useful predictions in a WTRU exposed to the AF / AS and applications executed in the WTRU, (ii) how the WTRU can generate such predictions, (iii) an architecture for such functionality, (iv) useful signaling for such functionality, (v) how the WTRU can communicate these predictions to the AF / AS and other entities in the 3GPP system (including the WTRU and the 5GC), and (vi) how the WTRU can use these predictions to optimize its behavior and prevent wasting resources.

[0073] An Example WTRU Architecture for Supporting AI / ML Exemplary embodiments provide a new architecture for a WTRU (e.g., a terminal device) to leverage AI / ML techniques to dynamically manage PDU sessions established between the WTRU and a 5G system (5GS). For example, this architecture can address challenges such as those associated with FL workloads. However, the new components in this architecture can also be used for other applications with dynamic QoS and / or resource management requirements.

[0074] 2 is a block diagram of an example embodiment of this architecture, which aims to leverage modern AI / ML techniques at its core in a unified way to assist applications 212 by providing a variety of intelligent predictions. The architecture proposes a new layer 202, sometimes called the "Prediction Engine" (PE), that hosts several intelligent, potentially ML-based components to generate key predictions within the WTRU, such as available bitrate / capacity, GPU / CPU availability, battery life, and / or user mobility.

[0075] In one embodiment, this layer may be built on top of a virtualized platform such as the Docker platform (OS-level virtualization platform), and each prediction module may run in an isolated container with customized software packages, libraries, and operating systems. This may be important for AI / ML-based techniques that typically run within a specific platform with a specific set of libraries, software packages, and operating systems. Other components in this architecture may include a PDU Session Modifier (PSM) 204, a Prediction Engine Coordinator (PEC) 206, and a database 208, which may also be used in a virtualized environment (e.g., in a Docker container) to interact with applications, PE modules, and external entities outside of the WTRU (e.g., NWDAF, AF, or other WTRUs in case of sidelink communications in 5GC).

[0076] This architecture protects the privacy of the WTRU and prevents it from providing its raw data (personal data) to third parties to generate such predictions. These predictions may be used within the WTRU, the Application Functions (AFs) serving the WTRU, the Application Servers (ASs), and the 3GPP entities (e.g., RAN and CN) (e.g., RAN and CN) to optimize various resources (e.g., network, computation, and storage). For example, the proposed PE layer can help the 3GPP system optimize its resources by dynamically managing PDU sessions via the PSM component. Communication between these components may be through RESTful APIs, for example, via an HTTP / 2[1] connection (dotted line in Figure 2).

[0077] Example Prediction Engine According to some embodiments, the prediction engine (PE) 202 may be an AI engine in which multiple machine learning (ML) modules 210 may be executed in parallel to generate a set of predictions. Each box in the PE layer of FIG. 2 may be an ML module that generates a particular prediction. For example, a prediction of GPU / CPU usage, a prediction of battery life, a prediction of available bitrate / capacity, a prediction of WTRU mobility, just to name a few. Each ML module may collect raw data, measurements, and / or statistics from the WTRU across its multiple components, including applications and even other ML modules. The latter creates an instance of a multi-agent ML scenario in which the output of an ML module is used as an input to another ML module. For example, a prediction of WTRU mobility may be used as a state input for a bitrate prediction module, or the output of a bitrate prediction module may be input to a GPU / CPU prediction module.

[0078] In one embodiment, communication between the prediction module 210 and other components of FIG. 2 may be performed via HTTP / 2 protocol (using a RESTful API). Communication with a RESTful API via HTTP / 2 provides several advantages, including, for example: (i) new (ML-based) modules may be designed and easily integrated into the PE engine and may interact with existing PE modules via standard APIs; (ii) the PE engine may communicate with other entities outside the WTRU (e.g., the 5GS, and in particular the 5GC, which also follows a service-based architecture) and provide its services to external consumers. (For example, the PE may receive network data and analysis from the 5GC through the NWDAF, or the NWDAF running in the 5GC may receive some predictions about the WTRU from the PE engine. These interactions may be performed on the control plane (through Non-Access Stratum (NAS) signaling [4]). (iii) communication via HTTP may be highly secure (e.g., via TLS) using well-known encryption techniques widely used today. (iv) The stateless nature of the RESTful API may result in efficient resource usage at the WTRU, ie, service producers (eg, PE modules) at the WTRU do not need to maintain state for their clients.

[0079] In some embodiments, internal communications between the PE module and other modules executing in the WTRU may be performed over an insecure connection to save some computational resources, and it may be preferable to perform external communications more securely.

[0080] PE modules may feed their predictions directly to other local modules such as applications, local databases, and PSMs. It is worth emphasizing that a PE component can use orchestration mechanisms to dynamically manage its containers (or virtual machines) (e.g., Docker, Kubernetes).

[0081] According to an embodiment, a PE Coordinator (PEC) 206 is introduced in the PE layer to interface with entities operating outside the PE layer, such as applications, databases, PSM (see, e.g., FIG. 3). These interactions may be performed via HTTP. Furthermore, the PEC may interact with entities external to the WTRU, such as entities in the 5GC. The PEC may interact with the 5GC (e.g., AMF, SMF, NWDAF, or other NFs) through NAS signaling. Overall, the concern of the PEC 206 is to enable data, predictions, and / or measurements to be optimally exchanged between WTRU components, and between the WTRU and external entities. This module may also interact closely with the container / VM orchestration components.

[0082] The PE may also include a Virtualized Network Function that is responsible for tracking which PE modules are onboarded and their status, e.g., whether they are activated or not. This may be similar to the Network Repository Function (NRF) in 5GC, or more generally, a Virtual Network Function (VNF) catalog or a container repository as part of the Docker platform.

[0083] Example PDU Session Modifier (PSM) According to one embodiment, the responsibility of the PDU Session Modifier (PSM) 204 is to dynamically modify PDU sessions on behalf of applications. The PSM can operate at the application layer and interface with the NAS layer to modify PDU sessions initially established by the application. In an embodiment, an application may express its requirements (e.g., bandwidth, latency, reliability, availability, task completion deadlines) to the PSM, which may then determine which predictions are needed for its decision-making to meet such requirements. The PSM may then activate a set of PE modules (if they are inactive) and subscribe to them to get event notifications when needed predictions (or events) become available. The PSM 204 may interact with the PE modules directly or through the PEC 206. The PSM feeds these predictions into its optimization algorithms to modify the corresponding PDU sessions to meet the application requirements and dynamically optimize WTRU resources. Such functionality is important for resource optimization, especially for applications that exhibit highly dynamic workflows.

[0084] In some embodiments, the decision by PSM 204 to select a set of predictions may be skipped when an application expresses its required predictions directly to the PSM, which may be upon initial registration with the PSM or any time during the application's life.

[0085] The PSM 204 offers several important advantages. First, applications do not need to deal with low-level interactions with the NAS layer. Second, applications do not need to know how to interact with the PE modules. That said, applications may prefer to interact with the PE modules, either directly or via the PEC 206, to obtain some predictions to optimize their behavior, regardless of PSM optimization. Third, the number of PE modules may grow over time in a WTRU or may be different in different WTRUs. Thus, the set of predictions available in a WTRU may be dynamically selected by the PSM 204 to meet the needs of a particular application, and applications do not need to know which predictions or modules are used to modify their PDU sessions. In other words, the PSM modules only need to be fully aware of the PE modules, not the applications. This condition may be more relaxed if the PSM interacts with the PE modules 210 via the PEC 206. In that case, the PEC only needs to be aware of the PE modules 210. It is worth emphasizing that the mapping between application requirements and predictions may be implemented by a set of standardized policies and rules.

[0086] One goal of the PSM is to prevent resources (e.g., network, radio, computation, storage, and energy) of the WTRU and the 3GPP system (including the RAN and CN) from being wasted. Below are some tasks that the PSM may dynamically perform: Initiate a PDU session modification procedure to increase or decrease the resources available to application traffic; Dynamically change application traffic priority within a PDU session; Switch User Plane Function (UPF) if the WTRU has multiple active PDU sessions to different UPFs, a common scenario with an Edge Application Server (EAS); Tear down or reactivate PDU sessions; and / or Stop or pause applications from continuing their current tasks (e.g., if the current tasks cannot meet the requirements of their applications).

[0087] The PSM may interact with the 5GC (e.g., NWDAF, AF, or other NFs) via the PEC component, which in turn may interact in part via NAS signaling. In this way, the PEC 206 can exchange information (e.g., data, predictions, analytics, and / or measurements) between the WTRU and the 5GC on behalf of the PSM 204. The PSM component may also interact with the 5GC via the NAS layer (more specifically, via NAS-SM signaling that terminates at the SMF). Finally, the PSM 110 may be empowered with ML techniques to make the PSM 204 decision-making more intelligent.

[0088] Exemplary Applications and Databases In this exemplary architecture, applications running on the WTRU can directly interact with the PE 202, the PSM 204, and the database 208. For example, applications may subscribe to some PE modules 210 to get event notifications about a set of predictions (e.g., GPU / CPU usage, available capacity in the next time window) directly or via the PEC 206. In this way, applications may proactively adjust their behavior, and the quality of user experience (e.g., QoE) may then be improved. Recall that the PE modules 210, the PSM 204, and the database 208 run at the application layer, preferably in virtualized and isolated containers.

[0089] Applications, PE modules, and PSMs can store their information in a database. This is particularly useful for the PE module 210, which usually needs to enter the history of certain parameters (e.g., WTRU mobility or GPU / CPU usage history). In one embodiment, this database can hold information for a short period of time, considering that some WTRUs may not be equipped with sufficient storage (memory) resources. Note that it is also possible to have multiple instances of this database for different activities.

[0090] Example Interactions with Entities External to the WTRU One advantage of using the PE sublayer in the WTRU is that other entities outside the WTRU can interact with the PE module (services), for example by exchanging data, predictions, analytics, and / or measurements. For example, an AF hosted in 5GC may access the WTRU (e.g., via a PEC) and may collect a set of predictions from the WTRU and use them locally to make some application-specific decisions (e.g., selecting a set of WTRUs for the next training cycle). Other NFs in 5GC, such as the AMF / SMF, may access the PE layer in a similar manner. The WTRU may also access some data and / or analytics generated by the NFs in 5GC. These interactions may be performed (e.g., partially performed) via NAS signaling, which allows the WTRU and 5GC to communicate securely with each other over the N1 interface. In this way, the AMF / SMF can act as an anchor point and relay messages between the WTRU and other NFs in 5GC, such as the NWDAF.

[0091] FIG. 3 shows an example of how the WTRU 201 and the 5GC 301 may interact via NAS signaling 320. In one embodiment, the WTRU (PE module 210) may provide useful predictions (related to the WTRU's network and computational resources) to the 5GC 301, which may then be used to optimize 5GS resources. Similarly, the 5GC may also provide some data and analysis to the WTRU, which may then be used within the PE module 210 to generate predictions (e.g., the AMF 314 may provide data to the WTRU's mobility prediction module) or to other WTRU components such as the applications 212 and the PSM 204. The PEC may interact with the 5GC NFs (e.g., the AMF 314, the SMF 312, the NWDAF 310) via NAS signaling 320 (over the N1 interface). 3GPP systems may support such interaction, which may therefore be activated during the WTRU's PDU session establishment or modification procedures [3]. That said, the WTRU can also provide its predictions to a 5GC NF, such as the NWDAF, via the AF. In this way, the AF can easily collect a set of WTRU predictions by interacting directly with the PEC module.

[0092] FIG. 4 illustrates one exemplary embodiment of how PEC and PSM may interact with 5GC. According to one embodiment, PSM 204 and PEC 206 can interact with SMF 312 via NAS-MM protocol using "SM" (Session Management Signaling) payload type. In this way, SMF 312 becomes an anchor point for exchanging data with other 5GC NFs (e.g. AI / ML 324 or NWDAF 310), and NAS messages are passed transparently through AMF. For PEC 206, it may be preferable to interact with NFs in 5GC directly through AMF 314 (i.e., via new signaling called "PEC signaling"). In this way, NAS messages with a payload type of "PEC" may be sent from the PEC layer to AMF 314 via the N1 interface (via NAS-MM protocol), which is terminated at the AMF. Once a PEC message arrives at the AMF, it may be routed to its destination (based on its message type) via an API-based interaction over HTTP. Using PEC signaling, the WTRU may communicate with any 5GC NF via the AMF. To send PEC signaling from the WTRU to the AMF, the NAS-MM layer 321 may create a NAS-MM message that includes a security header indicating the NAS transport of the PEC signaling and additional information for the receiving NAS-MM 321 to derive how to route the PEC signaling message to its destination. To receive the PEC signaling, the NAS-MM layer 321 may process the NAS-MM portion of the message and walk through the additional information portion to determine how and where to derive the PEC signaling message. The PEC signaling portion may include a PDU session ID.

[0093] NAS signaling (i.e., the N1 interface) is not the only way that the WTRU can interact with the 5GC. For example, the WTRU can interact with the 5GC over the user plane via the AF. For example, if the 5GC provides data and / or analysis to the WTRU, the AF may be configured to communicate directly (e.g., via the PEC 206) with the WTRU's PE. The interaction between the WTRU and the AF can be performed over a transport protocol. In this way, the WTRU application can first request their desired analysis from the PE (e.g., from the PEC). The PEC can then communicate with the AF. The AF can then subscribe to a set of NWDAFs (operating in the 5GC) to obtain their requested analysis either directly or via a network publishing function (NEF), depending on whether the AF is in a trusted or untrusted domain. When these analyses are available, the AF and then the PEC may be notified. The PE module can then consume these analyses and / or they may be provided to other WTRU components, such as the PSM. The PSM component may consume these analyses along with other predictions from the PE to intelligently modify the PDU session. Similarly, if the 5GC wants to get some predictions from the WTRU, it can interact with a set of PE modules via the AF. In this architecture, the AF can be an anchor point for relaying messages between the WTRU and the 5GC.

[0094] Example signal flow showing WTRU internal and external interactions 5 is a signal flow diagram illustrating an example embodiment of how the PSM can interact with a PE module in the WTRU and an NF in the 5GC. The procedures and interactions at each step are described in detail below.

[0095] In step 1, an application 212 can express its desired requirements and / or constraints (e.g., latency, bandwidth, availability, etc.) to the PSM 204 via a request / response message type interaction. With this service operation (sometimes called "Npsm_PDUSessionModification_Subscribe"), the application can provide its unique ID and corresponding pduSessioId, dnn, sNssai, supi, amfId, desired QoS profile, 5GMS core network capabilities, and other parameters necessary for the PSM to interact with the NAS layer and then with the 5GC on behalf of the application. In addition, the application may indicate what predictions are potentially required to meet those requirements / constraints.

[0096] Note that the PSM may not only handle a single application. Instead, it may handle PDU sessions on behalf of multiple or all WTRU applications. This means that the PSM has a comprehensive view of both the application requirements and the available resources of the current PDU session.

[0097] It should be noted that applications can also assist the PSM by periodically providing some data, e.g. end-to-end measurements and / or statistics. This event notification may be subscribed to directly by the PSM itself to the application. In other words, the application may be a data source for the PSM or other PE modules.

[0098] In step 2, the PSM 204 can check whether the currently established PDU session supports data exchange over the 5G control plane. This check can be performed using information provided to the PSM by the application layer.

[0099] In step 3, if the PSM 204 detects that the PDU session in question does not support data exchange with the 5GC (specifically, the AMF / SMF, e.g., 310-312, 314) via the control plane, the PSM may request the 5GC to activate such functionality in the AMF / SMF of the current PDU session or to reselect the AMF / SMF. To do this, the PSM may initiate a PDU session modification procedure indicating that the AMF / SMF supports such functionality and therefore should enable the WTRU to exchange information (such as data, analytics, and measurements) with the 5GC via the control plane.

[0100] Note that activating such functionality (i.e., enabling data / measurements / predictions exchange between the WTRU and the 5GC) may require authorization from the 5GC. For example, when the AMF / SMF receives such a request, it may contact the Policy Control Function / Unified Data Management (PCF / UDM) to check whether the AMF / SMF is authorized to exchange such information with the WTRU via NAS signaling.

[0101] Please note that an application can also request / activate such functionality from the 5GC during the PDU session establishment / modification procedure.

[0102] In step 4, the PSM may determine the set of prediction modules required in the PE to join if the application does not explicitly express the required prediction modules to the PSM in step 1. The PSM may try to collect other data and / or logs from WTRU internal data sources (e.g., application or radio protocol stack) or from external data sources such as NWDAF in the CN and / or AF. In the latter case, this may be done through the PEC 206. It is worth emphasizing that the PSM may have a standard mapping that can translate application requirements into a set of required predictions. For example, if the WTRU is equipped with more advanced PE modules in the future, this mapping may be updated, which means that the application does not necessarily need to be aware of the PE modules available in the WTRU. This frees the application developer from having to focus on low-level optimizations that the WTRU can perform on its behalf.

[0103] In step 5, the PSM can subscribe to the set of prediction modules identified in the previous step. This step may be done either via the PEC or directly with each PE module. The latter may introduce redundancy in distributing predictions if a prediction module may need to notify a set prediction consumers (e.g., PSMs). Still, the former may be advantageous if the PEC can collect predictions and then notify / distribute them to a set of prediction consumers.

[0104] Note that the PSM may also indicate to the PEC or PE module whether to store the desired prediction in a database. To simplify the call flow in Figure 5, the interaction with the database is not shown.

[0105] Note that applications can also subscribe to the PEC (or directly to the PE module) to get event notifications about sets of predictions when they become available. It is possible for the PSM to issue such requests to the PEC on behalf of the application.

[0106] In step 6, the PEC may determine whether it has already collected the requested predictions. If so, the PEC does not need to send the join message to the corresponding PE module again. However, if a current join needs to be updated (e.g., to change some parameters), the PEC may resend the join request message with the new parameters to the PE module. A similar determination may be performed by the PEC if the PSM requires any data and / or logs.

[0107] Note that the PEC may hold predictions and data for a group of prediction and data consumers, respectively. PSM and other WTRU applications may be data and prediction consumers at the same time.

[0108] Note that the PEC can also decide whether to store the collected predictions / data in a database (which could be a local WTRU database or a remote database hosted in the cloud or 5G network). This may be expressed directly by the prediction / data consumer (e.g., a PSM or other WTRU application). Interaction with the database is not shown in FIG. 5 for simplicity.

[0109] In step 7, if the PEC does not currently collect some requested predictions, it may subscribe to a corresponding prediction module (i.e., prediction provider 220), for example, via an EventExposure service similar to that used in 5GC. Alternatively or additionally, in step 7a, the PEC may request some analytics from 5GC via a NAS message (e.g., UL NAS transport) to the AMF. The AMF may then subscribe to a corresponding analytics provider (e.g., an NWDAF instance). When the AMF receives the event notification, it may relay it back to the WTRU (specifically, the PEC) via a NAS message (DL NAS transport). It should be noted that the SMF may be an anchor point for relaying messages between the WTRU and 5GC. In this way, when the AMF receives a WTRU request via a UL NAS transport message, the AMF can deliver it to the SMF by invoking the Nsmf_PDUSession_UpdateSMContext service operation. In this interaction, the AMF can provide the N1 SM container (i.e., NAS PDU and PDU Session ID) to the SMF. The SMF can then subscribe to the corresponding analysis provider (NWDAF). Note that the interactions between the five GC entities (e.g., AMF, SMF, and NWDAF) are not shown in Figure 5 to keep the call flow diagram simple.

[0110] In step 8, the prediction module may want to collect some data / logs for its prediction algorithm to run periodically. These data are typically formulated to accurately model the state of the WTRU, and thus some of these data may be commonly needed by some of the PE modules. To prevent such redundant data collection by the PE modules, the PEC may collect the data / logs on behalf of the PE modules, meaning that the PEC delivers the data / logs to each module, rather than each module directly asking the data source to get the data it needs. In this way, each PE module can express its desired data / logs to the PEC. Note that FIG. 5 illustrates a scenario in which each PE module interacts directly with the data source.

[0111] In one embodiment, the interaction in step 8 may be in the form of subscription / notification API communication or simply data retrieval / pulling from different entities within the WTRU (eg, applications, OS, network / radio protocol stacks, etc.).

[0112] In step 9, if the data provider 222 conforms to a RESTful API, the prediction provider 220 (i.e., a PE module) may subscribe to that EventExposure-like service. If so, the data provider 222 may notify the prediction provider (or, more precisely, the data consumer in this case) of the requested data / logs. Note that data provider is used broadly herein to denote any component in the WTRU that can provide data / logs to another component. For example, one of the ML modules 210 in the PE may be a data provider (i.e., a source of data or logs) to another ML module in the PE. For example, a mobility module may be a source of data to a bitrate module or a PSM component in the PE. In another example, a radio protocol stack may be a data provider to one or more PE modules. A data source may also be any entity in the 5GC, e.g., NWDAF, SMF, AMF.

[0113] In step 10, once the prediction provider 220 has collected its required input data (e.g., all required input data), it can feed it to its (AI / ML) algorithms, which then generate the required predictions.

[0114] In step 11, once the prediction provider (i.e., the PE module) generates the required prediction, the prediction provider can notify and / or distribute the prediction to the PEC. The PEC 206 can then notify and / or distribute the prediction to the PSM 204. Note that the prediction may also be distributed from the prediction provider 220 directly to the PSM 204 in response to a PSM / PEC subscription request. This alternative is shown by the dotted line in step 11a of FIG. 5. This step relates to data, analysis, and / or measurements coming from the 5GC via the control plane, for example, partly via NAS signaling. For example, as described in relation to step 7a, the PEC can request some analysis from the 5GC via a NAS message (e.g., UL NAS transport) to the AMF. The AMF can then subscribe to the corresponding analysis provider (e.g., NWDAF instance). When the AMF receives the event notification, it can relay it back to the PEC via a NAS message (DL NAS transport) (step 11(a)). The SMF may also be an anchor for relaying messages between the WTRU and the 5GC. A new NAS message type may be defined to identify these types of messages between the WTRU and the 5GC.

[0115] In step 12, the PSM 204 can collect all its predictions and data / logs for its optimization purposes. It can then decide how to modify the PDU session resources to provide better QoS treatment for the WTRU application, for example with the help of ML-based techniques. The PSM initiates a PDU session modification procedure to dynamically adjust the resources of the PDU session across the (R)AN and 5GC (SMF / UPF). The PSM may also suspend or terminate application activities based on its decision. The PSM may rely on NAS signaling to interact with the 5GC, although direct interaction between the PSM and the NF in 5GC is theoretically feasible via other transport mechanisms. The advantage of using NAS signaling is that it allows the WTRU to communicate with the 5GC over protected and authorized channels.

[0116] FIG. 6 is a flow chart illustrating a method according to an example embodiment. For example, FIG. 6 may illustrate a method for providing analytics, data, and / or predictions, e.g., using AI / ML techniques. In some embodiments, the method of FIG. 6 may be implemented, e.g., by a WTRU. In other example embodiments, the method of FIG. 6 may be performed by other network nodes or elements.

[0117] 6, the method may include receiving 610 an indication of requirements and / or constraints associated with one or more WTRU applications. According to some embodiments, the requirements and / or constraints may include, but are not limited to, any one or more of QoS requirements, latency, bandwidth, availability, and / or reliability.

[0118] Based on requirements and / or constraints associated with one or more WTRU applications, the method may include determining, at 620, to request one or more ML-based analyses, data, and / or predictions from the network and / or from an internal ML module of the WTRU. For example, the network may be a 3GPP and / or 5G core network, which may include one or more core network nodes (e.g., AMF, SMF, UPF, MME, SGW, NWDAF, etc.). According to some embodiments, the ML-based analyses, data, and / or predictions may be related to, for example, any one or more of computational resource availability, network capacity, signal strength or quality, and / or battery status.

[0119] 6 may include, at 630, transmitting a request or subscription for one or more ML-based analyses, data, or predictions to a network or an internal WTRU ML module. According to an example, transmitting 630 may include transmitting the request or subscription to the network via either Non-Access Stratum (NAS) signaling or a User Plane (UP) protocol. In some embodiments, transmitting 630 may include transmitting the request or subscription to an internal WTRU module via Hypertext Transfer Protocol (HTTP).

[0120] According to some embodiments, the method may include a Prediction Engine Coordinator (PEC) entity generating a request or subscription and sending the generated request or subscription to the network via NAS signaling. In one embodiment, the PEC entity may be configured to operate as part of a NAS-SM layer or as a standalone on a NAS-MM layer.

[0121] In an embodiment, the method may include an internal WTRU ML module generating one or more ML-based analyses, data, and / or predictions regarding the operation of the WTRU. According to some example embodiments, the internal WTRU ML module may include, but is not limited to, one or more of an ML module configured to generate a prediction of an available bit rate at the WTRU, an ML module configured to generate a prediction of a mobility state of the WTRU, and an ML module configured to generate a prediction of a processing unit utilization.

[0122] According to one embodiment, the method of FIG. 6 may include, at 640, receiving a response or notification of one or more ML-based analyses, data, and / or predictions from the network and / or an internal WTRU ML module.

[0123] In some embodiments, the method may include dynamically modifying, by a PDU session modifier (PSM) entity, a PDU session associated with one or more WTRU applications. For example, modifying the PDU session may include modifying, by the PSM, the PDU session to meet capacity requirements of the associated applications and optimize WTRU resource usage. According to one embodiment, the method may further include the PSM receiving application resource requirements from at least one of the applications, selecting a prediction module associated with determining appropriate PDU session parameters for a PDU session associated with the at least one of the applications, and activating the selected prediction module to generate a prediction of the determined PDU session parameters.

[0124] conclusion Although features and elements are provided above in specific combinations, one skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in this application, which are intended as illustrations of various aspects. As will be apparent to those skilled in the art, many modifications and variations may be made without departing from the spirit and scope of the present invention. No element, operation, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly set forth as such. In addition to those enumerated herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that the present disclosure is not limited to any particular method or system.

[0125] The foregoing embodiments are discussed with respect to the terminology and structure of infrared-enabled devices (i.e., infrared emitters and receivers) for simplicity, however, the discussed embodiments are not limited to these systems and may also be applied to other systems that use other forms of electromagnetic waves, or non-electromagnetic waves such as acoustic waves.

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

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

[0128] Modifications of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, the embodiments provided herein include a portable device, which may include or be utilized with any suitable voltage source, such as a battery providing any suitable voltage.

[0129] Further, in the above embodiments, it should be noted that processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one Central Processing Unit (CPU) and memory. In accordance with the practices of those skilled in the art of computer programming, references to operations and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such operations and operations or instructions may be referred to as being "executed," "computer executed," or "CPU executed."

[0130] Those skilled in the art will appreciate that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may cause a resultant transformation or reduction of the electrical signals, and maintains the data bits in memory locations of the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be appreciated that the embodiments are not limited to the platforms or CPUs mentioned above, and that other platforms and CPUs may support the methods provided.

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

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

[0133] There is little distinction between hardware and software implementations of aspects of the system. Whether to use hardware or software is generally a design choice that represents a cost vs. efficiency tradeoff (although in some circumstances the choice between hardware and software may be important). There may be a variety of vehicles (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other techniques described herein may be effective, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware vehicle. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0134] The foregoing detailed description has illustrated various embodiments of devices and / or processes through the use of block diagrams, flow charts, and / or examples. To the extent that such block diagrams, flow charts, and / or examples include one or more functions and / or operations, it will be appreciated by those skilled in the art that each function and / or operation within such block diagrams, flow charts, or examples may be individually and / or collectively implemented by a wide range of hardware, software, firmware, or substantially any combination thereof. In one embodiment, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated forms. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein may be equivalently implemented, in whole or in part, in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as substantially any combination thereof, and that designing circuitry and / or writing software and / or firmware code is within the skill of those skilled in the art in light of this disclosure. In addition, those skilled in the art will recognize that the subject matter mechanisms described herein may be distributed as program products in a variety of forms, and that representative embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution. Examples of signal bearing media include, but are not limited to, recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0135] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then use engineering techniques to integrate such described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein may be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, computing entities such as an operating system, drivers, graphical user interfaces, and application programs, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback to sense position and / or velocity, control motors to move and / or adjust components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication systems and / or network computing / communication systems.

[0136] The subject matter described herein may illustrate different components that are included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Thus, any two components herein that are combined to achieve a particular functionality may be considered to be "associated" with one another such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components so associated may be considered to be "operably connected" or "operably coupled" with one another to achieve the desired functionality, and any two components that can be associated in this way may be considered to be "operably couplable" with one another to achieve the desired functionality. Examples of operably coupleable include, but are not limited to, physically matable and / or physically interacting components, and / or wirelessly interactable and / or wirelessly interacting components, and / or logically interacting and / or logically interacting components.

[0137] With respect to the use of substantially any plural and / or singular term herein, those of skill in the art may convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. For purposes of clarity, various singular / plural permutations may be expressly set forth herein.

[0138] In general, those skilled in the art will understand that the terms used in this specification, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," and the term "includes" should be interpreted as "includes but is not limited to"). Furthermore, those skilled in the art will understand that where a specific number of recitations of an introduced claim are intended, such intention is expressly set forth in the claim, and in the absence of such recitation, no such intention exists. For example, where only one item is intended, the term "single" or similar language may be used. To aid in understanding, the following appended claims and / or the description of this specification may include the use of the introductory phrases "at least one" and "one or more" to introduce the claim recitations. However, the use of such phrases should not be interpreted as meaning that the introduction of a claim recitation with the indefinite article "a" or "an" limits any particular claim that includes such an introduced claim recitation to an embodiment that includes only such one recitation, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. In addition, those skilled in the art will recognize that even if a specific number of recitations of an introduced claim are explicitly recited, such recitation should be interpreted to mean at least the recited number (e.g., the simple recitation "two recitations" without any other qualifiers means at least two recitations, or more than two recitations).Furthermore, when notation similar to "such as at least one of A, B, and C" is used, such structure is generally intended as a person of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When notation similar to "such as at least one of A, B, or C" is used, such structure is generally intended as a person of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). Those skilled in the art will further appreciate that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" should be understood to include the possibilities of "A" or "B" or "A and B." Additionally, as used herein, the term "any of" followed by a list of items and / or a list of categories of items is intended to include "any of," "any combination of," "any more than," and / or "any more than," of the items and / or categories of items, individually or in combination with other items and / or other categories of items. Additionally, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. Also, as used herein, the term "multiple" is intended to be synonymous with "a plurality."

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

[0140] As will be appreciated by those skilled in the art, for all purposes, including in terms of providing a written description, all ranges disclosed herein also encompass any possible subranges and combinations of subranges thereof. Any recited range can be readily recognized as fully descriptive and allowing the same range to be broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, a middle third, an upper third, etc. As will also be appreciated by those skilled in the art, all words such as "up to," "at least," "greater than," "less than" and the like refer to ranges that include the recited numbers and that can be further broken down into subranges as discussed above. Finally, as will be appreciated by those skilled in the art, a range includes each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so on.

[0141] Moreover, the claims should not be read as limited to the provided order or to the provided elements unless specifically so stated. In addition, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. ...

[0142] Suitable processors include, by way of example, 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), an application specific standard product (ASSP), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine.

[0143] The WTRU may be used in conjunction with hardware and / or software implemented modules, such as, for example, a Software Defined Radio (SDR), and may be implemented in other components, such as a camera, a video camera module, a video phone, a speaker phone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, a Bluetooth module, a Frequency Modulation (FM) radio unit, a Near Field Communication (NFC) module, an LCD display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and / or a Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

[0144] Although various embodiments have been described with respect to a communications system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In particular embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0145] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications of the details can be made within the scope of the claims and their equivalents and without departing from the invention.

[0146] References The following references may have been mentioned above and are incorporated by reference herein in their entireties: [1] IETF RFC 7549, Hypertext Transfer Protocol Version 2 (HTTP / 2). https: / / datatracker.ietf.org / doc / html / rfc7540. [2] 3GPP TS 23.501 V17.1.1(2021-06). System Architecture for 5G Systems (5GS). Stage 2 (Release 17). [3] 3GPP TS 23.502 V17.1.0(2021-06). Procedures for 5G Systems (5GS). Stage 2 (Release 17). [4] 3GPP TS 24.501 V17.5.0(2021-12). Non-Access Stratum (NAS) Protocol for 5G Systems (5GS). Stage 3 (Release 17). [5] 3GPP TS 23.288 V17.1.0(2021-06). Architectural Extensions for 5G Systems (5GS) to Support Network Data Analysis Services (Release 17).

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: A transceiver; a processor, the processor comprising: Receiving an indication of at least one of requirements or constraints associated with one or more WTRU applications; determining one or more machine learning (ML) based analyses, data, or predictions based on the at least one of the requirements or constraints associated with the one or more WTRU applications to request or subscribe from at least one of a network or one or more internal WTRU ML modules; sending a request or subscription for the one or more ML-based analyses, data, or predictions to the network or the one or more internal WTRU ML modules; and receiving a response or notification of the one or more ML-based analyses, data, or predictions from at least one of the network or the one or more internal WTRU ML modules.

2. The WTRU of claim 1 , wherein the request or the subscription is transmitted to the network via either a Non-Access Stratum (NAS) signaling or a User Plane (UP) protocol.

3. The WTRU of claim 1 , wherein the request or the subscription is sent to the one or more internal WTRU modules via HyperText Transfer Protocol (HTTP).

4. The at least one of the requirements or constraints is: Quality of Service (QoS) requirements; and Waiting time, Bandwidth, Availability and / or and reliability. A WTRU as claimed in any one of claims 1 to 3.

5. The ML-based analysis, data, or predictions Availability of computational resources; Network capacity and The signal strength, Signal quality and / or and a battery status; A WTRU as claimed in any one of claims 1 to 4.

6. A Prediction Engine Coordinator (PEC) entity, comprising: generating said request or said subscription; sending the generated request or the generated subscription to the network via NAS signaling; a prediction engine coordinator (PEC) entity configured to: A WTRU as claimed in any one of claims 1 to 5.

7. The WTRU of claim 6, wherein the PEC entity is configured to operate as part of a NAS Session Management (NAS-SM) layer or as a standalone on a layer above a NAS Mobility Management (NAS-MM) layer.

8. The WTRU of any preceding claim, wherein the one or more internal WTRU ML modules are configured to generate the one or more ML-based analyses, data, or predictions regarding operation of the WTRU.

9. the one or more internal WTRU ML modules; an ML module configured to generate a prediction of an available bit rate at the WTRU; an ML module configured to generate a prediction of a mobility state of the WTRU; or and an ML module configured to generate a prediction of the processor utilization. The WTRU of claim 8.

10. a Protocol Data Unit (PDU) Session Modifier (PSM) entity configured to modify a Protocol Data Unit (PDU) session associated with the one or more WTRU applications; A WTRU as claimed in any one of claims 1 to 9.

11. The WTRU of claim 10, wherein the PSM is configured to modify the PDU session to meet capacity requirements of an associated application or to optimize usage of WTRU resources.

12. The PSM is receiving one or more application resource requirements from at least one of the applications; Selecting at least one prediction module associated with determining appropriate PDU session parameters for a PDU session associated with the at least one of the applications; and activating the selected prediction module to generate a prediction of the determined PDU session parameter.

12. The WTRU of claim 10 or 11.

13. 1. A method implemented in a wireless transmit / receive unit (WTRU), comprising: Receiving an indication of at least one of requirements or constraints associated with one or more WTRU applications; determining one or more machine learning (ML) based analyses, data, or predictions based on the at least one of the requirements or constraints associated with the one or more WTRU applications to request or subscribe from at least one of a network or one or more internal WTRU ML modules; sending a request or subscription for the one or more ML-based analyses, data, or predictions to the network or to the one or more internal WTRU ML modules; receiving a response or notification of the one or more ML-based analyses, data, or predictions from at least one of the network or the one or more internal WTRU ML modules; A method implemented in a wireless transmit / receive unit (WTRU), comprising:

14. 14. The method of claim 13, wherein the transmitting comprises transmitting the request or the subscription to the network via either a Non-Access Stratum (NAS) signaling or a User Plane (UP) protocol.

15. 14. The method of claim 13, wherein the sending comprises sending the request or the subscription to the one or more internal WTRU modules via HyperText Transfer Protocol (HTTP).

16. The at least one of the requirements or the constraints is: Quality of Service (QoS) requirements; and Waiting time, Bandwidth, Availability and / or and reliability. The method according to any one of claims 13 to 15.

17. The ML-based analysis, data, or predictions the availability of computational resources; Network capacity and The signal strength, Signal quality and / or and a battery status; The method according to any one of claims 13 to 16.

18. generating said request or said subscription by a Prediction Engine Coordinator (PEC) entity; transmitting, by the PEC, the generated request or the generated subscription to the network via NAS signaling; The method according to any one of claims 13 to 17, comprising:

19. 20. The method of claim 18, wherein the PEC entity is configured to operate as part of a NAS Session Management (NAS-SM) layer or independently on a layer above a NAS Mobility Management (NAS-MM) layer.

20. The method of any one of claims 13 to 19, comprising generating, by the one or more internal WTRU ML modules, the one or more ML-based analyses, data, or predictions regarding operation of the WTRU.

21. the one or more internal WTRU ML modules; an ML module configured to generate a prediction of an available bit rate at the WTRU; an ML module configured to generate a prediction of a mobility state of the WTRU; or and a ML module configured to generate a prediction of utilization of a processing unit of the WTRU.

22. modifying, by a Protocol Data Unit (PDU) Session Modifier (PSM) entity, a PDU session associated with the one or more WTRU applications. The method according to any one of claims 13 to 21.

23. 23. The method of claim 22 comprising modifying, by the PSM, the PDU session to meet capacity requirements of an associated application or to optimize usage of WTRU resources.

24. receiving, by the PSM, one or more application resource requirements from at least one of the applications; selecting, by the PSM, at least one prediction module associated with determining appropriate PDU session parameters for a PDU session associated with the at least one of the applications; activating the selected prediction module to generate a prediction of the determined PDU session parameter; 24. The method of claim 22 or 23, comprising:

25. A computer readable medium comprising program instructions for carrying out the method of any one of claims 13 to 24.

Images