Enhancing 3GPP systems to map traffic categories to application AI / ML operation types

Abstract

A wireless transmit / receive unit (WTRU) may receive a configuration. The configuration may include at least one of an artificial intelligence machine learning (AI / ML) operation type association with a traffic category. The traffic category may correspond to an AI / ML operation traffic category and / or at least one parameter. The WTRU may determine an AI / ML service operation type to be operated by, for example, an AI / ML application client on the WTRU. The WTRU may send, for example, a request for analysis and / or prediction related to the AI / ML service operation type to a network element. The request may include an indication of the traffic category and / or the at least one parameter. The WTRU may receive the analysis and / or the prediction related to the AI / ML service operation type, for example in response to the request.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 411,284, filed on September 29, 2022, and U.S. Provisional Application No. 63 / 517,726, filed on August 4, 2023, each of which is incorporated herein by reference in its entirety. Background Art

[0003] The traffic class may represent traffic generated by applications such as gaming, video streaming, and enterprise service related applications. The traffic class may be included in a wireless transmit / receive unit (WTRU) RSP (WTRU Routing Policy) within a traffic descriptor. Summary of the invention

[0004] Embodiments are described herein for providing a mapping of business classes to applied artificial intelligence (AI) / machine learning (ML) (AI / ML) operation types.

[0005] Described herein is an implementation for providing the use of UE routing selection policy (URSP) rules to match service classes and / or connection capabilities to application services, which may be further filtered using auxiliary parameters, such as connection capabilities, operating system identifier (OSid), application identifier (AppID) and / or single network slice assistance information (S-NSSAI) / data network name (DNN) (S-NSSAI / DNN).

[0006] The content described herein may include an application client in a wireless transmit / receive unit (WTRU), which may receive a mapping of application AI / ML operation type to service class and / or connection capability and / or auxiliary parameters (e.g., AppID) through an application layer, and / or the WTRU may use the mapping when requesting a connection from a NAS layer.

[0007] The WTRU may match the service class and / or the connection capabilities provided by the AI / ML application client with the associated URSP rules and / or may use the matched service class value to request analysis and / or prediction from the 5G Core (5GC).

[0008] The session management function (SMF) may use the service class and / or connection capabilities and / or auxiliary parameters received from the WTRU to identify the relevant analysis ID that the WTRU is requesting. The SMF may use one or more of the parameters to obtain relevant analysis from the unified data management (UDM).

[0009] A WTRU (e.g., a WTRU hosting an application client) may use URSP rules and / or information obtained from the application client, for example, to determine characteristics of a protocol data unit (PDU) session that may be used by the application client to perform AI / ML operations. A WTRU (e.g., a WTRU hosting an application client) may use URSP rules to obtain (e.g., from a network) a list of analysis IDs that the application client has access to, for example, by using service class and / or connection capabilities. The list may be provided to the application client.

[0010] The WTRU may receive a configuration. The configuration may include at least one of an artificial intelligence machine learning (AI / ML) operation type associated with a service class. The service class may correspond to the AI / ML operation service class and / or at least one parameter. The WTRU may determine, for example, an AI / ML service operation type to be operated by an AI / ML application client on the WTRU. The WTRU may, for example, send a request to a network element for an analysis and / or a prediction related to the AI / ML service operation type. The request may include an indication of the service class and / or the at least one parameter. The WTRU may, for example, receive the analysis and / or the prediction related to the AI / ML service operation type in response to the request.

[0011] The WTRU may match the AI / ML service operation type with the service class or the at least one parameter, for example, based on the configuration. The at least one parameter may be related to a service generated by one or more client applications on the network. The WTRU may match the AI / ML service operation type with the service class and / or the at least one parameter, for example, based on a routing policy (RSP) rule that matches the service class. The service class may indicate at least one AI / ML value. The at least one AI / ML value may indicate at least one of a model distribution value, a federated learning value, and / or an operation split value.

[0012] The traffic class may include the at least one parameter. The at least one parameter may include, for example, an application descriptor and / or a connection capability parameter that may be associated with an AI / ML value. The analysis and / or the prediction may indicate a quality of service (QoS) for the traffic to be generated by the client application on the network over a time period.

[0013] The WTRU may receive a mapping of the AI / ML operation type via a user plane. The WTRU may receive a mapping of the AI / ML operation type from an application function (AF). The at least one parameter may include at least one of a connection capability, an OSid, an App ID, and / or an S-NSSAI / DNN. The WTRU may determine a routing strategy based on, for example, the analysis and / or the prediction related to the AI / ML service operation type. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0015] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system.

[0016] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within an illustrated communication system.

[0017] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of another example RAN and another example CN for use within the illustrated communication system.

[0018] Figure 2A is a schematic diagram of an example system environment in which an AI / ML model can be implemented.

[0019] Figure 2B An example of a neural network is illustrated.

[0020] Figure 2C is a schematic diagram of an example system environment for training and implementing an AI / ML model including a NN.

[0021] Figure 3 is an example flow chart of a system requesting network data analysis.

[0022] Figure 4A and Figure 4B An example of WTRU RSP based configuration of traffic classes to application services is depicted. DETAILED DESCRIPTION

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

[0024] like Figure 1A As shown, the communication 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, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d 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 send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, and devices operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0025] 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 that is 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 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, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

[0030] In an 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).

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

[0032] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies 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), and GSM EDGE (GERAN).

[0033] Figure 1A The base station 114b in 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 local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. 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 an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0034] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, 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 described in detail in the text, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, 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. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT 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 be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0035] 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 that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

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

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

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

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

[0040] Although the transmit / receive element 122 Figure 1B 1 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.

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

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

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

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

[0045] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules 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 video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

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

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

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

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

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

[0051] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. 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.

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

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

[0054] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 networks and / or wireless networks owned and / or operated by other service providers.

[0055] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

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

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

[0058] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons 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 dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (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.

[0059] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0060] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

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

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

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

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

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

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

[0067] 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 while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle 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 eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0069] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0070] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 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 mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

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

[0073] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 networks 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 via the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0074] Given that Figures 1A to 1D as well as Figures 1A to 1D , one or more or all of the functions described herein for one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182ab, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0075] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0076] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0077] The systems, methods, and / or apparatus described herein may implement artificial intelligence (AI) and / or machine learning (ML) (AI / ML). For example, one or more devices in the communication system 100 may implement AI / ML. One or more of the WTRUs 102a, 102b, 102c, 102d, the RAN 104 / 113, and / or the CN 106 / 115 may implement AI / ML. Additionally, other WTRUs, base stations, and / or network elements may implement AI / ML.

[0078] Figure 2A201 is a schematic diagram of an example system environment 201 in which an AI / ML 209 model may be implemented. The AI / ML 209 model may include model data and one or more algorithms and / or functions configured to learn from received input data 207 to train the AI / ML 1209 and / or generate output 215. The input data 207 may be input in one or more formats, such as an image format, an audio format (e.g., a spectrogram or other audio format), a tensor format (e.g., including a one-dimensional or multi-dimensional array), and / or another data type capable of being input into the AI / ML 209 algorithm. The input data 207 may be the result of pre-processing 205 that may be performed on the raw data 203, or the input data 207 may include the raw data 203 itself. The raw data 103 may include image data, text data, audio data, or another information sequence (such as a network information sequence associated with a communication network), and / or other types of data. The pre-processing 205 may include format changes or other types of processing to generate the input data 207 in a format for input into the AI / ML 209 algorithm. For example, image data (e.g., including video data) and / or audio data may be raw data 203, which may be pre-processed during pre-processing 205 to generate input data 207 configured to be received by the AI / ML 209 algorithm. The input data 207 for generating the output may include one or more of the WTRU location (e.g., when analysis is requested), the WTRU identity (e.g., GPSI), and / or mobility registration update data. The mobility registration update data may include the periodicity of the registration. The network function may, for example, request analysis from the NWDAF to generate WTRU mobility statistics and / or predictions, and / or generate an algorithm to run an ML model. The mobility statistics and / or predictions and / or the algorithm to run an ML model may be executed by the NWDAF, for example, to obtain the (e.g., requested) analysis. The network function may be in a 3GPP 5G system. The NWDAF may collect / determine the algorithm to be executed (e.g., whether a federated learning operation is permitted) and / or the (e.g., required) input data. The input data may be collected from (e.g., related) NFs. The NWDAF may collect / determine algorithms and / or input data from (e.g., by viewing) an analysis ID and / or other auxiliary parameters (e.g., targets for analysis reports), for example, provided by an entity requesting statistics and / or predictions. A network entity (e.g., one or more of a gNB, a WTRU, and / or a NF (e.g., which requires network analysis from the NWDAF)) may request network analysis. The network entity may request network analysis by providing / transmitting an analysis ID. For example, the analysis ID may be set to UE mobility. The WTRU may request network analysis from the 5G system, for example, to determine characteristics of a data connection. The data connection may be used for ML mode distribution, such as part of a federated learning operation. There may be requests for multiple network analyses.The WTRU may provide input data, for example, including one or more of AI / ML operations / types / characteristics, traffic classes, and / or connection capabilities. The AI / ML algorithm 209 may generate an output. The output 215 may be generated by the AI / ML 209 algorithm in one or more formats, such as a tensor, a text format (e.g., a word, sentence, or other text sequence), a numerical format (e.g., a prediction), an audio format, an image format (e.g., including a video format), another data sequence format, or / another output format. The AI / ML algorithm 209 may predict and / or infer WTRU mobility analysis. The output 215 may include one or more of the following: a geographical distribution of WTRUs between tracking areas (TAs) and / or cells, and / or a direction of WTRU movement within a coverage area. The output 215 may additionally or alternatively include one or more analyses and / or predictions, for example, as described herein.

[0079] AI / ML can be implemented using software and / or hardware as described herein. AI / ML can be stored as computer executable instructions on a computer readable medium that can be accessed by one or more processors for execution as described herein. Example AI / ML environments and / or libraries include TENSORFLOW, TORCH, PYTORCH, MATLAB, GOOGLECLOUD AI and AUTOML, AMAZON SAGEMAKER, AZURE MACHINE LEARNING STUDIO, and / or ORACLE MACHINE LEARNING.

[0080] The AI / ML 209 may include one or more algorithms configured for unsupervised learning. Unsupervised learning may be implemented using AI / ML 209 algorithms that learn from input data 207 without training for a specific target output. For example, during unsupervised learning, the AI / ML 209 algorithm may receive unlabeled data as input data 207 and determine patterns or similarities in the input data 207 without additional intervention (e.g., updating parameters and / or hyperparameters). The AI / ML 209 algorithm configured to implement unsupervised learning may include an algorithm configured to identify patterns, groupings, clusters, anomalies, and / or similarities or other associations in the input data 207. For example, the AI / ML may implement a hierarchical clustering algorithm, a k-means clustering algorithm, a k-nearest neighbor (K-NN) algorithm, an anomaly detection algorithm, a principal component analysis algorithm, and / or a priori algorithms. An autoencoder may be a form of AI / ML 209 that may be implemented for unsupervised learning. An autoencoder may include an encoder configured to transform the input data 207 and / or a decoder that may regenerate the input data from the data received by the encoder. The autoencoder may be implemented to process image data and / or other forms of input data. The AI / ML 209 algorithm configured for unsupervised learning may be implemented on a single device or distributed across multiple devices such that the output 215 or portions thereof may be aggregated at one or more devices for further processing and / or implementation in other downstream algorithms or processes, as may be further described herein.

[0081] AI / ML 209 may include one or more algorithms configured for supervised learning. Supervised learning may be implemented using an AI / ML 209 algorithm trained during a training process to determine a predictive model using known results. The AI / ML 209 algorithm may be characterized by parameters and / or hyperparameters that may be trained during the training process. These parameters may include values ​​derived during the training process. These parameters may include weights, coefficients, and / or biases. AI / ML 209 may also include hyperparameters. These hyperparameters may include values ​​for controlling the learning process. These hyperparameters may include a learning rate, the number of time periods, a batch size, the number of layers, the number of nodes in each layer, the number of kernels (e.g., CNN), the stride size (e.g., CNN), the kernel size in the pooling layer (e.g., CNN), and / or other hyperparameters. In some cases, certain parameters and hyperparameters may be used interchangeably.

[0082] The AI / ML 209 may be trained during supervised learning by inputting training data into the AI / ML 209 algorithm and adjusting parameters and / or hyperparameters toward a known target output 215 while minimizing the loss or error in the output 215 generated by the AI / ML 209 algorithm. The raw data 203 may include or be divided into training data, validation data, and / or test data, which are used to train, validate, and / or test the AI / ML 209 algorithm during supervised learning, respectively. The training data, validation data, and / or test data may be pre-processed from the raw data 203 for input into the AI / ML 209 algorithm. During supervised learning, the training data may be labeled before being input into the AI / ML 209. The training data may be labeled to teach the AI / ML 209 algorithm to learn from the labeled data and to test the accuracy of the AI / ML 209 implemented on unlabeled input data 207 during production / implementation of the AI / ML 209 algorithm or a similar AI / ML 209 algorithm utilizing similar parameters and / or hyperparameters. The training data may be used to fit the parameters of the AI / ML 209 model using an optimization function, such as a loss or error function. Typically, the training data includes pairs of input data 207 and corresponding target outputs 215, and the parameters may be trained to generate these input data and target outputs (e.g., within a threshold loss or error). The trained or fitted AI / ML 209 model may receive validation data as input to evaluate the fit of the model to the training data set while tuning the hyperparameters of the AI / ML 209 model. The AI / ML 209 model may receive test data to evaluate the fit of the final model to the training data set and to evaluate the performance of the AI / ML 209 model. One or more of training, validation, and / or testing may be performed during supervised learning for different types of AI / ML 209 models.

[0083] Supervised learning can be implemented for various types of AI / ML 209 algorithms, including algorithms that implement linear regression, logistic regression, neural networks (NNs), decision trees, Bayesian logic, random forests, and / or support vector machines (SVMs). NNs and deep NNs (DNNs) are commonly used examples of algorithms utilized in AI / ML models that can be trained using supervised learning. However, the AI / ML 209 model may implement one or more NN-based and / or non-NN-based algorithms. Various examples of NNs include: perceptrons, multilayer perceptrons (MLPs), feedforward NNs, fully connected NNs, convolutional neural networks (CNNs), recursive NNs (RNNs), long short-term memory (LSTM) NNs, and / or residual NNs (ResNets). A perceptron is a NN that includes a function that multiplies its input by a learned weight coefficient to generate an output value. A feedforward NN is a NN that receives input at one or more nodes of an input layer and moves information in a direction through one or more hidden layers to one or more nodes of an output layer. In a feedforward NN, one or more nodes of a given layer may be connected to one or more nodes of another layer. A fully connected NN is a NN that includes an input layer, one or more hidden layers, and an output layer. In a fully connected NN, each node in one layer is connected to each node in another layer of the NN. MLP is a feedforward NN of the fully connected class. CNN is a NN with one or more convolutional layers that are configured to perform convolutions. Various types of NNs may have elements including one or more CNNs or convolutional layers, such as generative adversarial networks (GANs). GANs may include conditional GANs (CGANs), cycle-consistent GANs (CycleGANs), StyleGANs, DiscoGANs, and / or IsGANs. GANs may include a generator submodel and a discriminator submodel. The generator submodel may be configured to receive input data and pass real, independently generated data to the discriminator submodel. The discriminator submodel may be configured to receive real, independently generated data from the generator, discriminate real, independently generated data, and provide feedback to the generator submodel during training to improve the function of the generator submodel in independently generating outputs based on the received input. For example, GANs are models commonly used to generate data types or data sequences (such as image data, audio data, and / or text). RNNs are NNs that are recursive in nature because nodes include feedback connections and internal hidden states (e.g., memories) that allow outputs from nodes in the NN to affect subsequent inputs to the same node. LSTM NNs may be similar to RNNs because nodes have feedback connections and internal hidden states (e.g., memories). However, LSTM NNs may include additional gates to allow LSTM NNs to learn long-term dependencies between data sequences. ResNets are NNs that may include skip connections to skip one or more layers of the NN.An autoencoder may be a form of AI / ML 209 that may be implemented for supervised learning such that parameters and / or hyperparameters may be updated during the training process. These parameters and / or hyperparameters may be associated with the encoder portion and / or decoder portion of the autoencoder. Some NNs include one or more attention layers or functions to enhance or focus on some portions of the input data while attenuating or de-emphasizing other portions.

[0084] Different types of NNs and / or layers may be implemented to process different types of data and / or produce different types of outputs. For example, a NN may include one or more convolutional layers (e.g., for CNNs or GANs), which may be commonly used to process image data and / or audio data (e.g., spectrograms). Each convolutional layer may vary according to various convolutional layer parameters or hyperparameters, such as kernel size (e.g., the field of view of the convolution), stride (e.g., the step size of the kernel when traversing the image), padding (e.g., for processing image boundaries), and / or input and output sizes. The image being processed may include one or more dimensions (e.g., rows of pixels or a two-dimensional array of pixels). These pixels may be represented according to one or more values ​​(e.g., one or more integer values ​​representing color and / or intensity) that may be received by the convolutional layer. A kernel, which may also be referred to as a convolution matrix or mask, may be a matrix for extracting and / or transforming features from the input data being received. Kernels may be used for blurring, sharpening, and / or edge detection, among others. Example kernel sizes may include matrices such as 3x3, 5x5, 10x10 (e.g., in units of pixels of a 2D image). The stride can be a parameter used to identify the amount by which the kernel moves on the image data. Example default strides have a size of 1 or 2 within the matrix (e.g., in pixels of a 2D image). Padding can include the amount of data added to the border of the image data as it is processed by the kernel (e.g., in pixels of a 2D image). The kernel can move on the input image data (e.g., according to the stride length) and perform a dot product with the overlapping input region to obtain an activation value for the region. The output of each convolutional layer can be provided to the next layer of the NN, or as the output of the NN itself (e.g., image data, feature maps, etc.) with convolution-based updated features.

[0085] The NN may include layers of similar types (e.g., convolutional layers, feed-forward layers, fully connected layers, etc.) and / or layers having similar or different configurations (e.g., size, number of nodes, etc.). The NN may also or alternatively include one or more layers of the NN of different types or subsets, which may be interconnected for training and / or implementation as described herein. For example, the NN may include both convolutional layers and feed-forward layers or fully connected layers.

[0086] Figure 2BAn example of a neural network 209a is illustrated. The purpose of training can be to use input 207a as training data and / or adjust the Figure 2B One or more weights indicated as w and x in 209a (e.g., these weights may be referred to as neuron weights and / or link weights) are used to make the output 215 from the neural network 209a close to the desired target value associated with the input 207a values ​​used for the training data. In an example, the neural network may include three layers (e.g., Figure 2B ). During training, for a given input, the difference between the output and the expected value can be calculated and / or the difference can be used to update one or more weights in the neural network. For example, if a significant (e.g., large) difference between the output value and the expected value is observed, then one or more relatively significant (e.g., large) changes in one or more weights can be expected. A small difference (e.g., between the output value and the expected value) can include one or more relatively small changes in one or more weights.

[0087] Training the neural network 209a may include identifying one or more of the following information: inputs to the neural network; expected outputs associated with the inputs; and / or actual outputs from the neural network that are compared to target values.

[0088] In an example, a neural network model may be characterized by one or more parameters and / or hyperparameters, which may include: the number of weights and / or the number of layers in the neural network.

[0089] As used herein, the term "deep learning" may refer to a class of machine learning algorithms that employ artificial neural networks (e.g., deep neural networks (DNNs)) that are loosely inspired from biological systems and / or include at least one hidden layer. DNNs may be a special class of machine learning models inspired by the human brain, in which inputs are linearly transformed and / or passed through a nonlinear activation function one or more times (e.g., multiple times). DNNs may include one or more (e.g., multiple) layers, in which one or more (e.g., each) layer includes a linear transformation and / or a given nonlinear activation function. DNNs may be trained using training data via a back-propagation algorithm.

[0090] Figure 2C201a is a schematic diagram of an example system environment 201a for training and implementing an AI / ML 209 model including a NN 209a. However, other types of AI / ML models (e.g., including NN and / or non-NN models) may be similarly trained and / or implemented. The NN 209a may be trained and / or implemented on one or more devices to determine and / or update parameters and / or hyperparameters 217 of the NN 209a. Raw data 203a may be generated from one or more sources. For example, the raw data 203 may include image data, text data, audio data, or another sequence of information (such as a sequence of network information associated with a communication network) and / or other types of data. The raw data 203 may be pre-processed at 105a to generate training data 207a. The pre-processing may include formatting or other types of processing of changes to generate the training data 207a in a format for input into the NN 109a.

[0091] NN 209a may include one or more layers 211. The configuration of NN 209a and / or layer 211 may be based on parameters and / or hyperparameters 217. As described herein, these parameters may include weights or coefficients and / or biases for nodes or functions in layer 211. These hyperparameters may include learning rate, number of epochs, batch size, number of layers, number of nodes in each layer, number of kernels (e.g., CNN), stride size (e.g., CNN), kernel size in pooling layer (e.g., CNN), and / or other hyperparameters. As described herein, NN 209a may include a feedforward NN, a fully connected NN, a CNN, a GAN, an RNN, a ResNet, and / or one or more other types of NNs. NN 209a may be composed of one or more different types of NNs or different layers for different types of NNs. For example, NN 209a may include one or more separate layers with one or more configurations.

[0092] During the training process, training data 207a may be input into the NN 209a and may be used to learn parameters and / or tune hyperparameters 217. Training may be performed by initializing parameters and / or hyperparameters of the NN 209a; generating and / or accessing training data 207a; inputting training data 207a into the NN 209a; calculating the error or loss from the output of the NN 209a to the target output 215a via a loss function 213 (e.g., using gradient descent and / or associated back propagation); and / or updating parameters and / or hyperparameters 217.

[0093] The loss function 213 may be implemented using a back-propagation based gradient update and / or gradient descent technique, such as stochastic gradient descent (SGD), synchronous SGD, asynchronous SGD, batch gradient descent, and / or mini-batch gradient descent. Examples of loss or error functions may include functions for determining squared error loss, mean squared error (MSE) loss, mean absolute error loss, mean absolute percentage error loss, mean squared logarithmic error loss, pixel-based loss, pixel-by-pixel loss, cross entropy loss, logarithmic loss, and / or benchmark-based loss. These loss functions may be implemented based on one or more quality metrics, such as a signal-to-noise ratio (SNR) metric or another signal or image quality metric.

[0094] An optimizer may be implemented with the loss function 213. The optimizer may be an algorithm or function configured to adapt properties of the NN 209a, such as learning rate and / or weights, to improve the accuracy of the NN 209a and / or reduce loss or error. The optimizer may be implemented to update parameters and / or hyperparameters 217 of the NN 209a.

[0095] The training process may be iterated to update parameters and / or hyperparameters 117 until an end condition is reached. The end condition may be reached when the output of the NN 109a is within a predefined threshold of the target output 215a.

[0096] After the training process is completed, the trained NN 209a or a portion thereof may be stored for implementation by one or more devices. The trained NN 209a or a portion thereof may be implemented in other downstream algorithms or processes, as may be further described herein. The trained NN 209a or a portion thereof may be implemented on the same device that performs the training. The trained NN 209a or a portion thereof may be sent or otherwise provided to another device for implementation. For example, NN 209b, 209c may include one or more portions of the trained NN 209a. NN 209b and NN 209c receive corresponding input data 207b, 207c and generate corresponding outputs 215b, 215c. The outputs 215b, 215c may be generated in one or more formats, such as tensors, text formats (e.g., words, sentences, or other text sequences), numerical formats (e.g., predictions), audio formats, image formats (e.g., including video formats), another data sequence format, and / or another output format. The outputs 215b, 215c may be aggregated at one or more devices for further processing and / or implementation in other downstream algorithms or processes, as may be further described herein.

[0097] Alternatively or additionally, after the training process is completed, the trained parameters and / or tuned hyperparameters 217 or portions thereof may be stored for implementation by one or more devices. The trained parameters and / or tuned hyperparameters 217 or portions thereof may be implemented in other downstream algorithms or processes, as may be further described herein. The trained parameters and / or tuned hyperparameters 217 or portions thereof may be implemented on the same device that performs the training. The trained parameters and / or tuned hyperparameters 217 or portions thereof may be sent or otherwise provided to another device for implementation, for example, based on the trained parameters and / or tuned hyperparameters 217 being sent or otherwise provided to another one or more devices that can implement NN209b, 209c. For example, NN 209b, 209c may be constructed at another device based on the trained parameters and / or tuned hyperparameters 217 or portions thereof. NN 209b and NN 209c may be configured according to parameters / hyperparameters 217 or portions thereof to receive respective input data 207b, 207c and generate respective outputs 215b, 215c. Outputs 215b, 215c may be generated in one or more formats, such as tensors, text formats (e.g., words, sentences, or other text sequences), numerical formats (e.g., predictions), audio formats, image formats (e.g., including video formats), another data sequence format, and / or another output format. Outputs 215b, 215c may be aggregated at one or more devices for further processing and / or implementation in other downstream algorithms or processes, as may be further described herein.

[0098] The AI / ML models and / or algorithms described herein may be implemented on one or more devices. For example, the AI / ML 209 may be implemented in whole or in part on one or more devices, such as one or more WTRUs, one or more base stations, and / or one or more other network entities, such as network servers. An example network in which the AI / ML may be distributed may include a federated network. A federated network may include a group of dispersed devices, each device including the AI / ML. Figure 2C As shown, AI / ML 209b and AI / ML 209c may be distributed on separate devices. Figure 2C Two models are shown (e.g., AI / ML 209b and AI / ML 209c), but any number of models may be implemented across any number of devices. AI / ML may be implemented for collaborative learning, where the AI / ML is trained across multiple devices. In another example, the AI / ML may be trained at a centralized location or device, and one or more portions of the AI / ML or trained parameters and / or tuned hyperparameters may be distributed to decentralized locations. For example, updated parameters or hyperparameters may be transmitted to one or more devices to update and / or implement the AI / ML thereon.

[0099] Abbreviations including federated learning (FL), mobile terminal (MT), non-access stratum (NAS), NAS mobility management (NAS-MM), NAS session management (NAS-SM), wireless transmit receive unit (WTRU), and / or WTRU routing policy (WTRU RSP) may be used herein. AI / ML model transfer may be enabled. Analysis and / or prediction may assist AI / ML operation. Analysis and / or prediction may be transmitted to the WTRU, for example, from a 5G system (5GS).

[0100] The WTRU may receive analysis and / or predictions that may, for example, assist AI / ML operations running on the 5GS. Additionally or alternatively, AI / ML operations may be run on the WTRU. The IEAF may provide information in different formats (e.g., additional information and / or the same information in addition to the analysis identification). For example, other parameters such as service class may be provided. The IEAF may utilize (e.g., require) other information to enable the collection of analysis. The information may include one or more of service class, data network name (DNN) and / or S-NSSAI (Single Network Slice Assistance Information), for example to be used as (e.g., additional) filtering information from the NWDAF.

[0101] One or more entities may be implemented in a network to perform operations as described herein. Figure 4A and Figure 4B As shown, the network or system 400 may include one or more of a WTRU 438 , a (R)AN 440 , an AMF 442 , an SMF 444 , a UPF 446 , a PCF 448 , a UDM / NWDAF 450 , a UDR 452 , a NEF 454 , and / or an AF / AIML AF 456 .

[0102] There may be an indication of whether a WTRU data exposure client (DEC) should be configured with information (e.g., additional information and / or the same information using a different format, and / or different information elements). For example, the DEC may utilize (e.g., require) configuration information (e.g., in the form of service classes and / or connection capabilities) to request authorized analysis (e.g., requesting network congestion in a particular area) via the IEAF.

[0103] The application client (AC) and / or the DEC may determine the scope of functionality. For example, the AC and / or the DEC may determine whether the DEC may be an enhanced edge enabling client (EEC). Information for enabling the WTRU to communicate with the IEAF and / or authentication for enabling the WTRU to access (e.g., sensitive) network performance data (e.g., IEAF address, analysis ID, authentication and authorization information) may be included in the WTRU application client and / or the DEC. Additionally or alternatively, a mechanism is provided to determine how the information is configured (e.g., the information is pre-configured in the WTRU and / or pushed over a data connection).

[0104] The DEC may interpret the AC request, for example, even if the S-NSSAI is not provided by the client. For example, the WTRU application client may provide the S-NSSAI, and / or which S-NSSAI is provided to the WTRU application client.

[0105] The AF (e.g., IEAF / DCAF) address may be obtained from the WTRU ID, for example without using an NRF (e.g., using other NFs such as UDR). The maintenance of the association (e.g., mapping) between the WTRU ID and the WTRU ID serving DCAF may be achieved via the UDR (e.g., instead of the NRF).

[0106] For example, AI / ML services may be identified even if no explicit awareness of the AI / ML operation type is provided to the 5GS. The 5GC may (e.g., may need to) be explicitly aware of the application AI / ML operation type. The 5GS may determine the WTRU's ability to receive network analysis and / or prediction, and / or associated AILM operations (e.g., without using the AI / ML operation type). The WTRU may, for example, indicate to the 5GC the WTRU's ability to support (e.g., a particular) application AI / ML operation type and / or associated granularity.

[0107] The network may control the WTRU's access to resources, for example, to support specific types of services. For example, the 5GS may authorize and / or be able to authorize a (e.g., a specific) WTRU to participate in a (e.g., a specific) application AI / ML operation (e.g., the WTRU may not have the correct subscription to consume network resources to support the operation).

[0108] The GMSA requirements for supporting service categories can be described in this document.

[0109] The GSMA (e.g., GSM Association) may request 3GPP support for service classes. The service classes may represent services generated by applications including one or more of gaming, video streaming, and / or applications related to enterprise services. The service classes may be included in a (e.g., existing) WTRU RSP (e.g., WTRU routing policy), for example, within a service descriptor.

[0110] Routing guidance by traffic class may be described herein. For example, a mechanism for configuring WTRU RSP rules using AF routing guidance may be described. RSP rules may be used to select one or more of (e.g., specific) data networks and / or network slice combinations that may, for example, support AI / ML applications that better meet the needs of AI / ML clients in the WTRU.

[0111] The AF may instruct the 5GS to establish a WTRU routing selection policy (WTRU RSP). The WTRU RSP may be used to determine (e.g., appropriate) S-NSSAI and / or DNN combinations (e.g., associated with specific service conditions). The WTRU RSP may be used to characterize AI / ML operation services.

[0112] Additionally or alternatively, an example may involve including a service class within a WTRU RSP rule. A service class may represent a (e.g., specific) service that, for example, operates within an operator's network. A service class may be assigned standardized values ​​and / or mobile network operator (MNO) specific values, for example, to identify and / or classify (e.g., uniquely) services generated by any active application in a consistent manner, and / or may be included in a (e.g., existing) WTRU routing policy (RSP), for example, within a service descriptor.

[0113] Analysis filtering may be described herein. Network data analysis may be requested using an analysis ID and / or analysis filtering information, which may, for example, indicate conditions to be met for reporting analysis information. Parameter types and / or values ​​may enable selection of which type of analysis information to request.

[0114] WTRU RSP rules may be described herein. The WTRU may use one or more WTRU RSP rules to determine desired characteristics of a PDU session. For example, when the service is initiated by a WTRU application, the PDU session may carry application traffic. Characteristics of a PDU session may include, for example, one or more of a DNN, S-NSSAI, and / or a session and service continuity (SSC) mode that may be associated with the PDU session.

[0115] WTRU RSP rules include, for example, policies that may be used by the WTRU to determine how to route outgoing traffic. Traffic may be routed to a (e.g., established) PDU session. Additionally or alternatively, traffic may be offloaded to a non-3GPP access outside of a PDU session. Additionally or alternatively, traffic may be routed via a ProSe layer 3 WTRU to network relay, for example outside of a PDU session. Additionally or alternatively, traffic may trigger the establishment of a PDU session.

[0116] One or more WTRU RSP rules may include multiple (e.g., two) parts. The first part of the WTRU RSP rule may include a service descriptor, which may be used, for example, to determine when the rule is applicable. When one or more (e.g., each) components in the service descriptor match corresponding information from an application, it may be determined that the WTRU RSP rule is applicable. The second part of the WTRU RSP rule may include a list of routing descriptors (RSDs). The list of routing descriptors may contain one or more routing descriptors. The RSDs may be listed in priority order and / or may describe characteristics of, for example, PDU sessions that may be used to carry uplink application data. Characteristics of a PDU session may include one or more of an SSC mode, a DNN, and / or an S-NSSAI. Additionally or alternatively, the RSD may include a non-seamless offload indication, which may, for example, indicate that the service may be transmitted via a non-3GPP access (e.g., WiFi) and / or outside of one or more (e.g., any) PDU sessions.

[0117] The WTRU may evaluate the WTRU RSP rules in order of rule priority and / or determine whether an application matches a traffic descriptor of one or more (e.g., any) WTRU RSP rules, e.g., for each detected (e.g., newly detected) application. The WTRU may select a routing descriptor within the WTRU RSP rules, e.g., in order of routing descriptor priority. Additionally or alternatively, the WTRU may select a routing descriptor within the WTRU RSP rules when the WTRU RSP rule is determined to be applicable for a given application.

[0118] For example, when a valid routing descriptor is found, the WTRU may determine whether there are existing PDU sessions that match one or more (e.g., all) of the components in the selected routing descriptor. For example, when there are matching PDU sessions, the WTRU may associate the application to the existing PDU session (e.g., the WTRU routes the detected application's traffic on the PDU session). For example, if none of the existing PDU sessions matches the RSD, the WTRU may attempt to establish another PDU session using the values ​​specified by the selected routing descriptor.

[0119] For example, if the RSD includes a non-seamless offload indication, the WTRU may attempt to use a WLAN access network to send data outside of any PDU session.One or more WLANSP rules may be used to select a WLAN access network.

[0120] For example, once traffic from an application is associated with a PDU session, the WTRU may re-evaluate the WTRU RSP rules and / or associate traffic from the application with a different PDU session. For example, based on events and / or triggers, the WTRU may re-evaluate the WTRU RSP rules and / or associate traffic from the application with a different PDU session. Events and / or triggers for WTRU RSP re-evaluation may include an implementation-dependent re-evaluation timer and / or the WTRU establishing access to a Wi-Fi network, which may, for example, provide Internet access without using a 5G system (e.g., non-seamless offload becomes possible).

[0121] The traffic descriptor may include one or more of an application descriptor, an IP descriptor, a domain descriptor, a non-IP descriptor, a DNN, and / or a connection capability. The IP descriptor may include a destination IP 3-tuple (IP address and / or IPv6 network prefix, port number, protocol ID of the protocol on IP).

[0122] The traffic descriptor may include one or more connection capabilities. For example, if the traffic descriptor lists one or more application identifiers along with the one or more connection capabilities, the WTRU may determine that the application identifier identifies the application requesting access to the connection capabilities. Examples may include one or more of IMS, Multimedia Messaging Service (MMS), Secure User Plane Location (SUPL), Internet, and / or operator-specific connection capability values.

[0123] Operator specific service classes may be specified, for example, using a range of connection capability values. The values ​​may not be standardized and / or there may be no details on how an application may request operator specific service classes / connection capabilities (eg, for matching with a service descriptor).

[0124] For example, when communicating with an operating system (OS), an application may request connection capabilities. The request may be OS-specific. The OS may map an OS-specific value, for example, provided by the application to a standardized value. Additionally or alternatively, the OS may map an OS-specific value provided by the application to a standardized value so that the application can associate its application ID to the standardized connection capabilities.

[0125] The application may use the service class to signal the expected connection capabilities, for example as a specific implementation option. Alternatively or additionally, the application may use the service class when communicating with the OS. The OS may also convert the expected connection capabilities into (e.g., specific) connection capabilities. The connection capabilities (e.g., specific connection capabilities) and / or the conversion into (e.g., specific) connection capabilities may enable an OS vendor to provide, for example, service classes that match the reserved connection capability values.

[0126] Functionality may be used to determine how a WTRU may be configured with information that may enable the WTRU, for example, to request relevant / appropriate analysis from the network and / or to support AI / ML operation services running on 5GS. Additionally or alternatively, functionality may be used to determine how a WTRU and / or a network identifies, characterizes, and / or communicates information that may, for example, enable the WTRU and / or the network to process AI / ML operation services without signaling (e.g., explicitly signaling) the AI / ML operation type (e.g., when configuring the WTRU with relevant analysis IDs and / or AI / ML server addresses, requesting analysis and prediction, and / or when determining whether the WTRU is allowed to access resources to support a particular service type). Service categories may include one or more of gaming, video (e.g., video recognition), digital twins, and / or connectivity capabilities. Connectivity capabilities may include one or more of operator-specific AI / ML (e.g., operator-specific AI / ML-1, operator-specific AI / ML-2, and / or operator-specific AI / ML-3). Additionally or alternatively, functionality may still need to be determined to determine how and whether the WTRU should be authorized to request analysis and / or predictions from the network. A gaming business category may be associated with federated learning. A video (e.g., video recognition) business category may be associated with model distribution. A digital twin business category may be associated with operational splitting.

[0127] Embodiments may be provided herein for enabling an AI / ML application running in a WTRU to request network analytics, for example, from a 5G cellular network. Service class or connection capabilities may be used, for example, as analysis filtering information. Additionally or alternatively, statistics and / or predictions may be used (e.g., in a WTRU) to optimize AI / ML operations, for example, specific AI / ML operations. For example, an AI / ML AI / ML application may choose to exit a federated learning group if the AI / ML application knows that the QoS on a PDU session running an AI / ML service will drop below a threshold (e.g., this may prevent the group from falling behind).

[0128] The service class and / or connection capabilities (e.g., currently) may or may not support AI / ML operations, for example, to obtain AI / ML analysis. Requesting network data analysis using the application AI / ML operation type as analysis filter information may or may not be supported, for example, by the service class, connection capabilities and / or parameters. As disclosed herein, the WTRU may use the service class and / or connection capabilities to signal an intent to request network data analysis, for example, from the 5GS. The AI / ML application running in the WTRU may be configured, for example, by an application service provider. The AI / ML application may be configured with a mapping of AI / ML operations (e.g., model distribution and / or federated learning). The mapping of the AI / ML operation may be to a service class and / or to a connection capability, such as one or more of those in Table 1 and / or as herein. Table 1 shows an example mapping of application AI / ML operations to service classes and / or connection capabilities.

[0129] AI / ML operation types / features Business Category Connectivity Related network analysis Federated Learning game Operator Specific – AI / ML-1 Network performance Model Distribution Video Recognition Operator Specific – AI / ML-2 WTRU communication Operation Splitting Digital Twin Operator Specific – AI / ML-3 QoS Sustainability

[0130] Table 1

[0131] Figure 3 300. At 302, 304, and / or 306, the AI / ML application function may configure a data analysis mapping in a data collection function (e.g., at 304) and / or a NF (e.g., a UDR (e.g., at 306)). One or more functions (e.g., of these functions) may reside within the operator's domain. The mapping may be used at 316 and / or 320, for example, to derive (e.g., applicable) network data analysis. The network data analysis may be requested from the network analysis function.

[0132] The WTRU may receive a configuration from the network, the configuration including an association between an (AI / ML) operation type and a service class, which service class may, for example, correspond (e.g., each) to an AI / ML operation service class and / or another parameter. For example, at 308, the AI / ML application function may provide a mapping of (e.g., associated) network analysis to service class and / or connection capabilities. Alternatively or additionally, the AI / ML function may provide other auxiliary parameters, such as one or more of an applicable network slice (e.g., applicable S-NSSAI), a DNN, an OSid, an application ID, and / or an AF address of a data collection function (e.g., IEAF) on the network side. For example, when there is a data connection with an AI / ML client in the WTRU and / or the information is pre-configured in the AI / ML client in the WTRU, the information and / or parameters may be provided by the AI / ML application function. The mapping may be consistent with those provided to the 5GC, for example, in steps 304 and / or 306 (e.g., similar or identical information may be provided to the AI / ML client in the WTRU and / or the applicable NF in the 5GC).

[0133] At 310, the AI / ML client may request data connectivity and / or establish a PDU session from the OS, for example, to enable data connectivity toward AI / ML application functions. Alternatively or additionally, the AI / ML client may request data connectivity and / or establishment of a PDU session from the OS at any time. For example, in the event that the AI / ML client requires network data analysis, the AI / ML client may request network data analysis from the 5GC. The AI / ML may provide (e.g., applicable) service categories and / or connection capabilities. The AI / ML may provide other parameters, such as one or more of DNN, Application Id, S-NSSAI, and / or (e.g., explicit) indications that network analysis is required. For example, the presence of connection capabilities associated with AI / ML services may be used to indicate (e.g., implicitly mark) the need for network data analysis associated with the connection capabilities, for example without having to explicitly request these network data analyses. The AI / ML application request may additionally or alternatively indicate whether network analysis should be requested via the user plane (e.g., using addressed AF data collection provided by the AI / ML application function) and / or via the control plane (e.g., using AI / ML specific connection capabilities). Although the AI / ML client request may be OS specific, the request may be implemented using an attention (AT) command. For example, an OS specific request from an AI / ML client may be mapped by the OS onto a commonly created AT command.

[0134] The OS may, for example, issue an AT command and / or applicable implementation-specific message to the WTRU 3GPP 5G modem at 312. The request may include information about the AI / ML client request, for example using a modem vendor-specific application programming interface (API).

[0135] For example, in the event that there is not already an existing PDU session that satisfies the request from the AI / ML client, the WTRU may determine the request and / or may request to establish a PDU session. An entity (e.g., an entity discussed herein) may determine the request and / or may request to establish a PDU session. For example, the entity may include one or more of a data collection entity and / or a session management entity. The PDU session may match, for example, a URSP rule that is found to be applicable to the AI / ML client request (e.g., matching the connection capabilities communicated by the AI / ML client). The WTRU may include the connection capabilities provided by the AI / ML client in the request. Alternatively or additionally, if, for example, a data collection client exists, the WTRU may decide to transmit the network data analysis request over the user plane. Transmitting the network data analysis over the user plane may utilize, for example, a data collection application function address provided by the AI / ML client. The WTRU selecting / determining to request network data analysis using a PDU session request and / or via a data collection entity may be based on whether the addressed data collection application function exists and / or whether a data collection entity exists in the WTRU.

[0136] At 316, for example, if the WTRU chooses to use a data collection entity, a request may be transmitted over the established PDU session to deliver AI / ML specific services. Additionally or alternatively, the request may be transmitted using connection capabilities, for example, to match applicable URSP rules.

[0137] At 318, the data collection application function may request applicable network data analysis using, for example, the connection capabilities and / or mapping configured at 304. The results may be communicated back to the data collection entity in the WTRU.

[0138] At 320, for example, if the WTRU decides to request establishment of a PDU session, the WTRU may include connection capabilities in the PDU session establishment. Including the connection capabilities may signal to the SMF a request for network data analysis associated with the connection capabilities.

[0139] At 322 and / or 324, the SMF may obtain, for example, a list of applicable network data analysis IDs from the UDR. This information (eg, a list of applicable network data analysis IDs) may be used to request network data analysis from the NWDAF.

[0140] At 326, the SMF may decide to provide the requested network data analysis (e.g., using an associated PDU Session Establishment Accept message), for example, depending on whether the network data analysis is available at the SMF when the WTRU requests the network data analysis. Additionally or alternatively, the SMF may use a PDU Session Modification procedure. The SMF may include the network data analysis with a Protocol Configuration Option (PCO) field and / or any other parameters (e.g., within the Protocol Configuration Option (PCO) field and / or any other parameters). The network data analysis may be used by the WTRU to determine the level of participation in existing and / or future application AI / ML operations, for example, depending on the connectivity capabilities provided by the WTRU. The network analysis may include one or more of network load (e.g., in an area of ​​interest), QoS sustainability analysis, WTRU mobility, WTRU communication analysis, and / or quality of experience analysis. The AI / ML client in the WTRU may decide not to participate in federated learning operations. For example, if the AI / ML client is about to be handed over to an area where congestion may occur and / or if the QoS characteristics of the data connection will not meet the requirements of applying the AI / ML operation to transfer a large amount of data between the AI / ML application client in the WTRU and the AI / ML application at the application function on the network side, the AI / ML client may decide not to participate in the federated learning operation. The WTRU may determine, for example, the type of AI / ML service operation to be performed by the AI / ML application client on the WTRU.

[0141] Some examples provided herein may use / utilize the concept of associating a service class and / or connection capability to an application AI / ML operation service and / or to an application AI / ML operation type service. The AI / ML operation service may be identified by a service class and / or connection capability. Additionally or alternatively, the AI / ML operation type may be identified using one or more components from a service descriptor. One or more components from a service descriptor may be used as analysis filtering information (e.g., a service class may be and / or may include an AI / ML service). The (e.g., specific) AI / ML operation type may be (e.g., further) identified by one or more of an S-NSSAI, an OSid, a connection capability, and / or an application ID.

[0142] Additionally or alternatively, a particular application AI / ML operation type may be identified using a business class. The business class may include one or more of federated learning, model distribution, and / or split AI / ML operations. The business class may additionally or alternatively include at least one parameter. The at least one parameter may include, for example, an application descriptor and / or a connection capability parameter that may be associated with the AI / ML value.

[0143] The WTRU may, for example, send a request to a network element for analysis and / or prediction related to an AI / ML service operation type. The request may include an indication of a service class and / or at least one parameter. The WTRU's request for analysis and / or prediction from the network may be authorized by a mechanism (e.g., via an Oauth 2.0 authorization token). The token may be requested by the AF from the network and / or delivered to the WTRU, for example, along with a policy. For example, when the WTRU requests network analysis and / or prediction, the request message may include an authorization token. The network may, for example, use a token provided by the WTRU to verify the request. The WTRU may, for example, receive analysis and / or prediction related to the AI / ML service operation type in response to the request. Additionally or alternatively, the analysis and / or prediction may indicate a quality of service (QoS) for a service to be generated by a client application on the network within a time period. The WTRU may receive a mapping of the AI / ML operation type via a user plane. The WTRU may receive a mapping of the AI / ML operation type from an application function (AF).

[0144] Associating and / or mapping service categories to AI / ML operation types (e.g., applications of AI / ML operation types) may be described herein. The AF may provide a mapping of service categories associated with application AI / ML operation types to the 5GC. A service category may be equivalent to an AI / ML service. Characteristics of (e.g., specific) application services may be associated with AI / ML operation types. The mapping may avoid the need for 5GC to require knowledge (e.g., explicit knowledge) of AI / ML operation types. Additionally or alternatively, services running on (e.g., specific) PDU sessions may be obtained by the 5GC and / or may be associated with service categories (e.g., AI / ML services). The AF may provide application services, including, for example, packet flow descriptions. Additionally or alternatively, the AF may associate an analysis ID and / or analysis filter with an application service. The analysis ID and / or analysis filter may indicate one or more conditions (e.g., regions of interest and / or time windows) to be met for reporting analysis information.

[0145] The WTRU may match the AI / ML service operation type with a service class or at least one parameter, for example based on a configuration. The at least one parameter may be related to a service generated by one or more client applications on the network. The WTRU may match the AI / ML service operation type with a service class and / or at least one parameter, for example based on a routing policy (RSP) rule that matches the service class. The WTRU may determine a routing policy based on, for example, analysis and / or prediction related to the AI / ML service operation type. The at least one parameter may include at least one of a connection capability, an OSid, an App ID, and / or an S-NSSAI / DNN. The service class may indicate at least one AI / ML value. The at least one AI / ML value may indicate at least one of a model distribution value, a federated learning value, and / or an operation split value.

[0146] For example, when the AF provides a mapping of service classes to application services to the 5GC, the WTRU may provide (e.g., optionally provide) a connection capability value, such as to (e.g., further) identify the application AI / ML operation service, and / or map both the service class and / or the connection capability to a specific application service. The application service may be associated with characteristics including one or more of an application ID, S-NSSAI, DNN, time window, and / or AoI (area of ​​interest).

[0147] The AF may determine that, for example, an application AI / ML operation service that supports FL operations can be tagged with a service class (e.g., associated with a service class). The tag may include AI / ML services. The connection capability may include AIM-Loption_1. AIM-Loption_1 may refer to, for example, a federated learning service, and / or two or more values ​​(e.g., DNN-1 and / or S-NSSAI-2) may be mapped to (e.g., a specific) time window and / or location. Additionally or alternatively, the AF may provide the 5GC with a set of analysis IDs that are relevant / valid for one or more service classes and / or connection capabilities. The AF may provide the 5GC with a set of analysis IDs using the process described herein. The AF may determine that AI / ML operations with specific QoS requirements can be tagged with a service class associated with (e.g., a specific) application service.

[0148] Associating a traffic class to an application traffic descriptor may be described herein. Table 2 provides examples of traffic descriptors that may be used by one or more WTRUs.

[0149]

[0150]

[0151] Table 2

[0152] The AF may, for example, use application guidance for the WTRU RSP determination process (e.g., as described herein) to provide one or more mapping parameters described herein to the 5GS. The AF may provide one or more mapping parameters to the 5GS by using service parameter operations, for example, utilizing enhancements as described herein.

[0153] The WTRU may be configured (e.g., pre-configured) with one or more of a service class, S-NSSA, AppID, and / or server FQDN. The WTRU registration may be sent to one or more of the WTRU, RAN, AMF, SMF, UPF, PCF, UDM / NWDAF, and / or UDR. The WTRU registration may include a policy association. The WTRU registration may include a Nudr_DM_Subscribe send. The PDU session establishment may be sent to one or more of the WTRU, RAN, AMF, SMF, UPF, PCF, UDM / NWDAF, and / or UDR. The WTRU may receive WTRU policy delivery, for example, using enhancements as described herein. The WTRU may receive an analysis request with a TC and / or AppID from an application client. The WTRU may select one or more WTRU RSP rules associated with one or more of a TC, App, S-NSSAI, AppID, DNN, time window, and / or location. The WTRU may request analysis, for example, using one or more of TC, S-NSSAI, DNN and / or CC via SMF. The WTRU may request analysis, for example, using one or more of TC, S-NSSAI, DNN and / or CC via AF.

[0154] The WTRU (e.g., an application client in the WTRU) may receive a WTRU (e.g., via a user plane) mapping of AI / ML operation types to service classes, for example, from the AF. The service class may correspond to one or more of the AI / ML operation, service class, S-NSSAI / DNN combination, and / or OSId and application ID, for example, to identify the AI / ML operation type. The WTRU may receive a WTRU mapping of AI / ML operation types from the AF. The application client WTRU may use the mapping when requesting a connection, for example, from the NAS layer.

[0155] The WTRU may match a service class, provided, for example, by an AI / ML application client, with associated WTRU RSP rules and / or use the matched service class value to request analysis and / or prediction from the 5GC.

[0156] See again Figure 4A and Figure 4B, an example 400 of WTRU RSP-based configuration of a service class to an application service is shown. For example, the WTRU may receive a configuration. The configuration may include at least one of an AI / ML operation type association with a service class. The service class may correspond to an AI / ML operation service class and / or at least one parameter. The service class may include the at least one parameter. The at least one parameter may include, for example, an application descriptor and / or a connection capability parameter that may be associated with an AI / ML value. At 402, an AI / ML application client in the WTRU may be configured with a mapping of an application AI / ML operation type to one or more (e.g., specific) service class values ​​and / or connection capability values. Additionally or alternatively, one or more other parameters may be used to further adjust the mapping. One or more of the S-NSSAI, DNN, AppID, server FQDN, and / or OSId may (e.g., also) be configured in the AI / ML application client as part of the mapping.

[0157] At 404 and / or 406, the WTRU may register with the system and / or establish a PDU session to connect to the AI / ML AF. At 408, the AF may determine to update the WTRU with a mapping of service classes to AI / ML operation types. For example, to achieve this, the AF may associate one or more service classes to an application AI / ML operation type and / or may map one or more of the service classes to an application service.

[0158] At 410, the WTRU may negotiate with the AFAI / ML (e.g., via the user plane) the configuration of a mapping of service categories (e.g., and App IDs and / or connection capabilities) to application AI / ML operations. At 412, the AF may provide one or more mappings of service categories and / or connection capabilities to (e.g., specific) application services to the 5GC. Additionally or alternatively, the AF may provide an analysis ID associated with the service category and / or with the NSWDAF instance ID. The AF may obtain one or more analysis IDs by subscribing to (e.g., related) NWDAF services (e.g., via the NEF). The AF may, for example, register the analysis ID in the UDM subscriber record using the service category and one or more of the AppID, S-NSSAI, connection capabilities, and / or OSid as data keys. For example, at 414, 416, and / or 418, the NEF may request authorization from the UDM via service-specific information. The authorization may include one or more of a traffic class, a connection capability, a service type (e.g., AF guidance for mapping traffic classes to application traffic), and / or an associated analysis ID. The WTRU may match the AI / ML service operation type with the traffic class or at least one parameter, for example based on a configuration. The at least one parameter may be related to traffic generated by one or more client applications on the network. The WTRU may match the AI / ML service operation type with the traffic class and / or at least one parameter, for example based on a routing policy (RSP) rule that matches the traffic class. The traffic class may indicate at least one AI / ML value. The at least one AI / ML value may indicate at least one of a model distribution value, a federated learning value, and / or an operation split value.

[0159] At 420, the NEF may store the AF request in the UDR according to the current procedure. At 422, the NEF may respond to the AF, for example, with a Nnef_ServiceParameter_Create / Update / Delete Response. At 424, the UDR may notify the PCF about the parameter update provided by the AF. At 426, the PCF may deliver a policy, which may, for example, indicate a service class ID and / or one or more analysis IDs associated with the service class included in the service descriptor. At 428, the AI / ML application client may request connectivity, and / or the AI / ML application client may provide TC, AppID, and / or other auxiliary parameters. At 430, the WTRU may receive a connection request from the AI / ML application client (AC), and / or the WTRU may use a policy to modify and / or match the service class and / or auxiliary parameters provided by the AC (e.g., connection capabilities, S-NSSAI and / or AppID, OSid).

[0160] Conditional requests for analysis using a control plane solution (e.g., via SMF) may be described herein. For example, at 432, the WTRU may request analysis and / or prediction from the network. The WTRU may replace the application AI / ML operation type with a service class and / or auxiliary parameters.

[0161] At 434, the SMF may use the parameters described herein to identify the analysis IDs of one or more WTRUs. The SMF may use the parameters to obtain the relevant analysis IDs associated with the service class provided by the WTRU, for example by requesting the information from the UDM. The UDM may use one or more of the service class, connection capabilities, OSid, AppID and / or S-NSSAI as data keys. For example, at least one parameter may include at least one of the connection capabilities, OSid, App ID and / or S-NSSAI / DNN. The WTRU may determine a routing strategy based on, for example, analysis and / or prediction related to the AI / ML service operation type.

[0162] Rule priority can be used to prioritize services with a particular service class. For example, when one or more (e.g., some) of the components of a rule including a service class are also part of another rule (e.g., domain descriptor and / or IP tuple), the rule priority can be used.

[0163] Conditional requests for analysis, for example, using a user plane solution (e.g., by an AF) may be described herein. At 436, the WTRU may request analysis and / or prediction from the network using the procedures described herein and / or replacing a specific analysis ID. The WTRU may request analysis and / or prediction from the network with a traffic class and / or auxiliary parameters, for example, to help the SMF identify (e.g., correlate) an analysis ID.

[0164] WTRU RSP rules for obtaining analysis IDs that an application client can access may be described herein. A WTRU hosting an application client may use WTRU RSP rules and / or information obtained from an application client, for example, to determine characteristics of a PDU session. The characteristics may be used by the application client to perform AI / ML operations and / or, for example, to obtain a list of analysis IDs that the application client can access from the network. The list of analysis IDs may be provided to the application client.

[0165] The connection capability in the service descriptor of the WTRU RSP rule may be assigned a value of AI / ML. The (e.g., identical) service descriptor may include one or more application identifiers. The WTRU RSP rule may include one or more RSDs. Each of the one or more RSDs may include a DNN / S-NSSAI combination, which may be used, for example, to establish a PDU session that may support AI / ML operations. The service descriptor may (e.g., further) include one or more operation type values. The operation type value may indicate one or more of model distribution, operation splitting, and / or federated learning.

[0166] For example, an AI / ML application client hosted on the WTRU may provide a traffic descriptor to the NAS layer of the WTRU. The AI / ML application client may provide the traffic descriptor to the MT part of the WTRU, for example, by invoking an AT command (e.g., +CGDCONT). The traffic descriptor may include one or more of an application ID, connection capabilities, and / or one or more operation type values.

[0167] For example, the connection capability value of the business descriptor provided by the application client can be set to AI / ML. For example, the operation type value of the business descriptor provided by the application client can be set to one or more of model distribution, operation splitting and / or federated learning. The operation type value may indicate which of three or more operation types the application wants to perform. The operation type value may indicate multiple operation types (for example, it may indicate that model distribution and / or operation splitting are desired, but federated learning is not desired). The application client can determine how to set the value of the business descriptor as described herein.

[0168] For example, upon receiving a service descriptor from an application client, the NAS layer may compare the service descriptor from the application client with the service descriptor of the WTRU RSP rule (e.g., configured in the WTRU). If a condition (e.g., two conditions) is met, the WTRU NAS layer may determine (e.g., consider) that the service descriptor from the application client matches the service descriptor of the WTRU RSP rule. The first condition may include that the application ID and / or connection capability value of the service descriptor from the application client is equal to the service descriptor of the WTRU RSP rule. The second condition may include that the operation type value of the service descriptor from the application client is included in the service descriptor of the WTRU RSP rule. For example, in the case where the application client provides an operation type value for one or more of model distribution and / or operation splitting, and the service descriptor of the WTRU RSP rule includes model distribution, operation splitting and / or federated learning, the operation type value may be considered to match.

[0169] The WTRU NAS layer may use the RSD of the WTRU RSP rule to determine a DNN and / or S-NSSAI combination, which may be used, for example, to establish a PDU session for a service of an application client. Once the WTRU RSP rule is determined (e.g., found) to be matched, the WTRU NAS layer may use the RSD of the WTRU RSP rule to determine the DNN and / or S-NSSAI combination. The WTRU NAS layer may transmit a PDU session establishment request to the network and / or may include the determined DNN and / or S-NSSAI in the PDU session establishment request. The DNN and / or S-NSSAI values ​​may be used by the network to select an AMF and / or SMF, which may, for example, service the AI / ML request. The PDU session establishment request may include, for example, a service descriptor (e.g., one or more of an operation type value, an application ID, and / or a connection capability) provided by the application client. The SMF may receive, for example, in the PDU session establishment request, an indication of a WTRU operation (e.g., an operation that the WTRU intends to perform). The indication of the WTRU operation may be included in a traffic descriptor (e.g., one or more of an operation type value, an application ID, and / or connection capabilities) in the PDU SESSION ESTABLISHMENT REQUEST. The SMF may use the traffic descriptor (e.g., one or more of an operation type value, an application ID, and / or connection capabilities) to identify, for example, an analysis ID that may be accessed by the WTRU. Additionally or alternatively, the SMF may provide the analysis ID to the WTRU in the PDU SESSION ESTABLISHMENT ACCEPT message.

[0170] Additionally or alternatively, the traffic descriptor may be included in a NAS-MM message. The NAS-MM message is used by the WTRU to transmit a PDU SESSION ESTABLISHMENT REQUEST to the network. The AMF may receive an indication of a WTRU operation (e.g., an operation that the WTRU intends to perform), for example, by including an operation type value in a NAS-MM message. The AMF may use the traffic descriptor to identify an analysis ID that is accessible to the WTRU and / or the AMF may provide the analysis ID to the WTRU, for example, in a NAS-MM message carrying a PDU SESSION ESTABLISHMENT ACCEPT message.

[0171] For example, when the NAS layer receives the analysis ID (e.g., accessible by the WTRU), the NAS layer may provide the analysis ID to the AI / ML application client. The WTRU may transmit a NAS-SM message (e.g., PDU Session Modification Request) to the network, for example, to provide a service descriptor (e.g., one or more of an operation type value, an application ID, and / or a connection capability) to the SMF and / or AMF. For example, if the WTRU NAS layer determines that the service descriptor from the application client matches the service descriptor of the WTRU RSP rule and / or the selected RSD matches the already established PDU session, then the service descriptor may be provided by the application client. For example, when the WTRU receives a NAS-MM message from the AMF and / or receives a NAS-SM (e.g., PDU Session Modification Command) from the SMF, the analysis ID may be received by the WTRU.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving a configuration, the configuration comprising at least one of an artificial intelligence machine learning (AI / ML) operation type association with a business class, wherein the business class corresponds to an AI / ML operation business class or at least one parameter; determining an AI / ML service operation type to be operated by an AI / ML application client on the WTRU; sending a request to a network element for an analysis or prediction related to the AI / ML service operation type, wherein the request includes an indication of the traffic class or the at least one parameter; and In response to the request, receiving the analysis or the prediction related to the AI / ML service operation type.

2. The method of claim 1, comprising matching the AI / ML service operation type with the business class or the at least one parameter based on the configuration. 3 . The method of claim 2 , wherein the at least one parameter is related to traffic generated by one or more client applications on the network.

4. The method of claim 2, wherein the matching is performed based on a routing policy (RSP) rule that matches a traffic class, wherein the traffic class indicates at least one AI / ML value, and wherein the at least one AI / ML value indicates at least one of a model distribution value, a federated learning value, or an operation split value.

5. The method of claim 1, wherein the traffic class comprises the at least one parameter, and wherein the at least one parameter comprises an application descriptor or a connection capability parameter associated with an AI / ML value.

6. The method of claim 1, wherein the analyzing or the predicting indicates a quality of service (QoS) of traffic to be generated by the client application on the network over a time period.

7. The method of claim 1, comprising receiving a mapping of the AI / ML operation type via a user plane.

8. The method of claim 1, comprising receiving a mapping of the AI / ML operation types from an application function (AF).

9. The method of claim 1, wherein the at least one parameter comprises at least one of connection capability, OSid, App ID, or S-NSSAI / DNN.

10. The method of claim 1, comprising determining a routing strategy based on the analysis or the prediction related to the AI / ML service operation type.

11. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising a processor, the processor configured to: receiving a configuration, the configuration comprising at least one of an artificial intelligence machine learning (AI / ML) operation type association with a business class, wherein the business class corresponds to an AI / ML operation business class or at least one parameter; determining an AI / ML service operation type to be operated by an AI / ML application client on the WTRU; sending a request to a network element for an analysis or prediction related to the AI / ML service operation type, wherein the request includes an indication of the traffic class or the at least one parameter; and In response to the request, receiving the analysis or the prediction related to the AI / ML service operation type.

12. The WTRU of claim 11, wherein the processor is configured to match the AI / ML service operation type with the service class or the at least one parameter based on the configuration.

13. The WTRU of claim 12, wherein the at least one parameter is related to traffic generated by one or more client applications on the network.

14. The WTRU of claim 12, wherein the processor is configured to match the AI / ML service operation type with the service class or the at least one parameter based on a routing policy (RSP) rule matching the service class, wherein the service class indicates at least one AI / ML value, and wherein the at least one AI / ML value indicates at least one of a model distribution value, a federated learning value, or an operation splitting value.

15. The WTRU of claim 11, wherein the traffic class comprises the at least one parameter, and wherein the at least one parameter comprises an application descriptor or a connection capability parameter associated with an AI / ML value.

16. The WTRU of claim 11, wherein the analysis or the prediction indicates a quality of service (QoS) for the traffic to be generated by the client application on the network over a time period.

17. The WTRU of claim 11, wherein the processor is configured to receive a mapping of the AI / ML operation type via a user plane.

18. The WTRU of claim 11, wherein the processor is configured to receive a mapping of the AI / ML operation type from an application function (AF).

19. The WTRU of claim 11, wherein the at least one parameter comprises at least one of connection capability, OSid, App ID, or S-NSSAI / DNN.

20. The WTRU of claim 11, wherein the processor is configured to determine a routing strategy based on the analysis or the prediction related to the AI / ML service operation type.

Images