Apparatus and method for management actions for UE-level measurement jobs

Abstract

Apparatuses and methods for management actions for UE-level measurement jobs are provided herein. An apparatus includes an interface circuit and a processor circuit coupled to the interface circuit. And processor circuitry to: decode a trace job creation request received from a service consumer via the interface circuitry to create a trace job for collecting UE-level measurements from the NF; in response to the trace job creation request, encoding a trace session activation request for activating a trace session for transmission to the NF; decoding a tracking session activation response which is received from the NF and responds to the tracking session activation request, wherein the tracking session activation response is used for indicating an activation result of the tracking session; and in response to the tracking session activation response, encoding a tracking job creation response for transmission to the service consumer via the interface circuitry, the tracking job creation response indicating a creation result of the tracking job. Other embodiments may be described and / or claimed.

Description

[0001] Priority Statement

[0002] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 620,721, filed on Jan. 12, 2024, which is hereby incorporated by reference in its entirety. Technical Field

[0003] Embodiments of the present disclosure generally relate to wireless communication, and more particularly, to apparatuses and methods for management actions for user equipment (UE)-level measurement operations. Background Art

[0004] Artificial intelligence (AI) / machine learning (ML) technologies and related applications are being adopted by an increasing number of industries and have proven to be successful. Currently, these technologies are being applied to the telecommunications industry, including mobile networks. Although AI / ML technologies are generally quite mature, some related aspects of these technologies are still evolving, and new complementary technologies are emerging. Summary of the Invention

[0005] One aspect of the present disclosure provides an apparatus, comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: decode a tracking job creation request received from a service consumer via the interface circuit to create a tracking job for collecting user equipment (UE)-level measurement results from a network function (NF); in response to the tracking job creation request, encode a tracking session activation request for activating a tracking session to be transmitted to the NF; decode a tracking session activation response received from the NF in response to the tracking session activation request, the tracking session activation response being for indicating an activation result of the tracking session; and in response to the tracking session activation response, encode a tracking job creation response to be transmitted to the service consumer via the interface circuit, the tracking job creation response being for indicating a creation result of the tracking job.

[0006] One aspect of the present disclosure provides an apparatus, comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: decode a tracking session activation request received from a service producer via the interface circuit to activate a tracking session for a user equipment (UE)-level measurement operation; in response to the tracking session activation request, encode a tracking session activation response to be transmitted to the service producer via the interface circuit, the tracking session activation response being for indicating an activation result of the tracking session; and start the tracking session based on the tracking session activation request.

[0007] One aspect of the present disclosure provides an apparatus, including: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: encode a trace job creation request for transmission via the interface circuit to a service producer, the trace job creation request being for creating a trace job for collecting user equipment (UE)-level measurement results from a network function (NF); and decode a trace job creation response received via the interface circuit from the service producer in response to the trace job creation request, the trace job creation response being for indicating a creation result of the trace job. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the drawings, embodiments of the present disclosure will be illustrated by way of example and not limitation, where like reference numerals refer to like elements.

[0009] Figure 1 An example architecture of a system according to some embodiments of the present disclosure is shown.

[0010] Figure 2 An example network architecture according to some embodiments of the present disclosure is shown.

[0011] Figure 3 An example of a method for management actions of a UE-level measurement job according to some embodiments of the present disclosure is shown.

[0012] Figure 4 An example of the interaction between MnS-C, MnS-P, and NF according to some embodiments of the present disclosure is shown.

[0013] Figure 5 An example of a method for management actions of a UE-level measurement job according to some embodiments of the present disclosure is shown.

[0014] Figure 6 An example of a method for management actions of a UE-level measurement job according to some embodiments of the present disclosure is shown.

[0015] Figure 7 An example of 5GC domain management deactivation for a UE-level measurement job according to some embodiments of the present disclosure is shown.

[0016] Figure 8 An example of NG-RAN management deactivation for a UE-level measurement job according to some embodiments of the present disclosure is shown.

[0017] Figure 9 Networks according to various embodiments are shown.

[0018] Figure 10 Wireless networks according to various embodiments are schematically shown.

[0019] Figure 11 The block diagram shows components that can read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methods discussed herein.

[0020] Figure 12 Shows a network according to various embodiments.

[0021] Figure 13 Depicts an example functional framework for ML and / or RAN intelligence.

[0022] Figure 14 Depicts an example AI / ML-assisted communication network that includes communication between two MLFs. Detailed Description

[0023] Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the present disclosure to others skilled in the art. However, it will be readily apparent to those skilled in the art that many alternative embodiments can be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth to provide a thorough understanding of the illustrative embodiments. However, it will be readily apparent to those skilled in the art that alternative embodiments can be practiced without these specific details. In other instances, well-known features are omitted or simplified to avoid obscuring the illustrative embodiments.

[0024] In addition, various operations will be described as multiple discrete operations in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must be order-dependent. In particular, these operations need not be performed in the order presented.

[0025] The phrases "in an embodiment," "in one embodiment," and "in some embodiments" are reused herein. This phrase generally does not refer to the same embodiment; however, it may refer to the same embodiment. Unless the context dictates otherwise, the terms "comprising," "having," and "including" are synonyms. The phrase "A or B" and "A / B" mean "(A), (B), or (A and B)."

[0026] The present disclosure generally relates to wireless communication, cellular networks, cloud computing, edge computing, cloud computing, data centers, network topologies, communication system implementation, network convergence, artificial intelligence (AI) / machine learning (ML) technologies, and more particularly to techniques for managing the relationship between (one or more) AI / ML inference functions and (one or more) AI / ML-based functions.

[0027] Figure 1FIG. 0 illustrates an example architecture of a system 100 in accordance with some embodiments of the present disclosure. The following description is provided with respect to an example system 100 operating in conjunction with Long Term Evolution (LTE) system standards and 5G or New Radio (NR) system standards provided by 3GPP Technical Specifications (TS). However, the example embodiments are not limited in this regard, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., Sixth Generation (6G)) systems, Institute of Electrical and Electronics Engineers (IEEE) 802.16 protocols (e.g., Wireless Metropolitan Area Network (MAN), Worldwide Interoperability for Microwave Access (WiMAX), etc.), and the like.

[0028] As Figure 1 shown, the system 100 may include UEs 101a and 101b (collectively referred to as “(one or more) UEs 101”). As used herein, the term “user equipment” or “UE” may refer to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The term “user equipment” or “UE” may be considered synonymous and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio device, reconfigurable radio device, reconfigurable mobile device, etc. Additionally, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device that includes a wireless communication interface. In this example, the UE 101 is shown as a smart phone (e.g., a handheld touchscreen mobile computing device connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a consumer electronic device, cellular phone, smart phone, feature phone, tablet, wearable computing device, Personal Digital Assistant (PDA), pager, wireless handheld device, desktop computer, laptop computer, In-Vehicle Infotainment (IVI) system, In-Vehicle Entertainment (ICE) device, Instrument Cluster (IC), Head-Up Display (HUD) device, On-Board Diagnostic (OBD) device, Dashboard Mobile Equipment (DME), Mobile Data Terminal (MDT), Electronic Engine Management System (EEMS), Electronic / Engine Control Unit (ECU), Electronic / Engine Control Module (ECM), embedded system, microcontroller, control module, Engine Management System (EMS), networked or “smart” device, Machine Type Communication (MTC) device, Machine-to-Machine (M2M), Internet of Things (IoT) device, and / or the like.

[0029] In some embodiments, any one of the UEs 101 may include an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a PLMN, proximity-based services (ProSe) or device-to-device (D2D) communication, a sensor network, or an IoT network. The data exchange of M2M or MTC may be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., maintaining active messages, status updates, etc.) to facilitate the connection to the IoT network.

[0030] The UE 101 may be configured to connect (e.g., communicatively couple) to the RAN 110. In an embodiment, the RAN 110 may be a next-generation (NG) RAN or 5G RAN, an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN), or a legacy RAN, such as UTRAN (UMTS terrestrial radio access network) or GERAN (GSM (Global System for Mobile Communications or Groupe Spécial Mobile) EDGE (GSM Evolution) radio access network). As used herein, the term "NGRAN" etc. may refer to the RAN 110 operating in an NR or 5G system 100, and the term "E-UTRAN" etc. may refer to the RAN 110 operating in an LTE or 4G system 100. The UE 101 utilizes connections (or channels) 103 and 104 respectively, each connection including a physical communication interface or layer (discussed in further detail below). As used herein, the term "channel" may refer to any tangible or intangible transmission medium for conveying data or a data stream. The term "channel" may be synonymous and / or equivalent to "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "link", "data link", "carrier", "radio frequency carrier", and / or any other similar term that represents the path or medium through which data is conveyed. Additionally, the term "link" may refer to a connection between two devices for the purpose of sending and receiving information via a radio access technology (RAT).

[0031] In this example, the connections 103 and 104 are shown as air interfaces to enable communication coupling and can be consistent with cellular communication protocols, such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Push-to-Talk over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, Fifth Generation (5G) protocol, New Radio (NR) protocol, and / or any other communication protocol discussed herein. In an embodiment, the UE 101 may directly exchange communication data via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink (SL) interface 105 and may include one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0032] The UE 101b is shown as being configured to access an access point (AP) 106 (also referred to as a "WLAN node 106", "WLAN 106", "WLAN terminal 106", or "WT 106", etc.) via the connection 107. The connection 107 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where the AP 106 will include a Wi-Fi router. In this example, the AP 106 is shown as being connected to the Internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, the UE 101b, RAN 110, and AP 106 may be configured to utilize LTE-WLAN Aggregation (LWA) operations and / or WLAN LTE / WLAN Radio-Level Integration with IPsec Tunnel (LWIP) operations. LWA operations may involve the UE 101b in the RRC_CONNECTED state being configured by the RAN node 111 to utilize the radio resources of LTE and WLAN. LWIP operations may involve the UE 101b using the WLAN radio resources (e.g., the connection 107) via an Internet Protocol Security (IPsec) protocol tunnel to authenticate and encrypt the packets (e.g., Internet Protocol (IP) packets) sent through the connection 107. The IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0033] The RAN 110 may include one or more RAN nodes 111a and 111b (collectively referred to as “(one or more) RAN nodes 111”) that enable connections 103 and 104. As used herein, the terms “access node (AN)”, “access point”, “RAN node”, etc. may describe a device that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as base stations (BSs), next-generation Node Bs (gNBs), RAN nodes, evolved Node Bs (eNBs), Node Bs, roadside units (RSUs), transmission and reception points (TRxP or TRP), etc., and may include terrestrial stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographical area (e.g., a cell). As used herein, the term “NGRAN node” etc. may refer to a RAN node 111 (e.g., gNB) operating in an NR or 5G system 100, and the term “E-UTRAN node” etc. may refer to a RAN node 111 (e.g., eNB) operating in an LTE or 4G system 100. According to various embodiments, the RAN node 111 may be implemented as one or more dedicated physical devices such as macrocell base stations and / or low-power (LP) base stations such as femtocells, picocells, or other similar cells that provide a smaller coverage area, smaller user capacity, or higher bandwidth compared to macrocells.

[0034] In some embodiments, all or part of the RAN node 111 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a cloud radio access network (CRAN) and / or a virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement RAN function partitioning, for example: PDCP partitioning, where the RRC and PDCP layers are operated by the CRAN / vBBUP, and other layer 2 (L2) protocol entities are operated by individual RAN nodes 111; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by individual RAN nodes 111; or “lower PHY” partitioning, where the RRC, PDCP, RLC, MAC layers, and the upper part of the PHY layer are operated by the CRAN / vBBUP, and the lower part of the PHY layer is operated by individual RAN nodes 111. This virtualization framework allows the processor cores of the RAN node 111 to be freed up to execute other virtualized applications. In some implementations, an individual RAN node 111 may represent a connection via an individual F1 interface ( Figure 1Individual gNB-DUs (not shown) connected to the gNB-CU. In these implementations, the gNB-DU may include one or more remote radio heads or radio front-end modules (RFEMs), and the gNB-CU may be operated by a server (not shown) located in the RAN 110 or by a pool of servers in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more RAN nodes 111 may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol termination to the UE 101 and are connected to the 5GC via the NG interface.

[0035] In a V2X scenario, one or more RAN nodes 111 may be or act as RSUs. The term "roadside unit" or "RSU" may refer to any transportation infrastructure entity for V2X communication. The RSU may be implemented in or by a suitable RAN node or fixed (or relatively stationary) UE, where the RSU implemented in or by a UE may be referred to as a "UE-type RSU", the RSU implemented in or by an eNB may be referred to as an "eNB-type RSU", the RSU implemented in or by a gNB may be referred to as a "gNB-type RSU", etc. In one example, the RSU is a computing device coupled to a radio frequency circuit located at the roadside that provides connectivity support for passing vehicle UEs 101 (vUE 101). The RSU may also include an internal data storage circuit for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate in the 5.9 GHz direct short-range communication (DSRC) frequency band to provide very low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may operate in the cellular V2X frequency band to provide the above low-latency communication and other cellular communication services. Additionally or alternatively, the RSU may operate as a WiFi hotspot (2.4 GHz frequency band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communication. The (one or more) computing devices and some or all of the radio frequency circuits of the RSU may be encapsulated in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired (e.g., Ethernet) connection to a traffic signal controller and / or a backhaul network.

[0036] Any RAN node 111 can terminate the air interface protocol and can be the first point of contact for the UE 101. In some embodiments, any RAN node 111 can fulfill various logical functions of the RAN 110, including but not limited to radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0037] In an embodiment, the UE 101 can be configured to communicate with each other or with any RAN node 111 via multi-carrier communication channels according to various communication technologies, using orthogonal frequency division multiplexing (OFDM) communication signals. The various communication technologies include, but are not limited to, orthogonal frequency division multiple access (OFDMA) communication technologies (e.g., for downlink communication) or single carrier frequency division multiple access (SC-FDMA) communication technologies (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiments is not limited to this aspect. The OFDM signal can include a plurality of orthogonal subcarriers.

[0038] In some embodiments, a downlink resource grid can be used for downlink transmissions from any RAN node 111 to the UE 101, and uplink transmissions can use similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or a time-frequency resource grid, which is the physical resource in the downlink for each time slot. This time-frequency plane representation is a common practice in OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one time slot in a radio frame. The smallest time-frequency unit in the resource grid is denoted as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this can represent the smallest amount of resources that can be currently allocated. There are several different physical downlink channels transmitted using such resource blocks.

[0039] According to various embodiments, the UE 101 and the RAN node 111 transmit (e.g., send and receive) data via a licensed medium (also referred to as "licensed spectrum" and / or "licensed band") and an unlicensed shared medium (also referred to as "unlicensed spectrum" and / or "unlicensed band"). The licensed spectrum can include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum can include the 5 GHz band.

[0040] To operate in unlicensed spectrum, UE 101 and RAN node 111 may operate using Licensed-Assisted Access (LAA), Enhanced LAA (eLAA), and / or Further eLAA (feLAA) mechanisms. In these implementations, UE 101 and RAN node 111 may perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to the Listen Before Talk (LBT) protocol.

[0041] LBT is a mechanism in which a device (e.g., UE 101, RAN nodes 111, 112, etc.) senses the medium (e.g., a channel or carrier frequency) and transmits when the medium is sensed idle (or when a particular channel in the medium is sensed unoccupied). The medium sensing operation may include Clear Channel Assessment (CCA), which determines whether there are other signals on the channel using at least Energy Detection (ED) to determine whether the channel is occupied or idle. This LBT mechanism allows cellular / LAA networks to coexist with incumbent systems in the unlicensed spectrum and with other LAA networks. ED may include sensing radio frequency (RF) energy on the intended transmission band for a period of time and comparing the sensed RF energy with a predetermined or configured threshold.

[0042] Typically, incumbent systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA). Here, when a WLAN node (e.g., a mobile station (MS) such as UE 101, AP 106) intends to transmit, the WLAN node may first perform CCA before transmitting. Additionally, a backoff mechanism is used to avoid collisions in the case where more than one WLAN node senses the channel as idle and transmits simultaneously. The backoff mechanism may be a counter randomly drawn within the contention window size (CWS), which increases exponentially in the event of a collision and is reset to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA of WLANs. In some implementations, the LBT procedure for DL or UL transmission bursts respectively including PDSCH or PUSCH transmissions may have a variable-length LAA contention window between X and Y Extended CCA (ECCA) slots, where X and Y are the minimum and maximum values of the CWS for LAA. In one example, the minimum CWS for LAA transmission may be 9 microseconds (μs); however, the size of the CWS and the Maximum Channel Occupancy Time (MCOT) (e.g., transmission burst) may be based on government regulatory requirements.

[0043] The LAA mechanism is based on the carrier aggregation (CA) technology of the Long Term Evolution - Advanced (LTE - Advanced) system. In CA, each aggregated carrier is called a component carrier (CC). A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated. Thus, the maximum aggregated bandwidth is 100 MHz. In a Frequency Division Duplexing (FDD) system, the number of aggregated carriers can be different for DL and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, an individual CC can have a different bandwidth from other CCs. In a Time Division Duplexing (TDD) system, for DL and UL, the number of CCs and the bandwidth of each CC are usually the same.

[0044] CA also includes a separate serving cell to provide a separate CC. The coverage of the serving cell may be different. For example, since CCs on different frequency bands will experience different path losses. The primary serving cell or primary cell (PCell) can provide the primary CC (PCC) for both UL and DL, and can handle radio resource control (RRC) and non - access stratum (NAS) related activities. Other serving cells are called secondary cells (SCells), and each SCell can provide a separate secondary CC (SCC) for both UL and DL. SCCs can be added and removed as needed, while changing the PCC may require the UE 101 to undergo a handover. In LAA, eLAA, and feLAA, some or all SCells can operate in the unlicensed spectrum (referred to as "LAA SCell"), and the LAA SCell is assisted by the PCell operating in the licensed spectrum. When the UE is configured with more than one LAA SCell, the UE can receive UL grants on the configured LAA SCells, and the UL grants indicate the starting positions of different Physical Uplink Shared Channels (PUSCH) within the same subframe.

[0045] The Physical Downlink Shared Channel (PDSCH) can carry user data and higher - layer signaling to the UE 101. The Physical Downlink Control Channel (PDCCH) can carry information such as the transmission format and resource allocation related to the PDSCH channel. It can also notify the UE 101 of the transmission format, resource allocation, and Hybrid Automatic Repeat Request (H - ARQ) information related to the uplink shared channel. Generally, downlink scheduling (allocating control and shared channel resource blocks to the UE 101b within the cell) can be performed at any RAN node 111 based on the channel quality information fed back from any UE 101. Downlink resource allocation information can be sent on the PDCCH for each UE 101 (e.g., allocated to).

[0046] The PDCCH may use control channel elements (CCEs) to convey control information. Before mapping to resource elements, the PDCCH complex-valued symbols may first be organized into quadruples and then permuted using a sub-block interleaver for rate matching. One or more of these CCEs may be used to transmit each PDCCH, where each CCE may correspond to nine groups of four physical resource elements called resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols may be mapped to each REG. One or more CCEs may be used to transmit the PDCCH, depending on the size of the downlink control information (DCI) and the channel conditions. In LTE, four or more different PDCCH formats with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8) may be defined.

[0047] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may use an enhanced physical downlink control channel (EPDCCH), which uses PDSCH resources for control information transmission. One or more enhanced control channel elements (ECCEs) may be used to transmit the EPDCCH. Similar to above, each ECCE may correspond to nine groups of four physical resource elements called enhanced resource element groups (EREGs). In some cases, an ECCE may have a different number of EREGs.

[0048] RAN nodes 111 may be configured to communicate with each other via interface 112. In an embodiment where system 100 is an LTE system, interface 112 may be an X2 interface 112. The X2 interface may be defined between two or more RAN nodes 111 (e.g., two or more eNBs, etc.) connected to the EPC 120 and / or between two eNBs connected to the EPC 120. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted through the X2 interface and may be used to convey information about user data transfer between eNBs. For example, the X2-U may provide specific sequence number information for user data transmitted from the master eNB (MeNB) to the secondary eNB (SeNB); information about the successful sequential transmission of PDCP PDUs for user data from the SeNB to the UE 101; information about PDCP PDUs not delivered to the UE 101; information about the current minimum required buffer size at the SeNB for transmitting user data to the UE; and so on. The X2-C may provide access mobility functions within LTE, including context transfer from the source eNB to the target eNB, user plane transmission control, etc.; load management functions; and inter-cell interference coordination functions.

[0049] In an embodiment where system 100 is a 5G or NR system, interface 112 may be an Xn interface 112. The Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gNBs, etc.) connected to 5GC 120, between a RAN node 111 (e.g., gNB) connected to 5GC 120 and an eNB, and / or between two eNBs connected to 5GC 120. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U may provide unguaranteed transfer of user plane PDUs and support / provide data forwarding and flow control functions. Xn-C may provide: management and error handling functions; functions for managing the Xn-C interface; mobility support for UEs 101 in the connected mode (e.g., CM-CONNECTED), including functions for managing the mobility of UEs in the connected mode between one or more RAN nodes 111. Mobility support may include context transfer from an old (source) serving RAN node 111 to a new (target) serving RAN node 111; and control of the user plane tunnel between the old (source) serving RAN node 111 and the new (target) serving RAN node 111. The protocol stack of Xn-U may include a transport network layer built on the Internet Protocol (IP) transport layer, and a GTP-U layer on top of the (one or more) UDP and / or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn application protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may be located on top of the IP layer and may provide guaranteed transfer of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the (one or more) user plane and / or control plane protocol stacks shown and described herein.

[0050] RAN 110 is shown communicatively coupled to a core network - in this embodiment, to core network (CN) 120. CN 120 may include a plurality of network elements 122, which are configured to provide various data and telecommunications services to consumers / subscribers (e.g., users of UE 101) connected to CN 120 via RAN 110. The term "network element" may describe a physical or virtualized device for providing wired or wireless communication network services. The term "network element" may be considered synonymous with and / or referred to as the following: networked computers, network hardware, network devices, routers, switches, hubs, bridges, radio network controllers, radio access network devices, gateways, servers, virtualized network functions (VNFs), network function virtualization infrastructure (NFVI), and / or the like. Components of CN 120 may be implemented in one physical node or separate physical nodes, including components that read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, network function virtualization (NFV) may be used to virtualize any or all of the above network node functions (described in further detail below) via executable instructions stored in one or more computer-readable storage media. The logical instantiation of CN 120 may be referred to as a network slice, and the logical instantiation of a part of CN 120 may be referred to as a network sub-slice. NFV architectures and infrastructure may be used to virtualize one or more network functions, or to execute them from dedicated hardware onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches. In other words, an NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0051] Generally, application server 130 may be an element that provides an application that uses IP bearer resources in conjunction with a core network (e.g., UMTS packet service (PS) domain, LTE PS data service, etc.). Application server 130 may also be configured to support one or more communication services (e.g., Internet protocol voice (VoIP) sessions, PTT sessions, group communication sessions, social network services, etc.) for UE 101 via EPC 120.

[0052] In an embodiment, CN 120 may be a 5GC (referred to as "5GC 120", etc.), and RAN 110 may be connected to CN 120 via NG interface 113. In an embodiment, NG interface 113 may be divided into two parts: the NG user plane (NG-U) interface 114, which carries traffic data between RAN node 111 and the user plane function (UPF); and the S1 control plane (NG-C) interface 115, which is a signaling interface between RAN node 111 and the AMF.

[0053] In an embodiment, CN 120 can be a 5G CN (referred to as "5GC 120", etc.), while in other embodiments, CN 120 can be an evolved packet core (EPC). In the case where CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 can be connected to CN 120 via the S1 interface 113. In an embodiment, the S1 interface 13 can be divided into two parts: the S1 user plane (S1-U) interface 114, which carries traffic data between the RAN node 111 and the serving gateway (S-GW); and the S1-mobility management entity (MME) interface 115, which is a signaling interface between the RAN node 111 and the MME.

[0054] Figure 2 An example network architecture 200 according to some embodiments of the present disclosure is shown. Network 200 can operate in a manner consistent with the 3GPP technical specifications of the LTE or 5G / NR systems. However, the example embodiments are not limited in this regard, and the examples can be applicable to other networks that benefit from the principles described herein, such as future 3GPP systems or similar systems.

[0055] Network 200 includes a UE 202, which is any mobile or non-mobile computing device designed to communicate with RAN 204 via an air interface. UE 202 is communicatively coupled to RAN 204 via the Uu interface, which is applicable to both LTE and NR systems. Examples of UE 202 include, but are not limited to, smartphones, tablets, wearable devices (e.g., smartwatches, fitness trackers, smart glasses, smart clothing / fabric, head-mounted displays, smart programs, and / or similar devices), desktop computers, workstations, laptops, in-vehicle infotainment systems, in-vehicle entertainment systems, dashboards, head-up display (HUD) devices, on-vehicle diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, connected home appliances, machine type communication devices, machine-to-machine (M2M), device-to-device (D2D), machine type communication (MTC) devices, Internet of Things (IoT) devices, smart home appliances, flying drones or unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, electronic signage, single-board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel Edison, etc.), plug-in computers, and / or any type of computing device (e.g., any type of computing device discussed herein).

[0056] The network 200 may include a set of UEs 202 directly coupled to each other via D2D, ProSe, PC5, and / or sidelink (SL) interfaces and / or any other suitable interfaces (such as any of the interfaces discussed herein). In a 3GPP system, SL communication involves communication between two or more UEs 202 using 3GPP technologies without passing through a network node. These UEs 202 may be M2M / D2D / MTC / IoT devices and / or vehicle-mounted systems that communicate using an SL interface, which may include, for example: one or more SL logical channels (e.g., sidelink broadcast control channel (SBCCH), sidelink control channel (SCCH), and sidelink traffic channel (STCH)); one or more SL transport channels (e.g., sidelink shared channel (SL-SCH) and sidelink broadcast channel (SL-BCH)); and one or more SL physical channels (e.g., physical sidelink shared channel (PSSCH), physical sidelink control channel (PSCCH), physical sidelink feedback channel (PSFCH), physical sidelink broadcast channel (PSBCH), and / or similar channels). The UE 202 may perform blind decoding attempts on the SL channel / link according to various examples herein.

[0057] In some examples, the UE 202 may also communicate with the AP 206 via an over-the-air (OTA) connection. The AP 206 manages a WLAN connection that can be used to offload some / all of the network traffic of the RAN 204. The connection between the UE 202 and the AP 206 may conform to any IEEE 802.11 protocol. In addition, the UE 202, RAN 204, and AP 206 may utilize cellular-WLAN aggregation / integration (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve the RAN 204 configuring the UE 202 to utilize cellular radio resources and WLAN resources simultaneously.

[0058] The RAN 204 includes one or more network access nodes (NANs) 214. The NAN 214 terminates the air interface of the UE 202 by providing access layer protocols (including RRC, PDCP, RLC, MAC, and PHY / L1 protocols). In this way, the NAN 214 can establish a data / voice connection between the CN 240 and the UE 202. The NAN 214 may be: a macrocell base station; or a low-power base station for providing femtocells, picocells, or other similar cells, which have a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to macrocells; or some combination thereof. In these implementations, the NAN 214 is referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRP, etc.

[0059] One example implementation is the "CU / DU separation" architecture, where NAN 214 is embodied as a gNB - Central Unit (CU) communicatively coupled to one or more gNB - Distributed Units (DUs), and each DU can be communicatively coupled to one or more Radio Units (RUs) (also known as RRHs, RRUs, etc.). In some implementations, one or more RUs can be individual RSUs. In some implementations, the CU / DU separation can include an ng - eNB - CU and one or more ng - eNB - DUs instead of gNB - CU and gNB - DUs, or can be supplementary to gNB - CU and gNB - DUs. NAN 214 used as a CU can be implemented in a discrete device or as one or more software entities running on a server computer, for example, as part of a virtual network including a virtual baseband unit (BBU) or BBU pool, Cloud RAN (CRAN), Radio Equipment Controller (REC), Radio Cloud Center (RCC), Centralized RAN (C - RAN), Virtualized RAN (vRAN), etc. (although these terms may refer to different implementation concepts). Any other type of architecture, arrangement, and / or configuration can also be used.

[0060] If RAN 204 is an LTE RAN or an Evolved Universal Terrestrial Radio Access Network (E - UTRAN) 210, a group of NAN214 are interconnected through the corresponding X2 interface; or if RAN 204 is an NG - RAN 214, a group of NAN 214 are interconnected through the corresponding Xn interface. In some examples, the X2 / Xn interface can be divided into a control / user plane interface, which can allow ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

[0061] The NAN 214 of RAN 204 can each manage one or more cells, cell groups, member carriers, etc., to provide an air interface for UE 202 for network access. UE 202 can be connected to a group of cells provided by the same or different NAN 214 of RAN 204 simultaneously. For example, UE 202 and RAN 204 can use carrier aggregation to allow UE 202 to connect to a group of member carriers, each member carrier corresponding to a PCell or an SCell. In a dual - connection scenario, the first NAN 214 can be the master node providing the MCG, and the second NAN 214 can be the secondary node providing the SCG. The first / second NAN 214 can be any combination of eNB, gNB, ng - eNB, etc.

[0062] The RAN 204 may provide an air interface through licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, a node may use LAA, eLAA, and / or feLAA mechanisms based on the CA technology with the PCell / Scell. Before accessing the unlicensed spectrum, a node may perform a medium / carrier sensing operation according to, for example, the listen-before-talk (LBT) protocol.

[0063] Additionally or alternatively, the individual UE 202 provides radio information to one or more NANs 214 and / or one or more edge computing nodes (e.g., edge servers / hosts, etc.). The radio information can be in the form of one or more measurement reports, and / or can include, for example, signal strength measurement information, signal quality measurement information, and / or similar measurement information. Each measurement report is tagged with a timestamp and a measurement location (e.g., the current location of the UE 202). As an example, the measurement information collected by the UE 202 and / or the measurement information included in the measurement reports can include one or more of the following: bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), number of interruptions, out-of-order delivery of packets, transmission power, bit error rate, bit error ratio (BER), block error rate (BLER), packet error rate (PER), packet loss rate, packet reception rate (PRR), data rate, peak data rate, end-to-end (e2e) latency, signal-to-noise ratio (SNR), signal-to-interference-plus-noise ratio (SINR), signal-plus-noise-plus-distortion to signal-plus-distortion (SINAD) ratio, carrier-to-interference-plus-noise ratio (CINR), additive white Gaussian noise (AWGN), energy per bit to noise power density ratio (Eb / N0), energy per chip to interference power density ratio (Ec / I0), energy per chip to noise power density ratio (Ec / N0), peak-to-average power ratio (PAPR), reference signal received power (RSRP), reference signal received quality (RSRQ), received signal strength indicator (RSSI), received channel power indicator (RCPI), received signal noise indicator (RSNI), received signal code power (RSCP), average noise-plus-interference (ANPI), GNSS cell frame timing for UE positioning in E-UTRAN or 5G / NR (e.g., the timing between the AP 206 or RAN node 208 reference time and the GNSS-specific reference time of a given GNSS), GNSS code measurements (e.g., the GNSS code phase (integer and fractional parts) of the propagation code of the i-th GNSS satellite signal), GNSS carrier phase measurements (e.g., the number of carrier phase cycles (integer and fractional parts) of the i-th GNSS satellite signal measured since the signal was locked; also known as accumulated delta range (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, power histogram measurements, channel load measurements, STA statistics, and / or other similar measurements.RSRP, RSSI, and / or RSRQ measurements may include RSRP, RSSI, and / or RSRQ measurements of cell-specific reference signals, channel state information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks of a 3GPP network (e.g., LTE or 5G / NR), as well as RSRP, RSSI, RSRQ, RCPI, RSNI, and / or ANPI measurements of various beacons, fast initial link setup (FILS) discovery frames, or probe response frames for a WLAN / WiFi (e.g., [IEEE80211]) network. Additionally or alternatively, other measurement methods may be used, such as those discussed in 3GPP TS 36.214 v17.0.0 (2022-03-31) (“[TS36214]”), 3GPP TS 38.215 v17.3.0 (2023-03-30) (“[TS38215]”), 3GPP TS 38.314 v17.3.0 (2023-06-30) (“[TS38314]”), [IEEE80211], etc. Additionally or alternatively, one or more NAN 214s may collect any of the above measurements (or combinations of measurements) and provide them to the edge computing node(s).

[0064] Additionally or alternatively, the measurements may include one or more of the following measurements: measurements related to a data radio bearer (DRB) (e.g., the number of DRBs attempted to be established, the number of successfully established DRBs, the number of released active DRBs, the in-session activity time of a DRB, the number of DRBs attempted to be resumed, the number of successfully resumed DRBs, etc.); measurements related to radio resource control (RRC) (e.g., the average number of RRC connections, the maximum number of RRC connections, the average number of stored inactive RRC connections, the maximum number of stored inactive RRC connections, the number of attempted, successful, and / or failed RRC connection establishments, etc.); measurements related to UE context (UECNTX); measurements related to radio resource utilization (RRU) (e.g., total DL PRB usage, total UL PRB usage, the distribution of total DL PRB usage, the distribution of total UL PRB usage, DL PRBs for data traffic, UL PRBs for data traffic, total number of available DL PRBs, total number of available UL PRBs, etc.); measurements related to registration management (RM); measurements related to session management (SM) (e.g., the number of PDU sessions requested to be established; the number of successfully established PDU sessions; the number of PDU sessions with setup failures, etc.); measurements related to GTP management (GTP); measurements related to IP management (IP); measurements related to policy association (PA); measurements related to mobility management (MM) (e.g., for inter-RAT, intra-RAT, and / or intra-frequency / inter-frequency handovers and / or conditional handovers: the number of attempted, successful, and / or failed handover preparations; the number of attempted, successful, and / or failed handover resource allocations; the number of attempted, successful, and / or failed handover executions; the average and / or longest time of attempted handover executions; the number of successful and / or failed handover executions per beam pair, etc.); measurements related to (one or more) virtualized resources (VR); measurements related to a carrier (CARR); measurements related to a QoS flow (QF) (e.g., the number of released active QoS flows, the number of QoS flows attempted to be released, the session activity time of a QoS flow, the session activity time of UE202, the number of QoS flows attempted to be established, the number of successfully established QoS flows, the number of QoS flows with establishment failures, the number of initial QoS flows attempted to be established, the number of successfully established initial QoS flows, the number of initial QoS flows with establishment failures, the number of QoS flows attempted to be modified, the number of successfully modified QoS flows, the number of QoS flows with modification failures, etc.); measurements related to application trigger (AT); measurements related to short message service (SMS); measurements related to power, energy, and environment (PEE); measurements related to NF service (NFS); measurements related to packet flow description (PFD); measurements related to random access channel (RACH); measurements related to measurement report (MR);Measurements related to the Layer 1 Measurement (L1M); Measurements related to the Network Slice Selection (NSS); Measurements related to the Paging (PAG); Measurements related to the Non-IP Data Delivery (NIDD); Measurements related to the External Parameter Provision (EPP); Measurements related to the Traffic Impact (TI); Measurements related to the Connection Establishment (CE); Measurements related to the Service Parameter Provision (SPP); Measurements related to the Background Data Transfer Policy (BDTP); Measurements related to the Data Management (DM); and / or any other performance measurements, such as the measurements discussed in 3GPP TS 28.552 v18.3.0 (2023-06-27) (“[TS28552]”), 3GPP TS 32.425 v17.1.0 (2021-06-24) (“[TS32425]”), and / or similar documents.;

[0065] Radio information can be reported in response to a triggering event and / or periodically. Additionally or alternatively, an individual UE 202 can report radio information and / or other information about the data transmission with low periodicity or high periodicity according to the data transmission to be performed. Additionally or alternatively, one or more edge computing nodes can request measurement results from the NAN 214 with low periodicity or high periodicity, or the NAN 214 can provide measurement results to one or more edge computing nodes with low periodicity or high periodicity. Additionally or alternatively, one or more edge computing nodes can also obtain other relevant data, such as Key Performance Indicators (KPIs), from one or more other edge computing nodes, Core Network Functions (NFs), Application Functions (AFs), and / or other UEs 202, and these data can be obtained together with the measurement report or separately from the measurement report.

[0066] Additionally or alternatively, in the case of differences in the observed data from one or more UEs, one or more RAN nodes, and / or Core Network NFs (e.g., missing reports, data errors, etc.), simple extrapolation can be performed to supplement the obtained observed data, such as replacing values in the previously reported and / or historical data, applying an extrapolation filter, etc. Additionally or alternatively, an acceptable range of the observed data can be predetermined or configured. For example, CQI and MCS measurements can be configured to be only within the ranges defined by the appropriate 3GPP standards. In the case where the reported data value is meaningless (e.g., the value exceeds the acceptable range / boundary, etc.), the current learning / training set or such values over time can be discarded. For example, a packet transfer delay boundary can be defined or configured, and packets determined to be received after the packet transfer delay boundary can be discarded.

[0067] UE 202 can also perform procedures to determine reference signal (RS) measurements and reports to provide the network with information about the quality of one or more wireless channels and / or the general communication medium, which can be used to optimize various aspects of the communication system. As an example, the measurement and reporting procedures performed by UE 202 can include the measurement and reporting procedures discussed in the following documents: 3GPP TS 38.211 v17.5.0 (2023-06-26) (“[TS38211]”), 3GPP TS 38.212 v17.5.0 (2023-03-30) (“[TS38212]”), 3GPP TS 38.213 v17.6.0 (2023-06-26) (“[TS38213]”), 3GPP TS 38.214 v17.6.0 (2023-06-26) (“[TS38214]”), [TS38215], 3GPP TS 38.101-1 v18.2.0 (2023-06-30) (“[TS38101-1]”), 3GPP TS 38.104 v18.2.0 (2023-06-30) (“[TS38104]”), 3GPP TS 38.133 v18.2.0 (2023-06-30) (“[TS38133]”), [TS38331], etc. Physical signals and / or reference signals can include demodulation reference signals (DM-RS), phase-tracking reference signals (PT-RS), positioning reference signals (PRS), channel state information reference signals (CSI-RS), synchronization signal blocks (SSB), primary synchronization signals (PSS), secondary synchronization signals (SSS), sounding reference signals (SRS), etc.

[0068] In any of the examples discussed herein, any suitable data collection and / or measurement mechanism(s) can be used to collect the observed data. For example, data tagging (e.g., sequence numbers, etc.), packet tracking, signal measurements, data sampling, and / or timestamping techniques can be used to determine any of the above metrics / observed data. Data collection can be based on events that trigger data collection. Additionally or alternatively, data collection can also occur at the start or end of an event. Data collection can be continuous, discontinuous, and / or have start and stop times. The data collection techniques / mechanisms can be specific to the HW configuration / implementation or not specific to the HW and can also be based on various software parameters (e.g., OS type and version, etc.). Various configurations can be used to define any of the above data collection parameters. Such configurations can be defined by suitable specifications / standards, such as 3GPP (e.g., [5GEdge]), ETSI (e.g., [MEC]), O-RAN (e.g., [O-RAN]), Smart Edge Open (formerly OpenNESS) (e.g., [ISEO]), IETF (e.g., MAMS [RFC8743]), IEEE / WiFi (e.g., [IEEE80211], [WiMAX], [IEEE16090], etc.) and / or any other similar standards discussed herein.

[0069] In a V2X scenario, the UE 202 or the NAN 214 can be or act as a roadside unit (RSU), and an RSU can refer to any traffic infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. The RSU implemented in or by a UE can be referred to as a "UE-type RSU"; the RSU implemented in or by an eNB can be referred to as an "eNB-type RSU"; the RSU implemented in or by a gNB can be referred to as a "gNB-type RSU"; and so on. In one example, an RSU is a computing device coupled to a radio frequency circuit located at the roadside, which can provide connection support for passing vehicle UEs. The RSU can also include an internal data storage circuit for storing intersection map geometries, traffic statistics, media, and applications / software for sensing and controlling current vehicle and pedestrian traffic. The RSU can provide extremely low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU can also provide other cellular / WLAN communication services. The components of the RSU can be encapsulated in a weatherproof enclosure suitable for outdoor installation and can include a network interface controller for providing a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network. Furthermore, one or more V2X RATs can be employed, which allow V2X nodes to communicate directly with each other, with infrastructure devices (e.g., NAN 214) and / or other devices / nodes. In some embodiments, at least two different V2X RATs can be used, including a WLAN V2X (W-V2X) RAT based on IEEE V2X technology (e.g., DSRC in the United States and ITS-G5 in Europe) and a cellular V2X (C-V2X) RAT based on 3GPP V2X technology (e.g., LTE V2X, 5G / NR V2X, etc.). In one example, the C-V2X RAT can use a C-V2X air interface, and the WLAN V2X RAT can use a W-V2X air interface.

[0070] The W-V2X RATs include, for example: IEEE "Wireless Access in Vehicular Environments (WAVE) Architecture Guidelines", IEEE Standards Association, IEEE 1609.0-2019 (April 10, 2019) ("[IEEE16090]"); "V2X Communication Message Set Dictionary", SAE INT'L (July 23, 2020) ("[J2735_202007]"); 5 GHz band Intelligent Transportation Systems (ITS-G5), [IEEE80211] (which is the Layer 1 (L1) and Layer 2 (L2) part of WAVE, DSRC, and ITS-G5); and / or IEEE Broadband Wireless Access System Air Interface Standard, IEEE Std 802.16-2017, pages 1-2726 (March 2, 2018) ("[WiMAX]"). The term "DSRC" refers to vehicle communication in the 5.9 GHz band commonly used in the United States, while "ITS-G5" refers to vehicle communication in the 5.9 GHz band used in Europe. Due to the applicability to any number of different RATs (including the [IEEE80211] RAT) that can be used in any geographical or political region, the terms "DSRC" (used in the United States among other regions) and "ITS-G5" (used in Europe among other regions) are used interchangeably in this disclosure. ETSI EN 302 663 V1.3.1 (2020-01) (hereinafter referred to as "[EN302663]") outlines the access layer of the ITS-G5 interface and describes the access layer of the ITS-S reference architecture. The ITS-G5 access layer includes [IEEE80211], as well as the functions of the distributed congestion control (DCC) method discussed in ETSI TS102 687 V1.2.1 (2018-04) (hereinafter referred to as "[TS102687]"). The access layer of the (one or more) 3GPP LTE-V2X-based interfaces is outlined in documents such as ETSI EN303 613 V1.1.1 (2020-01), 3GPP TS23.285 v16.2.0 (2019-12); the 3GPP 5G / NR-V2X is outlined in documents such as 3GPP TR23.786 v16.1.0 (2019-06) and 3GPP TS23.287 v18.0.0 (March 31, 2023) ("[TS23287]").

[0071] In an example where RAN 204 is an E-UTRAN 210 with one or more eNBs 212, the E-UTRAN 210 provides an LTE air interface (Uu) whose parameters and characteristics are at least the same as those discussed in 3GPP TS 36.300 v17.2.0 (2022-09-30) (“[TS36300]”). In an example where RAN 204 is a next-generation (NG)-RAN 214 with a set of gNBs 216, each gNB 216 connects to a 5G-capable UE 202 using a 5G-NR air interface (also referred to as the Uu interface), whose parameters and characteristics are discussed in [TS38300] and many other 3GPP standards. When the NG-RAN 214 includes a set of ng-eNBs 218, one or more ng-eNBs 218 connect to the UE 202 via a 5G Uu and / or LTE Uu interface. The gNBs 216 and ng-eNBs 218 connect to the 5GC 240 via corresponding NG interfaces (including the N2 interface, the N3 interface, and / or other interfaces). The gNBs 216 and ng-eNBs 218 are interconnected via the Xn interface. Additionally, individual gNBs 216 are interconnected via corresponding Xn interfaces, and individual ng-eNBs 218 are interconnected via corresponding Xn interfaces. In some examples, the NG interface can be divided into two parts, one part is the NG user plane (NG-U) interface for transmitting traffic data (e.g., the N3 interface) between NG-RAN 214 nodes and the UPF 248; the other part is the NG control plane (NG-C) interface, which is a signaling interface between NG-RAN 214 nodes and the AMF 244 (e.g., the N2 interface).

[0072] The NG-RAN 214 can provide a 5G-NR air interface (also referred to as the Uu interface) with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, simplex codes, and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface can rely on CSI-RS, PDSCH / PDCCH DMRS, which is similar to the LTE air interface. The 5G-NR air interface may not use CRS, but can: use PBCH DMRS for PBCH demodulation; use PTRS for phase tracking of PDSCH; use a tracking reference signal for time tracking. The 5G-NR air interface can operate in the FR1 band including frequencies below 6 GHz or in the FR2 band including frequencies from 24.25 GHz to 52.6 GHz. The 5G-NR air interface can include an SSB, which is an area in the downlink resource grid that includes PSS / SSS / PBCH.

[0073] The 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used for dynamic adaptation of SCS. For example, UE 202 can be configured with multiple BWPs, where each BWP configuration has a different SCS. When a BWP change is indicated to UE 202, the transmitted SCS also changes. Another use case of BWPs is related to energy saving. In particular, multiple BWPs with different numbers of frequency resources (e.g., PRBs) can be configured for UE 202 to support data transmission in different traffic load scenarios. The BWP with fewer PRBs can be used for data transmission under low traffic loads, while allowing power consumption savings at UE 202 and in some cases at gNB 216. The BWP with more PRBs can be used for scenarios with higher traffic loads.

[0074] In some implementations, an individual gNB 216 can include a gNB-CU and a set of gNB-DUs. Additionally or alternatively, gNB 216 can include one or more RUs. In these implementations, the gNB-CU can be connected to each gNB-DU via a corresponding F1 interface. In the case of network sharing with multiple cell ID broadcasts, each cell identity associated with a PLMN subset corresponds to a gNB-DU and its connected gNB-CU, sharing the same physical layer cell resources. To improve resilience, the gNB-DU can be connected to multiple gNB-CUs through appropriate implementations. Additionally, the gNB-CU can be divided into gNB-CU control plane (gNB-CU-CP) functions and gNB-CU user plane (gNB-CU-UP) functions. The gNB-CU-CP is connected to the gNB-DU via the F1 control plane interface (F1-C), the gNB-CU-UP is connected to the gNB-DU via the F1 user plane interface (F1-U), and the gNB-CU-UP is connected to the gNB-CU-CP via the E1 interface. In some implementations, one gNB-DU is only connected to one gNB-CU-CP, and one gNB-CU-UP is only connected to one gNB-CU-CP. To improve resilience, the gNB-DU and / or gNB-CU-UP can be connected to multiple gNB-CU-CPs through appropriate implementations. Under the control of the same gNB-CU-CP, one gNB-DU can be connected to multiple gNB-CU-UPs, and under the control of the same gNB-CU-CP, one gNB-CU-UP can be connected to multiple DUs. Xn-U can support data forwarding between gNB-CU-UPs during handovers within the gNB-CU-CP inside the gNB.

[0075] Similarly, an individual ng-eNB 218 may include an ng-eNB-CU and a set of ng-eNB-DUs. In these implementations, the ng-eNB-CU and each ng-eNB-DU are interconnected via corresponding W1 interfaces. An ng-eNB may include an ng-eNB-CU-CP, one or more ng-eNB-CU-UPs, and one or more ng-eNB-DUs. The ng-eNB-CU-CP and the ng-eNB-CU-UP are connected via an E1 interface. The ng-eNB-DU is connected to the ng-eNB-CU-CP via a W1-C interface and to the ng-eNB-CU-UP via a W1-U interface. Unless otherwise explicitly specified, the general principles described herein with respect to the gNB side also apply to the ng-eNB side and the corresponding E1 and W1 interfaces.

[0076] The node hosting the user plane part of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and for EN-DC, MeNB or SgNB, depending on the bearer separation scenario) performs user inactivity monitoring and further notifies its inactivity or (re)activation to the node having a control plane connection to the core network (e.g., via E1, X2, etc.). The node hosting the RLC protocol layer (e.g., gNB-DU) may perform user inactivity monitoring and further notify its inactivity or (re)activation to the node hosting the control plane (e.g., gNB-CU or gNB-CU-CP).

[0077] In these implementations, the NG-RAN 214 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN 214 architecture (e.g., NG-RAN logical nodes and the interfaces between them) is part of the RNL. For each NG-RAN interface (e.g., NG, Xn, F1, etc.), the relevant TNL protocols and functions are specified. The TNL provides services for user plane transmission and / or signaling transmission. In an NG-Flex configuration, each NG-RAN node is connected to all AMFs 244 in the AMF set within the AMF area that supports at least one slice also supported by the NG-RAN node. The AMF set and the AMF area are defined in [TS23501].

[0078] RAN 204 is communicatively coupled to CN 240, which includes network elements and / or network functions (NFs) for providing various functions to support the provision of data and telecommunications services to consumers / subscribers (e.g., UE 202). The components of CN 240 may be implemented in one physical node or separate physical nodes. In some examples, NFV may be utilized to virtualize any or all of the functions provided by the network elements of CN 240 onto physical computing / storage resources in servers, switches, etc. The logical instantiation of CN 240 may be referred to as a network slice, and a partial logical instantiation of CN 240 may be referred to as a network sub-slice.

[0079] In Figure 2 the example, CN 240 is 5GC 240, which includes an authentication server function (AUSF) 242, an access and mobility management function (AMF) 244, a session management function (SMF) 246, a user plane function (UPF) 248, a network slice selection function (NSSF) 250, a network exposure function (NEF) 252, a network repository function (NRF) 254, a policy control function (PCF) 256, a unified data management (UDM) 258, a unified data repository (UDR), an application function (AF) 260, and a network data analytics function (NWDAF) 262, which are coupled to each other through various interfaces as shown. The NFs in 5GC 240 are briefly introduced below.

[0080] NWDAF 262 is an NF capable of collecting data from: UE 202; (one or more) other NFs in 5GC 240 (e.g., AMF 244, SMF 246, UPF 248, PCF 256, UDM 258, network slice admission control function (NSACF), AF 260 (directly and / or through NEF 252)); operations, administration, and maintenance (OAM) entities / functions; external AF 260; DN 236; (one or more) servers 238; cloud computing services; edge computing nodes; and / or edge networks and / or other entities / elements available for analysis.

[0081] The NWDAF 262 includes one or more of the following functions: supporting data collection from the NF and the AF 260; supporting data collection from the OAM; registering the NWDAF service and exposing metadata to the NF and the AF 260; supporting the provision of analysis information to the NF and the AF 260; supporting ML model training and provision to (one or more) NWDAF 262 (e.g., those NWDAF that include the analysis logic function). Some or all of the NWDAF functions may be supported in a single instance of the NWDAF 262. The NWDAF 262 also includes an analysis reporting function, which includes means for allowing the discovery of analysis types consumable by external parties and / or requesting the consumption of analysis information generated by the NWDAF 262. The NWDAF 262 may collect data from (one or more) NF and / or other entities / components / functions through an Nnf service-based interface associated with (one or more) NF and / or other entities / components / functions. The NWDAF 262 and the NF providing the data belong to the same PLMN. The Nnf interface is defined for the NWDAF 262 to request subscription for data transfer for a specific context, cancel subscription for data transfer, and request a specific data report for a specific context. The 5GS architecture also allows the NWDAF 262 to retrieve management data from the OAM entity by invoking the OAM service.

[0082] The NWDAF 262 interacts with different entities for different purposes, such as one or more of the following: data collection based on event subscriptions provided by the AMF 244, SMF 246, PCF 256, UDM 258, NSACF, AF 260 (directly or through the NEF 252), and the OAM; analysis and data collection using the DCCF 263; retrieving information from a data repository (e.g., retrieving subscriber-related information from the UDR 259 via the UDM 258); location information data collection from the LCS system; information storage and retrieval from the ADRF 266; analysis and data collection from the MFAF 265; retrieving information about the NF (e.g., retrieving NF-related information from the NRF 254), providing analysis to consumers on demand in accordance with Article 6 of [TS23288]; providing bulk data related to (one or more) analysis IDs; providing accuracy information related to (one or more) analysis IDs; and / or providing ML model accuracy information and / or ML model accuracy degradation related to one or more ML models. Articles 6.3.13 of [TS23501] and 5.2 of [TS23288] discuss the NWDAF discovery and selection process.

[0083] A single instance or multiple instances of NWDAF 262 can be deployed in a PLMN. If multiple instances of NWDAF 262 are deployed, the architecture supports deploying NWDAF 262 as a central NF, a distributed NF set, or a combination of both. If multiple instances of NWDAF 262 are deployed, NWDAF 262 can act as an aggregation point (e.g., aggregator NWDAF 262) and collect analysis information from other NWDAF 262 (which may have different service areas) to generate aggregated analysis (e.g., based on each analysis ID), possibly including analysis generated by itself. When there are multiple NWDAF 262, not all NWDAF 262 need to be able to provide the same type of analysis results. For example, some NWDAF 262 can be specialized to provide certain types of analysis.

[0084] The analysis ID information element (IE) is used to identify the types of supported analysis that NWDAF 262 can generate. In some implementations, one or more NWDAF instances 262 can be collocated with another 5GS NF.

[0085] There may be different NWDAF instances 262 in 5GC 240, and each type of analysis (and / or each analysis ID) may be specialized. The NWDAF configuration file stored in NRF 254 describes the functions of NWDAF instances 262, which will be described in more detail below. In a multi-NWDAF deployment scenario, NWDAF instances 262 can be specialized to provide analysis for one or more analysis IDs. Each NWDAF instance 262 can serve a certain area of interest, one or more tracking area identifiers (TAIs), one or more service areas, one or more registration areas, one or more DN names (DNNs), one or more local DNNs, one or more DN access IDs (DNAIs), and / or some other predefined or configured area / region, service, application, or other entity / component. Multiple NWDAF 262 can jointly serve one or more specific analysis IDs. NWDAF 262 may be capable of supporting the aggregation of analysis data received from other NWDAF 262 (e.g., based on each analysis ID), and may also have its own generated analysis data.

[0086] The NWDAF 262 may include an Analytical Logic Function (AnLF) 262a and / or a Model Training Logic Function (MTLF) 262b. The NWDAF 262 may include only the MTLF 262b, only the AnLF 262a, or both. The 5GS architecture allows an NWDAF that includes the AnLF 262a (referred to herein as "NWDAF-ANLF AnLF 262a", etc.) to use a trained ML model from the same or a different NWDAF that includes the MTLF 262b (also referred to herein as "NWDAF MTLF 262b") to provide services. The NWDAF-AnLF 262a uses the Nnwdaf interface to request and subscribe to the trained ML model provision service provided by the NWDAF-MTLF 262b. The Nnwdaf_MLModelProvision service provided by the NWDAF 262 enables an NF service consumer (NFc) to receive a notification when an ML model that matches the subscription parameters in the NWDAF-MTLF 262b is available (see, for example, clause 7.5 of [TS23288]). The NWDAF 262 provides the Nnwdaf_MLModelInfo service, enabling the NFc to request and obtain ML model information from the NWDAF-MTLF 262b (see, for example, clause 7.6 of [TS23288]). The AnLF 262a is a logic function in the NWDAF 262 for performing inference, deriving analytical information (e.g., deriving statistics, inferences, and / or predictions according to an analytical consumer request), and exposing analytical services (e.g., Nnwdaf_AnalyticsSubscription or Nnwdaf_AnalyticsInfo). In some implementations, the AnLF 262a is an AI / ML inference function included in the NWDAF 262. In various implementations, the AnLF 262a may be modeled by the NRM for AI / ML inference management discussed herein. The analytical information may be statistical information about past events or predictive information (e.g., generating predictions / inferences using one or more AI / ML models, etc.). The MTLF 262b is a logic function in the NWDAF 262 for training AI / ML models and exposing new training services (e.g., providing trained ML models), as defined in clauses 7.5 and 7.6 of [TS23288].

[0087] To ensure the accuracy of the analysis output for an analysis ID, based on UE abnormal behavior analysis (including the abnormal UE list and the observed time window) from itself and / or other NWDAF 262, the NWDAF 262 will detect and may delete the input data from the abnormal UE(s) 202, and then may generate a new ML model and / or analysis output for the analysis ID without the input data related to the abnormal UE list during the unobserved time window, and then send / update the ML model information and / or analysis output to the subscribed NWDAF service consumers.

[0088] To support the NF in discovering and selecting the NWDAF-MTLF 262b, NWDAF-AnLF 262a, or both, that can provide the required services (e.g., analysis exposure, AI / ML services (e.g., MLT, ML model provisioning, model testing, etc.), sensing services, communication services, and / or any other service(s) including any service discussed herein) for the required analysis type, each NWDAF instance 262 shall provide a list of the supported analysis ID(s) when registering with the NRF 254, in addition to the other NRF registration elements of the NF profile, which may be based on each supported service (e.g., AI / ML services, analysis exposure / services, sensing services, and / or any other service(s) including any service discussed herein). An NF that needs to discover the NWDAF instance 262 (which supports some service(s) for a specific type of analysis) can query the NRF 254 to obtain the NWDAF 262 that supports the required service(s) and the required analysis ID(s).

[0089] Since multiple NWDAF 262 instances may be deployed in the network, the NFc may use the NRF 254 to discover the (one or more) NWDAF 262 instances, unless the NWDAF information can be obtained in other ways (e.g., locally configured on the NFcs). If supported, the NFc may make additional queries to the UDM 258. The NWDAF selection function in the NFc selects the NWDAF instance 262 (or NWDAF-MTLF instance 262b and / or NWDAF-AnLF instance 262a) based on the available NWDAF 262 instances, the stored / list of supported (one or more) analysis IDs from the NRF 254 (e.g., may be based on each supported service), the NWDAF capabilities (e.g., analysis aggregation capabilities, analysis metadata supply capabilities, ML model training capabilities, ML model deployment capabilities, etc.) and / or other NRF 254 registration elements of the NF profile. 3GPP TS23.288 (“[TS23288]”) defines other and / or alternative aspects of the NWDAF262 function.

[0090] The AUSF 242 stores data for authenticating the UE 202 and processes authentication-related functions. The AUSF242 may facilitate a common authentication framework for various access types.

[0091] The AMF 244 allows other functions of the 5GC 240 to communicate with the UE 202 and the RAN 204, and subscribes to notifications about UE 202 mobility events. The AMF 244 is also responsible for registration management (e.g., registering the UE 202), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 244 provides transmission for SM messages between the UE 202 and the SMF 246 and acts as a transparent proxy for routing SM messages. The AMF 244 also provides transmission for SMS messages between the UE 202 and the SMSF. The AMF 244 interacts with the AUSF 242 and the UE 202 to perform various security anchoring and context management functions. In addition, the AMF 244 is the termination point of the RAN-CP interface, which includes the N2 reference point between the RAN 204 and the AMF 244. The AMF 244 is also the termination point of the NAS (N1) signaling and performs NAS encryption and integrity protection.

[0092] The AMF 244 also supports NAS signaling between the UE 202 via the N3IWF interface. The N3IWF allows access to untrusted entities. The N3IWF can be the termination point of the N2 interface for the control plane between the (R)AN 204 and the AMF 244, or the termination point of the N3 reference point for the user plane between the (R)AN 204 and 248. Therefore, the AMF 244 processes N2 signaling for PDU sessions and QoS from the SMF 246 and the AMF 244, encapsulates / decapsulates packets for IPSec and N3 tunnels, marks N3 user plane packets in the UL, and enforces QoS corresponding to the N3 packet marking, taking into account the QoS requirements associated with such markings received via N2. The N3IWF can also relay UL and DL control plane NAS signaling between the UE 202 and the AMF 244 via the N1 reference point between the UE 202 and the AMF 244, and relay UL and DL user plane packets between the UE 202 and the UPF 248. The N3IWF also provides a mechanism to establish an IPsec tunnel with the UE 202. The AMF 244 can expose an interface based on the Namf service and can be the termination point of the N14 reference point between two AMF 244s and the N17 reference point between the AMF 244 and the 5G-EIR ( Figure 2 not shown). In addition to the functions of the AMF 244 described herein, the AMF 244 can also provide support for network slice restrictions and network slice instance restrictions based on NWDAF analysis.

[0093] The SMF 246 is responsible for: SM (e.g., session establishment, tunnel management between the UPF 248 and the NAN 214); UE IP address allocation and management (including optional authorization); selection and control of the UP function; configuration of traffic steering at the UPF 248 to route traffic to the appropriate destination; termination of the interface towards the policy control function; control of partial policy enforcement, charging, and QoS; lawful interception (for SM events and the interface with the LI system); termination of the SM part of the NAS message; DL data notification; initiation of AN-specific SM information, sent via the AMF 244 to the NAN 214 through N2; and determination of the SSC mode of the session. SM refers to the management of the PDU session, and the PDU session or "session" refers to the PDU connection service that provides or enables the PDU exchange between the UE 202 and the DN 236. The SMF 246 may also include the following functions to support edge computing enhancements (e.g., see [TS23548]): selection of the EASDF 261 and provision of its address to the UE as the DNS server for the PDU session; use of the EASDF261 service defined in [TS23548]; and provision and update of the ECS address configuration information to the UE for supporting the application layer architecture defined in [TS23558]. The discovery and selection process for the EASDF 261 is discussed in Section 6.3.23 of [TS23501].

[0094] The UPF 248 acts as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection with the data network 236, and a branching point for supporting multi-homed PDU sessions. The UPF 248 also performs packet routing and forwarding, packet inspection, enforcement of the user plane part of the policy rules, lawful interception of packets (UP collection), execution of traffic usage reports, execution of QoS handling in the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), execution of UL traffic verification (e.g., SDF to QoS flow mapping), transport layer packet marking in UL and DL, and execution of DL packet buffering and DL data notification triggering. The UPF 248 may include a UL classifier to support routing of traffic flows to the data network.

[0095] The NSSF 250 selects a set of network slice instances serving the UE 202. The NSSF 250 also determines the allowed NSSAI and its mapping to the subscribed S-NSSAI as required. The NSSF 250 also determines a set of AMFs or a list of candidate AMFs 244 for serving the UE 202 based on appropriate configurations and possibly by querying the NRF 254. By interacting with the NSSF 250, the AMF 244 to which the UE 202 is registered can trigger the selection of a set of network slice instances for the UE 202; this may result in a change of the AMF 244. The NSSF 250 interacts with the AMF 244 via the N22 reference point; and can communicate with another NSSF in the visited network via the N31 reference point (not shown).

[0096] The NEF 252 securely exposes the services and capabilities provided by 3GPP NFs to third parties, internal exposure / re-exposure, AF 260, edge computing networks / frameworks, etc. In such examples, the NEF 252 may authenticate, authorize, or throttle the AF 260. The NEF 252 uses the Nudr interface of the Unified Data Repository (UDR) to store / retrieve information as structured data. The NEF 252 also transforms the information exchanged with the AF 260 and the information exchanged with internal NFs. For example, as described in clause 5.6.7 of [TS23501], the NEF 252 may transform between an AF service identifier and internal 5GC information (e.g., DNN, S-NSSAI). In particular, the NEF 252 shields network and user sensitive information from the external AF 260 according to network policies. The NEF 252 also receives information from other NFs based on the capabilities exposed by other NFs. This information may be stored in the NEF 252 as structured data, or stored in a data storage NF using a standardized interface. Then, the stored information can be re-exposed by the NEF 252 to other NFs and AFs, or used for other purposes such as analysis. For example, according to the provisions of [TS23288], the NWDAF analysis can be securely exposed to the outside by the NEF 252. In addition, the NWDAF 262 can collect externally provided data through the NEF 252 for generating analysis results. As described in [TS23288], the NEF 252 processes and forwards requests and notifications between the NWDAF 262 and the AF(s) 260. In some examples, the NEF 252 may provide one or more interfaces to one or more edge computing nodes 238, which can be used to handle the radio connection with the RAN 214 and / or offload tasks to the edge computing nodes 238.

[0097] The NRF 254 supports the service discovery function, receives NF discovery requests from NF instances, and provides the information of the discovered NF instances to the NF instance that made the request. The NRF 254 also maintains the NF profiles of the available NF instances and the services they support. The NF profiles of the NF instances maintained in the NRF 254 include the following information: NF instance ID, NF type, PLMN ID (if it is a PLMN), PLMN ID + NID (if it is an SNPN), (one or more) network slice related identifiers (e.g., S-NSSAI, NSIID), (one or more) network addresses of the NF (e.g., FQDN, IP address, etc.), NF capacity information, NF priority information (e.g., for AMF selection), NF set ID, NF service set ID of the NF service instance; NF specific service authorization information; the name of the supported service (if applicable); (one or more) endpoint addresses of (one or more) instances of each supported service; the identification of the stored data / information (e.g., for UDR profiles and / or other NF profiles); (one or more) other service parameters (e.g., DNN or DNN list, LADN DNN or LADN DNN list, notification endpoints for each type of notification that the NF service is interested in receiving, etc.); the location information of the NF instance (e.g., geographical location, data center, etc.); (one or more) TAI; NF load information; routing indicator; home network public key identifier (for UDM 258 and AUSF 242); for UDM258, AUSF 242, and NSSAAF, in the case of accessing an SNPN using the credentials owned by the credential holder with an AAA server, the identification of the credential holder (e.g., subscription permanent identifier (SUPI) based on the network specific identifier domain); for UDM 258 and AUSF 242, if UDM 258 / AUSF 242 is used to access an SNPN using the credentials owned by the credential holder, the identification of the credential holder (e.g., the domain if a network specific identifier-based SUPI is used; or MCC and MNC if an IMSI-based SUPI is used); for AUSF 242 and NSSAAF, in the case of SNPN Onboarding using a DCS with an AAA server, the identification of the DCS (e.g., the domain of the network specific identifier-based SUPI); for UDM 258 and AUSF 242, for SNPN Onboarding if UDM 258 / AUSF 242 is used as the DCS, the identification of the DCS (e.g., the domain if a network specific identifier-based SUPI is used; or MCC and MNC if an IMSI-based SUPI is used); for AMF 244, one or more GUAMI;For UPF 248, see clause 5.2.7.2.2 of [TS23502]; for UDM 258, UDM group ID, (one or more) ranges of SUPI, (one or more) ranges of GPSI, (one or more) ranges of internal group identifiers, (one or more) ranges of external group identifiers; for UDR, UDR group ID, (one or more) ranges of SUPI, (one or more) ranges of GPSI, (one or more) ranges of external group identifiers; for AUSF 242, AUSF group ID, (one or more) ranges of SUPI; for PCF 256, PCF group ID, (one or more) ranges of SUPI; for HSS, HSS group ID, (one or more) sets of IMPI, (one or more) sets of IMPU, (one or more) sets of IMSI, (one or more) sets of PSI, (one or more) sets of MSISDN; for NEF 252, (one or more) event IDs supported by AF 260; for NEF 252, (one or more) event exposure service event IDs supported by UPF 248; for NEF 252, (one or more) application identifiers supported by AF 260; for NEF 252, (one or more) ranges of external identifiers or domain names served by NEF (e.g., used when NEF 252 exposes AF information for analysis, as detailed in [TS23288]); in addition, NRF 254 may also store the mappings between UDM group ID and (one or more) SUPI, between UDR group ID and (one or more) SUPI, between AUSF group ID and (one or more) SUPI, and between PCF group ID and (one or more) SUPI, to discover UDM 258, UDR, AUSF 242, and PCF 256 using SUPI, SUPI ranges as specified in clause 6.3 of [TS23501], and / or interact with UDR to resolve UDM group ID / UDR group ID / AUSF group ID / PCF group ID based on the UE identity (e.g., SUPI); for BSF, IP domain list (as described in clause 6.1.6.2.21 of 3GPP TS29.510 v18.2 (2023-03-29) (“[TS29510]”)), (one or more) ranges of (UE) IPv4 addresses or (one or more) ranges of (UE) IPv6 prefixes, (one or more) ranges of SUPI or (one or more) ranges of GPSI or BSF group ID; the SCP domain to which the NF belongs; for DCCF 263, DCCF service area information, NF type of the data source, NF set ID of the data source (if any); for SMF 246, the list of supported DNAI;For the SNPN, the ability to support SNPN Onboarding in the case of the AMF, and the ability to support user plane remote provisioning in the case of the SMF 246; for the UPF 248, the IP address range, DNAI; additional NF profile parameters related to V2X are defined in 3GPP TS 23.287; additional ProSe-related NF profile parameters are defined in 3GPP TS 23.304; additional MBS-related NF profile parameters are defined in 3GPP TS 23.247; additional UAS-related NF profile parameters are defined in TS 23.256; and many other parameters discussed in [TS23501]. In some examples, such as when the NF instance has special service authorization information, the service authorization information provided by the OAM system is also included in the NF profile.;

[0098] For the NWDAF 262, the NF profile includes: (one or more) supported analysis IDs (possibly per service), NWDAF service area information (e.g., a list of TAIs for which the NWDAF can provide services and / or data), supported analysis latency per analysis ID (if any), NF type of the NF data source, NF set ID of the NF data source (if any), analysis aggregation ability (if any), analysis metadata provisioning ability (if any), (one or more) ML model filtering information parameters S-NSSAI and (one or more) regions of interest of the (one or more) trained ML models per analysis ID (if any), federated learning (FL) ability type (e.g., FL server or FL client, if any), time interval supporting FL (if any). The NWDAF 262 service area information is common for all the analysis IDs it supports. The analysis IDs supported by the NWDAF 262 can be associated with the supported analysis latency. For example, the analysis report can be generated within a time (including data collection latency and inference latency) less than or equal to the supported analysis latency. The determination of the supported analysis latency and how the NWDAF 262 avoids frequent updates of its supported analysis latency in the NRF may be related to the specific implementation of the NWDAF.

[0099] The PCF 256 provides policy rules for the control plane function to enforce these rules and may also support a unified policy framework to manage network behavior. The PCF 256 can also implement a front end to access subscription information related to policy decisions in the UDR 259 of the UDM 258. In addition to communicating with functions via the reference points as shown, the PCF 256 also exposes an Npcf service-based interface.

[0100] The UDM 258 processes subscription-related information to support network entities in handling communication sessions and stores the subscription data of the UE 202. For example, the subscription data can be communicated via the N8 reference point between the UDM 258 and the AMF 244. The UDM 258 can include two parts: an application front end and a UDR. The UDR can store subscription data and policy data for the UDM 258 and the PCF 256, and / or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 202) for the NEF 252. An interface based on the Nudr service can be presented by the UDR to allow the UDM258, the PCF 256, and the NEF 252 to access specific stored data sets, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM 258 can include a UDM-FE responsible for handling credentials, location management, subscription management, etc. Multiple different front ends can serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identity processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown, the UDM 258 can also present an interface based on the Nudm service.

[0101] Edge Application Server Discovery Function (EASDF) 261 presents an interface based on the Neasdf service and is connected to the SMF 246 via the N88 interface. One or more EASDF instances can be deployed within a PLMN, and the interaction between the (one or more) 5GC NFs and the EASDF 261 occurs within the PLMN. The EASDF 261 includes one or more of the following functions: registering with the NRF 254 for EASDF261 discovery and selection; processing DNS messages according to instructions from the SMF 246; and / or terminating DNS security (if used). Processing DNS information according to instructions from the SMF 246 includes one or more of the following functions: receiving DNS message processing rules and / or BaselineDNSPattern from the SMF 246; exchanging DNS messages with / from the UE 202; forwarding DNS messages to the C-DNS or L-DNS for DNS queries; adding the EDNS Client Subnet (ECS) option to DNS queries for FQDNs; reporting information related to the received DNS messages to the SMF246; and / or buffering / dropping DNS messages from the UE 202 or DNS servers. The EASDF has a direct user plane connection with the PSA UPF via N6 (e.g., without any NAT) to transport DNS signaling exchanged with the UE. Deployment of NAT between the EASDF 261 and the PSA UPF 248 may or may not be supported. Other aspects of the EASDF 261 are discussed in [TS23548].

[0102] The AF 260 provides application impact on traffic routing, provides access to the NEF 252, and interacts with the policy framework for policy control. The AF 260 can affect UPF 248 (re)selection and traffic routing. Depending on the operator's deployment, when the AF260 is considered a trusted entity, the network operator may allow the AF 260 to directly interact with the relevant NFs. In some implementations, the AF 260 is used for edge computing implementations.

[0103] NFs that need to collect data from the AF 260 can directly subscribe / unsubscribe from the AF 260 or via the NEF 252 for notifications regarding data collected from the AF260. The data collected from the AF 260 is used as input for the analysis by the NWDAF 262. Details of the data collected from the AF 260 and the interaction between the NEF 252, AF 260, and NWDAF 262 are described in [TS23288].

[0104] The 5GC 240 can implement edge computing by selecting an operator / third-party service that is geographically close to the point where the UE 202 attaches to the network. This can reduce latency and network load. In the edge computing implementation, the 5GC 240 can select a UPF 248 close to the UE 202 and perform traffic steering from the UPF 248 to the DN 236 through the N6 interface. This can be based on UE subscription data, UE location, and information provided by the AF 260, which allows the AF 260 to influence UPF (re)selection and traffic routing.

[0105] The data network (DN) 236 can represent various network operator services, Internet access, or third-party services, which can be provided by one or more servers, such as including an application (App) / content server 238. The DN 236 can be an operator-external public network, a private PDN, or an operator-internal packet data network, for example, for providing IMS services. In this example, the application server 238 can be coupled to the IMS through an S-CSCF or an I-CSCF. In some implementations, the DN 236 can represent one or more local DNs (LADNs), which are DNs 236 (or DN names (DNNs)) that the UE 202 can access in one or more specific areas. Outside of these specific areas, the UE 202 cannot access the LADN / DN 236.

[0106] Additionally or alternatively, the DN 236 can be an edge DN 236, which is a (local) DN that supports an architecture enabling edge applications. In these examples, the application server 238 can represent a physical hardware system / device providing application server functionality and / or application software of an edge computing node residing in the cloud or executing (one or more) server functions. In some examples, the application / content server 238 provides an edge hosting environment that provides the support required for the execution of an edge application server.

[0107] In some examples, the 5GS can use one or more edge computing nodes to provide an interface and offload processing of wireless communication traffic. In these examples, the edge computing nodes can be included in or co-located with one or more RANs 204 or RAN nodes 214. For example, the edge computing nodes can provide a connection between the RAN 204 and the UPF 248 in the 5GC 240. The edge computing nodes can use one or more NFV instances instantiated on the virtualization infrastructure within the edge computing nodes to process wireless connections to and from the RAN 214 and the UPF 248.

[0108] In some implementations, the edge computing node provides a distributed computing environment for application and service hosting and also provides storage and processing resources to enable data and / or content to be processed closer to the subscribers (e.g., the users of UE 202), thereby reducing the response time. The edge computing node also supports a multi-tenant runtime and a hosting environment for (one or more) applications, including virtual device applications, middleware applications, and infrastructure services that can be delivered as packaged virtual machine (VM) images, content delivery services including content caching, mobile big data analytics, and compute offloading, etc. Compute offloading includes offloading compute tasks, workloads, applications, and / or services from UE 202, CN 240, DN 236, and / or (one or more) servers 238 to the edge computing node and vice versa. For example, a device application or a client application running in UE 202 can offload an application task or workload to one or more edge computing nodes. In another example, the edge computing node can offload an application task or workload to a group of UEs 202 (e.g., for distributed machine learning computations, etc.).

[0109] The edge computing node can include or be part of an edge system that employs one or more edge computing technologies (ECTs) (also referred to as "edge computing frameworks", etc.). The edge computing node can also be referred to as an "edge host" or an "edge server". The edge system includes a collection of edge servers and an edge management system (not shown) required to run edge computing applications in the carrier network or a subset of the carrier network. The edge server is a physical computer system that can include an edge platform and / or virtualization infrastructure and provides computing, storage, and network resources to edge computing applications. Each edge server is deployed at the edge of a corresponding access network and is arranged to provide computing resources and / or various services (e.g., compute task and / or workload offloading, cloud computing capabilities, IT services, and other similar resources and / or services discussed herein) relatively close to UE 202. The VI of the edge computing node provides a virtualization environment and virtualization resources for the edge host, and edge computing applications can run on the VI as VMs and / or application containers.

[0110] In one example implementation, the ECT is part of and / or operates according to the MEC framework, such as those discussed in the following documents: ETSI GR MEC 001v3.1.1 (2022-01), ETSI GS MEC 003v3.1.1 (2022-03), ETSI GS MEC 009v3.1.1 (2021-06), ETSI GS MEC 010-1v1.1.1 (2017-10), ETSI GS MEC 010-2v2.2.1 (2022-02), ETSI GS MEC 011v2.2.1 (2020-12), ETSI GS MEC 012V2.2.1 (2022-02), ETSI GS MEC 013V2.2.1 (2022-01), ETSI GS MEC 014v2.1.1 (2021-03), ETSI GS MEC015v2.1.1 (2020-06), ETSI GS MEC 016v2.2.1 (2020-04), ETSI GS MEC 021v2.2.1 (2022-02), ETSI GR MEC 024v2.1.1 (2019-11), ETSI GS MEC 028V2.2.1 (2021-07), ETSI GS MEC029v2.2.1 (2022-01), ETSI MEC GS 030v2.1.1 (2020-04), and ETSI GR MEC 031v2.1.1 (2020-10) (collectively referred to herein as "[MEC]").This example implementation (and / or any other example implementation discussed herein) may also include NFV and / or other similar virtualization technologies such as those discussed in the following documents: ETSI GR NFV 001 V1.3.1 (2021-03), ETSI GS NFV 002 V1.2.1 (2014-12), ETSI GR NFV 003 V1.6.1 (2021-03), ETSI GS NFV 006 V2.1.1 (2021-01), ETSI GS NFV-IF 001 V1.1.1 (2015-01), ETSI GS NFV-IF 003 V1.1.1 (2014-12), ETSI GS NFV-INF 004 V1.1.1 (2015-01), ETSI GS NFV-MAN 001 v1.1.1 (2014-12), and / or Israel et al., OSM Release FIVE Technical Overview, ETSI OPENSOURCE MANO, OSM White Paper, 1st ed. (January 2019), https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf (collectively referred to as "[ETSI NFV]"). Other virtualization technologies and / or service orchestration and automation platforms may be used, such as the virtualization technologies and / or service orchestration and automation platforms discussed in the following items: E2E Network Slicing Architecture, GSMA, Official Doc. NG.127, v1.0 (June 3, 2021); https: / / www.gsma.com / newsroom / wp-content / uploads / / NG.127-v1.0-2.pdf, Open Network Automation Platform (ONAP) documentation, Release Istanbul, v9.0.1 (February 17, 2022); https: / / docs.onap.org / en / latest / index.html ("[ONAP]"); 3GPP TS 28.533 v17.1.0 (2021-12-23) ("[TS28533]") - based Service Based Management Architecture (SBMA).

[0111] In another example implementation, the ECT is and / or operates according to the O-RAN framework. Various aspects of the O-RAN architecture are described in the following: O-RAN Working Group 1 (Use Cases and Overall Architecture), O-RAN Architecture Description, O-RAN Alliance WG1, O-RAN Hardening Description v09.00, Release 003 (June 2023) (“[ORAN.OAD]”); O-RAN Working Group 1 Slice Architecture, O-RAN Alliance WG1, Slice Architecture Technical Specification v10.00, Release 003 (June 2023); O-RAN Working Group 1 Use Case Detailed Specification Architecture, v11.00, Release 003 (June 2023) (“[ORAN.UseCases]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: Application Protocol, v04.00, R003 (March 2023) (“[ORAN.A1AP]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: General Aspects and Principles, v03.01, Release 003 (March 2023) (“[ORAN.A1GAP]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: Type Definitions, v05.01, R003 (June 2023) (“[ORAN.A1TD]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) A1 Interface: Transport Protocol, v02.01, R003 (March 2023); O-RAN Working Group 2 AI / ML Workflow Description and Requirements v01.03 O-RAN Alliance WG2 (October 2021) (“[ORAN.AIML]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group): R1 Interface: General Aspects and Principles 5.0, v05.00, R003 (June 2023); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group) Non-RT RIC Architecture, v03.00, Release 003 (June 2023) (“[O-RAN.Non-RT-RIC-ARCH]”); O-RAN Working Group 2 (Non-RT RIC and A1 Interface Working Group): Use Cases and Requirements, v07.00, Release 003 (June 2023) (“[O-RAN.Use-Case-Requirements]”); O-RAN Working Group 3 Near Real-Time RAN Intelligent Controller Architecture and E2 General Aspects and Principles, v03.01, Release 003 (June 2023) (“[ORAN.E2GAP]”); O-RAN Working Group 3, Near Real-Time Intelligent Controller, E2 Application Protocol (E2AP), v03.01, Release 003 (June 2023) (“[ORAN.=O-RAN Working Group 3, Near Real-Time Intelligent Controller E2 Service Model (E2SM), v03.01, Release R003 (June 2023) (“[ORAN.E2SM]”); O-RAN Working Group 3, Near Real-Time Intelligent Controller E2 Service Model (E2SM) KPM, v03.00, Release R003 (March 2023) (“[ORAN.E2SM-KPM]”); O-RAN Working Group 3 Near Real-Time Intelligent Controller E2 Service Model (E2SM), Cell Configuration and Control, v01.01, Release R003 (March 2023) (“[ORAN.E2SM-CCC]”); O-RAN Working Group 3 Near Real-Time Intelligent Controller E2 Service Model (E2SM), Cell Configuration and Control, v01.01, Release R003 (March 2023) (“[ORAN.E2SM-CCC]”); Controller E2 Service Model (E2SM) RAN Functional Network Interface (NI) v01.00 (February 2020) (“[ORAN.E2SM-NI]”); O-RAN Working Group 3 Near Real-Time Intelligent Controller E2 Service Model (E2SM) RAN Control v03.00, Release R003 (June 2023) (“[ORAN.E2SM-RC]”); O-RAN Working Group 3 (Near Real-Time RAN Intelligent Controller and E2 Interface Working Group): Near Real-Time RIC Architecture, v04.00, Release R003 (March 2023) (“[ORAN.RICARCH]”); O-RAN Working Group 4 (Open Fronthaul Interface Working Group) Control, User and Synchronization Platform O-RAN Fronthaul Working Group 4, Cooperative Transport Interface Transport Control Plane Specification, v04.00, Release R003 (June 2023); O-RAN Fronthaul Working Group 4, Cooperative Transport Interface Transport Management Plane Specification, v12.00, Release R003 (June 2023) (“[ORAN.MP]”); O-RAN Alliance Working Group 5, O1 Interface Specification for O-CU-UP and O-CU-CP, v05.00, Release R003 (June 2023); O-RAN Alliance Working Group 5, O1 Interface Specification for O-DU, v07.00, Release R003 Version (June 2023); O-RAN Alliance Working Group 6, O2 Interface General Aspects and Principles 4.0, v04.00, Version R003 (June 2023); O-RAN Working Group 6 (Cloudification and Coordination) O-RAN Virtualized RAN Cloud Architecture and Deployment Scenarios v04.00 (October 2022) (“[ORAN.CADS]”); O-RAN Working Group 6 (Cloudification and Coordination Working Group): O-RAN Acceleration Abstraction Layer General Aspects and Principles, v06.00, Version R003 (June 2023); O-RAN Working Group 6: O-Cloud Notification API Specification for Event Consumers, v03.00 (October 2022) (“[ORAN.O-RAN White Box Hardware Working Group, Hardware Reference Design Specification for Indoor Pico Cell with Fronthaul Split Option 6, v02.00, O-RAN Alliance WG7 (October 2021) (“[ORAN.IPC-HRD-Opt6]”); O-RAN WG7, Hardware Reference Design Specification for Indoor Pico Cell (FR1) with Split Architecture Option 7-2, v03.00, O-RAN Alliance WG7 (October 2021) (“[ORAN.IPC-HRD-Opt7-2]”); O-RAN WG7, Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 8, v03.00 (October 2021) (“[ORAN.IPC-HRD-Opt8]”); O-RAN White Box Hardware Working Group, Hardware Reference Design Specification for Outdoor Microcell with Split Architecture Option 7.2, v03.00, O-RAN Alliance WG7 (October 2022) (“[ORAN.OMC-HRD-Opt7-2]”); O-RAN White Box Hardware Working Group, Hardware Reference Design Specification for Outdoor Macro Cell with Split Architecture Option 7.2, v03.00, Release R003 (June 2023) (“[ORAN.OMAC-HRD]”); O-RAN Open X-haul Transport Working Group, Management Interface for Transport Network Elements, v06.00, Release R003 (June 2023); O-RAN Open Transport Working Group 9, Xhaul Packet Switching Architecture and Solutions, v05.00, Release R003 (2 O-RAN.XPSAAS, June 2023) (“[ORAN.XPSAAS]”); O-RAN Open Xhaul Transport Working Group, Synchronized Architecture and Solution Specification, v03.00 (October 2022); O-RAN Open Xhaul Transport WG9, WDM-based Front-end Transport, v03.00, Release R003 (March 2023); O-RAN Operation and Maintenance Architecture, v09.00, Release R003 (June 2023) (“[ORAN.OAM-Arch]”); O-RAN Operation and Maintenance Interface Specification, v10.00, O-RAN Alliance WG10, Version R003 (June 2023) (“[ORAN.O1-Interface]”); O-RAN Information Model and Data Model Specification v05.00, O-RAN Alliance WG10, Version R003 (June 2023); and O-RAN: Towards an Open and Intelligent RAN, O-RAN Alliance White Paper (October 2018) (collectively, “[O-RAN]”). .

[0112] In another example implementation, the ECT is the architecture enabling edge applications of the 3rd Generation Partnership Project (3GPP) System Architecture Working Group 6 (SA6) (abbreviated as "[3GPP Edge Computing]") and / or operates according to the architecture enabling edge applications of 3GPP SA6 (abbreviated as "[3GPP Edge Computing]"). For example, the architecture enabling edge applications of 3GPP SA6 (abbreviated as "[3GPP Edge Computing]") is discussed in the following documents: 3GPP TS 23.222 ("[TS23222]"), 3GPP TS 23.401, 3GPP TS 23.434 ("[TS23434]"), 3GPP TS 23.501 ("[TS23501]"), 3GPP TS 23.502 ("[TS23502]"), 3GPP TS 23.548 ("[TS23548]"), 3GPP TS 23.558 ("[TS23558]"), 3GPP TS 23.682 ("[TS23682]"), 3GPP TR 23.700-98 ("[TR23700-98]"), 3GPP TS 28.104 ("[TS28104]"), 3GPP TS 28.105 ("[TS28105]"), 3GPP TS 28.532 ("[TS28532]"), 3GPP TS 28.533 ("[TS28533]"), 3GPP TS 28.535 ("[TS28535]"), 3GPP TS 28.536 ("[TS28536]"), 3GPP TS 28.538 ("[TS28538]"), 3GPP TS 28.541 ("[TS28541]"), 3GPP TS 28.545 ("[TS28545]"), 3GPP TS 28.550 ("[TS28550]"), 3GPP TS 28.554 ("[TS28554]"), 3GPP TS 28.622 ("[TS28622]"), 3GPP TS 29.122 ("[TS29122]"), 3GPP TS 29.222 ("[TS29222]"), 3GPP TS 29.522 ("[TS29522]"), 3GPP TR 28.908 ("[TR28908]"), 3GPP TS 33.122 ("[TS33122]") (collectively referred to as "[5G Edge]").

[0113] In another example implementation, the ECT is the following item and / or operates according to the following item: Intel Smart Edge Open Framework (formerly known as OpenNESS), which framework is at Intel Discussed in the Smart Edge Open Developer Guide, version 21.09 (September 30, 2021), details are available at https: / / smart-edge-open.github.io / (“[ISEO]”).

[0114] In another example implementation, the ECT operates according to the Multi-Access Management Service (MAMS) framework, which is discussed in the following documents: Kanugovi et al., Multi-Access Management Service (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (March 2020) (“[RFC8743]”); Ford et al., TCP Extensions for Multipath Operations with Multiple Addresses, IETF RFC 8684, (March 2020); De Coninck et al., Multipath Extensions for QUIC (MP-QUIC), IETF DRAFT-DECONINCK-QUIC-MULTIPATH-07, IETA, QUIC Working Group (May 3, 2021); Zhu et al., User Plane Protocol for Multi-Access Management Service, IETF DRAFT-ZHU-INTAREA-MAMS-USER-PROTOCOL-09, IETA, INTAREA (March 4, 2020); and Zhu et al., General Multi-Access (GMA) Convergence Encapsulation Protocol, IETF RFC 9188 (February 2022) (collectively referred to as “[MAMS]”).

[0115] It should be understood that the above-described edge computing framework / ECT and service deployment examples are merely illustrative examples of ECT, and the present disclosure is applicable to many other or additional edge computing / network technologies in various combinations and layouts of devices located at the network edge (including various edge computing networks / systems described herein). In addition, the technologies disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be applicable to the present disclosure. Examples of such edge computing / network technologies include: [MEC]; [O-RAN]; [ISEO]; [5GEdge]; content delivery networks (CDNs) (also referred to as "content distribution networks", etc.); mobile service provider (MSP) edge computing and / or mobile as a service (MaaS) provider systems (e.g., systems used in the AECC architecture); nebula edge cloud systems; fog computing systems; small cell cloud edge cloud systems; mobile cloud computing (MCC) systems; re-architected central office as a data center (CORD), mobile CORD (M-CORD), and / or converged multi-access and core (COMAC) systems; and / or similar systems. In addition, the technologies disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be used for the purposes of the present disclosure.

[0116] The interfaces of the 5GC 240 include reference points and service-based interfaces. At least in some examples, a reference point is a point of attachment between two non-overlapping functional groups, elements, or entities. The reference points include: N1 (between the UE 202 and the AMF 244), N2 (between the RAN 214 and the AMF 244), N3 (between the RAN 214 and the UPF 248), N4 (between the SMF 246 and the UPF 248), N5 (between the PCF 256 and the AF 260), N6 (between the UPF 248 and the DN 236), N7 (between the SMF 246 and the PCF 256), N8 (between the UDM 258 and the AMF 244), N9 (between two UPFs 248), N10 (between the UDM 258 and the SMF 246), N11 (between the AMF 244 and the SMF 246), N12 (between the AUSF 242 and the AMF 244), N13 (between the AUSF 242 and the UDM 258), N14 (between two AMFs 244; not shown), N15 (between the PCF 256 and the AMF 244 in the non-roaming case or between the PCF 256 of the visited network and the AMF 244 in the roaming case), N16 (between two SMFs 246; not shown), and N22 (between the AMF 244 and the NSSF 250). Other reference point notations not shown in Figure 2 the text may also be used, such as any of those discussed in [TS23501].

[0117] Figure 2 NFs within the control plane are represented based on service-based representations, where the NF enables other authorized NFs to access its services. At least in some examples, a service-based interface (SBI) may enable an NF to access the services of one or more other NFs via the interface. In some implementations, the service-based interface is an API-based interface (e.g., northbound API, southbound API, HTTP / 2, RESTful, SOAP, A1AP, E2AP, and / or any other API, web service, application layer, and / or other communication protocols, such as any protocol discussed herein), and NFs can use these interfaces to invoke or call specific services or service operations. The SBI includes: Namf (SBI presented by AMF 244), Nsmf (SBI presented by SMF 246), Nnef (SBI presented by NEF 252), Npcf (SBI presented by PCF 256), Nudm (SBI presented by UDM 258), Naf (SBI presented by AF 260), Nnrf (SBI presented by NRF254), Nnssf (SBI presented by NSSF 250), Nausf (SBI presented by AUSF 242). Other service-based interfaces not shown herein (e.g., Nudr, N5g-eir, and Nudsf) may also be used, such as any interface discussed in [TS23501]. Figure 2 Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf), such as any interface discussed in [TS23501].

[0118] Although Figure 2 not shown, the system 200 may also include NFs not shown, such as UDR, unstructured data storage function (UDSF), network slice admission control function (NSACF), network slice specific and stand-alone non-public network (SNPN) authentication and authorization function (NSSAAF), UE radio capability management function (UCMF), 5G equipment identity register (5G-EIR), charging function (CHF), time-sensitive network (TSN) AF 260, time-sensitive communication and time synchronization function (TSCTSF), data collection coordination function (DCCF), analytical data repository function (ADRF), message framework adapter function (MFAF), binding support function (BSF), non-seamless WLAN offloading function (NSWOF), service communication proxy (SCP), secure edge protection proxy (SEPP), non-3GPP interoperability function (N3IWF), trusted non-3GPP gateway function (TNGF), wired access gateway function (W-AGF), and / or trusted WLAN interoperability function (TWIF), as described in [TS23501].

[0119] The present disclosure generally relates to wireless communication, cellular networks, cloud computing, edge computing, data centers, network topologies, communication system implementation, network convergence, artificial intelligence (AI) / machine learning (ML) technologies, and in particular, to techniques for UE-level measurement information collection and management activation for UE-level measurement operations.

[0120] An increasing number of use cases are starting to rely on the availability of per-UE measurements, for example, management control loops (such as distributed self-organizing network (SON) (D-SON), centralized SON (C-SON), hybrid SON functions, etc.) and analysis and intelligence functions in the network (such as network data analytics function (NWDAF), RAN intelligent functions, etc.).

[0121] The concept of traditional performance measurement focuses on aggregating measurement results into objects (such as NFs, cells, interfaces, etc.) that serve all relevant UEs (rather than measurement results specific to a particular UE). The purpose of this aggregation is to reduce the total amount of management data to be transmitted and analyzed (for example, there is no need to track individual UEs to evaluate the performance of cells, NFs, AFs, etc.). Considering per-UE measurements as performance measurements (PM) requires expanding this concept to focus not only on generalization and aggregation but also on finer granularity. Therefore, it is challenging to define per-UE measurements using traditional performance measurement methods, which may confuse the concept of performance measurement.

[0122] The concept of key performance indicators (KPIs) further expands the PM concept (in the data aggregation direction). PM aggregates multiple UEs at the MeasuredObject level, while KPIs further aggregate data from multiple instances of the same or different types of measurement objects. The focus of KPI standardization is to define standardized aggregation formulas and data sources (usually PM).

[0123] The traditional method for handling per-UE measurements in 3GPP SA5 specifications is MDT (for example, see 3GPP TS 37.320 V17.5.0 (2023-09) (3rd Generation Partnership Project; Radio Access Network Technical Specification Group; Radio Measurement Collection for Minimization Drive Test (MDT); General Description; Stage 2 (Release 17))): perform measurements at the UE or the base station; execute, collect, and report measurements per UE; use a tracing mechanism to collect and report measurements (for example, see 3GPP TS 32.422 V18.1.0 (2023-12) (3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Telecommunications Management; User and Equipment Tracing; Trace Control and Configuration Management (Release 18))); and measurements used outside the 3GPP network require user consent and may need to be anonymized.

[0124] Challenges brought by modern use cases across 5GC and NG-RAN to UE-level measurement data collection include: the need to collect UE-based measurement information in both NG-RAN and 5GC; the collected data should not be aggregated and / or anonymized to maintain its value for various AI / ML data consumers; measurement definitions cannot be limited to the RAN only (e.g., not all use cases are RAN-centric); a common approach for UE-based measurements needs to be adopted in both NG-RAN and 5GC; 3GPP network and management functions, as well as functions or entities defined by non-3GPP, should have access to UE-based measurements; and UE-based measurements need to be easily accessible (e.g., collected and reported) to any potential consumer.

[0125] Some use cases require collecting UE-level measurement information for certain specific UEs, and some use cases require collecting UE measurements for all potentially measurable UEs from one or more 5GC network functions or NG-RAN nodes. Therefore, the management system needs to provide these capabilities to allow consumers to collect UE-level measurement information for specific UEs or for all potentially UEs from 5GC NFs or NG-RAN nodes.

[0126] The present disclosure provides techniques and technical means for management actions of UE-level measurement jobs by reusing and extending a tracing mechanism (e.g., the tracing mechanism defined in 3GPP TS 32.422). Specifically, embodiments of the present disclosure include performing management actions on UE-level measurement jobs by reusing and extending the tracing mechanism. UE-level measurements can be used to enable AI / ML applications / use cases in 5GS (e.g., as training data, test data, validation data, inference data, etc.).

[0127] Figure 3 An example of a method 300 for management actions of UE-level measurement jobs according to some embodiments of the present disclosure is shown. Method 300 can be executed by a service producer, which can be, for example, a management service (MnS) producer (MnS-P). As shown, method 300 can include operations 310-340.

[0128] At 310, the tracking job creation request received from the service consumer is decoded to create a tracking job for collecting UE-level measurement results from the NF. At 320, in response to the tracking job creation request, a tracking session activation request for activating a tracking session is encoded for transmission to the NF. At 330, the tracking session activation response received from the NF in response to the tracking session activation request is decoded, and the tracking session activation response is used to indicate the activation result of the tracking session. At 340, in response to the tracking session activation response, a tracking job creation response is encoded for transmission to the service consumer, and the tracking job creation response is used to indicate the creation result of the tracking job.

[0129] Figure 4 An example of the interaction between the MnS consumer (MnS-C), MnS-P, and NF according to some embodiments of the present disclosure is shown. As Figure 4 shown, the service producer can be MnS P, and the service consumer can be MnS C. The MnS consumer interacts with the MnS producer for UE-level measurement result collection and reporting. The MnS consumer requests the MnS producer to create a tracking job for collecting UE-level measurement results on the 5GC NF or NG-RAN node, and the tracking job is managed by operations and notifications defined for the general supply management service as the MOI (MOI of the TraceJob IOC) (see clause 11.1.1 of 3GPP TS 28.532 V18.1.0 (2023-12) (3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Management and Coordination; General Management Service (Release 18))). Specifically, the MnS consumer can use CreateMOI, getMOIAttributes, modifyMOIAttributes, deleteMOI to manage the MOI (create, obtain, modify, delete the attributes of the MOI) of the tracking job representing the UE measurement job, and receive corresponding notifications (notifyMOICreation, notifyMOIDeletion, notifyMOIAttributeValueChanges, notifyMOIChanges, notifyEvent).

[0130] In some embodiments, a tracing job may include one or more attributes. For example, a tracing job includes: an indication of the job type for UE-level measurement result collection; a tracing target of the UE to be measured; administrative attributes for UE-level measurement configuration; a Public Land Mobile Network (PLMN) target; a job ID; a tracing reference; an Internet Protocol (IP) address of a tracing collection entity for file-based tracing reports; a Uniform Resource Identifier (URI) of a tracing report consumer for streaming tracing reports; a tracing report format; and so on.

[0131] In some embodiments, the administrative attributes for UE-level measurement configuration may include: UE-level measurement results to be collected; UE-level measurement granularity period; object instances to be measured; root object instances of the objects to be measured; and so on.

[0132] In some embodiments, a tracing session activation request may carry UE-level measurement configuration parameters. In some embodiments, the UE-level measurement configuration parameters may include: a tracing target of the UE to be measured; UE-level measurement results to be collected; UE-level measurement granularity period; a list of NG RAN cells to be measured; a tracing reference; an IP address of a tracing collection entity for file-based tracing reports; a URI of a tracing report consumer for streaming tracing reports; a tracing report format; and so on. In some embodiments, the tracing target may include a UE identifier indicating the UE to be measured or a null value indicating that all UEs are to be measured.

[0133] In some embodiments, a service producer may: decode a tracing job deletion request received from the service consumer to delete a tracing job; in response to the tracing job deletion request, encode a tracing session deactivation request to be transmitted to the NF, the tracing session deactivation request being for deactivating a tracing session; decode a tracing session deactivation response received from the NF in response to the tracing session deactivation request, the tracing session deactivation response being for indicating a deactivation result of the tracing session; and in response to the tracing session deactivation response, encode a tracing job deletion response to be transmitted to the service consumer, the tracing job deletion response being for indicating a deletion result of the tracing job.

[0134] In some embodiments, the NF may include a 5GC NF or an NG-RAN node.

[0135] Figure 5 An example of a method 500 for managing actions for UE-level measurement jobs according to some embodiments of the present disclosure is shown. The method 500 may be performed by an NF (e.g., a 5GC NF or an NG-RAN node). As shown, the method 500 may include operations 510-530.

[0136] At 510, the trace session activation request received from the service producer is decoded to activate a trace session for UE-level measurement jobs. At 520, in response to the trace session activation request, a trace session activation response is encoded for transmission to the service producer, and the trace session activation response is used to indicate the activation result of the trace session. At 530, the trace session is started based on the trace session activation request.

[0137] In some embodiments, the NF may: generate UE-level measurements at a granularity period based on the trace session activation request to start a trace record session under the trace session; and report the results of the UE-level measurements for the trace record session to a Trace Collection Entity (TCE). A trace record session is a sub-session for recording or measuring each configured event under a trace session.

[0138] In some embodiments, the NF may: decode a trace session deactivation request received from the service producer to deactivate the trace session; in response to the trace session deactivation request, encode a trace session deactivation response for transmission to the service producer, and the trace session deactivation response is used to indicate the deactivation result of the trace session; and stop the trace session based on the trace session deactivation request. In some embodiments, the NF may stop the trace record session under the trace session based on the trace session deactivation request.

[0139] Figure 6 An example of a method 600 for management actions of UE-level measurement jobs according to some embodiments of the present disclosure is shown. The method 600 may be performed by a service consumer (e.g., MnS-C). As shown, the method 600 may include operations 610 and 620.

[0140] At 610, a trace job creation request is encoded for transmission to the service producer to create a trace job for collecting UE-level measurement results from the NF. At 620, the trace job creation response received from the service producer in response to the trace job creation request is decoded, and the trace job creation response is used to indicate the creation result of the trace job.

[0141] In some embodiments, the service consumer may: encode a trace job deletion request for transmission to the service producer, and the encoded trace job deletion request is used to delete the trace job; and decode the trace job deletion response received from the service producer in response to the trace job deletion request, and the trace job deletion response is used to indicate the deletion result of the trace job.

[0142] The management actions of UE-level measurement jobs reuse and extend the trace mechanism defined in 3GPP TS 32.422, and the activation mechanisms for 5GC and NG-RAN are described in the following sub-clauses.

[0143] 7.1 Management tracking session activation and deactivation for UL level measurement operations

[0144] 7.1.1 Creation of trace jobs from the management system

[0145] The MnS consumer interacts with the MnS producer for UE level measurement result collection and reporting. The MnS consumer requests the MnS producer to create a trace job for collecting UE level measurement results on a 5GC NF or NG-RAN node. This trace job is managed by operations and notifications defined for the common provisioning management service as the MOI (MOI of TraceJob IOC) (see clause 11.1.1 of 3GPP TS 28.532). Specifically, the MnS consumer can use CreateMOI, getMOIAttributes, modifyMOIAttributes, deleteMOI to manage the MOI (create, obtain, modify, delete the attributes of the MOI) of the trace job representing the UE measurement job, and receive corresponding notifications (notifyMOICreation, notifyMOIDeletion, notifyMOIAttributeValueChanges, notifyMOIChanges, notifyEvent).

[0146] The TraceJob IOC (defined in 3GPP TS 28.622 V18.5.0 (2023-12) (3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Telecommunications Management; Common Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS) (Release 18))) is enhanced to include configuration parameters for UE level measurement.

[0147] 7.1.1.1 Trace Job

[0148] 7.1.1.1.1 Definition

[0149] A TraceJob instance represents the trace control and configuration parameters of a specific trace job (see 3GPP TS 32.421 V18.1.0 (2023-12) (3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Telecommunications Management; User and Equipment Trace; Trace Concepts and Requirements (Release 18)) and TS 32.422). It can be name-contained by SubNetwork, ManagedElement, and ManagedFunction. If the trace activation is signaling-based, it should be name-contained by UDM.

[0150] To activate a trace job, an MnS consumer can create an instance of a trace job object on an MnS producer. An MnS consumer can activate a trace job for another MnS consumer, as it is not required that the values of traceCollectionEntityIPAddress or traceReportingConsumerUri be its own.

[0151] When an MnS consumer wishes to deactivate a trace job, the MnS consumer can delete the corresponding TraceJob instance.

[0152] The attribute traceReference specifies a globally unique ID and identifies a trace session. A trace session can be activated for multiple network elements. traceReference is filled in by the consumer that requests the trace session (e.g., see TS32.422).

[0153] The jobId attribute represents the job identifier of a TraceJob instance. The jobId can be used to correlate multiple TraceJob instances. For example, the same jobId value can be configured for multiple desired TraceJob instances to generate data for a specific network analysis (e.g., RSRP values for M1 and RLF reports).

[0154] The attribute traceReportingFormat defines the method for reporting the generated measurement results. The options can include file-based reporting and stream-based reporting. In file-based reporting, the attribute traceCollectionEntityIPAddress is used to specify the IP address to which the trace records should be transferred, while in stream-based reporting, the attribute traceReportingConsumerUri specifies the streaming target.

[0155] The mandatory attribute traceTarget determines the target object of the TraceJob. Depending on the network element for which the trace session is activated, there can be different types of target objects. The attribute pLMNTarget defines the PLMN in the case of administratively-based activation when the RAN supports multiple PLMNs, for which a session will be selected in the trace session.

[0156] The attribute jobType specifies the type of data to be collected. Only in the case of tracing, the configuration parameters of the attribute traceConfig should be applied. In the cases of Immediate MDT only, Logged MDT only, RLF report only, RCEF report only, and Logged MBSFN MDT, the configuration parameters of the attribute mdtConfig or its subset should be applied. If only UE measurements are performed, the configuration parameters of the attribute ueMeasConfig should be applied. If it is any combination of tracing, Immediate MDT Trace, and UE measurements, the corresponding configuration parameters of the attributes traceConfig, mdtConfig, and ueMeasConfig are applicable.

[0157] The creation and deletion of TraceJob instances by MnS consumers are optional; when not supported, TraceJob instances can be created and deleted by the system or pre-installed.

[0158] 7.1.1.1.2 Attributes

[0159] The TraceJob IOC includes the attributes inherited from the Top IOC (defined in Clause 4.3.29 of TS28.622) and the following attributes. In this document, the Support Qualifier (hereinafter referred to as S) of an attribute can be Mandatory (hereinafter referred to as M), Optional (hereinafter referred to as O), Conditionally Optional (hereinafter referred to as CO), or Conditionally Mandatory (hereinafter referred to as CM). "T" represents true and "F" represents false.

[0160] Attribute Name S Readable Writable Mutable Notifyable jobType M T T F T pLMNTarget CM T T F T traceReportingConsumerUri CM T T F T traceCollectionEntityIPAddress CM T T F T traceReference M T T F T jobId O T T T T traceReportingFormat M T T F T traceTarget M T T F T traceConfig CM T T F T mdtConfig CM T T F T ueMeasConfig CM T T F T nPNTarget CM T T F T

[0161] 7.1.1.1.3 Attribute Constraints

[0162]

[0163] 7.1.1.2 UEMeasConfig< <datatype>>

[0164] 7.1.1.2.1 Definition

[0165] The < <datatype>>Defines the configuration parameters of the IOC TraceJob, which are specifically used for UE-level measurement result collection.

[0166] The attribute ueMeasurements defines the measurements to be generated, and the attribute ueGranularityPeriod defines the granularity period to be applied.

[0167] All of the following object instances, including those that contain instances of named TraceJobs (basic object instances), fall within the scope of measurement result collection and measurement generation. UE-level measurements are generated only on object instances whose object class matches the object class associated with the measurements to be generated.

[0168] The optional attributes objectInstances and rootObjectInstances allow the scope to be restricted. When the attribute objectInstances exists, only the object instances identified by this attribute are within the scope. When the rootObjectInstances attribute exists, the subordinate objects of the root object identified by this attribute are also within the scope. These two attributes can exist simultaneously, which means the total scope is equal to the sum of the two scopes. An object instance can be included within the scope by both the objectInstances and rootObjectInstances attributes. When these two attributes exist simultaneously, the MnS producer does not consider it an error.

[0169] In some embodiments, changes to all other configurable attributes take effect only at the start of the next granularity period. In some other embodiments, changes to all other configurable attributes take effect immediately. The present disclosure does not impose a limitation in this regard.

[0170] 7.1.1.2.2 Attributes

[0171] Attribute Name S Readable Writable Mutable Notifyable ueMeasurements CM T T F T ueMeasGranularityPeriod CM T T F T objectInstances O T T F T rootObjectInstances O T T F T

[0172] 7.1.1.2.3 Attribute Constraints

[0173] Name Definition ueMeasurements (CM S) This attribute appears only if UE-level measurement result collection is supported. ueMeasGranularityPeriod (CM S) This attribute appears only if UE-level measurement result collection is supported.

[0174] 7.1.1.3 Attribute Characteristics

[0175]

[0176]

[0177]

[0178] 7.1.2 5GC Management Activation Mechanism for UE-Level Measurement Jobs

[0179] When a 5GC NF receives a trace session activation for UE-level measurement result collection from the management function, it shall start the trace session. The trace session activation received from the management system contains the following control and configuration parameters for the trace session:

[0180] - Trace target: The measured UE identifier defined in item g) of the UE-level measurement defined for the 5GC NF (see Appendix A in TS28.558, where item g) describes "This element indicates what kind of UE identifier needs to be provided. Such UE identifier can be IMSI, IMEI, SUPI, N4 session ID, or RAN UE ID, etc., depending on the specific measurement") or a null value;

[0181] - Trace reference;

[0182] - Trace report format;

[0183] - Trace collection entity IP address for file-based trace reports or trace report consumer URI for streamed trace reports;

[0184] - UE-level measurement (measurement type defined in item e) of the UE-level measurement specified in TS28.558);

[0185] - UE-level measurement granularity period (see ueMeasGranularityPeriod defined in TS28.622).

[0186] In some embodiments, the 5GC NF shall not forward these trace control and configuration parameters to other nodes. However, in some other embodiments, the 5GC NF may forward these trace control and configuration parameters to other nodes. In some embodiments, the received trace control and configuration parameters shall be saved and used to determine when to start a trace recording session.

[0187] 7.1.3 NG-RAN Management Activation Mechanism for UE-level Measurement Result Collection

[0188] When an NG-RAN node receives a trace session activation for UE-level measurement result collection from the management function, it shall start the trace session. The trace session activation received from the management system contains the following control and configuration parameters for the trace session:

[0189] - Trace target: The measured UE identifier defined in item g) of the UE-level measurement defined for the NG-RAN (see TS28.558) or a null value;

[0190] - Trace reference;

[0191] - Trace report format;

[0192] - The tracking collection entity IP address for file - based trace reports or the trace report consumer URI for streamed trace reports;

[0193] - UE - level measurements (measurement types defined in item e) of UE - level measurements specified in TS28.558);

[0194] - UE - level measurement granularity period (see ueMeasGranularityPeriod defined in TS28.622);

[0195] -(Optional) A list of NG - RAN cells to be measured. If this parameter does not exist, all NG - RAN cells under the NG - RAN node will be measured.

[0196] If the trace target is a null value, the NG - RAN cell traffic tracking function can be used to implement administratively - based trace activation for UE - level measurement result collection.

[0197] When the NG - RAN node receives a trace session activation message for a given or a series of NG - RAN cells from the management system, the NG - RAN node shall initiate a trace session for the given or the series of NG - RAN cells. If there is no list of NG - RAN cells, the NG - RAN node shall initiate a trace session for all cells.

[0198] 7.1.4 5GC Domain Management De - activation Mechanism for UE - level Measurement Jobs

[0199] In 5GC, the administrative de - activation of UE - level measurement jobs is the same as the administrative de - activation mechanism for tracing defined in clause 4.1.3.9 of TS 32.422, except for the trace jobs and trace configuration parameters for UE - level measurement result collection.

[0200] Figure 7 An example of 5GC domain management de - activation for UE - level measurement jobs according to some embodiments of the present disclosure is shown.

[0201] 7.1.5 NG - RAN Management De - activation Mechanism for UE - level Measurement Jobs

[0202] In NG - RAN, the administrative de - activation mechanism of UE - level measurement jobs is the same as the administrative de - activation mechanism for tracing defined in clause 4.1.3.10 of TS 32.422, except for the trace jobs and trace configuration parameters for UE - level measurement result collection.

[0203] Figure 8 An example of NG - RAN management de - activation for UE - level measurement jobs according to some embodiments of the present disclosure is shown.

[0204] 7.2 Trace Record Session Start / Stop Trigger for UE-Level Measurement Operations

[0205] 7.2.1 5GC Domain Start Mechanism for UE-Level Measurement Operations

[0206] In the 5GC NF, when the NF starts generating UE-level measurements in each granularity period according to the trace session activation received from the management system, the trace record session shall be started.

[0207] For each trace record session (i.e., each granularity period), the 5GC generates UE-level measurements.

[0208] If the resources available for recording are insufficient, the 5GC NF may not start the trace record session.

[0209] When starting the trace record session, the 5GC NF shall allocate a trace record session reference for the trace record session.

[0210] When the trace record session ends (i.e., UE-level measurements are generated at the end of the granularity period), the 5GC NF shall send a trace record containing the UE-level measurement results to the TCE according to the UE-level measurement report specified in Clause 7.3.

[0211] 7.2.2 NG-RAN Start Mechanism for UE-Level Measurement Operations

[0212] In the NG-RAN, when the NG-RAN starts generating UE-level measurements in each granularity period according to the trace session activation received from the management system, the trace record session shall be started.

[0213] If the Trace Target is a null value, after activating cell traffic tracing in the (one or more) measured cells of the UE-level measurement operation, the NG-RAN node shall start a trace record session for each measured UE in each granularity period.

[0214] When multiple PLMNs are supported in the RAN, the NG-RAN node shall only select the UE that includes pLMNTarget = selectedPLMN-Identity in the RRCConnectionSetup message when starting to collect UE-level measurement results (see 3GPP TS38.331 V17.6.0 (2023-09) (3rd Generation Partnership Project; Radio Access Network Technical Specification Group; NR; Radio Resource Control (RRC) Protocol Specification (Release 17))). When the trace record session ends (i.e., UE-level measurements are generated at the end of the granularity period), the NG-RAN node sends a trace record containing the UE-level measurement results to the TCE according to the UE-level measurement report specified in Clause 7.3.

[0215] 7.2.3 5GC Domain Stop Mechanism for UE-level Measurement Operations

[0216] In the 5GC NF, when a call / session ends under the subject NF or the UE moves out of that NF, the trace recording session shall be stopped.

[0217] If a management trace session deactivation is received during the trace recording session, the 5GC NF is allowed to complete the ongoing measurement production during the current granule.

[0218] 7.2.4 NG-RAN Stop Mechanism for UE-level Measurement Operations

[0219] The trace recording session in the NG-RAN node shall be stopped when the call / session in the traced cell ends or the call / session is handed over to another cell. If a management-based trace session deactivation is received while there is an ongoing session, the NG-RAN node is allowed to complete the ongoing measurement production during the current granule period.

[0220] 7.3 UE-level Measurement Reporting

[0221] The results of UE-level measurements for each granule period corresponding to each trace recording session are included in the trace record and reported to the TCE. The UE-level measurement reporting mechanism is the same as the trace reporting mechanism specified in Clause 7 of TS 32.422, except that the trace record contains the results of UE-level measurements.

[0222] By using the technical solution of the present disclosure, the management operations of UE-level measurement operations can be implemented by reusing and extending the trace mechanism.

[0223] Figure 9 Network 900 is shown in accordance with various embodiments. Network 900 may operate in a manner compliant with the 3GPP technical specifications of the LTE or 5G / NR systems. However, the example embodiments are not limited thereto, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, and so on.

[0224] Network 900 may include a UE 902, which may include any mobile or non-mobile computing device designed to communicate with the RAN 904 via an air interface. The UE 902 may be communicatively coupled to the RAN 904 via the Uu interface. The UE 902 may be, but is not limited to, a smart phone, a tablet computer, a wearable computing device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, a dashboard, a head-up display device, an on-board diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine-type communication device, an M2M or D2D device, an IoT device, and so on.

[0225] In some embodiments, network 900 may include multiple UEs that are directly coupled to each other via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels, such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, and so on.

[0226] In some embodiments, the UE 902 may also communicate with an AP 906 via an air interface. The AP 906 may manage a WLAN connection that may be used to offload some / all network traffic from the RAN 904. The connection between the UE 902 and the AP 906 may conform to any IEEE 802.11 protocol, where the AP 906 may be a Wi-Fi router. In some embodiments, the UE 902, the RAN 904, and the AP 906 may utilize cellular-WLAN aggregation (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve the UE 902 being configured by the RAN 904 to utilize both cellular radio resources and WLAN resources.

[0227] RAN 904 may include one or more access nodes, e.g., AN 908. AN 908 may terminate the air interface protocol for UE 902 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and L1 protocols. In this way, AN908 may enable data / voice connectivity between CN 920 and UE 902. In some embodiments, AN 908 may be implemented in a discrete device or as one or more software entities running on a server computer, as part of, for example, a virtual network, which may be referred to as CRAN or virtual baseband unit pool. AN 908 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN 908 may be a macro cell base station or a low-power base station for providing a femto cell, pico cell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macro cell.

[0228] In embodiments where RAN 904 includes multiple ANs, they may be coupled to each other via an X2 interface (if RAN 904 is an LTE RAN) or an Xn interface (if RAN 904 is a 5G RAN). The X2 / Xn interface (which may be separated into a control / user plane interface in some embodiments) may allow ANs to convey information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

[0229] The ANs of RAN 904 may each manage one or more cells, cell groups, component carriers, etc., to provide an air interface for network access to UE 902. UE 902 may be connected to multiple cells provided by the same or different ANs of RAN 904 simultaneously. For example, UE 902 and RAN 904 may use carrier aggregation to allow UE 902 to connect to multiple component carriers, each corresponding to a Pcell or Scell. In a dual connectivity scenario, the first AN may be the master node providing the MCG, and the second AN may be the secondary node providing the SCG. The first / second AN may be any combination of eNB, gNB, ng-eNB, etc.

[0230] RAN 904 may provide an air interface via licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, nodes may use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCell / Scell. Before accessing unlicensed spectrum, nodes may perform medium / carrier sensing operations based on, for example, the listen-before-talk (LBT) protocol.

[0231] In a V2X scenario, UE 902 or AN 908 can be or can act as an RSU, which can refer to any traffic infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by a UE can be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU"; an RSU implemented in or by a gNB can be referred to as a "gNB-type RSU"; and so on. In one example, an RSU is a computing device coupled to a roadside radio frequency circuit that provides connectivity support to passing vehicle UEs. The RSU may also include an internal data storage circuit to store intersection map geometry, traffic flow statistics, media, and applications / software to sense and control ongoing vehicle and pedestrian traffic flow. The RSU can provide extremely low-latency communication required for high-speed events such as collision avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU can provide other cellular / WLAN communication services. The components of the RSU can be encapsulated in a weatherproof enclosure suitable for outdoor installation and can include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic flow signal controller or a backhaul network.

[0232] In some embodiments, RAN 904 can be an LTE RAN 910 with an eNB, e.g., eNB 912. The LTE RAN910 can provide an LTE air interface with the following characteristics: an SCS of 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo coding for data and TBCC for control; and so on. The LTE air interface can rely on CSI-RS for CSI acquisition and beam management; rely on PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation; and rely on CRS for cell search and initial acquisition, channel quality measurement, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface can operate in a frequency band below 6 GHz.

[0233] In some embodiments, RAN 904 can be an NG-RAN 914 with a gNB, e.g., gNB 916, or an NG-RAN 914 with an ng-eNB, e.g., ng-eNB 918. The gNB 916 can connect to a 5G-capable UE using a 5G NR interface. The gNB 916 can connect to the 5G core through the NG interface, which can include an N2 interface or an N3 interface. The ng-eNB 918 can also connect to the 5G core through the NG interface but can connect to the UE via the LTE air interface. The gNB 916 and the ng-eNB 918 can be connected to each other through the Xn interface.

[0234] In some embodiments, the NG interface can be divided into two parts. One is the NG user plane (NG-U) interface, which carries traffic data (e.g., the N3 interface) between the nodes of the NG-RAN 914 and the UPF 948. The other is the NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN 914 and the AMF 944 (e.g., the N2 interface).

[0235] The NG-RAN 914 can provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, simplex codes, and Reed-Muller codes for control, and LDPC for data. The 5G-NR air interface can rely on CSI-RS, PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface may not use CRS, but may use PBCH DMRS for PBCH demodulation; use PTRS for phase tracking of PDSCH; and use the tracking reference signal for time tracking. The 5G-NR air interface can operate in the FR1 band including frequencies below 6 GHz or in the FR2 band including the frequency band from 24.25 GHz to 52.6 GHz. The 5G-NR air interface can include an SSB, which is an area of the downlink resource grid including PSS / SSS / PBCH.

[0236] In some embodiments, the 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used for dynamic adjustment of SCS. For example, the UE 902 can be configured with multiple BWPs, where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 902, the transmitted SCS is also changed. Another use case example of BWPs is related to power saving. Specifically, the UE 902 can be configured with multiple BWPs having different amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. The BWP containing a smaller number of PRBs can be used for data transmission with a small traffic load, while allowing power saving at the UE 902 and in some cases at the gNB 916. The BWP containing a larger number of PRBs can be used for scenarios with a higher traffic load.

[0237] RAN 904 is communicatively coupled to CN 920, which includes network elements to provide various functions to support data and telecommunications services for customers / subscribers (e.g., the users of UE 902). The components of CN 920 can be implemented in one physical node or separate physical nodes. In some embodiments, NFV can be utilized to virtualize any or all of the functions provided by the network elements of CN 920 onto physical computing / storage resources in servers, switches, etc. The logical instantiation of CN 920 can be referred to as a network slice, and the logical instantiation of a part of CN 920 can be referred to as a network sub-slice.

[0238] In some embodiments, CN 920 can be an LTE CN 922, which can also be referred to as an EPC. LTE CN 922 can include MME 924, SGW 926, SGSN 928, HSS 930, PGW 932, and PCRF 934, which are coupled to each other through interfaces (or "reference points") as shown in the figure. The functions of the elements of LTE CN 922 can be briefly introduced as follows.

[0239] MME 924 can implement mobility management functions to track the current location of UE 902 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, etc.

[0240] SGW 926 can terminate the S1 interface facing the RAN and route data packets between the RAN and LTE CN 922. SGW 926 can be a local mobility anchor point for inter-RAN node handovers and also provide anchoring for inter-3GPP mobility. Other responsibilities can include lawful interception, charging, and some policy enforcement.

[0241] SGSN 928 can track the location of UE 902 and perform security functions and access control. In addition, SGSN 928 can perform EPC node-to-node signaling for mobility between different RAT networks; select the PDN and S-GW as specified by MME 924; select the MME for handover; etc. The S3 reference point between MME 924 and SGSN 928 can enable user and bearer information exchange for inter-3GPP access network mobility in the idle / active state.

[0242] HSS 930 can include a database for network users, which includes subscription-related information to support the handling of communication sessions by network entities. HSS 930 can provide support for routing / roaming, authentication, authorization, name / address resolution, location compliance, etc. The S6a reference point between HSS 930 and MME 924 can enable the transfer of subscription and authentication data to authenticate / authorize user access to LTE CN 920.

[0243] The PGW 932 can terminate the SGi interface towards the data network (DN) 936, which may include an application / content server 938. The PGW 932 can route data packets between the LTE CN 922 and the data network 936. The PGW 932 can be coupled to the SGW 926 via the S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 932 may also include a node (e.g., PCEF) for policy enforcement and charging data collection. In addition, the SGi reference point between the PGW 932 and the data network 936 can be an operator-external public or private PDN or an operator-internal packet data network, for example, for the configuration of IMS services. The PGW 932 can be coupled to the PCRF 934 via the Gx reference point.

[0244] The PCRF 934 is the policy and charging control element of the LTE CN 922. The PCRF 934 can be communicatively coupled to the application / content server 938 to determine the appropriate QoS and charging parameters for the service flow. The PCRF 932 can configure the associated rules into the PCEF with the appropriate TFT and QCI (via the Gx reference point).

[0245] In some embodiments, the CN 920 can be the 5GC 940. The 5GC 940 may include an AUSF 942, an AMF 944, an SMF 946, a UPF 948, an NSSF 950, a NEF 952, an NRF 954, a PCF 956, a UDM 958, and an AF 960, which are coupled to each other through interfaces (or "reference points") as shown. The functions of the elements of the 5GC 940 can be briefly introduced as follows.

[0246] The AUSF 942 can store the data for the authentication of the UE 902 and handle authentication-related functions. The AUSF 942 can facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 940 through the reference points as shown, the AUSF 942 can also expose a service-based interface of Nausf.

[0247] The AMF 944 may allow other functions of the 5GC 940 to communicate with the UE 902 and the RAN 904, and subscribe to notifications about mobility events for the UE 902. The AMF 944 may be responsible for registration management (e.g., for registering the UE 902), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 944 may provide transport for SM messages between the UE 902 and the SMF 946 and act as a transparent proxy for routing SM messages. The AMF 944 may also provide transport for SMS messages between the UE 902 and the SMSF. The AMF 944 may interact with the AUSF 942 and the UE 902 to perform various security anchoring and context management functions. In addition, the AMF 944 may be an end-point of the RAN CP interface, which may include or may be the N2 reference point between the RAN 904 and the AMF 944; and the AMF 944 may be an end-point of the NAS (N1) signaling and perform NAS encryption and integrity protection. The AMF 944 may also support NAS signaling with the UE 902 via the N3 IWF interface.

[0248] The SMF 946 may be responsible for SM (e.g., session establishment, tunnel management between the UPF 948 and the AN 908); UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuring traffic steering at the UPF 948 to route traffic to the appropriate destination; termination of the interface towards the policy control function; the control part of policy enforcement, charging, and QoS; lawful interception (for SM events and the interface to the LI system); termination of the SM part of NAS messages; downlink data notification; initiating AN-specific SM information sent to the AN 908 via the AMF 944 over N2; and determining the SSC mode of the session. SM may refer to the management of a PDU session, and a PDU session or "session" may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 902 and the data network 936.

[0249] The UPF 948 can act as an anchor point for mobility within and between RATs, an external PDU session point for the interconnection to the data network 936, and a branching point for supporting multi-homed PDU sessions. The UPF 948 can also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of the policy rules, legally intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), perform transport-level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 948 can include an uplink classifier to support routing traffic flows to the data network.

[0250] The NSSF 950 can select a set of network slice instances to serve the UE 902. If needed, the NSSF 950 can also determine the allowed NSSAI and the mapping to the subscribed S-NSSAI. The NSSF 950 can also determine, based on appropriate configuration and possibly by querying the NRF 954, the set of AMFs or a list of candidate AMFs to be used to serve the UE 902. Selecting a set of network slice instances for the UE 902 can be triggered by the AMF 944 to which the UE 902 is registered by interacting with the NSSF 950, which can result in a change of AMF. The NSSF 950 can interact with the AMF 944 via the N22 reference point; and can communicate with another NSSF in the visited network via the N31 reference point (not shown). In addition, the NSSF 950 can expose the Nnssf service-based interface.

[0251] The NEF 952 can securely expose the services and capabilities provided by the 3GPP network functions, internal exposure / re-exposure, to third parties such as AF (e.g., AF 960), edge computing or fog computing systems, etc. In such an embodiment, the NEF 952 can authenticate, authorize or throttle the AF. The NEF 952 can also translate the information exchanged with the AF 960 and the information exchanged with the internal network functions. For example, the NEF 952 can translate between the AF service identifiers and the internal 5GC information. The NEF 952 can also receive information from other NFs based on the exposed capabilities of the other NFs. This information can be stored at the NEF 952 as structured data, or stored at a data storage NF using a standardized interface. The stored information can then be re-exposed by the NEF 952 to other NFs and AFs, or used for other purposes such as resolution. In addition, the NEF 952 can expose the Nnef service-based interface.

[0252] The NRF 954 can support the service discovery function, receive NF discovery requests from NF instances, and provide information on the discovered NF instances to NF instances. The NRF 954 also maintains information on available NF instances and the services they support. As used herein, terms such as "instantiation" can refer to the creation of an instance, and "instance" can refer to a specific occurrence of an object, which can occur, for example, during the execution of program code. In addition, the NRF 954 can expose the Nnrf service-based interface.

[0253] The PCF 956 can provide policy rules to control plane functions to enable them to be enforced, and can also support a unified policy framework to constrain network behavior. The PCF 956 can also implement a front end to access subscription information related to policy decisions in the UDR of the UDM 958. In addition to communicating with functions via reference points as shown in the figure, the PCF 956 can also expose the Npcf service-based interface.

[0254] The UDM 958 can handle subscription-related information to support network entities in handling communication sessions, and can store the subscription data of the UE 902. For example, subscription data can be communicated via the N8 reference point between the UDM 958 and the AMF 944. The UDM 958 can include two parts, an application front end and a UDR. The UDR can store subscription data and policy data for the UDM 958 and the PCF 956, and / or store structured data and application data for exposure by the NEF 952 (including PFDs for application detection, application request information for multiple UEs 902). The Nudr service-based interface can be exposed by the UDR 221 to allow the UDM 958, PCF 956, and NEF 952 to access a specific set of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of relevant data changes in the UDR. The UDM can include a UDM-FE, which is responsible for handling credentials, location management, subscription management, etc. Several different front ends can serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and performs authentication credential processing, user identity handling, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown in the figure, the UDM 958 can also expose the Nudm service-based interface.

[0255] The AF 960 can provide application influence on traffic routing, provide access to the NEF, and interact with the policy framework for policy control.

[0256] In some embodiments, the 5GC 940 may implement edge computing by selecting a carrier / third-party service to be geographically close to the point where the UE 902 attaches to the network. This may reduce latency and load on the network. To provide edge computing implementation, the 5GC 940 may select a UPF 948 close to the UE 902 and perform traffic steering from the UPF 948 to the data network 936 via the N6 interface. This may be based on UE subscription data, UE location, and information provided by the AF 960. In this way, the AF 960 may influence UPF (re)selection and traffic routing. Based on the operator deployment, when the AF 960 is considered a trusted entity, the network operator may allow the AF 960 to directly interact with the relevant NF. Additionally, the AF 960 may expose a Naf service-based interface.

[0257] The data network 936 may represent various network operator services, Internet access, or third-party services, which may be provided by one or more servers, such as including application / content servers 938.

[0258] Figure 10 A wireless network 1000 is schematically illustrated in accordance with various embodiments. The wireless network 1000 may include a UE 1002 that wirelessly communicates with an AN 1004. The UE 1002 and the AN 1004 may be similar to components with similar names described elsewhere herein and are substantially interchangeable with these components.

[0259] The UE 1002 may be communicatively coupled to the AN 1004 via a connection 1006. The connection 1006 is illustrated as an air interface to enable communicative coupling and may conform to a cellular communication protocol, such as the LTE protocol or the 5G NR protocol operating at mmWave or sub-6 GHz frequencies.

[0260] The UE 1002 may include a host platform 1008 coupled to a modem platform 1010. The host platform 1008 may include application processing circuitry 1012, which may be coupled to protocol processing circuitry 1014 of the modem platform 1010. The application processing circuitry 1012 may run various applications for the UE 1002 that source / sink application data. The application processing circuitry 1012 may further implement one or more layer operations to send / receive application data to / from the data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations.

[0261] The protocol processing circuitry 1014 may implement one or more layer operations to facilitate sending or receiving data over the connection 1006. The layer operations implemented by the protocol processing circuitry 1014 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0262] The modem platform 1010 may also include a digital baseband circuit 1016, which may implement one or more layer operations in the network protocol stack that are "below" the layer operations performed by the protocol processing circuit 1014. These operations may include, for example, PHY operations, which may include one or more of the following: HARQ-ACK functions, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding (which may include one or more of space-time, space-frequency, or space coding), reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, blind decoding of control channel signals, and other related functions.

[0263] The modem platform 1010 may also include a transmit circuit 1018, a receive circuit 1020, an RF circuit 1022, and an RF front end (RFFE) 1024, which may include or be connected to one or more antenna panels 1026. Briefly, the transmit circuit 1018 may include a digital-to-analog converter, mixers, intermediate frequency (IF) components, etc.; the receive circuit 1020 may include an analog-to-digital converter, mixers, IF components, etc.; the RF circuit 1022 may include a low-noise amplifier, a power amplifier, power tracking components, etc.; the RFFE 1024 may include filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of the components of the transmit circuit 1018, receive circuit 1020, RF circuit 1022, RFFE 1024, and antenna panel 1026 (collectively referred to as "transmit / receive components") may depend on the details of the particular implementation, e.g., whether the communication is TDM or FDM, at mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit / receive components may be arranged in multiple parallel transmit / receive chains, may be disposed on the same or different chips / modules, etc.

[0264] In some embodiments, the protocol processing circuit 1014 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit / receive components.

[0265] UE reception may be established by and via the antenna panel 1026, RFFE 1024, RF circuit 1022, receive circuit 1020, digital baseband circuit 1016, and protocol processing circuit 1014. In some embodiments, the antenna panel 1026 may receive transmissions from the AN 1004 via receive beamforming signals received by multiple antennas / antenna elements of one or more antenna panels 1026.

[0266] Transmissions from the UE can be established by and through protocol processing circuitry 1014, digital baseband circuitry 1016, transmission circuitry 1018, RF circuitry 1022, RFFE 1024, and antenna panel 1026. In some embodiments, the transmission components of UE 1004 may apply a spatial filter to data to be transmitted to form a transmission beam emitted by the antenna elements of antenna panel 1026.

[0267] Similar to UE 1002, AN 1004 may include a host platform 1028 coupled to a modem platform 1030. The host platform 1028 may include application processing circuitry 1032 coupled to protocol processing circuitry 1034 of the modem platform 1030. The modem platform may also include digital baseband circuitry 1036, transmission circuitry 1038, reception circuitry 1040, RF circuitry 1042, RFFE circuitry 1044, and antenna panel 1046. The components of AN 1004 may be similar to the similarly named components of UE 1002 and may be substantially interchangeable. In addition to performing data transmission / reception as described above, the components of AN 1008 may also perform various logical functions, including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0268] Figure 11 The block diagram shows components that, according to some example embodiments, can read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methods discussed herein. Specifically, Figure 11 shows a graphical representation of hardware resources 1100 that include one or more processors (or processor cores) 1110, one or more memory / storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via a bus 1140 or other interface circuitry. For embodiments that utilize node virtualization (e.g., NFV), a hypervisor 1102 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1100.

[0269] Processor 1110 may include, for example, processor 1112 and processor 1114. Processor 1110 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0270] Memory / storage device 1120 may include a main memory, disk storage, or any suitable combination thereof. Memory / storage device 1120 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage, and the like.

[0271] Communication resources 1130 may include an interconnect or network interface controller, component, or other suitable device to communicate with one or more peripheral devices 1104 or one or more databases 1106 or other network elements via network 1108. For example, communication resources 1130 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, (or low-power ) components, components, and other communication components.

[0272] Instruction 1150 may include software, a program, an application, an applet, an app, or other executable code for causing at least any one of processors 1110 to execute any one or more of the methods discussed herein. Instruction 1150 may reside wholly or partially within at least one of processors 1110 (e.g., within a cache memory of the processor), within memory / storage device 1120, or any suitable combination thereof. Additionally, any portion of Instruction 1150 may be transferred from any combination of peripheral device 1104 or database 1106 to hardware resource 1100. Accordingly, the memory of processors 1110, memory / storage device 1120, peripheral device 1104, and database 1106 are examples of computer-readable and machine-readable media.

[0273] Figure 12 Network 1200 is shown in accordance with various embodiments. Network 1200 may operate in a manner compliant with 3GPP technical specifications or technical reports for 6G systems. In some embodiments, Network 1200 may operate concurrently with Network 900. For example, in some embodiments, Network 1200 may share one or more frequency or bandwidth resources with Network 900. As a specific example, a UE (e.g., UE 1202) may be configured to operate in both Network 1200 and Network 900. Such a configuration may be based on the UE including circuitry configured to communicate with the frequency and bandwidth resources of both Network 900 and Network 1200. Generally, several elements of Network 1200 may share one or more characteristics with elements of Network 900. For the sake of brevity and clarity, these elements may not be repeated in the description of Network 1200.

[0274] Network 1200 may include UE 1202, which may include any mobile or non-mobile computing device designed to communicate with RAN 1208 via an air interface. UE 1202 may be similar to, for example, UE 902. UE 1202 may be, but is not limited to, a smart phone, a tablet computer, a wearable computing device, a desktop computer, a laptop computer, an in-vehicle infotainment device, an in-vehicle entertainment device, a dashboard, a head-up display device, an on-board diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine-type communication device, an M2M or D2D device, an IoT device, and so on.

[0275] Although in Figure 12 Although not specifically shown in the figure, in some embodiments, network 1200 may include multiple UEs that are directly coupled to each other via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels such as, for example but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, and so on. Similarly, although not specifically shown in Figure 12 the figure, UE 1202 may be communicatively coupled to an AP (such as the AP 906 described with reference to Figure 9 ). In addition, although not specifically shown in Figure 12 the figure, in some embodiments, RAN 1208 may include one or more ANs such as the AN 908 described with reference to Figure 9 . The RAN 1208 and / or the ANs of the RAN 1208 may be referred to as a base station (BS), a RAN node, or some other term or name.

[0276] UE 1202 and RAN 1208 may be configured to communicate via an air interface that may be referred to as a sixth-generation (6G) air interface. The 6G air interface may include one or more features such as communication in the terahertz (THz) or sub-terahertz bandwidth, or joint communication and sensing. As used herein, the term "joint communication and sensing" may refer to a system that enables wireless communication and radar-based sensing via various types of multiplexing. As used herein, the THz or sub-THz bandwidth may refer to communication in the frequency range of 80 GHz and above. This frequency range may additionally or alternatively be referred to as the "millimeter wave" or "mmWave" frequency range.

[0277] RAN 1208 may allow communication between UE 1202 and 6G core network (CN) 1210. Specifically, RAN 1208 may facilitate the transmission and reception of data between UE 1202 and 6G CN 1210. 6G CN 1210 may include various functions such as NSSF 950, NEF 952, NRF 954, PCF 956, UDM 958, AF 960, SMF 946, and AUSF 942. As Figure 12 shown, 6G CN 1210 may also include UPF 948 and DN 936.

[0278] In addition, the RAN 1208 may include various additional functions that are additions to or alternatives to the functions of traditional cellular networks (such as 4G or 5G networks). Two such functions may include a Compute Control Function (Comp CF) 1224 and a Compute Service Function (Comp SF) 1236. The Comp CF 1224 and Comp SF 1236 may be parts or functions of the compute service plane. The CompCF 1224 may be a control plane function that provides functions such as management of the Comp SF 1236, generation and management of compute task contexts (e.g., create, read, modify, delete), interaction with the underlying compute infrastructure for compute resource management, and so on. The Comp SF 1236 may be a user plane function that acts as an interface gateway between a compute service user (e.g., UE 1202) and the compute nodes behind the CompSF instance. Some functions of the Comp SF 1236 may include: parsing compute service data received from the user to compute tasks executable by the compute nodes; maintaining a service mesh ingress gateway or a service API gateway; service and billing policy enforcement; performance monitoring and telemetry collection, and so on. In some embodiments, the Comp SF 1236 instance may act as a user plane gateway for a cluster of compute nodes. The Comp CF 1224 instance may control one or more Comp SF 1236 instances.

[0279] Two other such functions may include a Communication Control Function (Comm CF) 1228 and a Communication Service Function (CommSF) 1238, which may be part of the communication service plane. The Comm CF 1228 may be a control plane function for managing the Comm SF1238, creating / configuring / releasing communication sessions, and managing communication session contexts. The CommSF 1238 may be a user plane function for data transmission. The CommCF 1228 and Comm SF 1238 may be regarded as upgrades to the SMF 946 and UPF948, for which reference has been made Figure 9 to the 5G system in. The upgrades provided by the Comm CF 1228 and Comm SF 1238 may enable service-aware transmission. For traditional (e.g., 4G or 5G) data transmission, the SMF 946 and UPF 948 may still be used.

[0280] Two other such functions can include a Data Control Function (Data CF) 1222 and a Data Service Function (Data SF) 1232, which can be part of the data service plane. The Data CF 1222 can be a control plane function and provide functions such as Data SF 1232 management, data service creation / configuration / release, data service context management, etc. The Data SF 1232 can be a user plane function and act as a gateway between data service users (e.g., various functions of UE 1202 and 6G CN 1210) and data service endpoints behind the gateway. Specific functions can include: parsing data service user data and forwarding it to the corresponding data service endpoints, generating charging data, and reporting data service status.

[0281] Another such function can be a Service Orchestration and Chaining Function (SOCF) 1220, which can discover, orchestrate, and chain communication / computation / data services provided by functions in the network. After receiving a service request from a user, the SOCF 1220 can interact with one or more of the Comp CF 1224, Comm CF 1228, and Data CF 1222 to identify Comp SF 1236, Comm SF 1238, and Data SF 1232 instances, configure service resources, and generate a service chain, which may contain multiple Comp SF 1236, Comm SF 1238, and Data SF 1232 instances and their associated computing endpoints. Then, workload processing and data movement can be performed within the generated service chain. The SOCF 1220 can also be responsible for maintaining, updating, and releasing the created service chain.

[0282] Another such function can be a Service Registration Function (SRF) 1214, which can act as a registry for system services provided in the user plane, such as services provided by Comp SF 1236 and service endpoints behind the Data SF 1232 gateway, as well as services provided by UE 1202. The SRF 1214 can be regarded as the counterpart of the NRF 954, which can act as a registry for network functions.

[0283] Other such functions may include an evolved service communication proxy (eSCP) and a service infrastructure control function (SICF) 1226, which may provide service communication infrastructure for both control plane services and user plane services. The eSCP may be related to the service communication proxy (SCP) of 5G and adds user plane service communication proxy capabilities. The eSCP is thus expressed as two parts: eCSP-C 1212 and eSCP-U 1234, for control plane service communication proxy and user plane service communication proxy respectively. The SICF 1226 may control and configure eCSP instances in terms of service traffic routing policies, access rules, load balancing configurations, performance monitoring, and so on.

[0284] Another such function is the AMF 1244. The AMF 1244 may be similar to 944 but has additional functions. Specifically, the AMF 1244 may include potential function re-partitioning, such as moving the message forwarding function from the AMF 1244 to the RAN 1208.

[0285] Another such function is the service orchestration exposure function (SOEF) 1218. The SOEF may be configured to expose service orchestration and chained services to external users (such as applications).

[0286] The UE 1202 may include an additional function called the compute client service function (comp CSF) 1204. The comp CSF 1204 may have both control plane functions and user plane functions and may interact with corresponding network-side functions (such as, SOCF 1220, Comp CF 1224, Comp SF 1236, data CF 1222, and / or data SF 1232) to achieve service discovery, request / response, compute task workload exchange, and so on. The Comp CSF 1204 may also cooperate with network-side functions to decide whether compute tasks should be run on elements of the UE 1202, RAN 1208, and / or 6G CN 1210.

[0287] The UE 1202 and / or the Comp CSF 1204 may include a service mesh proxy 1206. The service mesh proxy 1206 may act as a proxy for service-to-service communication in the user plane. The functions of the service mesh proxy 1206 may include one or more of addressing, security, load balancing, and so on.

[0288] Figure 13 Depicts an example functional framework 1300 for ML and / or RAN intelligence. The functional framework 1300 includes a data collection function 1305 that provides input data for a model training function 1310 and a model inference function 1315. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) may or may not be performed in the data collection function 1305. Examples of input data may include: measurements from UEs, RAN nodes, and / or additional or alternative network entities; feedback from an actor 1320; and / or (one or more) outputs from (one or more) ML models. The input data fed into the model training function 1310 is training data, and the input data fed into the model inference function 1315 is inference data.

[0289] The model training function 1310 is a function that performs ML model training, validation, and testing. As part of the model testing process and / or the model validation process, the model training function 1310 may generate model performance metrics. Examples of model performance metrics will be discussed below. If needed, the model training function 1310 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the training data provided by the data collection function 1305.

[0290] The model training function 1310 performs model deployment / updating, where the model training function 1310 initially deploys a trained, validated, and tested ML model to the model inference function 1315 and / or delivers (one or more) updated models to the model inference function 1315. Examples of model deployment and updating will be discussed below.

[0291] The model inference function 1315 is a function that provides ML model inference outputs (e.g., statistical inference, prediction, decision, probability and / or probability distribution, action, configuration, policy, data analysis, result, optimization, etc.). The model inference function 1315 may provide model performance feedback to the model training function 1310 when applicable. The model performance feedback may include various performance metrics related to generating the inference (e.g., any of the metrics discussed herein). The model performance feedback may be used to monitor the performance of the ML model when applicable. If needed, the model inference function 1315 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the inference data provided by the data collection function 1305.

[0292] The model inference function 1315 generates an inference output, i.e., an inference generated or otherwise produced when the model inference function 1315 operates on an ML model using inference data. The model inference function 1315 provides the inference output to the actuator 1320. The details of the inference output are related to the specific use case and can be based on the specific type of ML model being used.

[0293] The actuator 1320 is a function that receives the inference output from the model inference function 1315 and triggers or otherwise performs corresponding operations based on the inference output. The actuator 1320 can trigger operations on other entities and / or itself. In some examples, the actuator 1320 is a NES function, a mobility optimization function, and / or a load balancing function. Additionally or alternatively, the inference output is related to NES, mobility optimization, and / or load balancing, and the actuator 1320 is one or more RAN nodes that perform various NES operations, mobility optimization operations, and / or load balancing operations based on the inference.

[0294] The actuator 1320 can also provide feedback to the data collection function 1305 for storage. The feedback includes information related to the actions performed by the actuator 1320. The feedback can include any information that may be required, which can be used to obtain training data (and / or test data and / or validation data), inference data, and / or data for monitoring the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0295] Figure 14 An example AI / ML-assisted communication network including communication between an ML function (MLF) 1402 and an MLF 1404 is depicted. In some embodiments, ML models / entities can be used or utilized to facilitate wired and / or over-the-air communication between the MLF 1402 and the MLF 1404. In this embodiment, the operations of the MLF 1402 and the MLF 1404 comply with 3GPP technical specifications and / or technical reports of 5G and / or 6G systems, such as any of the technical reports discussed herein. In some examples, the communication mechanism between the MLF 1402 and the MLF 1404 includes any suitable access technology and / or RAT, such as any of the technologies and / or RATs discussed herein. Additionally, Figure 14 the communication mechanism in Figure 1-13 can be part of and / or operate concurrently with other components, devices, systems, networks, and / or deployments described herein.

[0296] MLFs 1402 and 1404 can correspond to any entity / component discussed in this document. In one example, MLF 1402 corresponds to MnF and / or MnS-P, and MLF 1404 corresponds to a consumer, MnS-C, and vice versa. In this example, the groups of MLFs can be mutually exclusive, or some or all of the MLFs in each group of MLFs can overlap or be shared. In another example, MLF 1402 and / or MLF 1404 are implemented by the corresponding UE (e.g., UE 902, UE 1002, UE 1202). Additionally or alternatively, MLF 1402 and / or MLF 1404 are implemented by the same UE or different UEs. In another example, MLF 1402 and / or MLF 1404 are implemented by the corresponding RAN or the corresponding NAN. Additionally or alternatively, some or all of the components / entities in the individual MLFs 1402, 1404 can be implemented or operated by separate entities / components.

[0297] As Figure 14 shown, MLFs 1402 and 1404 include various AI / ML-related components, functions, elements, or entities, and can be implemented as hardware, software, firmware, and / or some combination thereof. In some examples, one or more AI / ML-related elements are implemented as part of the same hardware (e.g., an integrated circuit, a chip, or a multi-processor chip), software (e.g., a program, a process, an engine, etc.), or firmware as at least one other element, function, element, or entity. The AI / ML-related elements of MLF 1402 can be the same as or similar to the AI / ML-related elements of MLF 1404. For the sake of brevity, various elements will be described from the perspective of MLF 1402, but it can be understood that, unless otherwise explicitly stated, such descriptions apply to the similarly named / numbered elements of MLF 1404.

[0298] The data repository 1415 is responsible for data collection and storage. As an example, the data repository 1415 can collect and store RAN configuration parameters, NF configuration parameters, measurement data, RLM data, key performance indicators (KPIs), SLAs, model performance metrics, knowledge base data, ground truth data, ML model parameters, hyperparameters, and / or other data for model training, updating, and inference. In some examples, the data collection function (not shown) is part of or connected to the data repository 1415. The data collection function is a function that provides input data to the MLTF 1425 and the model inference function 1445. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) may or may not be performed in the data collection function. Examples of input data can include measurement results from UEs, RAN nodes, and / or additional or alternative network entities; feedback from actuators; and / or (one or more) outputs from (one or more) ML models. The input data fed to the MLTF 1425 is training data, and the input data fed to the model inference function 1445 is inference data.

[0299] The collected data is stored in / by the repository 1415, and the stored data can be discovered and extracted from the data repository 1415 by other elements. For example, the inference data selector / filter 1450 can retrieve data from the data repository 1415 and provide the data to the inference engine 1445 to generate / determine an inference. In various examples, the MLF 1402 is configured to discover and request data from the data repository 1415 in the MLF 1404, and / or vice versa. In these examples, the data repository 1415 of the MLF 1402 can be communicatively coupled to the data repository 1415 of the MLF 1404, so that the corresponding data repositories 1415 can share the collected data with each other. Additionally or alternatively, the MLF 1402 and / or the MLF 1404 are configured to discover and request data from one or more external sources and / or data storage systems / devices.

[0300] The training data selector / filter 1420 is configured to generate training, validation, and test data sets for ML training (MLT) (or ML model training). One or more of these data sets can be extracted from or otherwise obtained from the data repository 1415. The data can be selected / filtered according to the specific ML model to be trained. The data can optionally be transformed, augmented, and / or preprocessed (e.g., normalized) before being loaded into the data set. The training data selector / filter 1420 can label the data in the data set for supervised learning; or it can not label the data for unsupervised learning. Then, the generated data set can be fed into the MLT function (MLTF) 1425.

[0301] The MLTF 1425 is responsible for training and updating (e.g., tuning and / or retraining) ML models. A selected model (or set of models) can be trained using a data set (including training, validation, and testing) fed from the training data selection / filter 1420. The MLTF 1425 generates trained and tested ML models that can be used for deployment at any time. The generated trained and tested models can be stored in the model library 1435. Additionally or alternatively, the MLTF 1425 performs ML model training, validation, and testing. As part of the model testing process and / or the model validation process, the MLTF 1425 can generate model performance metrics. Examples of model performance metrics will be discussed below. If needed, the MLTF 1425 is also responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the data collection function and / or the training data provided by the training data selection / filter 1420. The MLTF 1425 performs model deployment / updating, where the MLTF 1425 initially deploys the trained, validated, and tested ML models to the model inference function 1445 and / or delivers the updated model(s) to the model inference function 1445. Examples of model deployment and updating will be discussed below.

[0302] The model library 1435 is responsible for the storage and exposure of ML models (trained and untrained). Various model data can be stored in the model library 1435. For example, the model data can include the trained / updated model(s), model parameters, hyperparameters, and / or model metadata such as model performance metrics, hardware platform / configuration data, model execution parameters / conditions, etc. In some examples, the model data can also include inferences made when running the ML model. The model data can be discovered and requested by other MLF components (e.g., the training data selection / filter 1420 and / or the MLTF 1425). In some examples, the MLF 1402 can discover and request model data from the model library 1435 of the MLF 1404. Additionally or alternatively, the MLF 1404 can discover and / or request model data from the model library 1435 of the MLF 1402. In some examples, the MLF 1404 can configure models, model parameters, hyperparameters, model execution parameters / conditions, and / or other aspects of the ML model in the model library 1435 of the MLF 1402. For representational manageability, the ML model is also referred to as an ML entity in this document, i.e., the two terms ML model and ML entity can be used interchangeably in this document.

[0303] The model management function 1440 is responsible for managing the ML models generated by the MLTF 1425. Such management functions may include: deploying the trained models, monitoring the performance of the ML entities, reporting ML entity verification and / or performance data, etc. When deploying a model, the model management function 1440 may allocate and schedule the hardware and / or software resources for inference based on the received trained and tested model. For the purposes of the present disclosure, the term "inference" refers to the process of using one or more trained ML models to generate statistical inferences, predictions, decisions, probabilities and / or probability distributions, actions, configurations, policies, data analysis, results, optimizations, etc. based on new, unseen data (e.g., "input inference data"). In some examples, the inference process may include feeding the input inference data into an ML model (e.g., the inference engine 1445), performing a forward pass of the input inference data through the architecture / topology of the ML model, where the ML model performs calculations on the data using the parameters it has learned (e.g., weights and biases), and predicting the output. In some examples, the inference process may include data transformation prior to the forward pass, where the input inference data is preprocessed or transformed to match the format required by the ML model. In performance monitoring, based on the model performance KPIs and / or metrics, the model management function 1440 may decide to terminate a running model, initiate model retraining and / or tuning, select another model, etc. In an example, the model management function 1440 of the MLF 1404 may configure the model management policy in the MLF 1402, and vice versa.

[0304] As described below, the inference data selection / filter 1450 is responsible for generating the dataset for model inference at the inference 1445. For example, the inference data may be extracted from the data repository 1415. The inference data selection / filter 1450 may select and / or filter the data according to the deployed ML model. The data may be transformed, augmented, and / or preprocessed in the same or similar manner as the transformation, augmentation, and / or preprocessing of the training data selection / filtering (e.g., as described for the training data selection filter 1420). The generated inference dataset may be fed into the inference engine 1445.

[0305] The inference engine 1445 (also referred to as "model inference function 1445", etc.) is responsible for performing / generating the inferences described herein. The inference engine 1445 consumes the inference data set provided by the inference data selection / filter 1450 and generates an ML model inference output, which includes one or more inferences. For example, an inference may be or include statistical inference, prediction, decision-making, probability and / or probability distribution, action, configuration, policy, data analysis, result, optimization, etc. The (one or more) inferences / (one or more) results may be provided to the performance measurement function 1430. When applicable, the model inference function 1445 may provide model performance feedback to the MLTF 1425 and / or the performance measurement function 1430. The model performance feedback may include various performance metrics related to generating the inferences (e.g., any of the metrics discussed herein). The model performance feedback may be used to monitor the performance of the ML model when applicable. If needed, the model inference function 1445 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting and transformation) based on the inference data provided by the data collection function and / or the inference data selection / filter 1450. The model inference function 1445 generates an inference output, i.e., the inferences generated or otherwise generated when the model inference function 1445 runs the ML model using the inference data (set). The details of the inference output are related to the specific use case and may be based on the specific type of ML model being used.

[0306] In some examples, the model inference function 1445 provides the inference output to an actuator (not shown). An actuator is a function, engine, component, device, system, network, and / or other entity that receives the inference output from the model inference function 1445 and triggers or otherwise performs the corresponding (one or more) actions based on the inference output. The actuator may trigger actions for other entities and / or itself. In some examples, the actuator is a network energy saving (NES) function, a mobility robustness optimization (MRO) function, a load balancing optimization (LBO) function, and / or other self-organizing network (SON) functions, including any of the functions mentioned herein. Additionally or alternatively, the inference output is related to NES, MRO, and / or LBO, and the actuator is one or more RAN nodes that perform various NES, MRO, and / or LBO operations based on the inference. The actuator may also provide feedback to the performance measurement function 1430 and / or the data collection function / data repository 1415 for storage. The actuator feedback includes information related to the actions performed by the actuator. For example, the feedback includes any information that may be needed to obtain training data, test data, and / or validation data; inference data; and / or data for monitoring the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0307] The performance measurement function 1430 is configured to measure model performance metrics (e.g., accuracy, momentum, precision, magnitude, recall / sensitivity, model bias, runtime latency, resource consumption, and / or other suitable metrics / measurements, such as any of the metrics / measurements discussed herein) of a deployed and executing model based on the inference(s) for monitoring purposes. The model performance data can be stored in the data repository 1415 and / or reported according to the verification report mechanism discussed herein.

[0308] The performance metrics that the performance measurement function 1430 can measure and / or predict can be based on the specific AI / ML task and other inputs / parameters of the ML entity. The performance metrics can include model-based metrics and platform-based metrics. Model-based metrics are metrics related to the performance of the model itself and / or metrics that do not consider the underlying hardware platform. Platform-based metrics are related to the performance of the underlying hardware platform when running the ML model.

[0309] Model-based metrics can be based on the specific type of ML model and / or AI / ML domain. For example, regression-related metrics of a regression-based ML model can be predicted. Examples of regression-related metrics include error value, mean error, mean absolute error (MAE), mean reciprocal rank (MRR), mean squared error (MSE), root MSE (RMSE), correlation coefficient (R), coefficient of determination (R2), Golbraikh and Tropsha criteria, and / or other similar regression-related metrics, such as those discussed in the article by Naser et al. (Insights into Performance Fitness and Error Metrics for Machine Learning, arXiv:2006.00887v1 (17 May 2020) ("[Naser]")).

[0310] In another example, correlation-related metrics can be used to predict correlation-related models. Examples of correlation-related metrics include accuracy, precision (also known as positive predictive value (PPV)), mean average precision (mAP), negative predictive value (NPV), recall (also known as true positive rate (TPR) or sensitivity), specificity (also known as true negative rate (TNR) or selectivity), false positive rate, false negative rate, F-score (e.g., F1-score, F2-score, Fβ-score, etc.), Matthews correlation coefficient (MCC), significance, receiver operating characteristic (ROC), area under the ROC curve (AUC), distance score, and / or other similar correlation-related metrics, such as those discussed in [Naser].

[0311] Additional or alternative model-based metrics can also be predicted, such as cumulative gain (CG), discounted CG (DCG), normalized DCG (NDCG), signal-to-noise ratio (SNR), peak signal-to-noise ratio (PSNR), structural similarity (SSIM), intersection over union (IoU), perplexity, bilingual evaluation understudy (BLEU) score, inception score, Wasserstein metric, Fréchet inception distance (FID), string metric, edit distance, Levenshtein distance, Damerau–Levenshtein distance, number of evaluation instances (e.g., iterations, epochs, or events), learning rate (e.g., the rate at which an algorithm reaches (converges to) optimal weights), learning rate decay (or weight decay), number and / or type of computations, multiply and accumulates (MAC) number and / or type, multiply adds (MAdds) operation number and / or type, and / or other similar performance metrics related to the performance of an ML model.

[0312] Examples of platform-based metrics include latency, response time, throughput (e.g., the rate at which a processor or platform / system processes work), availability and / or reliability, power consumption (e.g., performance per watt and / or similar metrics), number of transistors, execution time (e.g., the amount of time to obtain an inference and / or similar metrics), memory footprint, memory utilization, processor utilization, processor time, number of computations, instructions per second (IPS), floating point operations per second (FLOPS), and / or other similar performance metrics related to the performance of an ML model and / or the underlying hardware platform used to run the ML model.

[0313] Additionally or alternatively, proxy metrics (e.g., metrics or attributes that serve as a stand-in or substitute for another metric or attribute) can be used to predict the performance of an ML model. For any of the above performance metrics, any suitable data collection and / or measurement mechanism can be used to predict and / or measure the total, average, and / or other distributions of such metrics.

[0314] The following paragraphs describe examples of various embodiments.

[0315] Example 1 includes a device, comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: decode a tracking job creation request received from a service consumer via the interface circuit to create a tracking job for collecting user equipment (UE) level measurement results from a network function (NF); in response to the tracking job creation request, encode a tracking session activation request for activating a tracking session to be transmitted to the NF; decode a tracking session activation response received from the NF in response to the tracking session activation request, the tracking session activation response being used to indicate an activation result of the tracking session; and in response to the tracking session activation response, encode a tracking job creation response to be transmitted to the service consumer via the interface circuit, the tracking job creation response being used to indicate a creation result of the tracking job.

[0316] Example 2 includes the device according to Example 1, wherein the tracking job includes: a job type indicating that the tracking job is for UE level measurement result collection; a tracking target indicating the UE to be measured; administrative attributes for UE level measurement configuration; a public land mobile network (PLMN) target; a job ID; a tracking reference; an Internet protocol (IP) address of a tracking collection entity for file-based tracking reports; a uniform resource identifier (URI) of a tracking report consumer for streaming tracking reports; or a tracking report format.

[0317] Example 3 includes the device according to Example 1 or 2, wherein the administrative attributes for UE level measurement configuration include: UE level measurement results to be collected; a UE level measurement granularity period; an object instance to be measured; or a root object instance of the object to be measured.

[0318] Example 4 includes the device according to any one of Examples 1 to 3, wherein the tracking session activation request carries UE level measurement configuration parameters.

[0319] Example 5 includes the device according to any one of Examples 1 to 4, wherein the UE level measurement configuration parameters include: a tracking target indicating the UE to be measured; UE level measurement results to be collected; a UE level measurement granularity period; a list of next generation (NG) radio access network (RAN) cells to be measured; a tracking reference; an Internet protocol (IP) address of a tracking collection entity for file-based tracking reports; a uniform resource identifier (URI) of a tracking report consumer for streaming tracking reports; or a tracking report format.

[0320] Example 6 includes the device according to any one of Examples 1 to 5, wherein the tracking target includes: a UE identifier indicating the UE to be measured or a null value indicating that all UEs are to be measured.

[0321] Example 7 includes the apparatus according to any one of Examples 1 to 6, wherein the processor circuit is further configured to: decode a trace job deletion request received from the service consumer via the interface circuit to delete the trace job; in response to the trace job deletion request, encode a trace session deactivation request for transmission to the NF, the trace session deactivation request being used to deactivate the trace session; decode a trace session deactivation response received from the NF in response to the trace session deactivation request, the trace session deactivation response being used to indicate a deactivation result of the trace session; and in response to the trace session deactivation response, encode a trace job deletion response for transmission to the service consumer via the interface circuit, the trace job deletion response being used to indicate a deletion result of the trace job.

[0322] Example 8 includes the apparatus according to any one of Examples 1 to 7, wherein the NF includes a fifth generation (5G) core network (5GC) NF or a next generation (NG) radio access network (RAN) node.

[0323] Example 9 includes the apparatus according to any one of Examples 1 to 8, wherein the service consumer includes a management service consumer (MnS-C).

[0324] Example 10 includes the apparatus according to any one of Examples 1 to 9, wherein the apparatus is applicable to a service producer.

[0325] Example 11 includes the apparatus according to any one of Examples 1 to 10, wherein the service producer includes a management service producer (MnS-P).

[0326] Example 12 includes an apparatus, comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: decode a trace session activation request received from a service producer via the interface circuit to activate a trace session for a user equipment (UE) level measurement job; in response to the trace session activation request, encode a trace session activation response for transmission to the service producer via the interface circuit, the trace session activation response being used to indicate an activation result of the trace session; and start the trace session based on the trace session activation request.

[0327] Example 13 includes the apparatus according to Example 12, wherein the trace session activation request carries UE level measurement configuration parameters.

[0328] Example 14 includes the apparatus according to Example 12 or 13, wherein the UE-level measurement configuration parameters include: a tracking target indicating the UE to be measured; UE-level measurement results to be collected; a UE-level measurement granularity period; a list of next-generation (NG) radio access network (RAN) cells to be measured; a tracking reference; an Internet Protocol (IP) address of a trace collection entity for file-based trace reports; a Uniform Resource Identifier (URI) of a trace report consumer for streaming trace reports; or a trace report format.

[0329] Example 15 includes the apparatus according to any one of Examples 12 to 14, wherein the tracking target includes: a UE identifier indicating the UE to be measured or a null value indicating that all UEs are to be measured.

[0330] Example 16 includes the apparatus according to any one of Examples 12 to 15, wherein the processor circuit is further configured to: generate UE-level measurements at a granularity period based on the trace session activation request to initiate a trace recording session under the trace session; and report the results of the UE-level measurements for the trace recording session to a trace collection entity (TCE).

[0331] Example 17 includes the apparatus according to any one of Examples 12 to 16, wherein the results of the UE-level measurements are reported via file-based reports or stream-based reports.

[0332] Example 18 includes the apparatus according to any one of Examples 12 to 17, wherein the processor circuit is further configured to: decode a trace session deactivation request received from the service producer via the interface circuit to deactivate the trace session; in response to the trace session deactivation request, encode a trace session deactivation response for transmission to the service producer via the interface circuit, the trace session deactivation response being used to indicate the result of the deactivation of the trace session; and stop the trace session based on the trace session deactivation request.

[0333] Example 19 includes the apparatus according to any one of Examples 12 to 18, wherein the processor circuit is further configured to: stop the trace recording session under the trace session based on the trace session deactivation request.

[0334] Example 20 includes the apparatus according to any one of Examples 12 to 19, wherein the service producer includes a management service producer (MnS-P).

[0335] Example 21 includes the apparatus according to any one of Examples 12 to 20, wherein the apparatus is applicable to a network function (NF).

[0336] Example 22 includes the apparatus according to any one of Examples 12 to 21, wherein the NF includes a fifth generation (5G) core network (5GC) NF or a next generation (NG) radio access network (RAN) node.

[0337] Example 23 includes an apparatus, comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: encode a trace job creation request for transmission via the interface circuit to a service producer, the trace job creation request being for creating a trace job for collecting user equipment (UE) level measurement results from a network function (NF); and decode a trace job creation response received via the interface circuit from the service producer in response to the trace job creation request, the trace job creation response being for indicating a creation result of the trace job.

[0338] Example 24 includes the apparatus according to Example 23, wherein the trace job includes: a job type indicating that the trace job is for UE level measurement result collection; a trace target indicating the UE to be measured; administrative attributes for UE level measurement configuration; a public land mobile network (PLMN) target; a job ID; a trace reference; an Internet protocol (IP) address of a trace collection entity for file-based trace reports; a uniform resource identifier (URI) of a trace report consumer for streaming trace reports; or a trace report format.

[0339] Example 25 includes the apparatus according to Example 23 or 24, wherein the administrative attributes for UE level measurement configuration include: UE level measurement results to be collected; a UE level measurement granularity period; an object instance to be measured; or a root object instance of the object to be measured.

[0340] Example 26 includes the apparatus according to any one of Examples 23 to 25, wherein the processor circuit is further configured to: encode a trace job deletion request for transmission via the interface circuit to the service producer to delete the trace job; and decode a trace job deletion response received via the interface circuit from the service producer in response to the trace job deletion request, the trace job deletion response being for indicating a deletion result of the trace job.

[0341] Example 27 includes the apparatus according to any one of Examples 23 to 26, wherein the NF includes a fifth generation (5G) core network (5GC) NF or a next generation (NG) radio access network (RAN) node.

[0342] Example 28 includes the apparatus according to any one of Examples 23 to 27, wherein the service producer includes a management service producer (MnS-P).

[0343] Example 29 includes the apparatus according to any one of Examples 23 to 28, wherein the apparatus is applicable to serving a consumer.

[0344] Example 30 includes the apparatus according to any one of Examples 23 to 29, wherein the consumer includes a Managed Service Consumer (MnS-C).

[0345] Example 31 includes a method, comprising: decoding a trace job creation request received from a consumer to create a trace job for collecting user equipment (UE) level measurement results from a network function (NF); in response to the trace job creation request, encoding a trace session activation request for activating a trace session to be transmitted to the NF; decoding a trace session activation response received from the NF in response to the trace session activation request, the trace session activation response being for indicating an activation result of the trace session; and in response to the trace session activation response, encoding a trace job creation response to be transmitted to the consumer, the trace job creation response being for indicating a creation result of the trace job.

[0346] Example 32 includes the method according to Example 31, wherein the trace job includes: a job type indicating that the trace job is for UE level measurement result collection; a trace target indicating the UE to be measured; administrative attributes for UE level measurement configuration; a Public Land Mobile Network (PLMN) target; a job ID; a trace reference; an Internet Protocol (IP) address of a trace collection entity for file-based trace reports; a Uniform Resource Identifier (URI) of a trace report consumer for streaming trace reports; or a trace report format.

[0347] Example 33 includes the method according to Example 31 or 32, wherein the administrative attributes for UE level measurement configuration include: UE level measurement results to be collected; a UE level measurement granularity period; an object instance to be measured; or a root object instance of the object to be measured.

[0348] Example 34 includes the method according to any one of Examples 31 to 33, wherein the trace session activation request carries UE level measurement configuration parameters.

[0349] Example 35 includes the method according to any one of Examples 31 to 34, wherein the UE-level measurement configuration parameters include: a tracking target indicating the UE to be measured; UE-level measurement results to be collected; a UE-level measurement granularity period; a list of next generation (NG) radio access network (RAN) cells to be measured; a tracking reference; an Internet Protocol (IP) address of a trace collection entity for file-based trace reports; a Uniform Resource Identifier (URI) of a trace report consumer for streaming trace reports; or a trace report format.

[0350] Example 36 includes the method according to any one of Examples 31 to 35, wherein the tracking target includes: a UE identifier indicating the UE to be measured or a null value indicating that all UEs are to be measured.

[0351] Example 37 includes the method according to any one of Examples 31 to 36, further comprising: decoding a trace job deletion request received from the service consumer to delete the trace job; in response to the trace job deletion request, encoding a trace session deactivation request for transmission to the NF, the trace session deactivation request being for deactivating the trace session; decoding a trace session deactivation response received from the NF in response to the trace session deactivation request, the trace session deactivation response being for indicating a deactivation result of the trace session; and in response to the trace session deactivation response, encoding a trace job deletion response for transmission to the service consumer, the trace job deletion response being for indicating a deletion result of the trace job.

[0352] Example 38 includes the method according to any one of Examples 31 to 37, wherein the NF includes a fifth generation (5G) core network (5GC) NF or a next generation (NG) radio access network (RAN) node.

[0353] Example 39 includes the method according to any one of Examples 31 to 38, wherein the service consumer includes a management service consumer (MnS-C).

[0354] Example 40 includes the method according to any one of Examples 31 to 39, wherein the method is applicable to a service producer.

[0355] Example 41 includes the method according to any one of Examples 31 to 40, wherein the service producer includes a management service producer (MnS-P).

[0356] Example 42 includes a method comprising: decoding a tracking session activation request received from a service producer to activate a tracking session for a user equipment (UE)-level measurement job; in response to the tracking session activation request, encoding a tracking session activation response for transmission to the service producer, the tracking session activation response being for indicating an activation result of the tracking session; and starting the tracking session based on the tracking session activation request.

[0357] Example 43 includes the method of Example 42, wherein the tracking session activation request carries UE-level measurement configuration parameters.

[0358] Example 44 includes the method of Example 42 or 43, wherein the UE-level measurement configuration parameters include: a tracking target indicating the UE to be measured; UE-level measurement results to be collected; a UE-level measurement granularity period; a list of next generation (NG) radio access network (RAN) cells to be measured; a tracking reference; an Internet protocol (IP) address of a tracking collection entity for file-based tracking reports; a uniform resource identifier (URI) of a tracking report consumer for streaming tracking reports; or a tracking report format.

[0359] Example 45 includes the method of any one of Examples 42 to 44, wherein the tracking target includes: a UE identifier indicating the UE to be measured or a null value indicating that all UEs are to be measured.

[0360] Example 46 includes the method of any one of Examples 42 to 45, further comprising: generating UE-level measurements at a granularity period based on the tracking session activation request to start a tracking record session under the tracking session; and reporting results of the UE-level measurements for the tracking record session to a tracking collection entity (TCE).

[0361] Example 47 includes the method of any one of Examples 42 to 46, wherein the results of the UE-level measurements are reported via file-based reports or stream-based reports.

[0362] Example 48 includes the method of any one of Examples 42 to 47, further comprising: decoding a tracking session deactivation request received from the service producer to deactivate the tracking session; in response to the tracking session deactivation request, encoding a tracking session deactivation response for transmission to the service producer, the tracking session deactivation response being for indicating a deactivation result of the tracking session; and stopping the tracking session based on the tracking session deactivation request.

[0363] Example 49 includes the method of any one of Examples 42 to 48, further comprising: stopping a tracking record session under the tracking session based on the tracking session deactivation request.

[0364] Example 50 includes the method described in any one of Examples 42 to 49, wherein the service producer includes a management service producer (MnS-P).

[0365] Example 51 includes the method described in any one of Examples 42 to 50, wherein the method is applicable to a network function (NF).

[0366] Example 52 includes the method described in any one of Examples 42 to 51, wherein the NF includes a fifth-generation (5G) core network (5GC) NF or a next-generation (NG) radio access network (RAN) node.

[0367] Example 53 includes a method, comprising: encoding a trace job creation request for transmission to a service producer, the trace job creation request being for creating a trace job for collecting user equipment (UE)-level measurement results from a network function (NF); and decoding a trace job creation response received from the service producer in response to the trace job creation request, the trace job creation response being for indicating a creation result of the trace job.

[0368] Example 54 includes the method described in Example 53, wherein the trace job includes: a job type indicating that the trace job is for UE-level measurement result collection; a trace target indicating the UE to be measured; administrative attributes for UE-level measurement configuration; a public land mobile network (PLMN) target; a job ID; a trace reference; an Internet protocol (IP) address of a trace collection entity for file-based trace reports; a uniform resource identifier (URI) of a trace report consumer for streaming trace reports; or a trace report format.

[0369] Example 55 includes the method described in Example 53 or 54, wherein the administrative attributes for UE-level measurement configuration include: UE-level measurement results to be collected; a UE-level measurement granularity period; an object instance to be measured; or a root object instance of the object to be measured.

[0370] Example 56 includes the method described in any one of Examples 53 to 55, further comprising: encoding a trace job deletion request for transmission to the service producer to delete the trace job; and decoding a trace job deletion response received from the service producer in response to the trace job deletion request, the trace job deletion response being for indicating a deletion result of the trace job.

[0371] Example 57 includes the method described in any one of Examples 53 to 56, wherein the NF includes a fifth-generation (5G) core network (5GC) NF or a next-generation (NG) radio access network (RAN) node.

[0372] Example 58 includes the method according to any one of Examples 53 to 57, wherein the service producer includes a management service producer (MnS-P).

[0373] Example 59 includes the method according to any one of Examples 53 to 58, wherein the method is applicable to a service consumer.

[0374] Example 60 includes the method according to any one of Examples 53 to 59, wherein the service consumer includes a management service consumer (MnS-C).

[0375] Example 61 includes an apparatus, comprising: a component for decoding a tracking job creation request received from a service consumer to create a tracking job for collecting user equipment (UE) level measurement results from a network function (NF); a component for encoding a tracking session activation request for activating a tracking session in response to the tracking job creation request to be transmitted to the NF; a component for decoding a tracking session activation response received from the NF in response to the tracking session activation request, the tracking session activation response being used to indicate an activation result of the tracking session; and a component for encoding a tracking job creation response in response to the tracking session activation response to be transmitted to the service consumer, the tracking job creation response being used to indicate a creation result of the tracking job.

[0376] Example 62 includes the apparatus according to Example 61, wherein the tracking job includes: a job type indicating that the tracking job is for UE level measurement result collection; a tracking target indicating the UE to be measured; management attributes for UE level measurement configuration; a public land mobile network (PLMN) target; a job ID; a tracking reference; an Internet protocol (IP) address of a tracking collection entity for file-based tracking reports; a uniform resource identifier (URI) of a tracking report consumer for streaming tracking reports; or a tracking report format.

[0377] Example 63 includes the apparatus according to Example 61 or 62, wherein the management attributes for UE level measurement configuration include: UE level measurement results to be collected; a UE level measurement granularity period; an object instance to be measured; or a root object instance of the object to be measured.

[0378] Example 64 includes the apparatus according to any one of Examples 61 to 63, wherein the tracking session activation request carries UE level measurement configuration parameters.

[0379] Example 65 includes the apparatus according to any one of Examples 61 to 64, wherein the UE-level measurement configuration parameters include: a tracking target indicating the UE to be measured; UE-level measurement results to be collected; a UE-level measurement granularity period; a list of next-generation (NG) radio access network (RAN) cells to be measured; a tracking reference; an Internet Protocol (IP) address of a trace collection entity for file-based trace reports; a Uniform Resource Identifier (URI) of a trace report consumer for streaming trace reports; or a trace report format.

[0380] Example 66 includes the apparatus according to any one of Examples 61 to 65, wherein the tracking target includes: a UE identifier indicating the UE to be measured or a null value indicating that all UEs are to be measured.

[0381] Example 67 includes the apparatus according to any one of Examples 61 to 66, further comprising: a component for decoding a trace job deletion request received from the service consumer to delete the trace job; a component for encoding a trace session deactivation request in response to the trace job deletion request for transmission to the NF, the trace session deactivation request being for deactivating the trace session; a component for decoding a trace session deactivation response received from the NF in response to the trace session deactivation request, the trace session deactivation response being for indicating a deactivation result of the trace session; and a component for encoding a trace job deletion response in response to the trace session deactivation response for transmission to the service consumer, the trace job deletion response being for indicating a deletion result of the trace job.

[0382] Example 68 includes the apparatus according to any one of Examples 61 to 67, wherein the NF includes a fifth-generation (5G) core network (5GC) NF or a next-generation (NG) radio access network (RAN) node.

[0383] Example 69 includes the apparatus according to any one of Examples 61 to 68, wherein the service consumer includes a management service consumer (MnS-C).

[0384] Example 70 includes the apparatus according to any one of Examples 61 to 69, wherein the apparatus is applicable to a service producer.

[0385] Example 71 includes the apparatus according to any one of Examples 61 to 70, wherein the service producer includes a management service producer (MnS-P).

[0386] Example 72 includes an apparatus, comprising: a component for decoding a tracking session activation request received from a service producer to activate a tracking session for a user equipment (UE) level measurement job; a component for encoding a tracking session activation response for transmission to the service producer in response to the tracking session activation request, the tracking session activation response being for indicating an activation result of the tracking session; and a component for starting the tracking session based on the tracking session activation request.

[0387] Example 73 includes the apparatus according to Example 72, wherein the tracking session activation request carries UE level measurement configuration parameters.

[0388] Example 74 includes the apparatus according to Example 72 or 73, wherein the UE level measurement configuration parameters include: a tracking target indicating the UE to be measured; UE level measurement results to be collected; a UE level measurement granularity period; a list of next generation (NG) radio access network (RAN) cells to be measured; a tracking reference; an Internet protocol (IP) address of a tracking collection entity for file-based tracking reports; a uniform resource identifier (URI) of a tracking report consumer for streaming tracking reports; or a tracking report format.

[0389] Example 75 includes the apparatus according to any one of Examples 72 to 74, wherein the tracking target includes: a UE identifier indicating the UE to be measured or a null value indicating that all UEs are to be measured.

[0390] Example 76 includes the apparatus according to any one of Examples 72 to 75, further comprising: a component for generating UE level measurements at a granularity period based on the tracking session activation request to start a tracking record session under the tracking session; and a component for reporting results of the UE level measurements for the tracking record session to a tracking collection entity (TCE).

[0391] Example 77 includes the apparatus according to any one of Examples 72 to 76, wherein the results of the UE level measurements are reported via a file-based report or a stream-based report.

[0392] Example 78 includes the apparatus according to any one of Examples 72 to 77, further comprising: a component for decoding a tracking session deactivation request received from the service producer to deactivate the tracking session; a component for encoding a tracking session deactivation response for transmission to the service producer in response to the tracking session deactivation request, the tracking session deactivation response being for indicating a deactivation result of the tracking session; and a component for stopping the tracking session based on the tracking session deactivation request.

[0393] Example 79 includes the apparatus according to any one of Examples 72 to 78, and further includes: a component for stopping a trace recording session under the trace session based on the trace session deactivation request.

[0394] Example 80 includes the apparatus according to any one of Examples 72 to 79, wherein the service producer includes a Managed Service Producer (MnS-P).

[0395] Example 81 includes the apparatus according to any one of Examples 72 to 80, wherein the apparatus is applicable to a Network Function (NF).

[0396] Example 82 includes the apparatus according to any one of Examples 72 to 81, wherein the NF includes a 5th Generation (5G) Core Network (5GC) NF or a Next Generation (NG) Radio Access Network (RAN) node.

[0397] Example 83 includes an apparatus, including: a component for encoding a trace job creation request for transmission to a service producer, the trace job creation request being for creating a trace job for collecting user equipment (UE) level measurement results from a network function (NF); and a component for decoding a trace job creation response received from the service producer in response to the trace job creation request, the trace job creation response being for indicating a creation result of the trace job.

[0398] Example 84 includes the apparatus according to Example 83, wherein the trace job includes: a job type indicating that the trace job is for UE level measurement result collection; a trace target indicating the UE to be measured; administrative attributes for UE level measurement configuration; a Public Land Mobile Network (PLMN) target; a job ID; a trace reference; an Internet Protocol (IP) address of a trace collection entity for file-based trace reports; a Uniform Resource Identifier (URI) of a trace report consumer for streaming trace reports; or a trace report format.

[0399] Example 85 includes the apparatus according to Example 83 or 84, wherein the administrative attributes for UE level measurement configuration include: UE level measurement results to be collected; a UE level measurement granularity period; an object instance to be measured; or a root object instance of the object to be measured.

[0400] Example 86 includes the apparatus according to any one of Examples 83 to 85, and further includes: a component for encoding a trace job deletion request for transmission to the service producer to delete the trace job; and a component for decoding a trace job deletion response received from the service producer in response to the trace job deletion request, the trace job deletion response being for indicating a deletion result of the trace job.

[0401] Example 87 includes the apparatus according to any one of Examples 83 to 86, wherein the NF includes a fifth generation (5G) core network (5GC) NF or a next generation (NG) radio access network (RAN) node.

[0402] Example 88 includes the apparatus according to any one of Examples 83 to 87, wherein the service producer includes a managed service producer (MnS-P).

[0403] Example 89 includes the apparatus according to any one of Examples 83 to 88, wherein the apparatus is applicable to a service consumer.

[0404] Example 90 includes the apparatus according to any one of Examples 83 to 89, wherein the service consumer includes a managed service consumer (MnS-C).

[0405] Example 91 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processing circuit, cause the processing circuit to perform the method according to any one of Examples 31 to 41.

[0406] Example 92 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processing circuit, cause the processing circuit to perform the method according to any one of Examples 42 to 52.

[0407] Example 93 includes a computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processing circuit, cause the processing circuit to perform the method according to any one of Examples 53 to 60.

[0408] Although some embodiments have been illustrated and described herein for purposes of description, various alternative and / or equivalent embodiments or implementations planned for the same purpose may replace the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Thus, it is readily understood that the embodiments described herein are limited only by the appended claims and their equivalent scope.< / datatype> < / datatype>

Claims

1. A device, comprising: An interface circuit; And A processor circuit, the processor circuit being coupled to the interface circuit, Wherein, the processor circuit is configured to: Decode a tracking job creation request received from a service consumer via the interface circuit to create a tracking job for collecting user equipment (UE) level measurement results from a network function (NF); In response to the tracking job creation request, encode a tracking session activation request for activating a tracking session to be transmitted to the NF; Decode a tracking session activation response received from the NF in response to the tracking session activation request, the tracking session activation response being used to indicate the activation result of the tracking session; and In response to the tracking session activation response, encode a tracking job creation response to be transmitted to the service consumer via the interface circuit, the tracking job creation response being used to indicate the creation result of the tracking job.

2. The device according to claim 1, wherein The tracking job includes: A job type indicating that the tracking job is for UE level measurement result collection; A tracking target indicating the UE to be measured; Administrative attributes for UE level measurement configuration; A public land mobile network (PLMN) target; A job ID; A tracking reference; The Internet Protocol (IP) address of a tracking collection entity for file-based tracking reports; The Uniform Resource Identifier (URI) of a tracking report consumer for streaming tracking reports; or A tracking report format.

3. The device according to claim 2, wherein, The administrative attributes for UE level measurement configuration include: UE level measurement results to be collected; The UE level measurement granularity period; The object instance to be measured; or The root object instance of the object to be measured.

4. The device according to claim 1, wherein The tracking session activation request carries UE level measurement configuration parameters.

5. The device according to claim 4, wherein The UE level measurement configuration parameters include: A tracking target indicating the UE to be measured; UE level measurement results to be collected; The UE level measurement granularity period; A list of next generation (NG) radio access network (RAN) cells to be measured; A tracking reference; The Internet Protocol (IP) address of a tracking collection entity for file-based tracking reports; The Uniform Resource Identifier (URI) of a tracking report consumer for streaming tracking reports; or A tracking report format.

6. The apparatus according to claim 5, wherein, The tracking target includes: a UE identifier indicating the UE to be measured; or a null value indicating that all UEs are to be measured.

7. The device according to claim 1, wherein, The processor circuit is further configured to: Decode a tracking job deletion request received from the service consumer via the interface circuit to delete the tracking job; In response to the tracking job deletion request, encode a tracking session deactivation request to be transmitted to the NF, the tracking session deactivation request being used to deactivate the tracking session; Decode a tracking session deactivation response received from the NF in response to the tracking session deactivation request, the tracking session deactivation response being used to indicate the deactivation result of the tracking session; And In response to the tracking session deactivation response, encode a tracking job deletion response to be transmitted to the service consumer via the interface circuit, the tracking job deletion response being used to indicate the deletion result of the tracking job.

8. The apparatus according to claim 1, wherein The NF includes a 5th Generation (5G) Core Network (5GC) NF or a Next Generation (NG) Radio Access Network (RAN) node.

9. The device according to claim 1, wherein The service consumer includes a Managed Service Consumer (MnS-C).

10. The device according to any one of claims 1 to 9, wherein The apparatus is applicable to a service producer.

11. The device according to claim 10, wherein, The service producer includes a Managed Service Producer (MnS-P).

12. An apparatus, comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: decode a tracking session activation request received from a service producer via the interface circuit to activate a tracking session for a User Equipment (UE) level measurement operation; in response to the tracking session activation request, encode a tracking session activation response to be transmitted to the service producer via the interface circuit, the tracking session activation response being for indicating the activation result of the tracking session; and initiate the tracking session based on the tracking session activation request.

13. The device according to claim 12, wherein The tracking session activation request carries UE level measurement configuration parameters.

14. The apparatus according to claim 13, wherein, The UE level measurement configuration parameters include: a tracking target indicating the UE to be measured; the UE level measurement results to be collected; a UE level measurement granularity period; a list of Next Generation (NG) Radio Access Network (RAN) cells to be measured; a tracking reference; the Internet Protocol (IP) address of a tracking collection entity for file-based tracking reports; the Uniform Resource Identifier (URI) of a tracking report consumer for streaming tracking reports; or a tracking report format.

15. The device according to claim 12, wherein, The processor circuit is further configured to: generate UE level measurements at a granularity period based on the tracking session activation request to initiate a tracking record session under the tracking session; and report the results of the UE level measurements for the tracking record session to a Tracking Collection Entity (TCE).

16. The device according to claim 12, wherein, The processor circuit is further configured to: decode a tracking session deactivation request received from the service producer via the interface circuit to deactivate the tracking session; in response to the tracking session deactivation request, encode a tracking session deactivation response to be transmitted to the service producer via the interface circuit, the tracking session deactivation response being for indicating the deactivation result of the tracking session; and stop the tracking session based on the tracking session deactivation request.

17. The apparatus according to any one of claims 12 to 16, wherein, The apparatus is applicable to a Network Function (NF).

18. An apparatus, comprising: an interface circuit; and a processor circuit coupled to the interface circuit, wherein the processor circuit is configured to: encode a tracking job creation request to be transmitted to a service producer via the interface circuit, the tracking job creation request being for creating a tracking job for collecting User Equipment (UE) level measurement results from a Network Function (NF); and decode a tracking job creation response received from the service producer via the interface circuit in response to the tracking job creation request, the tracking job creation response being for indicating the creation result of the tracking job.

19. The apparatus according to claim 18, wherein The processor circuit is further configured to: Encode a tracking job deletion request to be transmitted via the interface circuit to the service producer for deleting the tracking job; and Decode a tracking job deletion response received via the interface circuit from the service producer in response to the tracking job deletion request, the tracking job deletion response being used to indicate the deletion result of the tracking job.

20. The apparatus according to claim 18 or 19, wherein The device is applicable to a service consumer.

Images