Apparatus and method for UE level measurement collection

Through the method of decoding and storing UE-level measurement results by processor circuits, the problem of inefficient UE measurement collection in 5G networks is solved, efficient measurement reporting and network monitoring are achieved, and system management efficiency is improved.

CN120343616APending Publication Date: 2025-07-18INTEL CORP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411690697.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-01-17
Filing Date
2024-11-25
Publication Date
2025-07-18

AI Technical Summary

Technical Problem

Existing wireless communication systems have problems with inefficiency in UE-level measurement collection and untimely data reporting, especially in 5G networks, which are difficult to effectively monitor and report measurement results of user equipment.

Method used

A device and method are provided to decode measurement requests from a session management function or management system through a processor circuit, perform UE-level measurement collection, and store the results in memory, and ultimately report measurement results to a designated entity to achieve efficient UE-level measurement collection and reporting.

Benefits of technology

It realizes efficient measurement collection and timely reporting at the UE level, supports accurate monitoring and performance optimization of user equipment in 5G networks, and improves network management efficiency and data analysis capabilities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120343616A_ABST
    Figure CN120343616A_ABST
Patent Text Reader

Abstract

The present disclosure provides an apparatus and method for UE level measurement collection. The present disclosure provides an apparatus comprising: a memory; and a processor circuit coupled with the memory. The processor circuitry is to: decode a first request for UE level measurement collection received from a session management function (SMF) or a management system; performing UE-level measurement collection based on the first request to obtain a UE-level measurement result; and reporting the UE-level measurement results to the SMF or an entity specified by the management system. The memory is to store a UE level measurement result. Other embodiments are also disclosed and protected.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Priority Statement

[0002] This application claims the priority benefit of U.S. Provisional Patent Application No. 63 / 621,920, filed on January 17, 2024, the entire content of which is incorporated herein by reference. Technical Field

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

[0004] Mobile communication has evolved significantly from early voice systems to today's highly complex integrated communication platforms. Next-generation wireless communication systems, such as the fifth generation (5G) or New Radio (NR), will provide access to information and data sharing anytime and anywhere through various terminals and applications. NR is expected to be a unified network / system designed to meet distinct and sometimes conflicting performance dimensions and services. Such diverse multi-dimensional requirements are driven by different services and applications. Generally, NR can evolve based on the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE)-Advanced and other potential new radio access technologies (RATs) to enrich people's lives with better, simpler, and seamless wireless connectivity solutions. NR can enable everything connected wirelessly and provide fast and rich content and services. Summary of the Invention

[0005] One aspect of the present disclosure provides an apparatus, including: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: decode a first request for UE-level measurement collection received from a session management function (SMF) or a management system; perform UE-level measurement collection based on the first request to obtain UE-level measurement results; and report the UE-level measurement results to the SMF or an entity designated by the management system, and wherein the memory is used to store the UE-level measurement results. Brief Description of the Drawings

[0006] 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.

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

[0008] Figure 2 An example architecture of a system including a 5GC according to some embodiments of the present disclosure is shown.

[0009] Figure 3 FIG. 2 illustrates an example flowchart of a method for UE-level measurement collection according to some embodiments of the present disclosure.

[0010] Figure 4 FIG. 6 illustrates an example of UE-level measurement collection according to some embodiments of the present disclosure.

[0011] Figure 5 FIG. 10 illustrates an example of a user plane interface according to some embodiments of the present disclosure.

[0012] Figure 6 FIG. 14 schematically illustrates a wireless network according to various embodiments of the present disclosure.

[0013] Figure 7 FIG. 18 shows an example component of a device according to some embodiments of the present disclosure.

[0014] Figure 8 FIG. 22 shows an example of an infrastructure device according to various embodiments.

[0015] Figure 9 FIG. 26 is a block diagram showing components capable of reading instructions from a machine-readable or computer-readable medium and performing any one or more of the methods discussed herein according to some example embodiments.

[0016] Figure 10 FIG. 30 shows a network according to various embodiments of the present disclosure. DETAILED DESCRIPTION

[0017] 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 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 in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternative embodiments can be practiced without these specific details. In other instances, well-known features have been omitted or simplified to avoid obscuring the illustrative embodiments.

[0018] 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 are necessarily order-dependent. In particular, these operations need not be performed in the order presented.

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

[0020] Figure 1 FIG. illustrates an example architecture of a system 100 in accordance with some embodiments of the present disclosure. The following description is provided for an example system 100 operating in conjunction with the Long Term Evolution (LTE) system standard and 5G or New Radio (NR) system standard provided in 3GPP Technical Specification (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.).

[0021] As Figure 1As shown, 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 with 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 including a wireless communication interface. In this example, 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 consumer electronic devices, cellular phones, smart phones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI) systems, in-vehicle entertainment (ICE) devices, instrument clusters (ICs), head-up display (HUD) devices, on-board diagnostic (OBD) devices, dashboard mobile devices (DMEs), mobile data terminals (MDTs), electronic engine management systems (EEMSs), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMSs), networked or "smart" devices, machine type communication (MTC) devices, machine-to-machine (M2M), Internet of Things (IoT) devices, and / or the like.

[0022] In some embodiments, any 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.

[0023] 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 denoting a 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).

[0024] In this example, the connections 103 and 104 are shown as air interfaces to enable communication coupling and may be in accordance with a cellular communication protocol 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, a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0025] UE 101b is shown as being configured to access an access point (AP) 106 (also referred to as "WLAN node 106", "WLAN 106", "WLAN terminal 106", or "WT 106", etc.) via connection 107. Connection 107 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 106 will include a Wi-Fi router. In this example, 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, 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 UE 101b in RRC_CONNECTED being configured by RAN node 111 to utilize radio resources of LTE and WLAN. LWIP operations may involve UE 101b using WLAN radio resources (e.g., connection 107) via an Internet Protocol Security (IPsec) protocol tunnel to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) sent over 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.

[0026] RAN 110 may include one or more RAN nodes 111a and 111b (collectively referred to as "(one or more) RAN nodes 111") enabling connections 103 and 104. As used herein, terms such as "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 (BS), next-generation Node B (gNB), RAN nodes, evolved Node B (eNB), Node B, roadside units (RSU), transmission and reception points (TRxP or TRP), etc., and may include a terrestrial station (e.g., a terrestrial access point) or a satellite station providing coverage within a geographical area (e.g., a cell). As used herein, terms such as "NGRAN node" etc. may refer to a RAN node 111 (e.g., gNB) operating in an NR or 5G system 100, and terms such as "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, 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, a smaller user capacity, or a higher bandwidth compared to macrocells.

[0027] In some embodiments, all or part of the RAN node 111 can 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 can implement RAN function partitioning, such as: PDCP partitioning, where the RRC and PDCP layers are operated by the CRAN / vBBUP, and the other Layer 2 (L2) protocol entities are operated by the 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 the 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 the 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, the individual RAN nodes 111 can represent individual gNB-DUs connected to the gNB-CU via individual F1 interfaces ( Figure 1 not shown). In these implementations, the gNB-DU can include one or more remote radio heads or radio front-end modules (RFEMs), and the gNB-CU can be operated by a server (not shown) located in the RAN 110 or by a pool of servers in a manner similar to the CRAN / vBBUP. Additionally or alternatively, one or more RAN nodes 111 can be a next-generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol termination to the UE 101 and is connected to the 5GC via the NG interface.

[0028] In a V2X scenario, one or more RAN nodes 111 can be or act as RSUs. The term "roadside unit" or "RSU" can refer to any transportation infrastructure entity for V2X communication. An RSU can be implemented in or by a suitable RAN node or a fixed (or relatively stationary) UE, where 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 radio frequency circuit located at the roadside, which provides connectivity support for passing vehicle UEs 101 (vUE 101). The RSU can 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 can operate on the 5.9 GHz direct short-range communication (DSRC) band to provide very low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU can operate on the cellular V2X band to provide the above low-latency communication and other cellular communication services. Additionally or alternatively, the RSU can operate as a WiFi hotspot (2.4 GHz 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 can be encapsulated in a weatherproof enclosure suitable for outdoor installation and can include a network interface controller to provide a wired (e.g., Ethernet) connection to a traffic signal controller and / or a backhaul network.

[0029] 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.

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

[0031] In some embodiments, a downlink resource grid can be used for downlink transmission from any RAN node 111 to UE 101, and uplink transmission 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 resources 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 represented 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 currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

[0032] According to various embodiments, UE 101 and RAN node 111 transmit (e.g., send and receive) data over 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.

[0033] To operate in the unlicensed spectrum, UE 101 and RAN node 111 can use licensed-assisted access (LAA), enhanced LAA (eLAA), and / or other enhanced LAA (feLAA) mechanisms to operate. In these implementations, UE 101 and RAN node 111 can 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 can be performed according to the listen-before-talk (LBT) protocol.

[0034] LBT is a mechanism in which devices (e.g., UE 101, RAN nodes 111, 112, etc.) sense the medium (e.g., a channel or carrier frequency) and transmit when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include a Clear Channel Assessment (CCA) that 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 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 predefined or configured threshold.

[0035] 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 a CCA before transmission. 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 a contention window size (CWS) that exponentially increases upon occurrence 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 WLAN. In some implementations, the LBT process for DL or UL transmission bursts respectively including PDSCH or PUSCH transmissions may have an LAA contention window of variable length 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.

[0036] 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.

[0037] CA also includes separate serving cells to provide separate CCs. The coverage of the serving cells may be different. For example, 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 sub - frame.

[0038] 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. The downlink resource allocation information can be sent on the PDCCH for each UE 101 (e.g., allocated to).

[0039] The PDCCH can use control channel elements (CCEs) to convey control information. Before mapping to resource elements, the complex-valued symbols of the PDCCH can first be organized into quadruples, and then a sub-block interleaver can be used to permute them for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine groups of four physical resource elements called resource element groups (REGs). Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. One or more CCEs can 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 (e.g., aggregation levels, L = 1, 2, 4, or 8) with different numbers of CCEs can be defined.

[0040] Some embodiments can use a concept for resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments can use an enhanced physical downlink control channel (EPDCCH), which uses PDSCH resources for control information transmission. One or more enhanced control channel elements (ECCEs) can be used to transmit the EPDCCH. Similar to above, each ECCE can 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.

[0041] RAN nodes 111 can be configured to communicate with each other via interface 112. In an embodiment where system 100 is an LTE system, interface 112 can be the X2 interface 112. The X2 interface can 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 can include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U can provide a flow control mechanism for user data packets transmitted through the X2 interface and can be used to convey information about user data transfer between eNBs. For example, the X2-U can 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 from the SeNB to the UE 101 for user data; 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 can 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.

[0042] In an embodiment where system 100 is a 5G or NR system, interface 112 can 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 can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U can provide unguaranteed transfer of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C can 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 UE mobility in the connected mode between one or more RAN nodes 111. Mobility support can 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 the Xn-U can 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 can include an application layer signaling protocol (referred to as the Xn application protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP can be located on top of the IP layer and can provide guaranteed transfer of application layer messages. In the transport IP layer, point-to-point transmission is used to transfer signaling PDUs. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack can be the same as or similar to the (one or more) user plane and / or control plane protocol stacks shown and described here.

[0043] 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 customers / subscribers (e.g., the user 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. The 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. The NFV architecture and infrastructure may be used to virtualize one or more network functions, or to execute from dedicated hardware onto physical resources including a combination of industry standard server hardware, storage hardware, or switches. In other words, the NFV system may be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0044] 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) session, PTT session, group communication session, social network service, etc.) for UE 101 via EPC 120.

[0045] 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.

[0046] In an embodiment, CN 120 may be a 5G CN (referred to as "5GC 120", etc.), while in other embodiments, CN 120 may be an evolved packet core (EPC). In the case where CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 may be connected to CN 120 via the S1 interface 113. In an embodiment, the S1 interface 13 may 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.

[0047] Figure 2 An example architecture of a system 200 including 5GC 220 according to some embodiments of the present disclosure is shown.

[0048] System 200 is shown as including: a UE 201, which may be the same as or similar to the previously discussed UE 101; a (R)AN 210, which may be the same as or similar to the previously discussed RAN 110 and may include the previously discussed RAN node 111; and a data network (DN) 203, which may be, for example, a carrier service, an Internet access, or a third-party service; and a 5G core network (5GC or CN) 220.

[0049] 5GC 220 may include an authentication server function (AUSF) 222; an access and mobility management function (AMF) 221; a session management function (SMF) 224; a network exposure function (NEF) 223; a policy control function (PCF) 226; a network function (NF) repository function (NRF) 225; a unified data management (UDM) 227; an application function (AF) 228; a user plane function (UPF) 202; and a network slice selection function (NSSF) 229.

[0050] The UPF 202 can act as an anchor point for in-RAT and inter-RAT mobility, an external PDU session interconnection point to the DN 203, and a branching point for supporting multi-homed PDU sessions. The UPF 202 can also perform packet routing and forwarding, packet inspection, enforce policy rules for the user plane portion, lawful interception of packets (UP set), 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 traffic mapping), transport-level packet marking in the uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 202 can include an uplink classifier for supporting routing of traffic flows to data networks. The DN 203 can represent various network operator services, Internet access, or third-party services. The DN 203 can include or be similar to the application server 130 discussed previously. The UPF 202 can interact with the SMF 224 via the N4 reference point between the SMF 224 and the UPF 202.

[0051] The AUSF 222 can store authentication data for the UE 201 and handle authentication-related functions. The AUSF 222 can facilitate a common authentication framework for various access types. The AUSF 222 can communicate with the AMF 221 via the N12 reference point between the AMF 221 and the AUSF 222; and can communicate with the UDM 227 via the N13 reference point between the UDM 227 and the AUSF 222. Additionally, the AUSF 222 can expose Nausf service-based interfaces.

[0052] The AMF 221 can be responsible for registration management (e.g., for registering the UE 201, etc.), connection management, reachability management, mobility management, and lawful interception of AMF-related events, as well as access authentication and authorization. The AMF 221 can be the termination point of the N11 reference point between the AMF 221 and the SMF 224. The AMF 221 can provide the transport for session management (SM) messages between the UE 201 and the SMF 224 and act as a transparent proxy for routing SM messages. The AMF 221 can also be between the UE 201 and the SMS function (SMSF)( Figure 2Provide transmission for Short Message Service (SMS) messages between (not shown). The AMF 221 can act as a Security Anchor Function (SEA), which can include interactions with the AUSF 222 and the UE 201, and receive the intermediate key established as a result of the UE 201 authentication process. In the case of using USIM-based authentication, the AMF 221 can obtain security material from the AUSF 222. The AMF 221 can also include a Security Context Management (SCM) function, which receives the key used by the SEA to derive the access network-specific key. In addition, the AMF 221 can be the termination point of the RAN CP interface, which can include or be the N2 reference point between the (R)AN 211 and the AMF 221; the AMF 221 can be the termination point of the NAS (N1) signaling and perform NAS encryption and integrity protection.

[0053] The AMF 221 can also support NAS signaling with the UE 201 through the N3 Interworking Function (IWF) interface. The N3IWF can be used to provide access to untrusted entities. The N3IWF can be the termination point of the N2 interface between the (R)AN 210 and the AMF 221 for the control plane, and can be the termination point of the N3 reference point between the (R)AN 210 and the UPF 202 for the user plane. In this way, the AMF 221 can process the N2 signaling from the SMF 224 and the AMF 221 for PDU sessions and QoS, encapsulate / de-encapsulate packets for IPSec and N3 tunneling, mark N3 user plane packets in the uplink, and perform QoS corresponding to the N3 packet marking, taking into account the QoS requirements associated with such marking received through N2. The N3IWF can also relay the uplink and downlink control plane NAS signaling between the UE 201 and the AMF 221 via the N1 reference point between the UE 201 and the AMF 221, and relay the uplink and downlink user plane packets between the UE 201 and the UPF 202. The N3IWF also provides a mechanism to establish an IPsec tunnel with the UE 201. The AMF 221 can expose an interface based on the Namf service, and can be the termination point of the N14 reference point between two AMF 221s and the N17 reference point between the AMF 221 and the 5G Equipment Identity Register (5G-EIR) ( Figure 2 not shown).

[0054] UE 201 may need to register with the AMF 221 to receive network services. Registration Management (RM) is used to register or deregister the UE 201 with the network (e.g., the AMF 221) and establish a UE context in the network (e.g., the AMF 221). The UE 201 can operate in an RM registration state or an RM deregistration state. In the RM deregistration state, the UE 201 is not registered with the network, and the UE context in the AMF 221 does not hold the valid location or routing information of the UE 201, so the AMF 221 cannot reach the UE 201. In the RM registration state, the UE 201 is registered with the network, and the UE context in the AMF 221 can hold the valid location or routing information of the UE 201, enabling the UE 201 to be reachable by the AMF 221. In the RM registration state, the UE 201 can perform a mobility registration update procedure, perform a periodic registration update procedure triggered by the expiration of a periodic update timer (e.g., notify the network that the UE 201 is still active), and perform a registration update procedure to update UE capability information or renegotiate protocol parameters with the network, etc.

[0055] The AMF 221 can store one or more RM contexts for the UE 201, where each RM context is associated with a specific access to the network. The RM context can be a data structure, a database object, etc., which indicates or stores the registration state and periodic update timer for each access type, etc. The AMF 221 can also store a 5GC MM context, which can be the same as or similar to the previously discussed (E)MM context. In various embodiments, the AMF 221 can store the CE mode B restriction parameters of the UE 201 in the associated MM context or RM context. When needed, the AMF 221 can also derive this value from the UE usage setting parameters that have been stored in the UE context (and / or MM / RM context).

[0056] Connection Management (CM) can be used to establish and release a signaling connection between the UE 201 and the AMF 221 over the N1 interface. This signaling connection is used to enable NAS signaling exchange between the UE 201 and the CN 120, and includes an AN signaling connection between the UE and the access network (AN) (e.g., an RRC connection or a UE-N3IWF connection for non-3GPP) and an N2 connection for the UE 201 between the AN (e.g., the RAN 210) and the AMF 221. The UE 201 can operate in one of two CM states: the CM Idle (CM-IDLE) mode or the CM Connected (CM-CONNECTED) mode. When the UE 201 operates in the CM-IDLE state / mode, the UE 201 may not have a NAS signaling connection established with the AMF 221 over the N1 interface, and there may be an (R)AN210 signaling connection (e.g., N2 and / or N3 connections) for the UE 201. When the UE 201 operates in the CM-CONNECTED state / mode, the UE201 may have a NAS signaling connection established with the AMF221 over the N1 interface, and there may be an (R)AN210 signaling connection (e.g., N2 and / or N3 connections) for the UE 201. Establishing an N2 connection between the (R)AN 210 and the AMF 221 can cause the UE201 to transition from the CM-IDLE mode to the CM-CONNECTED mode, and when the N2 signaling between the (R)AN 210 and the AMF 221 is released, the UE 201 can transition from the CM-CONNECTED mode to the CM-IDLE mode.

[0057] The SMF 224 may be responsible for: Session Management (SM) (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF and the AN node); UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuration of traffic steering at the UPF to route traffic to the correct destination; termination of the interface to the Policy Control Function; control of part of the policy enforcement and QoS; lawful interception (for SM events and the interface to the LI system); termination of NAS messages for the SM part; downlink data notification; originator of AN-specific SM information, sent to the AN via the AMF over N2; determination of the SSC mode of the session. SM may refer to the management of PDU sessions, and a PDU session or "session" may refer to a PDU connection service that provides or enables PDU exchange between the UE 201 and a data network (DN) 203 identified by a data network name (DNN). A PDU session may be established upon request of the UE 201, modified upon request of the UE 201 and the 5GC 220, and released using NAS SM signaling exchanged between the UE 201 and the SMF 224 over the N1 reference point upon request of the UE 201 and the 5GC 220. Based on a request from an application server, the 5GC 220 may trigger a specific application in the UE 201. In response to receiving the trigger message, the UE 201 may pass the trigger message (or relevant parts / information of the trigger message) to one or more identified applications in the UE 201. The identified application(s) in the UE 201 may establish a PDU session to a specific DNN. The SMF 224 may check whether the UE 201 request complies with the user subscription information associated with the UE 201. In this regard, the SMF 224 may retrieve and / or request updated notifications regarding SMF 224-level subscription data from the UDM 227.

[0058] The SMF 224 may include the following roaming functions: handling local enforcement to apply QoS SLA (VPLMN); charging data collection and charging interface (VPLMN); lawful interception (in the interface between the VPLMN of the SM event and the LI system); support for interaction with an external DN to transmit signaling for PDU session authorization / authentication over the external DN. The N16 reference point between two SMF 224s may be included in the system 200, which may be between another SMF 224 in the access network and the SMF 224 in the home network in a roaming scenario. Additionally, the SMF 224 may expose an Nsmf service-based interface.

[0059] The NEF 223 can provide means for securely exposing services and capabilities provided by 3GPP network functions to third parties, internal exposure / re - exposure, application functions (e.g., AF 228), edge computing or fog computing systems, etc. In such an embodiment, the NEF 223 can authenticate, authorize, and / or restrict the AF. The NEF 223 can also transform information exchanged with the AF 228 and information exchanged with internal network functions. For example, the NEF 223 can transform between an AF service identifier and internal 5GC information. The NEF 223 can also receive information from other network functions (NFs) based on the exposure capabilities of the other NFs. This information can be stored in the NEF 223 as structured data, or stored in a data storage device NF using a standardized interface. Then, the stored information can be re - exposed by the NEF 223 to other NFs and AFs, and / or used for other purposes, such as analysis. Additionally, the NEF 223 can expose an interface based on the Nnef service.

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

[0061] The PCF 226 can provide policy rules to control (one or more) plane functions to enforce them, and can also support a unified policy framework to manage network behavior. The PCF 226 can also implement a front - end (FE) to access subscription information related to policy decisions in the UDR of the UDM 227. The PCF 226 can communicate with the AMF 221 via the N15 reference point between the PCF 226 and the AMF 221, which can include the PCF 226 in the access network and the AMF 221 in a roaming scenario. The PCF 226 can communicate with the AF 228 via the N5 reference point between the PCF 226 and the AF 228; and communicate with the SMF 224 via the N7 reference point between the PCF 226 and the SMF 224. The system 200 and / or the CN 120 can also include an N24 reference point between the PCF 226 (in the home network) and the PCF 226 in the access network. Additionally, the PCF 226 can expose an interface based on the Npcf service.

[0062] The UDM 227 can process subscription-related information to support the handling of communication sessions by network entities, and can store the subscription data of the UE 201. For example, the subscription data can be transmitted between the UDM 227 and the AMF 221 via the N8 reference point between the UDM 227 and the AMF 221 ( Figure 2 not shown). The UDM 227 can include two parts: an application FE and a user data repository (UDR) ( Figure 2 the FE and the UDR are not shown in ). The UDR can store subscription data and policy data for the UDM 227 and the PCF 226 for the NEF 223, and / or structured data and application data for exposure (including packet flow descriptions (PFDs) for application detection, application request information for multiple UEs 201). The UDR 221 can expose an interface based on the Nudr service to allow the UDM 227, the PCF 226, and the NEF 223 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 voucher handling, 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 voucher handling; user identification handling; access authorization; registration / mobility management; and subscription management. The UDR can interact with the SMF 224 via the N10 reference point between the UDM 227 and the SMF 224. The UDM 227 can also support SMS management, where the SMS-FE implements similar application logic as described above. Additionally, the UDM 227 can expose an interface based on the Nudm service.

[0063] The AF 228 can provide application impact on traffic routing, access the network capabilities exposure (NCE), and interact with the policy framework for policy control. The NCE can be a mechanism that allows the 5GC 220 and the AF 228 to provide information to each other via the NEF 223, which can be used for edge computing implementation. In such an implementation, the network operator and third-party services can be hosted close to the UE 201 access connection point to achieve efficient service delivery by reducing the end-to-end latency and the load on the transport network. For edge computing implementation, the 5GC can select the UPF 202 close to the UE 201 and perform traffic steering from the UPF 202 to the DN 203 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by the AF 228. In this way, the AF 228 can influence UPF (re)selection and traffic routing. Based on the operator deployment, when the AF 228 is considered a trusted entity, the network operator can allow the AF 228 to directly interact with the relevant NFs. Additionally, the AF 228 can expose an interface based on the Naf service.

[0064] The NSSF 229 can select a set of network slice instances to serve the UE 201. The NSSF 229 can also determine the allowed network slice selection assistance information (NSSAI) and the mapping to the subscribed single NSSAI (S-NSSAI), if needed. The NSSF 229 can also determine a set of AMFs or a list of candidate AMFs 221 for serving the UE 201 based on a suitable configuration and possibly by querying the NRF 225. The selection of a set of network slice instances for the UE 201 can be triggered by the AMF 221 (which registers the UE 201 by interacting with the NSSF 229), which can result in a change of the AMF 221. The NSSF 229 can interact with the AMF 221 via the N22 reference point between the AMF 221 and the NSSF 229; and can communicate with another NSSF 229 in the access network via the N31 reference point ( Figure 2 not shown in the figure). Additionally, the NSSF 229 can expose an interface based on the Nnssf service.

[0065] As previously mentioned, the 5GC 220 can include an SMSF, which can be responsible for SMS subscription checking and verification, and relaying SM messages from other entities to the UE 201 / relaying SM messages from the UE 201 to other entities, where the other entities can be, for example, the SMS-GMSC / IWMSC / SMS router. The SMS can also interact with the AMF 221 and the UDM 227 for the notification process for which the UE 201 is available for SMS transmission (e.g., setting the UE unreachable flag and notifying the UDM 227 when the UE 201 is available for SMS).

[0066] The 5GC 220 may also include Figure 2 other elements not shown, such as a data storage system / architecture, a 5G Equipment Identity Register (5G-EIR), a Security Edge Protection Proxy (SEPP), and so on. The data storage system may include a Structured Data Storage Network Function (SDSF), an Unstructured Data Storage Network Function (UDSF), and so on. Any NF may store unstructured data into or retrieve unstructured data (e.g., UE context) from the UDSF via an N18 reference point ( Figure 2 not shown) between any NF and the UDSF. Separate NFs may share the UDSF for storing their respective unstructured data, or each NF may have its own UDSF located at or near each NF. Additionally, the UDSF may expose an interface based on Nudsf services ( Figure 2 not shown). The 5G-EIR may be an NF that checks the status of the Permanent Equipment Identifier (PEI) to determine whether a particular device / entity is blacklisted from the network; the SEPP may be a non-transparent proxy that performs topology hiding, message filtering, and supervision on the inter-PLMN control plane interface.

[0067] Additionally, there may be more reference points and / or service-based interfaces between NF services in the NF; however, for clarity, Figure 2 these interfaces and reference points are omitted in. In one example, the 5GC 220 may include an Nx interface, which is an inter-CN interface between the MME and the AMF 221 to enable interworking between the EPC and the 5GC 220. Other example interfaces / reference points may include an interface based on N5g-eir services exposed by the 5G-EIR, an N27 reference point between the NRF in the access network and the NRF in the home network; and an N31 reference point between the NSSF in the access network and the NSSF in the home network.

[0068] In a 5G network, the DL / UL latency associated with the NG-RAN (e.g., the latency between the Protocol Data Unit (PDU) Session Anchor (PSA) UPF and the NG-RAN, the latency between the NG-RAN and the UE) can cause end-to-end latency, affecting the user experience for certain types of services (e.g., Ultra-Reliable and Low-Latency Communication (URLLC)).

[0069] Specifically for UL, the UL packet delay in NG-RAN can be measured by the gNB, considering the cases with or without the D1 UL PDCP delay occurring in the UE (see 3GPP TS 38.415 V18.0.0 (2023-12), 3rd Generation Partnership Project; Radio Access Network Technical Specification Group; NG-RAN; PDU Session User Plane Protocol (Release 18)), so separate measurements are required for the cases with and without D1 respectively to monitor the total UL packet delay between NG-RAN and the UE. Here, the D1 UL PDCP delay (or "D1") is the average delay of UL PDCP packets. Specifically, it is the PDCP packet delay in UL based on each DRB. This measurement refers to the PDCP queue delay for the DRB in the UE, which captures the delay from the packet arriving at the PDCP upper layer SAP to the UL grant for transmitting the packet, including the delay for the UE to obtain the resource grant (from sending SR / RACH to obtaining the first grant). This measurement is performed separately for each DRB (see 3GPP TS 38.314 V17.4.0 (2023-12), 3rd Generation Partnership Project; Radio Access Network Technical Specification Group; NR; Layer 2 Measurements (Release 17)).

[0070] The measurement results for DL / UL one-way delay based on each UE and each QoS flow between the PSA UPF and NG-RAN, and between NG-RAN and the UE can be used to analyze the user plane delay performance and user experience in the 5G network, and support the end-to-end data volume transmission time-related analysis performed by the Network Function Data Analytics (NWDAF).

[0071] Figure 3 FIG. shows an example flowchart of a method 300 for UE-level measurement collection according to some embodiments of the present disclosure. The method 300 can be executed by the UPF or the gNB. As Figure 3As shown, method 300 includes operations 310 to 330. At 310, a first request collected for UE-level measurement is decoded. The first request may be received from a management system or the SMF. At 320, UE-level measurement collection is performed based on the first request to obtain UE-level measurement results. At 330, the UE-level measurement results are reported to the SMF or an entity designated by the management system. In some embodiments, the management system includes a Management Service (MnS) producer and an MnS consumer. For example, the first request is received from the management system (e.g., the MnS consumer), and the UE-level measurement results are reported to the target entity designated by the MnS consumer. In another example, the first request is received from the management system (e.g., the MnS consumer), and the UE-level measurement results are reported to the SMF. In another example, the first request is received from the SMF, and the UE-level measurement results are reported to the SMF. In another example, the first request is received from the SMF, and the UE-level measurement results are reported to the target entity designated by the MnS consumer. The present disclosure is not limited in this regard.

[0072] In some embodiments, the UPF or the gNB may: in response to the first request, decode a second request received from the SMF for Quality of Service (QoS) monitoring per Quality of Service (QoS) flow per UE (per Quality of Service (QoS) flow per UE QoS monitoring); perform QoS monitoring per UE per QoS flow based on the second request to obtain QoS monitoring results; and perform UE-level measurement collection based on the QoS monitoring results. In some embodiments, the second request may include a QoS monitoring request or a tracking request, etc.

[0073] In some embodiments, UE-level measurement collection may be requested by any process related to UE-level measurement collection. That is, the present disclosure does not limit the first request. In these embodiments, when a request for UE-level measurement collection is received, UE-level measurement collection will be performed together with corresponding monitoring processes (e.g., QoS monitoring per UE per QoS flow), tracking processes, etc. For example, a request for UE-level measurement collection triggers the corresponding monitoring or tracking process to obtain UE-level measurement results.

[0074] In some embodiments, the obtaining of UE-level measurement results may rely on other processes, for example, monitoring processes (e.g., QoS monitoring based on each UE and each QoS flow), tracking processes, etc. That is, in these embodiments, requests for UE-level measurement collection may not trigger the corresponding monitoring or tracking processes, but the UE-level measurement results are obtained based on the corresponding QoS monitoring results. In this case, the corresponding monitoring or tracking processes can be triggered in different ways to obtain the QoS monitoring results.

[0075] Figure 4 An example of UE-level measurement collection according to some embodiments of the present disclosure is shown. In some embodiments, the UPF may perform QoS monitoring based on each UE and each QoS flow, and the QoS monitoring is triggered by a UE-level measurement collection request received from the SMF during the PDU session establishment or modification process (see Figure 4 Operation 2a) in (see 3GPP TS23.501V18.4.0(2023-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for 5G Systems (5GS); Phase 2 (Release 18)). The gNB may perform QoS monitoring based on each UE and each QoS flow, and the QoS monitoring is triggered by a UE-level measurement collection request received from the SMF during the PDU session establishment or modification process (see Figure 4 Operation 2b) in (see 3GPPTS 23.501V18.4.0(2023-12)).

[0076] In some embodiments, the QoS monitoring or UE-level measurement collection request may be initiated by a management system (see Figure 4 Operation 1a) in) on the SMF through the MOI (e.g., QFQoSMonitoringControl MOI) (see 3GPPTS28.541V18.5.0(2023-09), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Management and Orchestration; 5G Network Resource Model (NRM); Phases 2 and 3 (Release 18)), or by the PCF (see Figure 4 Operation 1b) in) on the SMF through the QoS monitoring policy included in the PCC rule configuration (see 3GPP TS23.503V18.4.0(2023-12), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy and Charging Control Architecture for 5G Systems (5GS); Phase 2 (Release 18)).

[0077] In some embodiments, the PSA UPF may create one or more monitoring packets according to the QoS monitoring request received from the SMF and send them to the RAN.

[0078] In some embodiments, the PSA UPF may generate measurements according to UE-level measurement tasks (e.g., TraceJob MOI) created by the management system (see operation 3a) in Figure 4 .

[0079] In some embodiments, the gNB may generate measurements according to UE-level measurement tasks (e.g., TraceJob MOI) created by the management system (see operation 3b) in Figure 4 .

[0080] In some embodiments, the SMF, UPF, and gNB may be managed by respective management functions (MnF) located either outside or inside the SMF, UPF, or gNB. The MnF may act as an MnS producer to provide management services (MnS) to MnS consumers.

[0081] In some embodiments, the SMF may configure the (one or more) UPFs and the NG-RAN to perform QoS monitoring per QoS flow per UE. The SMF may configure the UPF to report the QoS monitoring results of the QoS flows. During the PDU session establishment or modification process, the SMF may activate end-to-end UL / DL packet delay measurements between the UE and the PSA UPF for the QoS flows. In some embodiments, the SMF may send a QoS monitoring request to the PSA UPF via N4 and a QoS monitoring request to the NG-RAN via N2 signaling to request QoS monitoring between the PSA UPF and the NG-RAN. The NG-RAN may initiate the RAN part of the UL / DL packet delay measurement according to the QoS monitoring request of the SMF. The NG-RAN may report the RAN part of the UL / DL packet delay result to the PSA UPF in the UL data packet or a dummy UL packet.

[0082] In some embodiments, the UPF may: encode a monitoring packet for transmission to the RAN based on a second request for QoS monitoring per QoS flow per UE; decode a monitoring response packet received from the RAN in response to the monitoring packet; and obtain UE-level measurement results based on the information obtained from the monitoring response packet.

[0083] In some embodiments, the UE-level measurement results include the DL packet delay between the PSA UPF and the RAN. The UPF may decode the monitoring response packet to obtain a first time instance T1 indicating the local time when the PSA UPF sends the monitoring packet and a second time instance T2 indicating the local time when the RAN receives the monitoring packet, and obtain the DL packet delay between the PSA UPF and the RAN based on the time difference between the second time instance T2 and the first time instance T1.

[0084] In some embodiments, the UE-level measurement result includes the UL packet delay between the PSA UPF and the RAN. The UPF can decode the monitoring response packet to obtain a third time instance T3 indicating the local time when the RAN sends the monitoring response packet and a fourth time instance T4 indicating the local time when the PSA UPF receives the monitoring response packet, and obtain the UL packet delay between the PSA UPF and the RAN based on the time difference between the fourth time instance T4 and the third time instance T3.

[0085] For example, the PSA UPF can encapsulate in the GTP-U header a QoS flow identifier (QFI), a QoS monitoring packet (QMP) indicator (indicating that the packet is for UL / DL packet delay measurement), and the local time T1 when the PSA UPF sends out the DL monitoring packet. The NG-RAN can record the local time T1 received in the GTP-U header and the local time T2 when receiving the DL monitoring packet. When receiving a UL packet for this QFI from the UE, or when the NG-RAN sends a dummy UL packet as a monitoring response (in the case where there is no UL service packet for UL packet delay monitoring), the NG-RAN can encapsulate in the GTP-U header of the monitoring response packet the QMP indicator, the RAN part of the UL / DL packet delay result, the time T1 received in the GTP-U header, the local time T2 when receiving the DL monitoring packet, and the local time T3 when the NG-RAN sends this monitoring response packet to the UPF through the N3 interface. When the NG-RAN sends a dummy UL packet to the PSA UPF as a monitoring response depends on the implementation of the NG-RAN. The PSA UPF can record the local time T4 when receiving the monitoring response packet and calculate the round-trip time between the NG-RAN and the anchored PSA UPF (if time synchronization is not implemented) or the UL / DL packet delay (if time synchronization is implemented) based on the time information contained in the GTP-U header of the received monitoring response packet. If the NG-RAN and the PSA UPF are not time synchronized, the PSA UPF can calculate the UL / DL packet delay between the NG-RAN and the PSA UPF according to (T2 - T1 + T4 - T3) / 2. If the NG-RAN and the PSA UPF are time synchronized, the PSA UPF can calculate the UL packet delay and the DL packet delay between the NG-RAN and the PSA UPF according to (T4 - T3) and (T2 - T1), respectively. The PSA UPF calculates the UL / DL packet delay between the UE and the PSA UPF based on the received RAN part of the UL / DL packet delay result and the calculated UL / DL packet delay between the RAN and the PSA UPF.

[0086] As described above, the gNB can measure the UL packet delay in the NG-RAN with or without the D1 UL PDCP delay in the UE. Therefore, it is necessary to measure separately for the cases with and without D1 to monitor the total UL packet delay between the NG-RAN and the UE.

[0087] Figure 5 FIG. shows an example of a user plane interface according to some embodiments of the present disclosure. As shown, the packet delay in the RAN part may include the delay occurring in the RAN, the delay on the Uu interface, and optionally the D1 UL PDCP delay occurring in the UE. The delay occurring in the RAN may include the delay at the gNB - Central Unit (CU) - User Plane (UP), F1-U, and the gNB - Distributed Unit (DU).

[0088] In some embodiments, the UE-level measurement result includes the DL packet delay between the RAN and the UE. The UPF can decode the monitoring response packet to obtain the DL packet delay between the RAN and the UE. The DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

[0089] In some embodiments, the UE-level measurement result includes the UL packet delay between the RAN and the UE. The UPF can decode the monitoring response packet to obtain the UL packet delay between the RAN and the UE. The UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL Packet Data Convergence Protocol (PDCP) delay occurring in the UE.

[0090] In some embodiments, the UE-level measurement result includes the UL packet delay between the RAN and the UE. The UPF can decode the monitoring response packet to obtain the UL packet delay between the RAN and the UE. The UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL PDCP delay occurring in the UE.

[0091] In some embodiments, the UE-level measurement result includes the DL packet delay between the RAN and the UE. The gNB can perform the RAN part of the DL packet delay measurement to obtain the DL packet delay between the RAN and the UE. The DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

[0092] In some embodiments, the UE-level measurement result includes the UL packet delay between the RAN and the UE. The gNB may perform the RAN part of the UL packet delay measurement to obtain the UL packet delay between the RAN and the UE. The UL packet delay between the RAN and the UE is the sum of the delay that occurs in the RAN, the delay on the Uu interface, and the D1 UL PDCP delay that occurs in the UE.

[0093] In some embodiments, the UE-level measurement result includes the UL packet delay between the RAN and the UE. The gNB may perform the RAN part of the UL packet delay measurement to obtain the UL packet delay between the RAN and the UE. The UL packet delay between the RAN and the UE is the sum of the delay that occurs in the RAN and the delay on the Uu interface, excluding the D1 UL PDCP delay that occurs in the UE.

[0094] In some embodiments, the UE-level measurement result is obtained based on the per-QoS flow per single network slice selection assistance information (S-NSSAI) according to the specific requirements of the first request.

[0095] In some embodiments, the UE-level measurement result or the QoS monitoring result may be stored in a memory or other storage device.

[0096] For performance measurement, the following content may be added to 3GPP TS28.558 V0.1.0 (2023-11) (3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Management and Orchestration; User Equipment (UE) Level Measurements in 5G Systems (Release 18)) to define the following performance measurements that an MnS (Management Service) consumer can collect from an MnS producer according to the measurement templates specified in TS28.558.

[0097] 6.1 Definition of UE-level measurements for 5GC

[0098] 6.1.1 Definition of UE-level measurements for UPF

[0099] 6.1.1.1 Packet delay

[0100] 6.1.1.1.x Average UL packet delay for a QoS flow between PSA UPF and NG-RAN

[0101] a) This measurement provides the average UL packet delay for a QoS flow between PSA UPF and NG-RAN. This measurement is only applicable to the case where PSA UPF and NG-RAN are time synchronized.

[0102] b) DER(n = 1).

[0103] c) The measurement is obtained by the following method:

[0104] The UPF performs QoS monitoring per UE per QoS flow based on the QoS monitoring request received from the SMF during the PDU session establishment or modification procedure (see TS 23.501). The QoS monitoring can be initiated by the management system on the SMF via the QFQoSMonitoringControl MOI (see TS 28.541), or by the PCF on the SMF via the QoS monitoring policy included in the PCC rule configuration (see TS 23.503). The PSA UPF creates a monitoring packet based on the QoS monitoring request received from the SMF and sends the monitoring packet to the RAN.

[0105] For each received GTP PDU monitoring response packet for QoS monitoring (packet i), the PSA UPF records the following timestamps and information (see TS 23.501 and TS 38.415):

[0106] - T3 received in the GTP-U header of the monitoring response packet, indicating the local time when the NG-RAN sent the monitoring response packet;

[0107] - T4 when the PSA UPF received the monitoring response packet.

[0108] The PSA UPF counts the number (N) of GTP PDU monitoring response packets received for the S-NSSAI and QoS flow within the granularity period and performs the following calculations:

[0109]

[0110] d) Each measurement value is a real number representing the average delay within 0.1 milliseconds.

[0111] e) GTP.DelayUlPsaUpfNgranMean.SNSSAI.QFI.

[0112] where SNSSAI represents the S-NSSAI and QFI represents the QoS flow.

[0113] f) EP_N3 (contained by UPFFunction);

[0114] EP_N9 (contained by UPFFunction).

[0115] g) N4 session identifier.

[0116] h) One use of this measurement is to support the end-to-end data volume transmission time analysis performed by the NWDAF.

[0117] 6.x Definition of UE-level measurements for NG-RAN

[0118] 6.x.1 UE-level Measurements Definitions for gNB

[0119] 6.x.1.1 Packet Delay

[0120] 6.x.1.1.1 Average DL Packet Delay for QoS Flows between NG-RAN and UE

[0121] a) This measurement provides the average DL packet delay for QoS flows between NG-RAN and UE.

[0122] b) DER (n = 1).

[0123] c) The measurement is obtained as follows:

[0124] The gNB performs QoS monitoring per UE per QoS flow according to the QoS monitoring request received from the SMF during the PDU session establishment or modification process (see TS23.501). The QoS monitoring can be initiated by the management system on the SMF through the QFQoSMonitoringControl MOI (see TS28.541), or by the PCF on the SMF through the QoS monitoring policy included in the PCC rule configuration (see TS23.503).

[0125] For each received GTP PDU monitoring response packet for QoS monitoring (packet i), the gNB records the following timestamps and information contained in the GTP-U header (see 23.501 and 38.415):

[0126] - DL Delay Result from NG-RAN to UE, which represents the downlink delay measurement result and is the sum of the delay that occurs in the NG-RAN (including the delay at gNB-CU-UP, on F1-U, and at gNB-DU) and the delay on the Uu interface (see 38.415, the DL delay result is denoted as DRdl in this document).

[0127] The gNB counts the number (N) of received GTP PDU monitoring response packets for the S-NSSAI and QoS flows within the granularity period, and takes the arithmetic mean of the DRdl of N packets.

[0128] d) Each measurement value is a real number representing the average delay within 0.1 milliseconds.

[0129] e) GTP.DelayDlNgranUeMean.SNSSAI.QFI.

[0130] Where SNSSAI represents S-NSSAI and QFI represents QoS flow.

[0131] f) NR Cell CU (for non-split and 2-split scenarios);

[0132] GNBCUUP Function (for 3-split scenarios).

[0133] g) RAN UE Id.

[0134] h) One use of this measurement is to support the end-to-end data volume transmission time analysis performed by NWDAF.

[0135] 6.x.1.1.2 Average UL Packet Delay for QoS Flows between NG-RAN and UE (excluding D1)

[0136] a) This measurement provides the average UL packet delay for QoS flows between NG-RAN and UE, excluding the D1 UL PDCP delay that occurs in the UE.

[0137] b) DER (n = 1).

[0138] c) The measurement is obtained as follows:

[0139] The gNB performs QoS monitoring for each UE for each QoS flow based on the QoS monitoring request received from the SMF during PDU session establishment or modification (see TS 23.501). QoS monitoring can be initiated by the management system on the SMF through the QFQoSMonitoringControl MOI (see TS 28.541), or by the PCF on the SMF through the QoS monitoring policy included in the PCC rule configuration (see TS 23.503).

[0140] For each received GTP PDU monitoring response packet for QoS monitoring (packet i), the gNB records the following timestamps and information (see 23.501 and 38.415):

[0141] - UL Delay Result from UE to NG-RAN, representing the uplink delay measurement result, which is the sum of the delays that occur in the NG-RAN (including the delays at gNB-CU-UP, on F1-U, and at gNB-DU) and the delay on the Uu interface (excluding the D1 UL PDCP delay that occurs in the UE) (see TS 38.415, the UL delay result is denoted as DRul in this document).

[0142] The gNB counts the number (N) of GTP PDU monitoring response packets received for the S-NSSAI and QoS flow within the granularity period, and takes the arithmetic mean of the DRul of the N packets.

[0143] d) Each measurement value is a real number representing the average delay within 0.1 milliseconds.

[0144] e) GTP.DelayUlNgranUeMeanExcD1.SNSSAI.QFI.

[0145] Among them, SNSSAI represents the S-NSSAI, and QFI represents the QoS flow.

[0146] f) NRCellCU (for non-split and 2-split scenarios);

[0147] GNBCUUPFunction (for 3-split scenarios).

[0148] g) RAN UE Id.

[0149] h) One use of this measurement is to support the end-to-end data volume transmission time analysis performed by the NWDAF.

[0150] 6.1.1.1.3 Average UL Packet Delay for QoS Flows between NG-RAN and UE (including D1)

[0151] a) This measurement provides the average UL packet delay for QoS flows between NG-RAN and UE, including the D1 UL PDCP delay that occurs in the UE.

[0152] b) DER (n = 1).

[0153] c) The measurement is obtained by the following method:

[0154] The gNB performs QoS monitoring for each UE for each QoS flow based on the QoS monitoring request received from the SMF during the PDU session establishment or modification process (see TS23.501). The QoS monitoring can be initiated by the management system on the SMF through the QFQoSMonitoringControl MOI (see TS28.541), or by the PCF on the SMF through the QoS monitoring policy included in the PCC rule configuration (see TS23.503).

[0155] For each received GTP PDU monitoring response packet (packet i) for QoS monitoring, the gNB records the following timestamps and information (see TS23.501 and TS 38.415):

[0156] - UL Delay Result from the UE to the NG-RAN, which represents the uplink delay measurement result and is the sum of the delays that occur in the NG-RAN (including the delays at the gNB-CU-UP, on F1-U, and at the gNB-DU), the delay on the Uu interface, and the D1 UL PDCP delay that occurs in the UE (see TS 38.415, and the UL delay result is denoted as DRul in this document).

[0157] The gNB counts the number (N) of GTP PDU monitoring response packets received for the S-NSSAI and QoS flow within the granularity period, and takes the arithmetic mean of the DRul of the N packets.

[0158] d) Each measurement value is a real number representing the average delay within 0.1 milliseconds.

[0159] e) GTP.DelayUlNgranUeMeanIncD1.SNSSAI.QFI.

[0160] Where SNSSAI represents the S-NSSAI and QFI represents the QoS flow.

[0161] f) NRCellCU (for non-split and 2-split scenarios);

[0162] GNBCUUPFunction (for 3-split scenarios).

[0163] g) RAN UE Id.

[0164] h) One use of this measurement is to support the end-to-end data volume transmission time analysis performed by the NWDAF.

[0165] 6.x.1.1.4 PSA UPF and NG-RAN Average DL Packet Delay for QoS Flow

[0166] a) This measurement provides the average DL packet delay between the PSA UPF and the NG-RAN for the QoS flow. This measurement is only applicable when the PSA UPF and the NG-RAN are time synchronized.

[0167] b) DER (n = 1).

[0168] c) The measurement is obtained by the following method:

[0169] The gNB performs QoS monitoring per UE per QoS flow based on the QoS monitoring request received from the SMF during the PDU session establishment or modification process (see TS 23.501). The QoS monitoring can be initiated by the management system on the SMF through the QFQoSMonitoringControl MOI (see TS 28.541), or by the PCF on the SMF through the QoS monitoring policy included in the PCC rule configuration (see TS 23.503).

[0170] For each received GTP PDU monitoring response packet for QoS monitoring (packet i), the gNB records the following timestamps and information (see TS 23.501 and TS 38.415):

[0171] - T1 received in the GTP-U header, indicating the local time when the PSA UPF sends the DL GTP PDU;

[0172] - T2 when the NG-RAN receives the DL GTP PDU.

[0173] The gNB counts the number (N) of GTP PDU monitoring response packets received for the S-NSSAI and QoS flow within the granularity period and performs the following calculations:

[0174]

[0175] d) Each measurement value is a real number representing the average delay within 0.1 milliseconds.

[0176] e) GTP.DelayDlPsaUpfNgranMean.SNSSAI.QFI.

[0177] where SNSSAI represents the S-NSSAI and QFI represents the QoS flow.

[0178] f) EP_N3 (contained by the GNBCUUPFunction).

[0179] g) RAN UE Id.

[0180] h) One use of this measurement is to support the end-to-end data volume transmission time analysis performed by the NWDAF.

[0181] In this document, DER refers to Discrete Event Registration. Data related to specific events is captured. Every n events are registered, where n can be 1 or a larger value. The value of n depends on the occurrence frequency of the measured events. DER measurements should be reset at the start of each granularity period and valid results are available at the end of the granularity period. EP_N3, EP_N9, etc. are IOCs representing the N3 and N9 endpoints defined in TS28.541 respectively. As mentioned above, the measurements are divided into sub-counters based on each S-NSSAI and each QoS flow, such as GTP.DelayUlPsaUpfNgranMean.SNSSAI.QFI, GTP.DelayDlNgranUeMean.SNSSAI.QFI, GTP.DelayUlNgranUeMeanExcD1.SNSSAI.QFI, GTP.DelayUlNgranUeMeanIncD1.SNSSAI.QFI, GTP.DelayDlPsaUpfNgranMean.SNSSAI.QFI.

[0182] The technical solution of this disclosure provides a method for collecting and generating performance measurements. In addition, performance measurement results related to one-way delay for each UE and each QoS flow between the PSA UPF and the NG-RAN are generated, as well as measurement results for UL / DL delay between the NG-RAN and the UE. The measurement results related to the user plane packet delay for each UE and each QoS flow reflect the user experience and can be used to optimize the delay performance when necessary.

[0183] Figure 6 A wireless network 600 is schematically shown according to various embodiments. The wireless network 600 may include a UE 602 that communicates wirelessly with an AN 604. The UE 602 and the AN 604 may be similar to and substantially interchangeable with the identically named components described elsewhere in this document.

[0184] The UE 602 may be communicatively coupled to the AN 604 via a connection 606. The connection 606 is shown as an air interface to enable the communication coupling and may be consistent with cellular communication protocols such as the LTE protocol or the 5G NR protocol operating at millimeter wave (mmWave) or sub-6 GHz frequencies.

[0185] The UE 602 may include a host platform 608 coupled to a modem platform 610. The host platform 608 may include application processing circuitry 612, which may be coupled to protocol processing circuitry 614 of the modem platform 610. The application processing circuitry 612 may run various applications for the UE 602 that source / receive application data. The application processing circuitry 612 may also implement one or more layer operations to send / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations.

[0186] The protocol processing circuitry 614 may implement one or more layer operations to facilitate the transmission or reception of data over the connection 606. The layer operations implemented by the protocol processing circuitry 614 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0187] The modem platform 610 may further include digital baseband circuitry 616, which may implement one or more layer operations of the "lower" layer operations performed by the protocol processing circuitry 614 in the network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding, where these functions may include one or more of the following: 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.

[0188] The modem platform 610 may further include a transmit circuit 618, a receive circuit 620, an RF circuit 622, and an RF front-end (RFFE) circuit 624, which may include or be connected to one or more antenna panels 626. In short, the transmit circuit 618 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; the receive circuit 620 may include an analog-to-digital converter, a mixer, an IF component, etc.; the RF circuit 622 may include a low-noise amplifier, a power amplifier, a power tracking component, etc.; the RFFE circuit 624 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 618, the receive circuit 620, the RF circuit 622, the RFFE circuit 624, and the antenna panel 626 (collectively referred to as the "transmit / receive components") may be specific to the details of a 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 a plurality of parallel transmit / receive chains and may be arranged in the same or different chips / modules, etc.

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

[0190] UE reception may be established through and via the antenna panel 626, the RFFE circuit 624, the RF circuit 622, the receive circuit 620, the digital baseband circuit 616, and the protocol processing circuit 614. In some embodiments, the antenna panel 626 may receive transmissions from the AN 604 by receiving beamformed signals received by a plurality of antennas / antenna elements of one or more antenna panels 626.

[0191] UE transmission may be established via and through the protocol processing circuit 614, the digital baseband circuit 616, the transmit circuit 618, the RF circuit 622, the RFFE circuit 624, and the antenna panel 626. In some embodiments, the transmit components of the UE 604 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panel 626.

[0192] Similar to UE 602, AN 604 may include a host platform 628 coupled to a modem platform 630. The host platform 628 may include application processing circuitry 632 coupled to protocol processing circuitry 634 of the modem platform 630. The modem platform may also include digital baseband circuitry 636, transmit circuitry 638, receive circuitry 640, RF circuitry 642, RFFE circuitry 644, and an antenna panel 646. The components of AN 604 may be similar to the similarly named components of UE 602 and may be substantially interchangeable with the similarly named components of UE 602. In addition to performing data transmission / reception as described above, the components of AN 608 may also perform various logical functions, which may include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0193] Figure 7 An example of components of a device 700 is shown in accordance with some embodiments. In some embodiments, device 700 may include at least application circuitry 702, baseband circuitry 704, radio frequency (RF) circuitry 706, front end module (FEM) circuitry 708, one or more antennas 710, and a power management circuit (PMC) 712 coupled together as shown. The components of the illustrated device 700 may be included in a UE or an AN. In some embodiments, device 700 may include fewer elements (e.g., an AN may not use application circuitry 702 but may include a processor / controller to process IP data received from the EPC). In some embodiments, device 700 may include additional elements such as a memory / storage device, a display, a camera, a sensor, or an input / output (I / O) interface. In other embodiments, the components described below may be included in more than one device (e.g., for Cloud-RAN (C-RAN) implementations, the circuitry may be separately included in more than one device).

[0194] Application circuitry 702 may include one or more application processors. For example, application circuitry 702 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The (one or more) processors may include any combination of general purpose processors and dedicated processors (e.g., a graphics processor, an application processor, etc.). The processor may be coupled to a memory / storage device or may include a memory / storage device and may be configured to run instructions stored in the memory / storage device such that various applications and / or operating systems can run on device 700. In some embodiments, the processor of application circuitry 702 may process IP packets received from the EPC.

[0195] The baseband circuit 704 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuit 704 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of the RF circuit 706 and generate baseband signals for the transmit signal path of the RF circuit 706. The baseband processing circuit 704 may interface with the application circuit 702 to generate and process baseband signals and control the operation of the RF circuit 706. For example, in some embodiments, the baseband circuit 704 may include a third-generation (3G) baseband processor 704A, a fourth-generation (4G) baseband processor 704B, a fifth-generation (5G) baseband processor 704C, or one or more other baseband processors 704D for other existing generations, generations under development, or generations to be developed in the future (e.g., sixth-generation (6G), etc.). The baseband circuit 704 (e.g., one or more of the baseband processors 704A-D) may process various radio control functions that support communication with one or more radio networks via the RF circuit 706. In other embodiments, some or all of the functions of the baseband processors 704A-D may be included in modules stored in the memory 704G and these functions may be executed via the central processing unit (CPU) 704E. The radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some embodiments, the modulation / demodulation circuitry of the baseband circuit 704 may include fast Fourier transform (FFT), precoding, and / or constellation mapping / demapping functions. In some embodiments, the encoding / decoding circuitry of the baseband circuit 704 may include convolutional, tail-biting convolutional, turbo, Viterbi, and / or low-density parity-check (LDPC) encoder / decoder functions. Embodiments of the modulation / demodulation and encoder / decoder functions are not limited to these examples and may include other suitable functions in other embodiments.

[0196] In some embodiments, the baseband circuit 704 may include one or more audio digital signal processors (DSPs) 704F. The one or more audio DSPs 704F may include elements for compression / decompression and echo cancellation and may include other suitable processing elements in other embodiments. In some embodiments, the components of the baseband circuit may be appropriately combined on a single chip, a single chipset, or arranged on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuit 704 and the application circuit 702 may be implemented together, for example, on a system-on-chip (SOC).

[0197] In some embodiments, the baseband circuit 704 may provide communications compatible with one or more radio technologies. For example, in some embodiments, the baseband circuit 704 may support communications with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area network (WMAN), wireless local area network (WLAN), wireless personal area network (WPAN). Embodiments where the baseband circuit 704 is configured to support radio communications for more than one wireless protocol may be referred to as multi-mode baseband circuits.

[0198] The RF circuit 706 may support communications with a wireless network using modulated electromagnetic radiation via a non-solid medium. In various embodiments, the RF circuit 706 may include switches, filters, amplifiers, etc. to assist with communications with the wireless network. The RF circuit 706 may include a receive signal path that may include circuitry for down-converting an RF signal received from the FEM circuit 708 and providing a baseband signal to the baseband circuit 704. The RF circuit 706 may also include a transmit signal path that may include circuitry for up-converting a baseband signal provided by the baseband circuit 704 and providing an RF output signal to the FEM circuit 708 for transmission.

[0199] In some embodiments, the receive signal path of the RF circuit 706 may include a mixer circuit 706a, an amplifier circuit 706b, and a filter circuit 706c. In some embodiments, the transmit signal path of the RF circuit 706 may include the filter circuit 706c and the mixer circuit 706a. The RF circuit 706 may also include a synthesizer circuit 706d that is used to synthesize frequencies for use by the mixer circuit 706a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 706a of the receive signal path may be configured to down-convert an RF signal received from the FEM circuit 708 based on a synthesized frequency provided by the synthesizer circuit 706d. The amplifier circuit 706b may be configured to amplify the down-converted signal, and the filter circuit 706c may be a low-pass filter (LPF) or a band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to the baseband circuit 704 for further processing. In some embodiments, the output baseband signal may be a zero-frequency baseband signal, but this is not required. In some embodiments, the mixer circuit 706a of the receive signal path may include a passive mixer, but the scope of the embodiments is not limited in this regard.

[0200] In some embodiments, the mixer circuit 706a of the transmit signal path may be configured to up-convert an input baseband signal based on a synthesized frequency provided by the synthesizer circuit 706d to generate an RF output signal for the FEM circuit 708. The baseband signal may be provided by the baseband circuit 704 and may be filtered by the filter circuit 706c.

[0201] In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may include two or more mixers and may be arranged for quadrature down-conversion and / or up-conversion, respectively. In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may be arranged for direct down-conversion and / or direct up-conversion, respectively. In some embodiments, the mixer circuit 706a of the receive signal path and the mixer circuit 706a of the transmit signal path may be configured for superheterodyne operation.

[0202] In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, but the scope of the embodiments is not limited in this regard. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, the RF circuit 706 may include an analog-to-digital converter (ADC) and a digital-to-analog converter (DAC) circuit, and the baseband circuit 704 may include a digital baseband interface for communicating with the RF circuit 706.

[0203] In some dual-mode embodiments, a separate radio IC circuit may be provided to process signals for each spectrum, but the scope of the embodiments is not limited in this regard.

[0204] In some embodiments, the synthesizer circuit 706d may be a fractional-N synthesizer or a fractional-N / N+1 synthesizer, but the scope of the embodiments is not limited in this regard as other types of frequency synthesizers may be suitable. For example, the synthesizer circuit 706d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0205] The synthesizer circuit 706d may be configured to synthesize an output frequency for use by the mixer circuit 706a of the RF circuit 706 based on a frequency input and a frequency divider control input. In some embodiments, the synthesizer circuit 706d may be a fractional-N / N+1 synthesizer.

[0206] In some embodiments, the frequency input may be provided by a voltage controlled oscillator (VCO), but this is not required. The divider control input may be provided by the baseband circuit 704 or the application processor 702 according to the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application processor 702.

[0207] The synthesizer circuit 706d of the RF circuit 706 may include a frequency divider, a delay locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual modulus divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide an input signal by N or N + 1 (e.g., based on a carry output) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded tunable delay elements, a phase detector, a charge pump, and a D-type flip-flop. In these embodiments, the delay elements may be configured to decompose a VCO period into at most Nd equal phase bins, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO period.

[0208] In some embodiments, the synthesizer circuit 706d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used with a quadrature generator and a frequency divider circuit to generate multiple signals having multiple different phases from each other at the carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 706 may include an IQ / polarity converter.

[0209] The FEM circuit 708 may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more antennas 710, amplify the received signals, and provide an amplified version of the received signals to the RF circuit 706 for further processing. The FEM circuit 708 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by the RF circuit 706 for transmission by one or more of the one or more antennas 710. In various embodiments, the amplification through the transmit signal path or the receive signal path may be done only in the RF circuit 706, only in the FEM 708, or in both the RF circuit 706 and the FEM 708.

[0210] In some embodiments, the FEM circuit 708 may include a TX / RX switch to switch between transmit mode and receive mode operations. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include a low noise amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to the RF circuit 706). The transmit signal path of the FEM circuit 708 may include a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuit 706) and one or more filters for generating an RF signal for subsequent transmission (e.g., via one or more of the one or more antennas 710).

[0211] In some embodiments, the PMC 712 may manage the power provided to the baseband circuit 704. Specifically, the PMC 712 may control power selection, voltage scaling, battery charging, or DC-DC conversion. When the device 700 is capable of being powered by a battery, e.g., when the device is included in a UE, the PMC 712 may typically be included. The PMC 712 may improve power conversion efficiency while providing desired implementation size and thermal characteristics.

[0212] Although Figure 7 it is shown that the PMC 712 is coupled only to the baseband circuit 704. However, in other embodiments, the PMC 712 may additionally or alternatively be coupled to other components and perform similar power management operations on the other components, such as but not limited to the application circuit 702, the RF circuit 706, or the FEM 708.

[0213] In some embodiments, the PMC 712 may control various power saving mechanisms of the device 700 or otherwise be part of various power saving mechanisms of the device 700. For example, if the device 700 is in the RRC_Connected state, in which the device 700 remains connected to the RAN node when it is expected to receive traffic soon and may then enter a state called discontinuous reception mode (DRX) after a period of inactivity. During this state, the device 700 may power down for short time intervals, thus saving power.

[0214] If there is no data traffic activity for an extended period, the device 700 may transition to the RRC_Idle state, in which the device 700 disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 700 enters a very low power state and performs paging, where the device 700 wakes up periodically again to listen to the network and then powers down again. The device 700 may not receive data in this state and may transition back to the RRC_Connected state in order to receive data.

[0215] An additional power saving mode may allow the device to be unavailable to the network for a period longer than the paging interval (ranging from a few seconds to a few hours). During this period, the device has no access to the network at all and may be completely powered off. Any data sent during this period will incur a significant delay, and it is assumed that the delay is acceptable.

[0216] The processors of the application circuit 702 and the baseband circuit 704 can be used to execute elements of one or more instances of the protocol stack. For example, the processor of the baseband circuit 704 (alone or in combination) can be used to execute layer 3, layer 2, or layer 1 functions, while the processor of the application circuit 704 can utilize the data received from these layers (e.g., packet data) and further execute layer 4 functions (e.g., the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include the RRC layer. As mentioned herein, layer 2 may include the Medium Access Control (MAC) layer, the Radio Link Control (RLC) layer, and the Packet Data Convergence Protocol (PDCP) layer. As mentioned herein, layer 1 may include the physical (PHY) layer of the UE / RAN node.

[0217] Figure 8 An example of an infrastructure device 800 according to various embodiments is shown. The infrastructure device 800 (or "system 800") may be implemented as a base station, a radio headend, a RAN node, etc., such as the RAN nodes 111 and 112 shown and described previously. In other examples, the system 800 may be implemented in or by a UE, one or more application servers 130, and / or any other element / device discussed herein. The system 800 may include one or more of the following: an application circuit 805, a baseband circuit 810, one or more radio front-end modules 815, a memory 820, a power management integrated circuitry (PMIC) 825, a power triple circuit 830, a network controller 835, a network interface connector 840, a satellite positioning circuit 845, and a user interface 850. In some embodiments, the device 800 may include additional elements, such as a memory / storage device, a display, a camera, a sensor, or an input / output (I / O) interface element. In other embodiments, the components described below may be included in more than one device (e.g., for a Cloud RAN (C-RAN) implementation, the circuits may be separately included in more than one device).

[0218] As used herein, the term "circuit" may refer to, be part of, or include hardware components such as the following that are configured to provide the described functionality: electronic circuits, logic circuits, processors (shared, dedicated, or grouped) and / or memories (shared, dedicated, or grouped), application specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or system-on-chip (SoC)), digital signal processors (DSPs), and so on. In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functionality. Additionally, the term "circuit" may also refer to a combination of one or more hardware elements (or circuits used in an electrical or electronic system) and program code for performing the functionality of the program code. In these embodiments, the combination of the hardware element and the program code may be referred to as a specific type of circuit.

[0219] The terms "application circuit" and / or "baseband circuit" may be considered synonymous with "processor circuit" and may be referred to as "processor circuit". As used herein, the term "processor circuit" may refer to a circuit that is, is part of, or includes a circuit that is capable of sequentially and automatically performing a sequence of arithmetic or logical operations; and recording, storing, and / or transmitting digital data. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, physical central processing units (CPUs), single-core processors, dual-core processors, triple-core processors, quad-core processors, and / or any other device capable of executing or otherwise operating on computer-executable instructions such as program code, software modules, and / or functional procedures.

[0220] The application circuit 805 may include one or more central processing unit (CPU) cores and one or more of the following: cache memory, a low drop-out (LDO) voltage regulator, an interrupt controller, a serial interface such as an SPI, I2C, or general-purpose programmable serial interface module, a real time clock (RTC), timer-counters including interval and watchdog timers, general-purpose input / output (I / O or IO), a memory card controller such as a Secure Digital (SD) / MultiMediaCard (MMC), a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. As an example, the application circuit 805 may include one or more Intel or processors; Advanced Micro Devices (AMD) processors, Accelerated Processing Unit (APU), or processors; and so on. In some embodiments, the system 800 may not utilize the application circuit 805 but may instead include, for example, a dedicated processor / controller to process the IP data received from the EPC or 5GC.

[0221] Additionally or alternatively, application circuitry 805 may include circuitry such as, but not limited to: one or more field programmable devices (FPDs), such as field programmable gate arrays (FPGAs), etc.; programmable logic devices (PLDs), such as complex PLDs (CPLDs), high capacity PLDs (HCPLDs), etc.; ASICs, such as structured ASICs, etc.; programmable system on chips (PSoCs); etc. In such an embodiment, the circuitry of application circuitry 805 may include logic blocks or logic architectures, including other interconnected resources, which may be programmed to perform various functions, such as the processes, methods, functions, etc. of the various embodiments discussed herein. In such an embodiment, the circuitry of application circuitry 805 may include storage units (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse, etc.) for storing logic blocks, logic architectures, data, etc. in a lookup-table (LUT), etc.).

[0222] Baseband circuitry 810 may be implemented, for example, as a soldered-in substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module including two or more integrated circuits. Although not shown, baseband circuitry 810 may include one or more digital baseband systems, which may be coupled to the CPU subsystem, audio subsystem, and interface subsystem via an interconnect subsystem. The digital baseband subsystem may also be coupled to a digital baseband interface and a mixed signal baseband subsystem via an additional interconnect subsystem. Each interconnect subsystem may include a bus system, point-to-point connections, a network-on-chip (NOC) architecture, and / or some other suitable bus or interconnect technology, such as those discussed herein. The audio subsystem may include digital signal processing circuitry, buffer memories, program memories, voice processing accelerator circuitry, data converter circuitry such as analog-to-digital and digital-to-analog converter circuitry, analog circuitry including one or more amplifiers and filters, and / or other similar components. In one aspect of the present disclosure, baseband circuitry 810 may include protocol processing circuitry having one or more instances of control circuitry (not shown) to provide control functions for the digital baseband circuitry and / or radio frequency circuitry (e.g., radio front-end module 815).

[0223] The user interface circuit 850 may include one or more user interfaces designed to enable user interaction with the system 800 or a peripheral component interface designed to enable interaction with peripheral components of the system 800. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, a speaker or other audio emitting device, a microphone, a printer, a scanner, headphones, a display screen or display device, and so on. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, and so on.

[0224] The radio front-end module (RFEM) 815 may include a millimeter-wave RFEM and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some implementations, one or more sub-millimeter-wave RFICs may be physically separated from the millimeter-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter-wave and sub-millimeter-wave radio functions may be implemented in the same physical radio front-end module 815. The RFEM 815 may include both millimeter-wave antennas and sub-millimeter-wave antennas.

[0225] The memory circuit 820 may include one or more of the following: volatile memory, including dynamic random access memory (DRAM) and / or synchronous dynamic random access memory (SDRAM); and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), and so on, and may include three-dimensional (3D) cross-point (XPOINT) memory from and The memory circuit 820 may be implemented as one or more of a soldered-in package integrated circuit, a socketed memory module, and a plug-in memory card.

[0226] The PMIC 825 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources such as a battery or a capacitor. The power alarm detection circuit may detect one or more of a power loss (under-voltage) and a surge (over-voltage) condition. The power triple circuit 830 may provide power drawn from a network cable to provide both power supply and data connectivity to the infrastructure device 800 using a single cable.

[0227] The network controller circuit 835 may provide connectivity to the network using a standard network interface protocol such as Ethernet, Ethernet over Generic Routing Encapsulation (GRE) tunnels, Multiprotocol Label Switching (MPLS)-based Ethernet, or some other suitable protocol. Network connectivity may be provided to / from the infrastructure device 800 via a physical connection through a network interface connector 840, which may be electrical (commonly referred to as “copper interconnect”), optical, or wireless. The network controller circuit 835 may include one or more dedicated processors and / or field-programmable gate arrays (FPGAs) to communicate using one or more of the above protocols. In some implementations, the network controller circuit 835 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0228] The positioning circuit 845 may include circuitry to receive and decode signals transmitted by one or more navigation satellite constellations of a global navigation satellite system (GNSS). Examples of navigation satellite constellations (or GNSS) may include the Global Positioning System (GPS) of the United States, the Global Navigation System (GLONASS) of Russia, the Galileo system of the European Union, the Beidou Navigation Satellite System of China, regional navigation systems, or GNSS augmentation systems (e.g., Navigation with Indian Constellation (NAVIC) of India, the Quasi-Zenith Satellite System (QZSS) of Japan, the Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS) of France, etc.), etc. The positioning circuit 845 may include various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate communication over-the-air (OTA)) to communicate with components of the positioning network (e.g., navigation satellite constellation nodes).

[0229] (One or more) nodes or satellites of a navigation satellite constellation (“GNSS nodes”) may provide positioning services by continuously transmitting or broadcasting GNSS signals along a line of sight, which may be used by a GNSS receiver (e.g., positioning circuitry 845 and / or positioning circuitry implemented by UEs 101, 102, etc.) to determine its GNSS position. The GNSS signals may include a pseudorandom code known to the GNSS receiver (e.g., a sequence of ones and zeros) and a message including the time of transmission (ToT) of the code epoch (e.g., a defined point in the pseudorandom code sequence) and the GNSS node position at the ToT. The GNSS receiver may monitor / measure GNSS signals transmitted / broadcast by multiple GNSS nodes (e.g., four or more satellites) and solve various equations to determine the corresponding GNSS position (e.g., spatial coordinates). The GNSS receiver also implements a clock that is generally not as stable and accurate as the atomic clocks of GNSS nodes, and the GNSS receiver may use the measured GNSS signals to determine the deviation of the GNSS receiver from true time (e.g., the offset of the GNSS receiver clock from the GNSS node time). In some embodiments, the positioning circuitry 845 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC that uses a primary timing clock to perform position tracking / estimation without GNSS assistance.

[0230] The GNSS receiver may measure the time of arrival (ToA) of GNSS signals from multiple GNSS nodes according to its own clock. The GNSS receiver may determine a time of flight (ToF) value for each received GNSS signal according to the ToA and ToT, and then may determine a three-dimensional (3D) position and a clock deviation according to the ToF. The 3D position may then be converted into latitude, longitude, and altitude. The positioning circuitry 845 may provide data to the application circuitry 805, which may include one or more of position data or time data. The application circuitry 805 may use the time data to synchronize operations with other radio base stations (e.g., RAN nodes 111, 112, etc.).

[0231] Figure 8The components shown can communicate with each other using an interface circuit. As used herein, the term "interface circuit" can refer to a circuit that supports the exchange of information between two or more components or devices, is part of such a circuit, or includes such a circuit. The term "interface circuit" can refer to one or more hardware interfaces, such as, for example, a bus, an input / output (I / O) interface, a peripheral component interface, a network interface card, and the like. Any suitable bus technology can be used in various implementations, and the bus technology can include any number of technologies, including Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe), or any number of other technologies. The bus can be, for example, a proprietary bus used in a system-on-chip (SoC)-based system. Other bus systems can be included, such as an I2C interface, an SPI interface, a point-to-point interface, and a power bus, and the like.

[0232] Figure 9 is a block diagram showing components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein. Specifically, Figure 9 shows a graphical representation of hardware resources 900, which includes one or more processors (or processor cores) 910, one or more memory / storage devices 920, and one or more communication resources 930, each of which can be communicatively coupled via a bus 940. The hardware resources 900 can be part of a UE, an AN, or an LMF. For embodiments that utilize node virtualization (e.g., NFV), a hypervisor 902 can be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 900.

[0233] The processor 910 (e.g., 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 digital signal processor (DSP) such as a baseband processor, an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) can include, for example, a processor 912 and a processor 914.

[0234] The memory / storage device 920 may include a main memory, a disk memory, or any suitable combination thereof. The memory / storage device 920 may include, but is not limited to, any type of volatile or non-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 devices, etc.

[0235] The communication resources 930 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 904 or one or more databases 906 via the network 908. For example, the communication resources 930 may include a wired communication component (e.g., for coupling via a Universal Serial Bus (USB)), a cellular communication component, an NFC component, a Bluetooth component (e.g., Bluetooth Low Energy), a Wi-Fi component, and other communication components.

[0236] The instructions 950 may include software, programs, applications, applets, apps, or other executable code to cause at least any of the processors 910 to perform any one or more of the methods discussed herein. The instructions 950 may reside, in whole or in part, in at least one of the processor 910 (e.g., within the buffer memory of the processor), the memory / storage device 920, or any suitable combination thereof. Additionally, any portion of the instructions 950 may be transferred from any combination of the peripheral devices 904 or the database 906 to the hardware resources 900. Thus, the memories of the processor 910, the memory / storage device 920, the peripheral devices 904, and the database 906 are examples of computer-readable and machine-readable media.

[0237] Figure 10 A diagram of a network 1000 in accordance with various embodiments of the present disclosure is shown. The network 1000 may operate in a manner consistent with the 3GPP technical specifications of an LTE or 5G / NR system. 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, etc.

[0238] Network 1000 may include a UE 1002, which may include any mobile or non-mobile computing device designed to communicate with a RAN 1004 via an air interface. The UE 1002 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, an instrument cluster, a head-up display device, an on-vehicle 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 Internet of Things device, etc.

[0239] In some embodiments, network 1000 may include multiple UEs 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, a Physical Sidelink Broadcast Channel (PSBCH), a Physical Sidelink Discovery Channel (PSDCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Fundamental Channel (PSFCH), etc.).

[0240] In some embodiments, the UE 1002 may also communicate with an AP 1006 via an air interface. The AP 1006 may manage a WLAN connection, which may be used to offload some / all network traffic from the RAN 1004. The connection between the UE 1002 and the AP 1006 may be compliant with any IEEE 802.11 protocol, where the AP 1006 may be a Wi-Fi router. In some embodiments, the UE 1002, the RAN 1004, and the AP 1006 may utilize cellular WLAN aggregation (such as, for example, LTE-WLAN Aggregation (LWA) / Lightweight IP (LWIP)). Cellular WLAN aggregation may involve the UE 1002 configured by the RAN 1004 to utilize both cellular radio resources and WLAN resources.

[0241] RAN 1004 may include one or more access nodes, e.g., AN 1008. AN 1008 may terminate the air interface protocol of UE 1002 by providing access stratum protocols including Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and L1 protocol. In this way, AN 1008 may enable data / voice connectivity between CN 1020 and UE 1002. In some embodiments, AN 1008 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 a Cloud Radio Access Network (CRAN) or a virtual baseband unit pool. AN 1008 may be referred to as a Base Station (BS), gNB, RAN node, evolved Node B (eNB), next generation eNB (ng-eNB), Node B, Road Side Unit (RSU), Transmission and Reception Point (TRxP), Transmission Point (TRP), etc. AN 1008 may be a macro cell base station or a low-power base station for providing a micro cell, a pico cell, or other similar cells with a smaller coverage area, a smaller user capacity, or a higher bandwidth compared to a macro cell.

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

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

[0244] The RAN 1004 can provide an air interface on licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, a node can use Licensed-Assisted Access (LAA), Enhanced LAA (eLAA), and / or Further Enhanced LAA (feLAA) mechanisms based on carrier aggregation (CA) techniques with a Primary Cell (PCell) / Secondary Cell (Scell). Before accessing unlicensed spectrum, a node can perform medium / carrier sensing operations based on, for example, the Listen Before Talk (LBT) protocol.

[0245] In a Vehicle-to-Everything (V2X) scenario, the UE 1002 or the AN 1008 can be or act as a Road Side Unit (RSU), which can refer to any transportation infrastructure entity for V2X communication. The RSU can be implemented in or by a suitable AN or a stationary (or relatively stationary) 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 next-generation NodeB (gNB) can be referred to as a "gNB-type RSU"; and so on. In one example, the RSU is a computing device coupled to a radio frequency circuit located by the roadside, which provides connectivity support to 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 ongoing vehicle and pedestrian traffic. The RSU can provide very low-latency communication required for high-speed events, such as collision avoidance, traffic warnings, etc. 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 signal controller or a backhaul network.

[0246] In some embodiments, the RAN 1004 can be an LTE RAN 1010, which includes an evolved Node B (eNB), e.g., the eNB 1012. The LTE RAN 1010 can provide an LTE air interface with the following characteristics: a Subcarrier Spacing (SCS) of 15 kHz; a Cyclic Prefix - Orthogonal Frequency Division Multiplexing (CP - OFDM) waveform for Downlink (DL) and a Single - Carrier Frequency Division Multiple Access (SC - FDMA) waveform for Uplink (UL); turbo codes for data and Tail - Biting Convolutional Codes (TBCC) for control, etc. The LTE air interface can rely on Channel State Information - Reference Signals (CSI - RS) for CSI acquisition and beam management; rely on Physical Downlink Shared Channel / Physical Downlink Control Channel Demodulation Reference Signals (PDSCH / PDCCH DMRS) for PDSCH / PDCCH demodulation; and rely on Cell - Specific Reference Signals (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 the sub - 6 GHz band.

[0247] In some embodiments, RAN 1004 may be a Next Generation (NG)-RAN 1014 with a gNB (e.g., gNB 1016) or a ng-eNB (e.g., ng-eNB 1018). The gNB 1016 may connect to 5G-enabled UEs using a 5G NR interface. The gNB 1016 may connect to the 5G Core via the NG interface, which may include an N2 interface or an N3 interface. The ng-eNB 1018 may also connect to the 5G Core via the NG interface, but may connect to UEs via an LTE air interface. The gNB 1016 and the ng-eNB 1018 may be connected to each other via an Xn interface.

[0248] In some embodiments, the NG interface may be divided into two parts: an NG User Plane (NG-U) interface and an NG Control Plane (NG-C) interface. The former carries traffic data between nodes of the NG-RAN 1014 and the UPF 1048, and the latter is a signaling interface (e.g., the N2 interface) between the NG-RAN 1014 and nodes of the Access and Mobility Management Function (AMF) 1044.

[0249] The NG-RAN 1014 may 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, repetition, simplex, and Reed-Muller codes for control, and LDPC for data. The 5G-NR air interface may 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 a tracking reference signal for time tracking. The 5G-NR air interface may operate in a FR1 band including the sub-6 GHz band or a FR2 band including the 24.25 GHz to 52.6 GHz band. The 5G-NR air interface may include an SSB, which is an area of the downlink resource grid including PSS / SSS / PBCH.

[0250] In some embodiments, the 5G-NR air interface may use BWPs for various purposes. For example, a BWP may be used for dynamic adaptation of the SCS. For example, UE 1002 may be configured with multiple BWPs, where each BWP configuration has a different SCS. When a BWP change is indicated to UE 1002, the SCS of the transmission also changes. Another use case of the BWP is related to power saving. Specifically, UE 1002 may be configured with multiple BWPs having different numbers of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. A BWP containing a smaller number of PRBs may be used for data transmission with a smaller traffic load, while allowing power saving at UE 1002 and in some cases at gNB 1016. A BWP containing a large number of PRBs may be used for scenarios with a higher traffic load.

[0251] RAN 1004 is communicatively coupled to CN 1020, which includes network elements, to provide various functions supporting data and telecommunications services to customers / subscribers (e.g., the user of UE 1002). The components of CN 1020 may be implemented in one physical node or may be implemented in different physical nodes. In some embodiments, NFV may be used to virtualize any or all of the functions provided by the network elements of CN 1020 onto physical computing / storage resources in servers, switches, etc. A logical instance of CN 1020 may be referred to as a network slice, and a logical instantiation of a part of CN 1020 may be referred to as a network sub-slice.

[0252] In some embodiments, CN 1020 may be an LTE CN 1022, which may also be referred to as an evolved packet core (EPC). LTE CN 1022 may include a mobility management entity (MME) 1024, a serving gateway (SGW) 1026, a serving GPRS support node (SGSN) 1028, a home subscriber server (HSS) 1030, a proxy gateway (PGW) 1032, and a policy control and charging rules function (PCRF) 1034, which are coupled to each other through interfaces (or "reference points") as shown. The functions of the elements of LTE CN 1022 are briefly introduced as follows.

[0253] MME 1024 may implement mobility management functions to track the current location of UE 1002, thus facilitating roaming, bearer activation / deactivation, handover, gateway selection, authentication, etc.

[0254] The Serving Gateway (SGW) 1026 can terminate the S1 interface towards the Radio Access Network (RAN) and route data packets between the RAN and the LTE Core Network (CN) 1022. The SGW 1026 can be a local mobility anchor for inter-RAN node handovers and can also provide anchoring for inter-3GPP mobility. Other responsibilities can include lawful interception, charging, and some policy enforcement.

[0255] The Serving GPRS Support Node (SGSN) 1028 can track the location of the User Equipment (UE) 1002 and perform security functions and access control. Additionally, the SGSN 1028 can perform EPC node-to-node signaling for mobility between different Radio Access Technology (RAT) networks; PDN and S-GW selection as specified by the Mobility Management Entity (MME) 1024; MME selection for handovers, etc. The S3 reference point between the MME 1024 and the SGSN 1028 can enable the exchange of user and bearer information for inter-3GPP access network mobility in the idle / active states.

[0256] The Home Subscriber Server (HSS) 1030 can include a database for network users that includes subscription-related information to support network entities in processing communication sessions. The HSS 1030 can provide support for routing / roaming, authentication, authorization, name / address resolution, location dependency, etc. The S6a reference point between the HSS 1030 and the MME 1024 can enable the transmission of subscription and authentication data to authenticate / authorize user access to the LTE CN 1020.

[0257] The Packet Data Network Gateway (PGW) 1032 can terminate the SGi interface towards the Data Network (DN) 1036 which can include the Application / Content Server 1038. The PGW 1032 can route data packets between the LTE CN 1022 and the data network 1036. The PGW 1032 can be coupled to the SGW 1026 via the S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 1032 can also include a node (e.g., the Policy and Charging Enforcement Function - PCEF) for policy enforcement and charging data collection. Additionally, the SGi reference point between the PGW 1032 and the data network 1036 can be, for example, an operator-external public, private PDN, or an operator-internal packet data network for providing IMS services. The PGW 1032 can be coupled to the Policy and Charging Rules Function (PCRF) 1034 via the Gx reference point.

[0258] The PCRF 1034 is the policy and charging control element of the LTE CN 1022. The PCRF 1034 can be communicatively coupled to the Application / Content Server 1038 to determine the appropriate Quality of Service (QoS) and charging parameters for service flows. The PCRF 1032 can provide the associated rules to the PCEF with the appropriate Traffic Flow Template (TFT) and QoS Class Identifier (QCI) (via the Gx reference point).

[0259] In some embodiments, CN 1020 may be a 5G Core Network (5GC) 1040. The 5GC 1040 may include an Authentication Server Function (AUSF) 1042, an Access and Mobility Management Function (AMF) 1044, a Session Management Function (SMF) 1046, a User Plane Function (UPF) 1048, a Network Slice Selection Function (NSSF) 1050, a Network Exposure Function (NEF) 1052, an NF Repository Function (NRF) 1054, a Policy Control Function (PCF) 1056, a Unified Data Management (UDM) 1058, and an Application Function (AF) 1060. As shown, these functions are coupled to each other via interfaces (or "reference points"). The functions of the elements of the 5GC 1040 are briefly introduced as follows.

[0260] The AUSF 1042 may store authentication data for the UE 1002 and handle authentication-related functions. The AUSF 1042 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 1040 via reference points as shown, the AUSF 1042 may also expose an interface based on the Nausf service.

[0261] The AMF 1044 may allow other functions of the 5GC 1040 to communicate with the UE 1002 and the RAN 1004, and subscribe to notifications about mobility events of the UE 1002. The AMF 1044 may be responsible for registration management (e.g., registering the UE 1002), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 1044 may provide the transmission of session management (SM) messages between the UE 1002 and the SMF 1046, and act as a transparent proxy for routing SM messages. The AMF 1044 may also provide the transmission of SMS messages between the UE 1002 and the SMSF. The AMF 1044 may interact with the AUSF 1042 and the UE 1002 to perform various security anchoring and context management functions. In addition, the AMF 1044 may be a termination point of the RANCP interface, which may include or be the N2 reference point between the RAN 1004 and the AMF 1044; the AMF 1044 may act as a termination point for NAS (N1) signaling and perform NAS encryption and integrity protection. The AMF 1044 may also support NAS signaling with the UE 1002 via the N3 IWF interface.

[0262] The SMF 1046 can be responsible for session management (e.g., session establishment, tunnel management between the UPF 1048 and the AN 1008); UE IP address allocation and management (including optional authorization); selection and control of the UPF function; configuring traffic control at the UPF 1048 to route traffic to the appropriate destination; termination of the interface to the policy control function; part of the control of policy enforcement, charging, and QoS; lawful interception (for SM events and the interface to the LI system); termination of the SM part of the NAS message; downlink data notification; initiating AN-specific SM information (sent to the AN 1008 on N2 via the AMF 1044); and determining the SSC mode of the session. Session management can refer to the management of the PDU session, and the PDU session or "session" can refer to the PDU connectivity service that provides or enables the PDU exchange between the UE 1002 and the data network 1036.

[0263] The UPF 1048 can serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnecting with the data network 1036, and a branching point for supporting multi-homed PDU sessions. The UPF 1048 can also perform packet routing and forwarding, perform packet inspection, execute the user plane part of the policy rules, lawfully intercept packets (UP collection), execute traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), execute 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 1048 can include an uplink classifier to support routing traffic flows to the data network.

[0264] The NSSF 1050 can select a set of network slice instances to serve the UE 1002. If needed, the NSSF 1050 can also determine the allowed network slice selection assistance information (NSSAI) and the mapping to the subscribed single NSSAI (S-NSSAI). The NSSF 1050 can also determine the set of AMFs to be used to serve the UE 1002 based on appropriate configurations and possibly by querying the NRF 1054, or determine a list of candidate AMFs. The selection of a set of network slice instances for the UE 1002 can be triggered by the AMF 1044 (the UE 1002 registers with the AMF by interacting with the NSSF 1050), which can cause a change in the AMF. The NSSF 1050 can interact with the AMF 1044 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 1050 can expose an interface based on the Nnssf service.

[0265] The NEF 1052 can securely disclose the services and capabilities provided by 3GPP network functions to third parties, for internal disclosure / re-disclosure, to AFs (e.g., AF 1060), edge computing, or fog computing systems. In these embodiments, the NEF 1052 can authenticate, license, or throttle AFs. The NEF 1052 can also translate the information exchanged with the AF 1060 and the information exchanged with internal network functions. For example, the NEF 1052 can convert between an AF service identifier and internal 5GC information. The NEF 1052 can also receive information from other NFs based on the public capabilities of other NFs. This information can be stored at the NEF 1052 as structured data, or stored at the data repository NF using a standardized interface. Then, the NEF 1052 can re-disclose the stored information to other NFs and AFs, or use it for other purposes such as analytics. Additionally, the NEF 1052 can expose an interface based on the Nnef service.

[0266] The NRF 1054 can support a service discovery function, receive NF discovery requests from NF instances, and provide information about the discovered NF instances to NF instances. The NRF 1054 also maintains information about available NF instances and the services they support. As used herein, terms such as "instantiate", "instance", etc. can refer to creating an instance, and an "instance" can refer to a specific occurrence of an object, which can occur, for example, during the execution of program code. Additionally, the NRF 1054 can expose an interface based on the Nnrf service.

[0267] The PCF 1056 can provide policy rules to control plane functions to enforce them, and can also support a unified policy framework to manage network behavior. The PCF 1056 can also implement a front end to access subscription information related to policy decisions in the UDR of the UDM 1058. In addition to communicating with functions via reference points as shown, the PCF 1056 also exposes an interface based on the Npcf service.

[0268] The UDM 1058 can process subscription-related information to support network entities in handling communication sessions and can store the subscription data of the UE 1002. For example, the subscription data can be transmitted via the N8 reference point between the UDM 1058 and the AMF 1044. The UDM 1058 can include two parts: an application front end and a UDR. The UDR can store policy data and subscription data for the UDM 1058 and the PCF 1056, and / or structured data and application data for disclosure (including PFDs for application detection, application request information for multiple UEs 1002) for the NEF 1052. The UDR 221 can expose an interface based on the Nudr service to allow the UDM 1058, the PCF 1056, and the NEF 1052 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 identification processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown, the UDM 1058 can also expose an interface based on the Nudm service.

[0269] The AF 1060 can provide an application impact on traffic routing, provide access to the NEF, and interact with the policy framework for policy control.

[0270] In some embodiments, the 5GC 1040 can enable edge computing by selecting an operator / third-party service that is geographically close to the point where the UE 1002 attaches to the network. This can reduce latency and load on the network. To provide edge computing implementation, the 5GC 1040 can select a UPF 1048 close to the UE 1002 and perform traffic steering from the UPF 1048 to the data network 1036 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by the AF 1060. In this way, the AF 1060 can influence UPF (re)selection and traffic routing. Based on operator deployment, when the AF 1060 is considered a trusted entity, the network operator can allow the AF 1060 to directly interact with the relevant NFs. Additionally, the AF 1060 can expose an interface based on the Naf service.

[0271] The data network 1036 can represent various network operator services, Internet access, or third-party services that can be provided by one or more servers (including, for example, application / content servers 1038).

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

[0273] Example 1 includes an apparatus comprising: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: decode a first request received from a session management function (SMF) or a management system for UE-level measurement collection; perform UE-level measurement collection based on the first request to obtain UE-level measurement results; and report the UE-level measurement results to the SMF or an entity designated by the management system, and wherein the memory is used to store the UE-level measurement results.

[0274] Example 2 includes the apparatus of Example 1, wherein the processor circuit is further configured to: in response to the first request, decode a second request received from the SMF for QoS monitoring per UE per quality of service (QoS) flow; perform QoS monitoring per UE per QoS flow based on the second request to obtain QoS monitoring results; and perform the UE-level measurement collection based on the QoS monitoring results.

[0275] Example 3 includes the apparatus of Example 1 or 2, wherein the second request includes a QoS monitoring request or a tracing request.

[0276] Example 4 includes the apparatus of any one of Examples 1 to 3, wherein the processor circuit is further configured to: encode a monitoring packet based on the second request for transmission to a radio access network (RAN); decode a monitoring response packet received from the RAN in response to the monitoring packet; and obtain the UE-level measurement results based on information obtained from the monitoring response packet.

[0277] Example 5 includes the apparatus of any one of Examples 1 to 4, wherein the UE-level measurement results include the downlink (DL) packet delay between a protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and the RAN, and wherein the processor circuit is further configured to: decode the monitoring response packet to obtain a first time instance T1 indicating the local time at which the PSA UPF sent the monitoring packet and a second time instance T2 indicating the local time at which the RAN received the monitoring packet; and obtain the DL packet delay between the PSA UPF and the RAN based on the time difference between the second time instance T2 and the first time instance T1.

[0278] Example 6 includes the apparatus according to any one of Examples 1 to 5, wherein the UE-level measurement result includes the uplink (UL) packet delay between the protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and the RAN, and wherein the processor circuitry is further configured to: decode the monitoring response packet to obtain a third time instance T3 indicating the local time when the RAN sends the monitoring response packet and a fourth time instance T4 indicating the local time when the PSA UPF receives the monitoring response packet; and obtain the UL packet delay between the PSA UPF and the RAN based on the time difference between the fourth time instance T4 and the third time instance T3.

[0279] Example 7 includes the apparatus according to any one of Examples 1 to 6, wherein the UE-level measurement result includes the downlink (DL) packet delay between the RAN and the UE, and wherein the processor circuitry is further configured to: decode the monitoring response packet to obtain the DL packet delay between the RAN and the UE, wherein the DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

[0280] Example 8 includes the apparatus according to any one of Examples 1 to 7, wherein the UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the processor circuitry is further configured to: decode the monitoring response packet to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0281] Example 9 includes the apparatus according to any one of Examples 1 to 8, wherein the UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the processor circuitry is further configured to: decode the monitoring response packet to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0282] Example 10 includes the apparatus according to any one of Examples 1 to 9, wherein the apparatus is part of a user plane function (UPF).

[0283] Example 11 includes the apparatus according to any one of Examples 1 to 10, wherein the first request is for requesting a downlink (DL) packet delay between a radio access network (RAN) and a UE, and wherein the processor circuitry is further configured to: perform a RAN part of the DL packet delay measurement to obtain the DL packet delay between the RAN and the UE, wherein the DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

[0284] Example 12 includes the apparatus according to any one of Examples 1 to 11, wherein the first request is for requesting an uplink (UL) packet delay between a radio access network (RAN) and a UE, and wherein the processor circuitry is further configured to: perform a RAN part of the UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0285] Example 13 includes the apparatus according to any one of Examples 1 to 12, wherein the first request is for requesting an uplink (UL) packet delay between a radio access network (RAN) and a UE, and wherein the processor circuitry is further configured to: perform a RAN part of the UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0286] Example 14 includes the apparatus according to any one of Examples 1 to 13, wherein the apparatus is part of a next-generation node B (gNB).

[0287] Example 15 includes the apparatus according to any one of Examples 1 to 14, wherein the UE-level measurement results include: an uplink (UL) packet delay between a protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and a radio access network (RAN); a downlink (DL) packet delay between the PSA UPF and the RAN; a UL packet delay between the RAN and the UE; or a DL packet delay between the RAN and the UE.

[0288] Example 16 includes the apparatus according to any one of Examples 1 to 15, wherein the management system includes a management function (MnF).

[0289] Example 17 includes the apparatus according to any one of Examples 1 to 16, wherein the MnF is co-located with the apparatus.

[0290] Example 18 includes the apparatus according to any one of Examples 1 to 17, wherein the MnF is separated from the apparatus.

[0291] Example 19 includes the apparatus according to any one of Examples 1 to 18, wherein the memory is further configured to store a RAN UE Id for UE-level measurement collection.

[0292] Example 20 includes the apparatus according to any one of Examples 1 to 19, wherein the UE-level measurement result is obtained based on specific requirements of the first request and for each service quality (QoS) flow per single network slice selection assistance information (S-NSSAI).

[0293] Example 21 includes a method, comprising: decoding a first request for UE-level measurement collection received from a session management function (SMF) or a management system; performing UE-level measurement collection based on the first request to obtain a UE-level measurement result; and reporting the UE-level measurement result to the SMF or an entity designated by the management system.

[0294] Example 22 includes the method according to Example 21, further comprising: in response to the first request, decoding a second request for QoS monitoring per UE per QoS flow received from the SMF; performing QoS monitoring per UE per QoS flow based on the second request to obtain a QoS monitoring result; and performing the UE-level measurement collection based on the QoS monitoring result.

[0295] Example 23 includes the method according to Example 21 or 22, wherein the second request includes a QoS monitoring request or a trace request.

[0296] Example 24 includes the method according to any one of Examples 21 to 23, further comprising: encoding a monitoring packet based on the second request for transmission to a radio access network (RAN); decoding a monitoring response packet received from the RAN in response to the monitoring packet; and obtaining the UE-level measurement result based on information obtained from the monitoring response packet.

[0297] Example 25 includes the method according to any one of Examples 21 to 24, wherein the UE-level measurement result includes the downlink (DL) packet delay between the protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and the RAN, and wherein the method further includes: decoding the monitoring response packet to obtain a first time instance T1 indicating the local time when the PSA UPF sends the monitoring packet and a second time instance T2 indicating the local time when the RAN receives the monitoring packet; and obtaining the DL packet delay between the PSA UPF and the RAN based on the time difference between the second time instance T2 and the first time instance T1.

[0298] Example 26 includes the method according to any one of Examples 21 to 25, wherein the UE-level measurement result includes the uplink (UL) packet delay between the protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and the RAN, and wherein the method further includes: decoding the monitoring response packet to obtain a third time instance T3 indicating the local time when the RAN sends the monitoring response packet and a fourth time instance T4 indicating the local time when the PSA UPF receives the monitoring response packet; and obtaining the UL packet delay between the PSA UPF and the RAN based on the time difference between the fourth time instance T4 and the third time instance T3.

[0299] Example 27 includes the method according to any one of Examples 21 to 26, wherein the UE-level measurement result includes the downlink (DL) packet delay between the RAN and the UE, and wherein the method further includes: decoding the monitoring response packet to obtain the DL packet delay between the RAN and the UE, where the DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

[0300] Example 28 includes the method according to any one of Examples 21 to 27, wherein the UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the method further includes: decoding the monitoring response packet to obtain the UL packet delay between the RAN and the UE, where the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0301] Example 29 includes the method according to any one of Examples 21 to 28, wherein the UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the method further includes: decoding the monitoring response packet to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0302] Example 30 includes the method according to any one of Examples 21 to 29, wherein the method is applicable to a user plane function (UPF).

[0303] Example 31 includes the method according to any one of Examples 21 to 30, wherein the first request is for requesting the downlink (DL) packet delay between the radio access network (RAN) and the UE, and wherein the method further includes: the RAN part that performs DL packet delay measurement to obtain the DL packet delay between the RAN and the UE, wherein the DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

[0304] Example 32 includes the method according to any one of Examples 21 to 31, wherein the first request is for requesting the uplink (UL) packet delay between the radio access network (RAN) and the UE, and wherein the method further includes: the RAN part that performs UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0305] Example 33 includes the method according to any one of Examples 21 to 32, wherein the first request is for requesting the uplink (UL) packet delay between the radio access network (RAN) and the UE, and wherein the method further includes: the RAN part that performs UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0306] Example 34 includes the method according to any one of Examples 21 to 33, wherein the method is applicable to a next-generation node B (gNB).

[0307] Example 35 includes the method according to any one of Examples 21 to 34, wherein the UE-level measurement result includes: the uplink (UL) packet delay between the protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and the radio access network (RAN); the downlink (DL) packet delay between the PSA UPF and the RAN; the UL packet delay between the RAN and the UE; or the DL packet delay between the RAN and the UE.

[0308] Example 36 includes the method according to any one of Examples 21 to 35, wherein the management system includes a management function (MnF).

[0309] Example 37 includes the method according to any one of Examples 21 to 36, wherein the MnF is co-located with a user plane function (UPF) or a next-generation node B (gNB).

[0310] Example 38 includes the method according to any one of Examples 21 to 37, wherein the MnF is separated from a user plane function (UPF) or a next-generation node B (gNB).

[0311] Example 39 includes the method according to any one of Examples 21 to 38, further comprising: storing the RAN UE Id for UE-level measurement collection.

[0312] Example 40 includes the method according to any one of Examples 21 to 39, wherein the UE-level measurement result is obtained according to the specific requirements of the first request and based on each quality of service (QoS) flow per single network slice selection assistance information (S-NSSAI).

[0313] Example 41 includes an apparatus, comprising: a component for decoding a first request received from a session management function (SMF) or a management system for UE-level measurement collection for a user equipment (UE); a component for performing UE-level measurement collection based on the first request to obtain a UE-level measurement result; and a component for reporting the UE-level measurement result to the SMF or an entity specified by the management system.

[0314] Example 42 includes the apparatus according to Example 41, further comprising: a component for decoding a second request received from the SMF for QoS monitoring based on each UE per quality of service (QoS) flow in response to the first request; a component for performing QoS monitoring based on each UE per QoS flow based on the second request to obtain a QoS monitoring result; and a component for performing the UE-level measurement collection based on the QoS monitoring result.

[0315] Example 43 includes the apparatus according to Example 41 or 42, wherein the second request includes a QoS monitoring request or a tracking request.

[0316] Example 44 includes the apparatus according to any one of Examples 41 to 43, further comprising: components for encoding a monitoring packet based on the second request for transmission to a radio access network (RAN); components for decoding a monitoring response packet received from the RAN in response to the monitoring packet; and components for obtaining the UE-level measurement result based on information obtained from the monitoring response packet.

[0317] Example 45 includes the apparatus according to any one of Examples 41 to 44, wherein the UE-level measurement result includes a downlink (DL) packet delay between a protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and the RAN, and wherein the apparatus further comprises: components for decoding the monitoring response packet to obtain a first time instance T1 indicating a local time at which the PSA UPF sent the monitoring packet and a second time instance T2 indicating a local time at which the RAN received the monitoring packet; and components for obtaining the DL packet delay between the PSA UPF and the RAN based on a time difference between the second time instance T2 and the first time instance T1.

[0318] Example 46 includes the apparatus according to any one of Examples 41 to 45, wherein the UE-level measurement result includes an uplink (UL) packet delay between a protocol data unit (PDU) session anchor (PSA) user plane function (UPF) and the RAN, and wherein the apparatus further comprises: components for decoding the monitoring response packet to obtain a third time instance T3 indicating a local time at which the RAN sent the monitoring response packet and a fourth time instance T4 indicating a local time at which the PSA UPF received the monitoring response packet; and components for obtaining the UL packet delay between the PSA UPF and the RAN based on a time difference between the fourth time instance T4 and the third time instance T3.

[0319] Example 47 includes the apparatus according to any one of Examples 41 to 46, wherein the UE-level measurement result includes a downlink (DL) packet delay between the RAN and the UE, and wherein the apparatus further comprises: components for decoding the monitoring response packet to obtain the DL packet delay between the RAN and the UE, wherein the DL packet delay between the RAN and the UE is the sum of a delay occurring in the RAN and a delay on the Uu interface.

[0320] Example 48 includes the apparatus according to any one of Examples 41 to 47, wherein the UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the apparatus further includes: a component for decoding the monitoring response packet to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0321] Example 49 includes the apparatus according to any one of Examples 41 to 48, wherein the UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the apparatus further includes: a component for decoding the monitoring response packet to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0322] Example 50 includes the apparatus according to any one of Examples 41 to 49, wherein the apparatus is part of a user plane function (UPF).

[0323] Example 51 includes the apparatus according to any one of Examples 41 to 50, wherein the first request is for requesting the downlink (DL) packet delay between the radio access network (RAN) and the UE, and wherein the apparatus further includes: a component of the RAN for performing DL packet delay measurement to obtain the DL packet delay between the RAN and the UE, wherein the DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

[0324] Example 52 includes the apparatus according to any one of Examples 41 to 51, wherein the first request is for requesting the uplink (UL) packet delay between the radio access network (RAN) and the UE, and wherein the apparatus further includes: a component of the RAN for performing UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0325] Example 53 includes the apparatus according to any one of Examples 41 to 52, wherein the first request is for requesting uplink (UL) packet delay between a radio access network (RAN) and a UE, and wherein the apparatus further includes: a RAN part for performing UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, where the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

[0326] Example 54 includes the apparatus according to any one of Examples 41 to 53, wherein the apparatus is part of a next-generation node B (gNB).

[0327] Example 55 includes the apparatus according to any one of Examples 41 to 54, wherein the UE-level measurement results include: uplink (UL) packet delay between a protocol data unit (PDU) session anchor point (PSA) user plane function (UPF) and a radio access network (RAN); downlink (DL) packet delay between the PSA UPF and the RAN; UL packet delay between the RAN and the UE; or DL packet delay between the RAN and the UE.

[0328] Example 56 includes the apparatus according to any one of Examples 41 to 55, wherein the management system includes a management function (MnF).

[0329] Example 57 includes the apparatus according to any one of Examples 41 to 56, wherein the MnF is co-located with the apparatus.

[0330] Example 58 includes the apparatus according to any one of Examples 41 to 57, wherein the MnF is separated from the apparatus.

[0331] Example 59 includes the apparatus according to any one of Examples 41 to 58, further including: a component for storing the RAN UE Id for UE-level measurement collection.

[0332] Example 60 includes the apparatus according to any one of Examples 41 to 59, wherein the UE-level measurement results are obtained based on each service quality (QoS) flow and each single network slice selection assistance information (S-NSSAI) according to the specific requirements of the first request.

[0333] Example 61 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 21 to 40.

[0334] 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 be substituted for 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. Accordingly, it is readily understood that the embodiments described herein are limited only by the appended claims and their equivalent scope.

Claims

1. A device, comprising: a memory; and a processor circuit coupled to the memory, wherein the processor circuit is configured to: decode a first request received from a Session Management Function (SMF) or a management system for UE-level measurement collection; perform UE-level measurement collection based on the first request to obtain UE-level measurement results; and report the UE-level measurement results to the SMF or an entity designated by the management system, and wherein the memory is used to store the UE-level measurement results.

2. The device according to claim 1, wherein The processor circuit is further configured to: in response to the first request, decode a second request received from the SMF for QoS monitoring per UE per Quality of Service (QoS) flow; perform QoS monitoring per UE per QoS flow based on the second request to obtain QoS monitoring results; and perform the UE-level measurement collection based on the QoS monitoring results.

3. The device according to claim 2, wherein The second request includes a QoS monitoring request or a trace request.

4. The apparatus according to claim 2, wherein, The processor circuit is further configured to: encode a monitoring packet based on the second request for transmission to a Radio Access Network (RAN); decode a monitoring response packet received from the RAN in response to the monitoring packet; and obtain the UE-level measurement results based on information obtained from the monitoring response packet.

5. The device according to claim 4, wherein, The UE-level measurement results include the downlink (DL) packet delay between a Protocol Data Unit (PDU) Session Anchor (PSA) User Plane Function (UPF) and the RAN, and wherein the processor circuit is further configured to: decode the monitoring response packet to obtain a first time instance T1 indicating the local time when the PSA UPF sent the monitoring packet and a second time instance T2 indicating the local time when the RAN received the monitoring packet; and obtain the DL packet delay between the PSA UPF and the RAN based on the time difference between the second time instance T2 and the first time instance T1.

6. The apparatus according to claim 4, wherein, The UE-level measurement results include the uplink (UL) packet delay between a Protocol Data Unit (PDU) Session Anchor (PSA) User Plane Function (UPF) and the RAN, and wherein the processor circuit is further configured to: decode the monitoring response packet to obtain a third time instance T3 indicating the local time when the RAN sent the monitoring response packet and a fourth time instance T4 indicating the local time when the PSA UPF received the monitoring response packet; and obtain the UL packet delay between the PSA UPF and the RAN based on the time difference between the fourth time instance T4 and the third time instance T3.

7. The apparatus according to claim 4, wherein The UE-level measurement results include the downlink (DL) packet delay between the RAN and the UE, and wherein the processor circuit is further configured to: decode the monitoring response packet to obtain the DL packet delay between the RAN and the UE, The DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

8. The device according to claim 4, wherein, The UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the processor circuit is further configured to: decode the monitoring response packet to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

9. The device according to claim 4, wherein The UE-level measurement result includes the uplink (UL) packet delay between the RAN and the UE, and wherein the processor circuit is further configured to: decode the monitoring response packet to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

10. The apparatus according to any one of claims 1 to 9, wherein, The device is part of a user plane function (UPF).

11. The apparatus according to claim 1, wherein, The first request is for requesting the downlink (DL) packet delay between a radio access network (RAN) and a UE, and wherein the processor circuit is further configured to: perform the RAN part of the DL packet delay measurement to obtain the DL packet delay between the RAN and the UE, wherein the DL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface.

12. The apparatus according to claim 1, wherein, The first request is for requesting the uplink (UL) packet delay between a radio access network (RAN) and a UE, and wherein the processor circuit is further configured to: perform the RAN part of the UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN, the delay on the Uu interface, and the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

13. The apparatus according to claim 1, wherein, The first request is for requesting the uplink (UL) packet delay between a radio access network (RAN) and a UE, and wherein the processor circuit is further configured to: perform the RAN part of the UL packet delay measurement to obtain the UL packet delay between the RAN and the UE, wherein the UL packet delay between the RAN and the UE is the sum of the delay occurring in the RAN and the delay on the Uu interface, excluding the D1 UL packet data convergence protocol (PDCP) delay occurring in the UE.

14. The device according to any one of claims 1-3 and 11-13, wherein, The device is part of a next-generation node B (gNB).

15. The device according to claim 1, wherein, The UE-level measurement result includes: the uplink (UL) packet delay between a protocol data unit (PDU) session anchor point (PSA) user plane function (UPF) and a radio access network (RAN); Downlink (DL) packet delay between PSA UPF and RAN; UL packet delay between RAN and UE; or DL packet delay between RAN and UE.

16. The apparatus according to claim 1, wherein, The management system includes a management function (MnF).

17. The apparatus according to claim 16, wherein, The MnF is co-located with or separated from the device.

18. The device according to claim 1, wherein The management system includes a management service (MnS) consumer, and the entity is specified by the MnS consumer.

19. The apparatus according to claim 1, wherein, The memory is further configured to store RAN UE Ids for UE-level measurement collection.

20. The apparatus according to claim 1, wherein The UE-level measurement results are obtained based on per service quality (QoS) flow per single network slice selection assistance information (S-NSSAI) according to the specific requirements of the first request.