Apparatus and method for performance measurement for MLB-related handover

Abstract

Apparatus and methods for performance measurement for MLB-related handover are provided herein. The present disclosure provides an apparatus comprising: a memory; and a processor circuit coupled with the memory. The processor circuitry is to: generate performance measurements for a handover associated with mobility load balancing (MLB); and causing the performance measurements to be reported to the service consumer by the service producer. The memory is used for storing performance measurement results. Other embodiments may be described and / or claimed.

Description

[0001] Priority Statement

[0002] This application is based on and claims priority to U.S. Provisional Patent Application No. 63 / 647,450, filed May 14, 2024, which is incorporated herein by reference in its entirety. Technical Field

[0003] The embodiments of this disclosure generally relate to wireless communication, and more specifically, to apparatus and methods for performance measurement related to mobility load balancing (MLB). Background Technology

[0004] In the field of communications, handover is a common practice. There are many reasons for handover, such as optimizing communication quality, increasing system throughput, and achieving load balancing. Researchers have conducted extensive studies to develop appropriate handover mechanisms. Summary of the Invention

[0005] One aspect of this disclosure provides an apparatus comprising: a memory; and processor circuitry coupled to the memory, wherein the processor circuitry is configured to: generate performance measurements for handover related to mobility load balancing (MLB); and cause the performance measurements to be reported to a service consumer by a service producer, wherein the memory is configured to store the performance measurements.

[0006] One aspect of this disclosure provides an apparatus comprising: a memory; and processor circuitry coupled to the memory, wherein the processor circuitry is configured to: collect performance measurements for handover related to mobility load balancing (MLB); and report the performance measurements to a service consumer, wherein the memory is configured to store the performance measurements. Attached Figure Description

[0007] In the accompanying drawings, embodiments of the present disclosure will be illustrated by way of example rather than limitation, wherein like reference numerals refer to similar elements.

[0008] Figure 1 An example architecture of a system according to some embodiments of this disclosure is shown.

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

[0010] Figure 3 Examples of switching according to some embodiments of this disclosure are shown.

[0011] Figure 4Examples of performance measurement result collection and reporting mechanisms according to some embodiments of this disclosure are shown.

[0012] Figure 5 An example flowchart of a method for performance measurement of MLB-related switching according to some embodiments of the present disclosure is shown.

[0013] Figure 6 An example flowchart of a method for performance measurement of MLB-related switching according to some embodiments of the present disclosure is shown.

[0014] Figure 7 An example functional framework for ML and / or RAN intelligence is described.

[0015] Figure 8 An example AI / ML-assisted communication network is depicted, including communication between two MLFs.

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

[0017] Figure 10 The illustrations depict wireless networks according to various embodiments.

[0018] Figure 11 The block diagram illustrates 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 methods discussed herein, according to some example embodiments.

[0019] Figure 12 Networks according to various embodiments are shown. Detailed Implementation

[0020] Various aspects of the illustrative embodiments will be described using terminology commonly employed by those skilled in the art to convey the essence of this disclosure to others skilled in the art. However, it will be readily understood by those skilled in the art that many alternative embodiments can be practiced using portions of the described aspects. Specific figures, materials, and configurations are set forth for illustrative purposes to provide a thorough understanding of the illustrative embodiments. However, it will be readily understood by those skilled in the art that alternative embodiments can be practiced without these specific details. In other instances, well-known features may be omitted or simplified to avoid obscuring the illustrative embodiments.

[0021] Furthermore, the various operations will be described as multiple discrete operations in a manner most conducive to understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations must depend on the order. In particular, these operations do not need to be performed in the order presented.

[0022] The phrases “in an embodiment,” “in one embodiment,” and “in some embodiments” are used repeatedly throughout this document. These phrases do not typically refer to the same embodiment; however, they may refer to the same embodiment. Unless the context otherwise specifies, the terms “comprising,” “having,” and “including” are synonyms. The phrases “A or B” and “A / B” mean “(A), (B), or (A and B).”

[0023] This disclosure generally relates to wireless communication, cellular networks, cloud computing, edge computing, cloud data centers, network topology, communication system implementation, network convergence, artificial intelligence (AI) / machine learning (ML) technologies, and more specifically to technologies for performance measurement of MLB-related handover.

[0024] Figure 1 An example architecture of a system 100 according to some embodiments of this disclosure is shown. The following description is provided for an example system 100 operating in combination with the Long Term Evolution (LTE) system standard provided by the 3GPP Technical Specification (TS) and the 5G or New Radio (NR) system standard. However, the example embodiments are not limited in this respect, and the described embodiments can be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., Wireless Metropolitan Area Network (MAN), Global Microwave Access Interoperability (WiMAX), etc.).

[0025] like Figure 1As shown, system 100 may include UE 101a and UE 101b (collectively referred to as "(one or more) UE 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 refer to 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 equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, 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 smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronics, cellular phones, smartphones, feature phones, tablets, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptops, in-vehicle infotainment systems (IVI), in-vehicle entertainment (ICE) devices, instrument clusters (ICs), head-up displays (HUDs), on-board diagnostics (OBD) devices, dashboard mobile devices (DMEs), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine control units (ECUs), electronic / engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or “smart” devices, machine-type communication (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, and / or the like.

[0026] In some embodiments, any of UEs 101 may include an IoT UE, which may include a network access layer designed for low-power IoT applications utilizing short-lived 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 Service (ProSe) or Device-to-Device (D2D) communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE may execute background applications (e.g., keeping messages active, state updates, etc.) to facilitate connectivity within the IoT network.

[0027] UE 101 can be configured to connect to (e.g., communicatively coupled to) RAN 110. In embodiments, RAN 110 can be a next-generation (NG) RAN or a 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., can refer to RAN 110 operating in NR or 5G system 100, and the term "E-UTRAN," etc., can refer to RAN 110 operating in LTE or 4G system 100. 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" can refer to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" may be synonymous and / or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and / or any other similar term that indicates a path or medium through which data is transmitted. Additionally, the term "link" may refer to a connection between two devices for the purpose of sending and receiving information via radio access technology (RAT).

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

[0029] UE 101b is shown configured to access 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 Wireless Fibre. Router. In this example, AP 106 is shown as connected to the Internet but not to the core network of the wireless system (described in further detail below). In various embodiments, UE 101b, RAN 110, and AP 106 can be configured to utilize LTE-WLAN aggregation (LWA) operation and / or WLAN LTE / WLAN radio-grade integration (LWIP) operation with IPsec tunneling. LWA operation may involve UE 101b in RRC_CONNECTED being configured by RAN node 111 to utilize LTE and WLAN radio resources. LWIP operation may involve UE 101b using WLAN radio resources (e.g., connection 107) via Internet Protocol Security (IPsec) protocol tunneling to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) transmitted through connection 107. The IPsec tunnel may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

[0030] RAN 110 may include one or more RAN nodes 111a and 111b (collectively referred to as "(one or more) RAN nodes 111") that enable connections to 103 and 104. As used herein, the terms "access node (AN)," "access point," "RAN node," etc., may describe equipment that provides radio baseband functionality for data and / or voice connections between the 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 unit (RSU), transmit receiver point (TRxP or TRP), etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., cell). As used herein, the terms "NGRAN node," etc., may refer to RAN node 111 (e.g., gNB) operating in NR or 5G system 100, and the terms "E-UTRAN node," etc., may refer to RAN node 111 (e.g., eNB) operating in LTE or 4G system 100. According to various embodiments, RAN node 111 may be implemented as one or more dedicated physical devices such as a macro cell base station and / or a low-power (LP) base station for providing smaller coverage areas, smaller user capacity, or higher bandwidth compared to a macro cell.

[0031] In some embodiments, all or part of 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, CRAN or vBBUP can implement RAN function partitioning, such as: PDCP partitioning, where the RRC and PDCP layers are operated by CRAN / vBBUP, while other Layer 2 (L2) protocol entities are operated by individual RAN node 111; MAC / PHY partitioning, where the RRC, PDCP, RLC, and MAC layers are operated by CRAN / vBBUP, and the PHY layer is operated by individual RAN node 111; or a “lower PHY” partitioning, where the upper part of the RRC, PDCP, RLC, MAC, and PHY layers is operated by CRAN / vBBUP, and the lower part of the PHY layer is operated by individual RAN node 111. This virtualization framework allows the processor cores of RAN node 111 to be freed up for executing other virtualized applications. In some implementations, individual RAN node 111 may represent a virtualized application running via an individual F1 interface (…). Figure 1(Not shown) Individual gNB-DUs connected to the gNB-CU. In these implementations, the gNB-DU may include one or more remote radio heads or radio front-end modules (RFEMs), and the gNB-CU may be operated by a server (not shown) located in RAN 110 or by a server pool in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more RAN nodes 111 may be next-generation eNBs (ng-eNBs), which are RAN nodes that provide E-UTRA user plane and control plane protocol termination to UE 101, and are connected to 5GC via the ng interface.

[0032] In a V2X scenario, one or more RAN nodes 111 can be or act as RSUs. The terms "roadside unit" or "RSU" can refer to any transport infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively static) UE, wherein 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 radio frequency circuitry located on the roadside, providing connectivity support for passing vehicle UE 101 (vUE 101). An RSU may also include internal data storage circuitry 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 and traffic warnings. Alternatively or additionally, the RSU can operate on the cellular V2X band to provide the aforementioned low-latency communication as well as other cellular communication services. Alternatively or additionally, 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. One or more computing devices and some or all of the RF circuitry of the RSU can be encapsulated in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide wired (e.g., Ethernet) connectivity to traffic signal controllers and / or backhaul networks.

[0033] Any RAN node 111 can terminate the air interface protocol and can be the first point of contact for UE 101. In some embodiments, any RAN node 111 can fulfill various logical functions of 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.

[0034] In an embodiment, UE 101 may be configured to communicate with each other or with any RAN node 111 via a multi-carrier communication channel using various communication technologies, such as, but not limited to, Orthogonal Frequency Division Multiple Access (OFDM) 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 to this aspect. The OFDM signal may include multiple orthogonal subcarriers.

[0035] In some embodiments, the downlink resource grid can be used for downlink transmissions from any RAN node 111 to UE 101, while uplink transmissions can use a similar technique. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink for each time slot. This time-frequency plane representation is common practice in OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to one OFDM symbol and one 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 comprises multiple resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this can represent the minimum amount of resources that can currently be allocated. Several different physical downlink channels exist that are transmitted using such resource blocks.

[0036] According to various embodiments, UE 101 and RAN node 111 transmit (e.g., send and receive) data through licensed media (also referred to as “licensed spectrum” and / or “licensed band”) and unlicensed shared media (also referred to as “unlicensed spectrum” and / or “unlicensed band”). Licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while unlicensed spectrum may include a 5 GHz band.

[0037] To operate in unlicensed spectrum, UE 101 and RAN node 111 can use Licensed Assisted Access (LAA), Enhanced LAA (eLAA), and / or other eLAA (feLAA) mechanisms. In these implementations, UE 101 and RAN node 111 can perform one or more known media sensing 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. Media / carrier sensing operations can be performed according to a Listen-After-Talk (LBT) protocol.

[0038] LBT is a mechanism in which a device (e.g., UE 101, RAN nodes 111, 112, etc.) senses the medium (e.g., a channel or carrier frequency) and transmits data when the medium is sensed to be idle (or when a specific channel in the medium is sensed to be unoccupied). The medium sensing operation may include a Free Channel Assessment (CCA), which utilizes at least Energy Detection (ED) to determine the presence of other signals on the channel 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 in the intended transmission band for a period of time and comparing the sensed RF energy with a predetermined or configured threshold.

[0039] Typically, current systems in the 5GHz 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 or AP 106) intends to transmit, the WLAN node can first perform CCA before transmitting. Additionally, a backoff mechanism is used to avoid collisions when more than one WLAN node senses the channel as idle and transmits simultaneously. The backoff mechanism can be a counter randomly drawn within the contention window size (CWS), which increases exponentially upon collision and is reset to a minimum upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA for WLAN. In some implementations, the LBT process for DL ​​or UL transmission bursts that respectively include PDSCH or PUSCH transmissions can 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 can be 9 microseconds (μs); however, the size of the CWS and the maximum channel occupancy time (MCOT) (e.g., transmission burst) can be based on government regulatory requirements.

[0040] The LAA mechanism is based on the carrier aggregation (CA) technology of LTE-Advanced systems. 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 Frequency Division Duplex (FDD) systems, the number of aggregated carriers can differ for DL ​​and UL, where the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, an individual CC can have a different bandwidth than the other CCs. In Time Division Duplex (TDD) systems, the number of CCs and the bandwidth of each CC are typically the same for DL ​​and UL.

[0041] CA also includes separate serving cells to provide separate CCs. The coverage of serving cells may differ, for example, because 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, and changing the PCC may require UE 101 to undergo a handover. In LAA, eLAA, and feLAA, some or all SCells can operate in unlicensed spectrum (referred to as "LAA SCells"), and LAA SCells are assisted by PCells operating in licensed spectrum. When a UE is configured with more than one LAA SCell, the UE can receive a UL grant on the configured LAASCell, which indicates the start position of different Physical Uplink Shared Channels (PUSCHs) within the same subframe.

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

[0043] PDCCH can use Control Channel Elements (CCEs) to convey control information. Before mapping to resource elements, PDCCH complex-valued symbols are first organized into quadruplets, which are then permuted using a sub-block interleaver for rate matching. Each PDCCH can be transmitted using one or more of these CCEs, 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. The number of CCEs used to transmit PDCCH depends on the size of the Downlink Control Information (DCI) and 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.

[0044] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the concepts described above. For example, some embodiments may use an Enhanced Physical Downlink Control Channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more Enhanced Control Channel Elements (ECCEs). Similar to the above, each ECCE may correspond to nine groups of four physical resource elements, referred to as Enhanced Resource Element Groups (EREGs). In some cases, there may be an additional number of EREGs for the ECCE.

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

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

[0047] RAN 110 is shown communicatively coupled to the core network—in this embodiment, the core network (CN) 120. CN 120 may include a plurality of network elements 122 configured to provide various data and telecommunications services to consumers / subscribers (e.g., users of UE 101) connected to CN 120 via RAN 110. The term “network element” can describe a physical or virtualized device used to provide wired or wireless communication network services. The term “network element” can be considered synonymous with and / or referred to as: networked computer, network hardware, network device, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, virtualized network function (VNF), network function virtualization infrastructure (NFVI), and / or the like. Components of CN 120 may be implemented in a single physical node or separate physical nodes, including components that read and execute instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, Network Functions Virtualization (NFV) can be used to virtualize any or all of the aforementioned network node functions (described in further detail below) via executable instructions stored in one or more computer-readable storage media. A logical instantiation of CN 120 may be referred to as a network slice, and a logical instantiation of a portion of CN 120 may be referred to as a network subslice. NFV architectures and infrastructures can be used to virtualize one or more network functions, or to execute them by dedicated hardware onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches. In other words, an NFV system can be used to execute virtual or reconfigurable implementations of one or more EPC components / functions.

[0048] Typically, application server 130 may be an element that provides applications that use IP bearer resources with the 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., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UE 101 via EPC 120.

[0049] In this 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 this embodiment, NG interface 113 may be divided into two parts: NG User Plane (NG-U) interface 114, which carries service data between RAN node 111 and User Plane Function (UPF); and S1 Control Plane (NG-C) interface 115, which is the signaling interface between RAN node 111 and AMF.

[0050] In one 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). When CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 may connect to CN 120 via S1 interface 113. In one embodiment, S1 interface 13 may be divided into two parts: an S1 user plane (S1-U) interface 114, which carries service data between RAN node 111 and the serving gateway (S-GW); and an S1 mobility management entity (MME) interface 115, which is the signaling interface between RAN node 111 and the MME.

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

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

[0053] 5GC 220 may include Authentication Server Function (AUSF) 222; Access and Mobility Management Function (AMF) 221; Session Management Function (SMF) 224; Network Exposure Function (NEF) 223; Policy Control Function (PCF) 226; Network Function (NF) Repository Function (NRF) 225; Unified Data Management (UDM) 227; Application Function (AF) 228; User Plane Function (UPF) 202; and Network Slice Selection Function (NSSF) 229.

[0054] UPF 202 can act as an anchor point for mobility within and between RATs, an external PDU session interconnection point to DN 203, and a branch point supporting multihomed PDU sessions. UPF 202 can also perform packet routing and forwarding, packet inspection, enforcement of policy rules for the user plane portion, lawful packet interception (UP sets), traffic usage reporting, QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), uplink traffic authentication (e.g., SDF-to-QoS traffic mapping), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. UPF 202 may include an uplink classifier to support routing traffic flows to the data network. DN 203 can represent various network operator services, Internet access, or third-party services. DN 203 may include or be similar to the previously discussed application server 130. UPF 202 can interact with SMF 224 via the N4 reference point between SMF 224 and UPF 202.

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

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

[0057] AMF 221 can also support NAS signaling with UE 201 via the N3 Interoperability 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 (R)AN 210 and AMF 221 for the control plane, and can be the termination point of the N3 reference point between (R)AN 210 and UPF 202 for the user plane. Thus, AMF 221 can process N2 signaling from SMF 224 and AMF 221 for PDU sessions and QoS, encapsulate / decapsulate 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 via N2. The N3IWF can also relay uplink and downlink control plane NAS signaling between UE 201 and AMF 221 via the N1 reference point between UE 201 and AMF 221, and relay uplink and downlink user plane packets between UE 201 and UPF 202. The N3IWF also provides a mechanism for establishing an IPsec tunnel with UE 201. AMF 221 can expose an interface based on Namf services and can be the N14 reference point between two AMF 221s, as well as the interface between AMF 221 and the 5G Device Identifier Register (5G-EIR). Figure 2 The endpoint of the N17 reference point (not shown).

[0058] UE 201 may need to register with AMF 221 to receive network services. Registration Management (RM) is used to register or deregister UE 201 with the network (e.g., AMF 221) and establish a UE context within the network (e.g., AMF 221). UE 201 can operate in either RM registration or RM deregistration states. In RM deregistration state, UE 201 is not registered with the network, and the UE context in AMF 221 does not maintain valid location or routing information for UE 201; therefore, AMF 221 cannot reach UE 201. In RM registration state, UE 201 registers with the network, and the UE context in AMF 221 can maintain valid location or routing information for UE 201, allowing UE 201 to be reached by AMF 221. In the RM registration state, UE 201 can perform a mobility registration update process, a periodic registration update process triggered by the expiration of a periodic update timer (e.g., to notify the network that UE 201 is still active), and a registration update process to update UE capability information or renegotiate protocol parameters with the network, etc.

[0059] AMF 221 may store one or more RM contexts for UE 201, where each RM context is associated with a specific access to the network. The RM context may be a data structure, database object, etc., indicating or storing registration status and periodic update timers for each access type. AMF 221 may also store a 5GC MM context, which may be the same as or similar to the previously discussed (E)MM context. In various embodiments, AMF 221 may store CE Mode B restriction parameters of UE 201 in the associated MM or RM context. When needed, AMF 221 may also derive this value from UE usage setting parameters already stored in the UE context (and / or MM / RM context).

[0060] Connection Management (CM) can be used to establish and release signaling connections between UE 201 and AMF 221 via the N1 interface. This signaling connection enables NAS signaling exchange between UE 201 and CN 120, and includes AN signaling connections (e.g., RRC connections or UE-N3IWF connections for non-3GPP networks) between the UE and the Access Network (AN), and N2 connections between the AN (e.g., RAN 210) and AMF 221 for UE 201. UE 201 can operate in one of two CM states: CM-IDLE mode or CM-CONNECTED mode. When UE 201 operates in CM-IDLE state / mode, UE 201 may not have a NAS signaling connection established with AMF 221 via the N1 interface, and (R)AN210 signaling connections (e.g., N2 and / or N3 connections) may exist for UE 201. When UE 201 operates in CM-CONNECTED state / mode, UE 201 may have a NAS signaling connection established with AMF 221 via the N1 interface, and may have (R)AN 210 signaling connections (e.g., N2 and / or N3 connections) for UE 201. Establishing an N2 connection between (R)AN 210 and AMF 221 allows UE 201 to transition from CM-IDLE mode to CM-CONNECTED mode, and when the N2 signaling between (R)AN 210 and AMF 221 is released, UE 201 can transition from CM-CONNECTED mode to CM-IDLE mode.

[0061] SMF 224 can be responsible for: Session Management (SM) (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes); UE IP address allocation and management (including optional authorization); selecting and controlling UP functions; configuring traffic routing at the UPF to route traffic to the correct destination; terminating the interface to policy control functions; controlling policy enforcement and a portion of QoS; lawful interception (for SM events and the interface with the LI system); terminating NAS messages for the SM portion; downlink data notification; initiating AN-specific SM information, sent to the AN via N2 through the AMF; and determining the SSC mode of the session. SM can refer to the management of PDU sessions, and a PDU session or "session" can refer to the PDU connection service that provides or enables PDU exchange between UE 201 and the data network (DN) 203 identified by the data network name (DNN). A PDU session can be established upon request from UE 201, modified upon request from both UE 201 and 5GC 220, and released upon request from both UE 201 and 5GC 220 using NAS SM signaling exchanged at the N1 reference point between UE 201 and SMF 224. Based on a request from the application server, 5GC 220 can trigger a specific application in UE 201. In response to receiving a trigger message, UE 201 can pass the trigger message (or relevant portions / information of the trigger message) to one or more identified applications in UE 201. One or more identified applications in UE 201 can establish a PDU session to a specific DNN. SMF 224 can check whether a UE 201 request matches the user subscription information associated with UE 201. In this regard, SMF 224 can retrieve and / or request updates from UDM 227 regarding SMF 224-level subscription data.

[0062] The SMF 224 can include the following roaming functions: handling local implementation to apply QoS SLAs (VPLMN); charging data collection and charging interface (VPLMN); lawful interception (in the interface between the VPLMN and LI systems for SM events); and support for interaction with external DNs to transmit PDU session authorization / authentication signaling over the external DN. An N16 reference point between two SMF 224s can be included in system 200, which can be between another SMF 224 in the access network and an SMF 224 in the home network in a roaming scenario. Additionally, the SMF 224 can expose an interface based on NSMF services.

[0063] 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. In such embodiments, NEF 223 can authenticate, authorize, and / or restrict AFs. NEF 223 can also translate information exchanged with AF 228 and information exchanged with internal network functions. For example, NEF 223 can translate between AF service identifiers and internal 5GC information. NEF 223 can also receive information from other network functions (NFs) based on their exposure capabilities. This information can be stored as structured data in NEF 223 or stored in a data storage device NF using a standardized interface. The stored information can then be re-exposed by NEF 223 to other NFs and AFs, and / or used for other purposes, such as analysis. Additionally, NEF 223 can expose interfaces based on Nnef services.

[0064] NRF 225 can support service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to those instances. NRF 225 also maintains information about available NF instances and the services they support. As used herein, terms such as "instantiation" can refer to the creation of an instance, and "instance" can refer to the concrete occurrence of an object, which can happen, for example, during the execution of program code. Additionally, NRF 225 can demonstrate interfaces based on NRF services.

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

[0066] UDM 227 can process subscription-related information to support network entities in handling communication sessions, and can store UE 201's subscription data. For example, subscription data can be exchanged between UDM 227 and AMF 221 via the N8 reference point between UDM 227 and AMF 221. Figure 2 Transmission is performed (not shown). The UDM 227 may include two parts: the application FE and the user data repository (UDR). Figure 2 (FE and UDR are not shown). The UDR can store subscription and policy data for UDM 227 and PCF 226, and / or structured and application data for exposure (including Packet Flow Description (PFD) for application detection and application request information for multiple UEs 201) for NEF 223. The UDR 221 can expose a Nudr-based service interface to allow UDM 227, PCF 226, and 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 related data changes in the UDR. The UDM may include a UDM FE, which is responsible for credential processing, location management, subscription management, etc. Several different front-ends can serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing; user identification processing; access authorization; registration / mobility management; and subscription management. The UDR can interact with SMF 224 via the N10 reference point between UDM 227 and SMF 224. The UDM 227 also supports SMS management, with SMS-FE implementing similar application logic as described above. Additionally, the UDM 227 can display interfaces based on Nudm services.

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

[0068] NSSF 229 can select a set of network slice instances to serve UE 201. 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. NSSF 229 can also determine the set of AMFs or a list of candidate AMFs 221 for serving UE 201 based on appropriate configuration and possibly by querying NRF 225. The selection of a set of network slice instances for UE 201 can be triggered by AMF 221 (which registers UE 201 by interacting with NSSF 229), which can result in a change to AMF 221. NSSF 229 can interact with AMF 221 via the N22 reference point between AMF 221 and NSSF 229; and via the N31 reference point ( Figure 2 (Not shown) Communicates with another NSSF 229 in the access network. Additionally, the NSSF 229 can display an interface based on the Nnssf service.

[0069] As previously mentioned, 5GC 220 may include an SMSF, which can be responsible for SMS subscription checks and authentication, as well as relaying SM messages from other entities to UE 201 and from UE 201 to other entities, such as SMS-GMSC / IWMSC / SMS routers. SMS can also interact with AMF 221 and UDM 227 for notification procedures when UE 201 is available for SMS delivery (e.g., setting a UE unreachable flag and notifying UDM 227 when UE 201 is available for SMS).

[0070] 5GC 220 may also include Figure 2 Other components not shown include the data storage system / architecture, the 5G Device Identity Register (5G-EIR), the Secure Edge Protection Agent (SEPP), and so on. The data storage system may include Structured Data Storage Network Function (SDSF), Unstructured Data Storage Network Function (UDSF), and so on. Any NF can be connected via an N18 reference point between any NF and the UDSF. Figure 2 Unstructured data (e.g., UE context) is stored in or retrieved from the UDSF (not shown). Individual NFs can share a UDSF for storing their respective unstructured data, or each NF can have its own UDSF located at or near the respective NF. Additionally, the UDSF can expose an interface based on Nudsf services (…). Figure 2 (Not shown). 5G-EIR can be an NF that checks the status of a Permanent Device Identifier (PEI) to determine whether a specific device / entity is blacklisted from the network; SEPP can be a non-transparent agent that performs topology hiding, message filtering, and policing on the control plane interface between PLMNs.

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

[0072] As defined in 3GPP TS 38.300V18.1.0 (2024-03) (3rd Generation Partner Program; Technical Specification Group Radio Access Networks; NR; General Description of NR and NG-RAN; Phase 2 (Revision 18)), Mobility Load Balancing (MLB) aims to distribute load evenly between cells and cell areas, or to divert some traffic from congested cells or cell-congested areas, or to offload users from a cell, cell area, carrier, or RAT to achieve network energy savings. MLB can be implemented by optimizing cell reselection / handover parameters and handover actions. MLB can be supported by traditional hard-coded designs or by AI / ML capabilities.

[0073] Figure 3Examples of handover according to some embodiments of the present disclosure are shown. As shown, UE-1, UE-2 and UE-3 are currently served by cell 1. For MLB purposes, UE-1 and UE-2 are moved to cell 2 by handover, and UE-3 is moved to cell 3 by handover.

[0074] For handover actions triggered by MLB, the handover may succeed or fail, which will affect the user experience. For MLB, inappropriate handover parameter settings may lead to the same problems that Mobility Robustness Optimization (MRO) is dealing with, such as handover too early or too late, handover to the wrong cell, and ping-pong handover.

[0075] Therefore, it is necessary to monitor the performance of MLB-related switching in order to evaluate MLB functionality and related AI / ML models (if used).

[0076] Figure 4 Examples of performance measurement result collection and reporting mechanisms according to some embodiments of this disclosure are shown. In this disclosure, performance measurement results may include any 5G NF performance measurement results.

[0077] like Figure 4 As shown, the gNB generates performance measurement results for MLB-related switching. In the first scenario, the MnS producer resides within the gNB, and the MnS producer reports the performance measurement results to the consumer. In the second scenario, the gNB sends the performance measurement results to the management function where the MnS producer resides, and then the MnS producer reports the performance measurement results to the consumer.

[0078] The following details the performance measurements and can be added to 3GPP TS28.552V18.6.0 (2024-03) (3rd Generation Partner Program; Technical Specification Group Services and Systems; Administration and Orchestration; 5G Performance Measurement Results (Release 18)).

[0079] The following performance measurements can be defined, which can be generated by the gNB and reported to consumers by the managed service (MnS) producer. This definition is based on the template specified in 3GPP TS 32.404V18.0.0 (2023-09) (3rd Generation Partner Program; Technical Specification Group: Services and Systems; Telecommunications Management; Performance Management (PM); Performance Measurement Results; Definitions and Templates (Version 18)). Specifically, as specified in 3GPP TS 32.404, a measurement result includes the following sub-clauses: a) Description, which explains the measurement operation; b) Collection method, which indicates the form in which the measurement data was acquired; c) Conditions, which describe the reasons for updating the measurement result data; d) Measurement result, which describes one or more expected result values; e) Measurement type, which includes an abbreviation of the measurement name specified in the header, used to identify the measurement type in the result file; f) Measurement object class, which describes the class of objects being measured; g) Switching technology, which indicates one or more switching domains to which this measurement applies; h) Generation associated with this measurement result; and optional i) Purpose, which describes the target user category that will use the measurement result.

[0080] 5.1.1.x MLB-related measurement results

[0081] 5.1.1.x.1 GNB-to-GNB handover for MLB

[0082] 5.1.1.x.1.1 Number of GNB handover preparations for MLB requests

[0083] a) The measurement results provide the number of times the source gNB Centralized Unit (CU) is prepared for a handover request in response to an MLB request.

[0084] b) Accumulator counter (CC).

[0085] c) When a gNB CU sends a HANDOVER REQUIRED message to the AMF (see 3GPP TS 38.413 V18.1.0 (2024-03) (3rd Generation Partners Project; Technical Specification Group Radio Access Networks; NG-RAN; NG Application Protocol (NGAP) (Version 18))), or when a source gNB CU sends a HANDOVER REQUEST message to a target gNB CU (see 3GPP TS38.423 V18.1.0 (2024-03) (3rd Generation Partners Project; Technical Specification Group Radio Access Networks; NG-RAN; Xn Application Protocol (XnAP) (Version 18))), where the aforementioned message includes a reason IE set to "Reduce Serving Cell Load" or "Optimize Handover". Each message increments the relevant sub-counter by 1 according to the reason.

[0086] d) Each measurement result is an integer value.

[0087] e)MM.HoPrepInterReqMLB.ResOpt;

[0088] MM.HoPrepInterReqMLB.RedLoad.

[0089] f)NRCellCU;

[0090] NRCellRelation.

[0091] g) Applicable to packet-switched traffic.

[0092] h)5GS.

[0093] 5.1.1.x.1.2 Number of preparation attempts for a successful gNB handover in MLB

[0094] a) This measurement provides the number of successful handover preparations for the MLB received by the source gNB CU.

[0095] b)CC.

[0096] c) When the gNB CU receives a HANDOVER COMMAND message from the AMF (see TS 38.413), or when it receives a HANDOVER REQUEST ACKNOWLEDGE message from the target gNB CU (see TS 38.423), it indicates that resources have been prepared for handover at the target NR cell CU, where the message corresponds to the previous gNB handover preparation requested for the MLB (see sub-clause 5.1.1.x.1.1).

[0097] d) Each measurement result is an integer value.

[0098] e)MM.HoPrepInterSuccMLB.ResOpt;

[0099] MM.HoPrepInterSuccMLB.RedLoad.

[0100] f)NRCellCU;

[0101] NRCellRelation.

[0102] g) Applicable to packet-switched traffic.

[0103] h)5GS.

[0104] 5.1.1.x.1.3 Number of preparation attempts for gNB handover in case of MLB failure

[0105] a) This measurement provides the number of successful handover preparations for the MLB received by the source gNB CU. This measurement is further subdivided into sub-counters according to the cause of failure.

[0106] b)CC.

[0107] c) When a gNB CU receives a HANDOVER PREPARATION FAILURE message from the AMF (see TS 38.413), or when it receives a HANDOVER PREPARATION FAILURE message from the target gNB CU (see TS 38.423), it indicates that resource preparation at the target NR cell CU has failed, where this message corresponds to a previous gNB handover preparation requested for the MLB (see sub-clause 5.1.1.x.1.1). Each message increments the relevant sub-counter by 1 according to the reason for failure.

[0108] d) Each sub-counter is an integer value.

[0109] e)MM.HoPrepInterFailMLB.cause;

[0110] The "cause" flag indicates the reason for the failure of the MLB switchover preparation.

[0111] f)NRCellCU;

[0112] NRCellRelation.

[0113] g) Applicable to packet-switched traffic.

[0114] h)5GS.

[0115] 5.1.1.x.1.4 Number of gNB handover executions for MLB requests

[0116] a) This measurement provides the number of outgoing gNB switching operations performed by the source gNB in ​​response to the MLB.

[0117] b)CC.

[0118] c) When sending an RRCReconfiguration message to the UE (which requests an inter-gNB handover from the source gNB CU to the target gNB CU) (see 3GPP TS 38.331V18.1.0 (2024-03) (3rd Generation Partners Project; Technical Specification Group Radio Access Networks; NR; Radio Resource Control (RRC) Protocol Specification (Version 18))), it corresponds to the previous inter-gNB handover preparation for the MLB request (see Subclause 5.1.1.x.1.1).

[0119] d) Each measurement result is an integer value.

[0120] e)MM.HoExeInterReqMLB.ResOpt;

[0121] MM.HoExeInterReqMLB.RedLoad.

[0122] f)NRCellCU;

[0123] NRCellRelation.

[0124] g) Applicable to packet-switched traffic.

[0125] h)5GS.

[0126] 5.1.1.x.1.5 Number of successful gNB handovers for MLB

[0127] a) This measurement provides the number of successful inter-gNB handover executions for MLB received by the source gNB.

[0128] b)CC.

[0129] c) Upon receiving a UECONTEXT RELEASE (see TS 38.423) from the target gNB via Xn at the source gNB after a successful inter-gNB handover for MLB, or upon receiving a UE CONTEXT RELEASE COMMAND (see TS 38.413) from the AMF after a successful inter-gNB handover for MLB, where the message indicates a handover corresponding to the previously requested inter-gNB handover for MLB (see sub-clause 5.1.1.x.1.4).

[0130] d) Each measurement result is an integer value.

[0131] e)MM.HoExeInterSuccMLB.ResOpt;

[0132] MM.HoExeInterSuccMLB.RedLoad.

[0133] f)NRCellCU;

[0134] NRCellRelation.

[0135] g) Applicable to packet-switched traffic.

[0136] h)5GS.

[0137] 5.1.1.x.1.6 Number of gNB handover executions for MLB failures

[0138] a) This measurement provides the number of gNB handovers performed at the source gNB in ​​response to an MLB failure.

[0139] b)CC.

[0140] c) This counter increments when a handover execution triggered by the MLB fails. It is assumed that the UE context is available in the source gNB. The following events correspond to a previous inter-gNB handover execution requested for the MLB (see sub-clause 5.1.1.x.1.4):

[0141] 1) When receiving an NGAP UE CONTEXT RELEASE COMMAND (see TS 38.413) from the AMF indicating that the handover between gNBs was unsuccessful;

[0142] 2) When the source gNB receives the RrcReestablishmentRequest from the UE (see TS)

[0143] In 38.331), where reestablishmentCause is handoverFailure, the re-establishment occurs in the source gNB;

[0144] 3) When the switchover monitoring timer in the source gNB expires;

[0145] 4) When an XnAP RETRIEVE UE CONTEXT REQUEST is received in the source gNB (see TS 38.423), where the re-establishment occurs in another gNB.

[0146] The reasons for failure of UE CONTEXT RELEASE COMMAND are listed in section 9.3.1.2 of TS 38.413. This message increments the relevant sub-counter by 1 according to the reason for failure.

[0147] Since a single switching failure can lead to multiple events as described above, it is necessary to filter out duplicates.

[0148] d) Each sub-counter is an integer value.

[0149] e)MM.HoExeInterFailMLB.UeCtxtRelCmd.cause;

[0150] MM.HoExeInterFailMLB.RrcReestabReq;

[0151] MM.HoExeInterFailMLB.HoExeSupTimer;

[0152] MM.HoExeInterFailMLB.RetrUeCtxtReq.

[0153] The "cause" identifier indicates the reason for the failure of the UE CONTEXT RELEASE COMMAND message.

[0154] f)NRCellCU;

[0155] NRCellRelation.

[0156] g) Applicable to packet-switched traffic.

[0157] h)5GS.

[0158] 5.1.1.x.2 GNB Intra-NB Switching for MLB

[0159] 5.1.1.x.2.1 Number of intra-gNB handover executions for MLB requests

[0160] a) This measurement provides the number of outbound gNB switching executions triggered by the MLB.

[0161] b)CC.

[0162] c) When sending an RRC Reconfiguration message triggered by MLB to the UE, the message requests a switch from the source NRCellCU to the target NRCellCU (see TS 38.331).

[0163] d) A single integer value.

[0164] e)MM.HoExeIntraReqMLB.

[0165] f)NRCellCU;

[0166] NRCellRelation.

[0167] g) Applicable to packet-switched traffic.

[0168] h)5GS.

[0169] 5.1.1.x.2.2 Number of successful intra-gNB switchovers for MLB

[0170] a) This measurement provides the number of successful gNB in-gNB handover executions for MLB received by the source NRCellCU.

[0171] b)CC.

[0172] c) When the target NRCellCU receives an RRC ReconfigurationComplete message from the UE (see TS38.331), the message indicates a successful intra-gNB handover corresponding to a handover execution request triggered by the MLB (see sub-clause 5.1.1.x.2.1).

[0173] d) A single integer value.

[0174] e)MM.HoExeIntraSuccMLB.

[0175] f)NRCellCU;

[0176] NRCellRelation.

[0177] g) Applicable to packet-switched traffic.

[0178] h)5GS.

[0179] 5.1.1.x.3 Classification Switching for MLB

[0180] 5.1.1.x.3.1 Classification switching failure caused by MLB within the system

[0181] a) This measurement provides the number of classified handover failure events detected during the in-system MLB within 5GS. The measurement includes separate sub-counters for various handover failure types, categorized as “early handover within the system,” “late handover within the system,” and “handover to the wrong cell within the system” (see Section 15.5.2 of 3GPP TS38.300V18.1.0 (2024-03) (3rd Generation Partner Program; Technical Specification Group Radio Access Networks; NR; General Description of NR and NG-RAN; Phase 2 (Revision 18)).

[0182] b)CC.

[0183] c) Measurements of premature handover, late handover, and handover to the wrong cell events are obtained by summing the number of failure events detected by the gNB during the MLB within the system in 5GS (see TS 38.300).

[0184] d) Each measurement result is an integer value.

[0185] e)HO.IntraSysMLB.TooEarly;

[0186] HO.IntraSysMLB.TooLate;

[0187] HO.IntraSysMLB.ToWrongCell.

[0188] f)NRCellCU;

[0189] NRCellRelation

[0190] g) Applicable to packet-switched traffic.

[0191] h)5GS.

[0192] Figure 5 An example flowchart of a method 500 for performance measurement of MLB-related switching according to some embodiments of the present disclosure is shown. Method 500 can be performed by an AN (e.g., gNB). Method 500 may include operations 510 and 520.

[0193] At point 510, generate performance measurement results for MLB-related switching. At point 520, enable the service producer to report the performance measurement results to the service consumer.

[0194] In some embodiments, performance measurement results are implemented as a cumulative counter (CC) triggered by a corresponding condition.

[0195] In some embodiments, the performance measurement results are related to gNB handover for MLB. In some embodiments, the performance measurement results include: the number of gNB handover preparations for MLB requests; the number of gNB handover preparations for successful MLB handovers; the number of gNB handover preparations for failed MLB handovers; the number of gNB handover executions for MLB requests; the number of gNB handover executions for successful MLB handovers; or the number of gNB handover executions for failed MLB handovers.

[0196] In some embodiments, the number of gNB handover preparations for an MLB request is implemented as a CC, and the CC is triggered when: the source gNB CU sends a HANDOVER REQUIRED message to the AMF; or the source gNB CU sends a HANDOVER REQUEST message to the target gNB CU.

[0197] In some embodiments, the number of successful gNB handover preparations for MLB is implemented as CC, and the triggering condition for CC is: the source gNB CU receives a HANDOVER COMMAND message from the AMF; or the source gNB CU receives a HANDOVER REQUEST ACKNOWLEDGE message from the target gNB CU.

[0198] In some embodiments, the number of gNB handover preparations for MLB failure is implemented as CC, and the triggering condition for CC is: the source gNB CU receives a HANDOVER PREPARATION FAILURE message from the AMF; or the source gNB CU receives a HANDOVER PREPARATION FAILURE message from the target gNB CU.

[0199] In some embodiments, the number of gNB handover executions for the MLB request is implemented as a CC, and the triggering condition for the CC is: sending an RRC Reconfiguration message to the UE to request a handover from the source gNB CU to the target gNB CU.

[0200] In some embodiments, the number of successful inter-gNB handovers performed for MLB is implemented as CC, and the triggering condition for CC is: after a successful inter-gNB handover source for MLB, the gNB CU receives a UE CONTEXTRELEASE message from the target gNB CU; or after a successful inter-gNB handover source for MLB, the source gNB CU receives a UECONTEXT RELEASE COMMAND from the AMF.

[0201] In some embodiments, the number of inter-gNB handover executions for MLB failures is implemented as a CC, which is triggered under the following conditions: the source gNB CU receives a Next Generation Application Protocol (NGAP) UE CONTEXTRELEASE COMMAND from the AMF indicating that the inter-gNB handover was unsuccessful; the source gNB receives an RrcReestablishmentRequest from the UE, where reestablishmentCause is set to handoverFailure and re-establishment occurs at the source gNB; the handover execution monitoring timer in the source gNB expires; or the source gNB receives an Xn Application Protocol (XnAP) RETRIEVE UE CONTEXT REQUEST from another gNB that is not the target gNB, where re-establishment occurs at that other gNB.

[0202] In some embodiments, performance measurements relate to actual intra-gNB handovers of MLBs. In some embodiments, performance measurements include: the number of intra-gNB handovers performed for MLB requests; or the number of successful intra-gNB handovers performed for MLBs.

[0203] In some embodiments, the number of intra-gNB handover executions for the MLB request is implemented as a CC, and the triggering condition for the CC is: sending an RRC Reconfiguration message to the UE to request an intra-gNB handover from the source new radio central unit (NRCellCU) to the target NRCellCU.

[0204] In some embodiments, the number of successful intra-gNB handovers performed by the MLB is implemented as a CC, and the triggering condition for the CC is: the target NRCellCU receives an RRC ReconfigurationComplete message from the UE indicating a successful intra-gNB handover.

[0205] In some embodiments, performance measurements include the number of classified handover failures caused by MLBs within the system, implemented as sub-counters for the corresponding handover failure types. In some embodiments, handover failure types include premature handover, late handover, and handover to the wrong cell event.

[0206] In some embodiments, the service producer is located inside the gNB or connected to the gNB externally.

[0207] In some embodiments, service consumers include managed service consumers (MnS-C). In some embodiments, service producers include managed service producers (MnS-P).

[0208] Figure 6An example flowchart of a method 600 for performance measurement of MLB-related switching according to some embodiments of the present disclosure is shown. Method 600 can be performed by a service producer. Method 600 may include operations 610 and 620.

[0209] At point 610, performance measurements for MLB-related handovers are collected from the gNB. At point 620, performance measurements are reported to the service consumer.

[0210] Method 600 can be understood in conjunction with embodiments of method 500 and any other description in this disclosure, which will not be repeated here.

[0211] By measuring the performance of MLB-related switching, the performance of MLB functions and related ML models (if AI / ML is used) can be monitored, thereby improving the performance of the communication system.

[0212] Figure 7 An example functional framework 700 for ML and / or RAN intelligence is depicted. Functional framework 700 includes a data collection function 705 that provides input data to a model training function 710 and a model inference function 715. AI / ML algorithm-specific data preparation (e.g., data preprocessing and cleaning, formatting and transformation) may or may not be performed in the data collection function 705. Examples of input data may include: measurements from UEs, RAN nodes, and / or attached or alternative network entities; feedback from actor 720; and / or outputs from one or more ML models. The input data fed to the model training function 710 is training data, and the input data fed to the model inference function 715 is inference data.

[0213] Model training function 710 is responsible for performing ML model training, validation, and testing. As part of the model testing and / or model validation process, model training function 710 can generate model performance metrics. Examples of model performance metrics are discussed below. If needed, model training function 710 can also handle data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the training data provided by data collection function 705.

[0214] Model training function 710 performs model deployment / update, wherein model training function 710 initially deploys a trained, validated, and tested ML model to model inference function 715, and / or delivers one or more updated models to model inference function 715. Examples of model deployment and update are discussed below.

[0215] Model inference function 715 provides ML model inference outputs (e.g., statistical inference, prediction, decision-making, probability and / or probability distributions, actions, configurations, strategies, data analysis, results, optimizations, etc.). Model inference function 715 may provide model performance feedback to model training function 710 when applicable. Model performance feedback may include various performance metrics related to the generation of inference (e.g., any metrics discussed herein). Model performance feedback may be used to monitor the performance of the ML model when applicable. If necessary, model inference function 715 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the inference data provided by data collection function 705.

[0216] Model inference function 715 produces inference output, which is the inference generated by model inference function 715 when manipulating the ML model using inference data, or otherwise produced. Model inference function 715 provides the inference output to actor 720. The details of the inference output are related to the specific use case and may be based on the specific type of ML model being used.

[0217] Actor 720 is a function that receives inference output from model inference function 715 and triggers or otherwise performs corresponding operations based on the inference output. Actor 720 can trigger operations against other entities and / or itself. In some examples, actor 720 is an NES function, a mobility optimization function, and / or a load balancing function. Additionally or alternatively, the inference output is associated with NES, mobility optimization, and / or load balancing, and actor 720 is one or more RAN nodes that perform various NES operations, mobility optimization operations, and / or load balancing operations based on the inference.

[0218] The actor 720 can also provide feedback to the data collection function 705 for storage. The feedback includes information related to the actions performed by the actor 720. The feedback may include any information that might be needed to acquire training data (and / or test data and / or validation data), inference data, and / or data for monitoring the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0219] Figure 8An example AI / ML-assisted communication network including communication between ML Function (MLF) 802 and MLF 804 is depicted. In some implementations, ML models / entities may be used or utilized to facilitate wired and / or over-the-air communication between MLF 802 and MLF 804. In this embodiment, the operation of MLF 802 and MLF 804 conforms to 3GPP technical specifications and / or technical reports for 5G and / or 6G systems, such as any technical reports discussed herein. In some examples, the communication mechanism between MLF 802 and MLF 804 includes any suitable access technology and / or RAT, such as any technology and / or RAT discussed herein. Furthermore, Figure 8 The communication mechanism in can be Figure 1-7 and / or other components, devices, systems, networks and / or deployments described herein, or operating concurrently with them.

[0220] MLF 802 and 804 may correspond to any entity / component discussed herein. In one example, MLF 802 corresponds to the UE and MLF 804 corresponds to the gNB; or MLF 802 corresponds to the gNB and MLF 804 corresponds to the UE. In one example, MLF 802 is implemented by the UE and MLF 804 is implemented by the gNB; or MLF 802 is implemented by the gNB and MLF 804 is implemented by the UE. In another example, MLF 802 corresponds to MnF and / or MnS-P, and MLF 804 corresponds to the consumer, MnS-C, or vice versa. In this example, the groups of MLFs may be mutually exclusive, or some or all of the MLFs in the groups may overlap or be shared. Additionally or alternatively, some or all of the components / entities in individual MLF 802 and 804 may be implemented or operated by separate entities / components.

[0221] like Figure 8 As shown, MLF 802 and MLF 804 include various AI / ML-related components, functions, elements, or entities that can be implemented as hardware, software, firmware, and / or some combination thereof. In some examples, one or more AI / ML-related elements are implemented as part of the same hardware (e.g., integrated circuit, chip, or multiprocessor chip), software (e.g., program, process, engine, etc.), or firmware as at least one other element, function, element, or entity. AI / ML-related elements of MLF 802 may be the same as or similar to AI / ML-related elements of MLF 804. For brevity, the various elements will be described from the perspective of MLF 802, but it is understood that, unless explicitly stated otherwise, such description applies to similar named / numbered elements of MLF 804.

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

[0223] The collected data is stored in / through repository 815, and the stored data can be discovered and retrieved from data repository 815 by other components. For example, inference data selector / filter 850 can retrieve data from data repository 815 and provide that data to inference engine 845 to generate / determine inference. In various examples, MLF 802 is configured to discover and request data from data repository 815 in MLF 804, and / or vice versa. In these examples, data repository 815 of MLF 802 may be communicatively coupled to data repository 815 of MLF 804, so that the respective data repositories 815 can share collected data with each other. Additionally or alternatively, MLF 802 and / or MLF 804 are configured to discover and request data from one or more external sources and / or data storage systems / devices.

[0224] Training data selection / filter 820 is configured to generate training, validation, and test datasets for ML training (MLT) (or ML model training). One or more of these datasets may be extracted from data repository 815 or otherwise obtained. Data can be selected / filtered based on the specific ML model to be trained. The data may optionally be transformed, augmented, and / or preprocessed (e.g., normalized) before being loaded into the dataset. Training data selection / filter 820 may label the data in the dataset for supervised learning or leave the data unlabeled for unsupervised learning. The resulting dataset can then be fed into MLT function (MLTF) 825.

[0225] The MLTF 825 is responsible for training and updating (e.g., tuning and / or retraining) ML models. Selected models (or sets of models) can be trained using datasets (including training, validation, and testing data) fed in from the training data selector / filter 820. The MLTF 825 generates trained and tested ML models that are ready for deployment. The generated trained and tested models can be stored in the model library 835. Additionally or alternatively, the MLTF 825 performs ML model training, validation, and testing. As part of the model testing and / or model validation process, the MLTF 825 can generate model performance metrics. Examples of model performance metrics are discussed below. If needed, the MLTF 825 can also handle data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the data collection capabilities and / or the training data provided by the training data selector / filter 820. The MLTF 825 performs model deployment / updates, whereby the MLTF 825 initially deploys a trained, validated, and tested ML model to the Model Inference Function 845, and / or delivers one or more updated models to the Model Inference Function 845. Examples of model deployment and updates are discussed below.

[0226] Model library 835 is responsible for the storage and exposure of ML models (trained and untrained). Various types of model data can be stored in model library 835. For example, model data may include (one or more) trained / updated models, model parameters, hyperparameters, and / or model metadata such as model performance metrics, hardware platform / configuration data, model execution parameters / conditions, etc. In some examples, model data may also include inferences made while running the ML model. Model data can be discovered and requested by other MLF components (e.g., training data selection / filter 820 and / or MLTF 825). In some examples, MLF 802 can discover and request model data from model library 835 of MLF 804. Additionally or alternatively, MLF 804 can discover and / or request model data from model library 835 of MLF 802. In some examples, MLF 804 can configure models, model parameters, hyperparameters, model execution parameters / conditions, and / or other ML model aspects in model library 835 of MLF 802. To indicate manageability, this paper also refers to the ML model as an ML entity; that is, the terms ML model and ML entity are interchangeable in this paper.

[0227] Model management function 840 is responsible for managing the ML models generated by MLTF 825. Such management functions may include: deploying trained models, monitoring ML entity performance, reporting ML entity validation and / or performance data, etc. When deploying a model, model management function 840 can allocate and schedule hardware and / or software resources for inference based on the received trained and tested model. For the purposes of this disclosure, the term "inference" refers to the process of generating statistical inference, predictions, decisions, probabilities and / or probability distributions, actions, configurations, policies, data analysis, results, optimizations, etc., based on new, unseen data (e.g., "input inference data") using one or more trained ML models. In some examples, the inference process may include: feeding input inference data to an ML model (e.g., inference engine 845), forward propagating input inference data through the architecture / topology of the ML model, wherein the ML model performs computations on the data using its learned parameters (e.g., weights and biases), and predicting outputs. In some examples, the inference process may include data transformation prior to the forward pass, where the input inference data is preprocessed or transformed to match the format required by the ML model. In performance monitoring, based on model performance KPIs and / or metrics, model management function 840 can decide to terminate a running model, begin model retraining and / or tuning, select another model, etc. In the example, model management function 840 of MLF 804 can configure model management policies in MLF 802, and vice versa.

[0228] As described below, the inference data selection / filter 850 is responsible for generating the dataset for model inference at inference 845. For example, inference data can be extracted from the data repository 815. The inference data selection / filter 850 can select and / or filter data based on the deployed ML model. The data can be transformed, enhanced, and / or preprocessed in the same or similar manner as the training data selection / filtering (e.g., as described for training data selection filter 820). The generated inference dataset can be fed into the inference engine 845.

[0229] The inference engine 845 (also referred to as "model inference function 845", etc.) is responsible for performing / generating the inference described herein. The inference engine 845 consumes the inference dataset provided by the inference data selection / filter 850 and generates ML model inference output, which includes one or more inferences. For example, inference can be or include statistical inference, prediction, decision-making, probability and / or probability distribution, action, configuration, strategy, data analysis, outcome, optimization, etc. One or more inferences / one or more results may be provided to the performance measurement function 830. Where applicable, the model inference function 845 may provide model performance feedback to the MLTF 825 and / or the performance measurement function 830. Model performance feedback may include various performance metrics related to the generation of inference (e.g., any metrics discussed herein). Model performance feedback may be used, where applicable, to monitor the performance of the ML model. If necessary, the model inference function 845 may also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and transformation) based on the inference data provided by the data collection function and / or the inference data selection / filter 850. Model inference function 845 generates inference output, which is the inference generated by model inference function 845 when running an ML model using inference data (set), or otherwise generated. The details of the inference output are related to the specific use case and can be based on the specific type of ML model being used.

[0230] In some examples, model inference function 845 provides inference output to an actor (not shown). An actor is a function, engine, component, device, system, network, and / or other entity that receives inference output from model inference function 845 and triggers or otherwise performs corresponding actions(s) based on the inference output. An actor may trigger actions against other entities and / or itself. In some examples, an actor is a Network Energy Saving (NES) function, a Mobility Robustness Optimization (MRO) function, a Load Balancing Optimization (LBO) function, and / or other Ad Hoc Networking (SON) function, including any functions mentioned herein. Additionally or alternatively, the inference output is related to NES, MRO, and / or LBO, and the actor is one or more RAN nodes that perform various NES, MRO, and / or LBO operations based on inference. The actor may also provide feedback to performance measurement function 830 and / or data collection function / data repository 815 for storage. The actor feedback includes information related to the actions performed by the actor. For example, feedback includes any information that may be needed to obtain training data, test data and / or validation data; inference data; and / or data to monitor the performance of the ML model and its impact on the network by updating KPIs, performance counters, etc.

[0231] Performance measurement function 830 is configured to measure model performance metrics (e.g., accuracy, momentum, precision, magnitude, recall / sensitivity, model bias, runtime latency, resource consumption, and / or other suitable metrics / measures, such as any of those discussed herein) of deployed and executing models based on one or more inference methods for monitoring purposes. Model performance data may be stored in data repository 815 and / or reported according to the validation reporting mechanism discussed herein.

[0232] The performance measurement function 830 can measure and / or predict performance metrics based on specific AI / ML tasks and other inputs / parameters of ML entities. Performance metrics can include model-based metrics and platform-based metrics. Model-based metrics are metrics related to the performance of the model itself and / or do not consider the underlying hardware platform. Platform-based metrics are related to the performance of the underlying hardware platform when running the ML model.

[0233] Model-based metrics can be based on specific types of ML models and / or AI / ML domains. For example, regression-related metrics can be used to predict regression-based ML models. Examples of regression-related metrics include error values, mean error, mean absolute error (MAE), mean reciprocal rank (MRR), mean squared error (MSE), root MSE (RMSE), correlation coefficient (R), coefficient of determination (R²), Golbraikh and Tropsha criteria, and / or other similar regression-related metrics, such as those discussed in the paper Naser et al. (Insights into Performance Fitness and Error Metrics for Machine Learning, arXiv:2006.00887v1(17May 2020)(“[Naser]”)).

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

[0235] It is also possible to predict other or alternative model-based metrics, such as cumulative gain (CG), discounted CG (DCG), normalized DCG (NDCG), signal-to-noise ratio (SNR), peak signal-to-noise ratio (PSNR), structural similarity (SSIM), joint crossover (IoU), perplexity, bilingual evaluation surrogate study (BLEU) score, initial score, Wasserstein metric, Fréchet inception distance (FID), string metric, edit distance, Levenshtein distance, Damerau–Levenshtein distance, number of evaluation instances (e.g., iterations, duration, or events), learning rate (e.g., how quickly the algorithm reaches (converges to) the optimal weights), learning rate decay (or weight decay), number and / or type of computations, number and / or type of multiply and accumulates (MAC), number and / or type of multiply adds (MAdds) operations, and / or other similar performance metrics related to ML model performance.

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

[0237] Additionally or alternatively, surrogate metrics (e.g., metrics or attributes used as substitutes or substitutes for another metric or attribute) may be used to predict the performance of the ML model. For any of the performance metrics described above, any suitable data collection and / or measurement mechanism may be used to predict and / or measure the total, mean, and / or other distributions of such metrics.

[0238] Figure 9 A network 900 according to various embodiments is illustrated. The network 900 can operate in a manner conforming to the 3GPP technical specifications of LTE or 5G / NR systems. However, the example embodiments are not limited thereto, and the described embodiments are applicable to other networks that benefit from the principles described herein, such as future 3GPP systems, etc.

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

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

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

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

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

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

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

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

[0247] In some embodiments, RAN 904 may be an LTE RAN 910 with an eNB, such as eNB 912. The LTE RAN 910 provides an LTE air interface with the following characteristics: 15 kHz SCS; CP-OFDM waveforms for DL ​​and SC-FDMA waveforms for UL; turbo coding for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; rely on PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation; and rely on CRS for cell search and initial acquisition, channel quality measurement, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface may operate in frequency bands below 6 GHz.

[0248] In some embodiments, RAN 904 can be an NG-RAN 914 with a gNB, such as gNB 916, or an NG-RAN 914 with an ng-eNB, such as ng-eNB 918. gNB 916 can connect to a 5G-enabled UE using a 5G NR interface. gNB 916 can connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. ng-eNB 918 can also connect to the 5G core via an NG interface, but can connect to the UE via an LTE air interface. gNB 916 and ng-eNB 918 can connect to each other via an Xn interface.

[0249] In some embodiments, the NG interface can be divided into two parts: an NG user plane (NG-U) interface, which carries traffic data between the NG-RAN 914 node and the UPF 948 (e.g., the N3 interface), and an NG control plane (NG-C) interface, which is the signaling interface between the NG-RAN 914 node and the AMF 944 (e.g., the N2 interface).

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

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

[0252] RAN 904 is communicatively coupled to CN 920, which includes network elements to provide various functions to support data and telecommunications services to customers / subscribers (e.g., users of UE 902). Components of CN 920 may be implemented in a single physical node or in separate physical nodes. In some embodiments, NFV may be used to virtualize any or all of the functions provided by the network elements of CN 920 onto physical computing / storage resources such as servers, switches, etc. A logical instantiation of CN 920 may be referred to as a network slice, and a logical instantiation of a portion of CN 920 may be referred to as a network subslice.

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

[0254] The MME 924 enables mobility management functions to track the current location of the UE 902, facilitating paging, bearer activation / deactivation, handover, gateway selection, authentication, and more.

[0255] The SGW 926 can terminate the S1 interface to the RAN and route data packets between the RAN and the LTE CN 922. The SGW 926 can serve as a local mobility anchor point for handovers between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0256] The SGSN 928 can track the location of UE 902 and perform security functions and access control. Furthermore, the SGSN 928 can perform EPC inter-node signaling for mobility between different RAT networks; select PDN and S-GW according to MME 924; select MME for handover; and so on. The S3 reference point between MME 924 and SGSN 928 can enable user and bearer information exchange for mobility between 3GPP access networks in idle / active states.

[0257] The HSS 930 may include a database for network users, including reservation-related information to support network entities in managing communication sessions. The HSS 930 provides support for routing / roaming, authentication, authorization, naming / addressing resolution, location compliance, and more. An S6a reference point between the HSS 930 and the MME 924 enables the transmission of reservation and authentication data to authenticate / authorize user access to the LTE CN 920.

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

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

[0260] In some embodiments, CN 920 may be 5GC 940. 5GC 940 may include AUSF 942, AMF 944, SMF946, UPF 948, NSSF 950, NEF 952, NRF 954, PCF 956, UDM 958, and AF 960, which are coupled to each other via interfaces (or "reference points"), as shown in the figure. The functionality of the components in 5GC 940 can be briefly described below.

[0261] The AUSF 942 stores data for UE 902 authentication and handles authentication-related functions. The AUSF 942 facilitates a common authentication framework for various access types. In addition to communicating with other components of the 5GC 940 via a reference point, as shown in the figure, the AUSF 942 also presents a Nausf service-based interface.

[0262] The AMF 944 allows other functions of the 5GC 940 to communicate with UE 902 and RAN 904, and to subscribe to notifications regarding mobility events for UE 902. The AMF 944 can handle registration management (e.g., for registering UE 902), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 944 can provide transport for SM messages between UE 902 and SMF 946 and acts as a transparent broker for routing SM messages. The AMF 944 can also provide transport for SMS messages between UE 902 and the SMSF. The AMF 944 can interact with the AMFF 942 and UE 902 to perform various security anchoring and context management functions. Furthermore, the AMF 944 can be a termination point for the RAN CP interface, which may include or be the N2 reference point between the RAN 904 and the AMF 944; and the AMF 944 can be a termination point for NAS (N1) signaling, performing NAS encryption and integrity protection. The AMF 944 can also support NAS signaling with the UE 902 via the N3 IWF interface.

[0263] SMF 946 can be responsible for SM (e.g., session establishment, tunnel management between UPF 948 and AN 908); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuration of traffic manipulation at UPF 948 to route traffic to appropriate destinations; termination of interfaces for policy control functions; control portions for policy enforcement, charging, and QoS; lawful interception (for SM events and interfaces to the LI system); termination of the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information sent to AN 908 via N2 through AMF 944; and determining the SSC mode of the session. SM can refer to the management of PDU sessions, while a PDU session or "session" can refer to the PDU connectivity service that provides or enables the exchange of PDUs between UE 902 and data network 936.

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

[0265] The NSSF 950 can select a set of network slice instances to serve UE 902. If needed, the NSSF 950 can also determine the allowed NSSAIs and their mappings to pre-booked S-NSSAIs. The NSSF 950 can also determine, based on appropriate configuration and possibly by querying the NRF 954, the set of AMFs to be used for serving UE 902, or a list of candidate AMFs. The selection of a set of network slice instances for UE 902 can be triggered by the AMF 944 to which UE 902 has registered, through interaction with the NSSF 950, which can result in a change of AMF. The NSSF 950 can interact with AMF 944 via reference point N22; and can communicate with another NSSF in the visited network via reference point N31 (not shown). Furthermore, the NSSF 950 can present a service-based interface for NNSSF.

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

[0267] NRF 954 supports service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to them. NRF 954 also maintains information about available NF instances and the services they support. As used herein, terms like "instantiation" can refer to the creation of an instance, while "instance" can refer to the actual occurrence of an object, which can happen, for example, during the execution of program code. Furthermore, NRF 954 can present a service-based interface for NnRF.

[0268] PCF 956 can provide policy rules to control plane functions to enable their enforcement and also supports a unified policy framework to constrain network behavior. PCF 956 can also enable front-ends to access reservation information related to policy decisions in the UDR of UDM 958. In addition to communicating with functions via reference points as shown in the figure, PCF 956 can also present an NPCF service-based interface.

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

[0270] The AF 960 can provide application impact on traffic routing, provide access to NEF, and enable interaction with policy frameworks for policy control.

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

[0272] Data network 936 can represent various network operator services, Internet access, or third-party services, which can be provided by one or more servers, such as application / content servers 938.

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

[0274] UE 1002 can be communicatively coupled to AN 1004 via connection 1006. Connection 1006 is illustrated as an air interface for communication coupling and can comply with cellular communication protocols, such as LTE or 5G NR protocols operating at mmWave or sub-6 GHz frequencies.

[0275] UE 1002 may include a host platform 1008 coupled to a modem platform 1010. Host platform 1008 may include application processing circuitry 1012, which may be coupled to protocol processing circuitry 1014 of modem platform 1010. Application processing circuitry 1012 may run various applications for UE 1002 to source / pool application data. Application processing circuitry 1012 may further 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.

[0276] Protocol processing circuitry 1014 can implement one or more layer operations to facilitate the transmission or reception of data via connection 1006. Layer operations implemented by protocol processing circuitry 1014 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0277] The modem platform 1010 may also include digital baseband circuitry 1016, which implements one or more layer operations in the network protocol stack that are "below" the layer operations performed by the protocol processing circuitry 1014. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK functionality, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding (which may include one or more of space-time, space-frequency, or spatial 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.

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

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

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

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

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

[0283] Figure 11 The block diagram illustrates components, according to some example embodiments, 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 methods discussed herein. Specifically, Figure 11 A schematic representation of hardware resources 1100 is shown, including one or more processors (or processor cores) 1110, one or more memory / storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via bus 1140 or other interface circuitry. In embodiments utilizing node virtualization (e.g., NFV), a hypervisor 1102 may be executed to provide an execution environment for one or more network slices / subslices utilizing hardware resources 1100.

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

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

[0286] Communication resource 1130 may include an interconnect or network interface controller, component, or other suitable device for communicating via network 1108 with one or more peripheral devices 1104 or one or more databases 1106 or other network elements. For example, communication resource 1130 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, etc. (or low energy consumption) ) components, Components, and other communication components.

[0287] Instructions 1150 may include software, programs, applications, applets, or other executable code for causing at least any one of the processors 1110 to perform any one or more of the methods discussed herein. Instructions 1150 may reside wholly or partially within at least one of the processors 1110 (e.g., within the processor's cache memory), within memory / storage device 1120, or any suitable combination thereof. Furthermore, any portion of instructions 1150 may be transferred from any combination of peripheral device 1104 or database 1106 to hardware resource 1100. Therefore, the memory of processor 1110, memory / storage device 1120, peripheral device 1104, and database 1106 are examples of computer-readable and machine-readable media.

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

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

[0290] Although Figure 12Not specifically shown, but in some embodiments, network 1200 may include multiple UEs that are directly coupled to each other via sidelink interfaces. The UEs may be M2M / D2D devices that communicate using physical sidelink channels, such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc. Similarly, although in Figure 12 Not specifically shown, but UE 1202 can be used with AP (e.g., reference). Figure 9 The AP 906 described is coupled in communication. Furthermore, although in Figure 12 Not specifically shown, but in some embodiments, RAN 1208 may include one or more ANs, for example, as referenced. Figure 9 The AN908 described. RAN 1208 and / or the AN of RAN 1208 may be referred to as a base station (BS), RAN node, or some other term or name.

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

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

[0293] In addition, RAN 1208 may include various additional functions that are additions to or replacements for functions of traditional cellular networks (such as 4G or 5G networks). Two such functions may include Compute Control Function (Comp CF) 1224 and Compute Service Function (Comp SF) 1236. Comp CF 1224 and Comp SF 1236 may be parts or functions of the Compute Service Plane. CompCF 1224 may be a control plane function that provides functions such as: management of Comp SF 1236, generation and management of compute task contexts (e.g., creation, reading, modification, deletion), interaction with the underlying compute infrastructure for compute resource management, etc. Comp SF 1236 may be a user plane function that acts as an interface gateway between compute service users (e.g., UE 1202) and the compute nodes behind the CompSF instance. Some functions of Comp SF 1236 may include: parsing compute service data received from users to compute tasks that can be performed by compute nodes; maintaining the service mesh ingress gateway or service API gateway; enforcing service and charging policies; performance monitoring and telemetry collection, etc. In some embodiments, a Comp SF 1236 instance can serve as a user plane gateway for a cluster of compute nodes. A Comp CF 1224 instance can control one or more Comp SF 1236 instances.

[0294] Two other such functions may include a communication control function (Comm CF) 1228 and a communication service function (CommSF) 1238, which may be part of the communication service plane. Comm CF 1228 may be a control plane function for managing Comm SF 1238, communication session creation / configuration / release, and managing communication session contexts. Comm SF 1238 may be a user plane function for data transfer. Comm CF 1228 and Comm SF 1238 can be considered upgrades to SMF 946 and UPF948, for which reference has been made. Figure 9 The 5G system described in the document. Upgrades provided by Comm CF 1228 and Comm SF 1238 enable service-aware transport. For legacy (e.g., 4G or 5G) data transmission, SMF 946 and UPF 948 can still be used.

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

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

[0297] Another such function could be a service registration function (SRF) 1214, which can act as a registry center for system services provided in the user plane, such as services provided by service endpoints behind the Comp SF 1236 and Data SF 1232 gateways, as well as services provided by UE 1202. SRF 1214 can be considered a counterpart to NRF 954, which can act as a registry center for network functions.

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

[0299] Another such function is AMF 1244. AMF 1244 can be similar to 944, but with additional functionality. Specifically, AMF 1244 may include potential function refactoring, such as moving message forwarding functionality from AMF 1244 to RAN 1208.

[0300] Another such feature is the service orchestration exposure function (SOEF)1218. SOEF can be configured to expose service orchestration and chaining services to external users (such as applications).

[0301] UE 1202 may include additional functionality called Computational Client Service Function (comp CSF) 1204. comp CSF 1204 may have both control plane and user plane functions and can interact with corresponding network-side functions (e.g., SOCF 1220, Comp CF 1224, Comp SF 1236, Data CF 1222, and / or Data SF 1232) to perform service discovery, request / response, computational task workload exchange, and so on. Comp CSF 1204 may also cooperate with network-side functions to determine whether computational tasks should run on elements of UE 1202, RAN 1208, and / or 6G CN 1210.

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

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

[0304] Example 1 includes an apparatus comprising: a memory; and processor circuitry coupled to the memory, wherein the processor circuitry is configured to: generate performance measurements for handover related to mobility load balancing (MLB); and cause the performance measurements to be reported to a service consumer via a service producer, wherein the memory is configured to store the performance measurements.

[0305] Example 2 includes the apparatus described in Example 1 or any other example herein, wherein the performance measurement result is implemented as an accumulation counter (CC) triggered by a corresponding condition.

[0306] Example 3 includes the apparatus described in Example 1 or any other example herein, wherein the performance measurement results are related to the handover between next-generation node Bs (gNBs) for MLB.

[0307] Example 4 includes the apparatus described in Example 3 or any other example herein, wherein the performance measurement results include: the number of gNB handover preparations for an MLB request; the number of gNB handover preparations for a successful MLB request; the number of gNB handover preparations for a failed MLB request; the number of gNB handover executions for a successful MLB request; or the number of gNB handover executions for a failed MLB request.

[0308] Example 5 includes the apparatus described in Example 4 or any other example herein, wherein the number of gNB handover preparations in response to an MLB request is implemented as a cumulative counter (CC), the CC being triggered by: the source gNB central unit (CU) sending a HANDOVER REQUIRED message to the Access and Mobility Management Function (AMF); or the source gNB CU sending a HANDOVER REQUEST message to the target gNB CU.

[0309] Example 6 includes the apparatus described in Example 4 or any other example herein, wherein the number of successful gNB handover preparations for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER COMMAND message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER REQUEST ACKNOWLEDGE message from the target gNB CU.

[0310] Example 7 includes the apparatus described in Example 4 or any other example herein, wherein the number of gNB handover preparations for MLB failure is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER PREPARATION FAILURE message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER PREPARATION FAILURE message from the target gNB CU.

[0311] Example 8 includes the apparatus described in Example 4 or any other example herein, wherein the number of gNB handovers performed in response to an MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRCReconfiguration message to a user equipment (UE) requesting an inter-gNB handover from a source gNB central unit (CU) to a target gNB CU for an MLB.

[0312] Example 9 includes the apparatus described in Example 4 or any other example herein, wherein the number of successful inter-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE message from the target gNB CU; or after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE COMMAND from the Access and Mobility Management Function (AMF).

[0313] Example 10 includes the apparatus described in Example 4 or any other example herein, wherein the number of gNB handover executions for MLB failures is implemented as a cumulative counter (CC), the CC being triggered by: the source gNB central unit (CU) receiving a Next Generation Application Protocol (NGAP) UE CONTEXT RELEASECOMMAND from the Access and Mobility Management Function (AMF), indicating an unsuccessful gNB handover; the source gNB receiving an RrcReestablishmentRequest from the User Equipment (UE), where reestablishmentCause is set to handoverFailure, indicating a re-establishment at the source gNB; the handover execution monitoring timer in the source gNB expiring; or the source gNB receiving an Xn Application Protocol (XnAP) RETRIEVE UE CONTEXT REQUEST from another gNB that is not the target gNB, indicating a re-establishment at that other gNB.

[0314] Example 11 includes the apparatus described in Example 1 or any other example herein, wherein the performance measurement is related to handover within a next-generation node B (gNB) for MLB.

[0315] Example 12 includes the apparatus described in Example 11 or any other example herein, wherein the performance measurement results include: the number of gNB in-gNB handovers performed for an MLB request; or the number of gNB in-gNB handovers performed for a successful MLB.

[0316] Example 13 includes the apparatus described in Example 12 or any other example herein, wherein the number of gNB intra-handover executions for the MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRC Reconfiguration message to the user equipment (UE) requesting a gNB intra-handover from the source new radio cell central unit (NRCellCU) to the target NRCellCU for the MLB.

[0317] Example 14 includes the apparatus described in Example 12 or any other example herein, wherein the number of successful intra-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when the target New Radio Cell Central Unit (NRCellCU) receives an RRC ReconfigurationComplete message from the User Equipment (UE) indicating a successful intra-gNB handover for the MLB.

[0318] Example 15 includes the apparatus described in Example 1 or any other example herein, wherein the performance measurement results include the number of classification handover failures caused by MLBs within the system, which are implemented as corresponding sub-counters for the respective handover failure types.

[0319] Example 16 includes the apparatus described in Example 15 or any other example herein, wherein the handover failure type includes premature handover, late handover, and handover to the wrong cell event.

[0320] Example 17 includes the apparatus described in any of Examples 1 to 16 or any other example herein, wherein the apparatus is adapted for a next-generation node B (gNB).

[0321] Example 18 includes the apparatus described in Example 17 or any other example herein, wherein the service producer is located inside the gNB or connected to the gNB externally.

[0322] Example 19 includes the apparatus described in any one of Examples 1 to 16 or any other example herein, wherein the service consumer includes a managed service consumer (MnS-C).

[0323] Example 20 includes the apparatus described in any one of Examples 1 to 16 or any other example herein, wherein the service producer includes a managed service producer (MnS-P).

[0324] Example 21 includes an apparatus comprising: a memory; and processor circuitry coupled to the memory, wherein the processor circuitry is configured to: collect performance measurements for handover related to mobility load balancing (MLB); and report the performance measurements to a service consumer, wherein the memory is configured to store the performance measurements.

[0325] Example 22 includes the apparatus described in Example 21 or any other example herein, wherein the performance measurement result is implemented as an accumulation counter (CC) triggered by a corresponding condition.

[0326] Example 23 includes the apparatus described in Example 21 or any other example herein, wherein the performance measurement results are related to the handover between next-generation node Bs (gNBs) for MLB.

[0327] Example 24 includes the apparatus described in Example 23 or any other example herein, wherein the performance measurements include: the number of gNB handover preparations for an MLB request; the number of gNB handover preparations for a successful MLB request; the number of gNB handover preparations for a failed MLB request; the number of gNB handover executions for a successful MLB request; or the number of gNB handover executions for a failed MLB request.

[0328] Example 25 includes the apparatus described in Example 24 or any other example herein, wherein the number of gNB handover preparations in response to an MLB request is implemented as a cumulative counter (CC), the CC being triggered by: the source gNB central unit (CU) sending a HANDOVER REQUIRED message to the Access and Mobility Management Function (AMF); or the source gNB CU sending a HANDOVER REQUEST message to the target gNB CU.

[0329] Example 26 includes the apparatus described in Example 24 or any other example herein, wherein the number of successful gNB handover preparations for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER COMMAND message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER REQUEST ACKNOWLEDGE message from the target gNB CU.

[0330] Example 27 includes the apparatus described in Example 24 or any other example herein, wherein the number of gNB handover preparations for MLB failure is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER PREPARATION FAILURE message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER PREPARATION FAILURE message from the target gNB CU.

[0331] Example 28 includes the apparatus described in Example 24 or any other example herein, wherein the number of gNB handovers performed in response to an MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRCReconfiguration message to a user equipment (UE) requesting an inter-gNB handover from a source gNB central unit (CU) to a target gNB CU for an MLB.

[0332] Example 29 includes the apparatus described in Example 24 or any other example herein, wherein the number of successful inter-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE message from the target gNB CU; or after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE COMMAND from the Access and Mobility Management Function (AMF).

[0333] Example 30 includes the apparatus described in Example 24 or any other example herein, wherein the number of gNB handover executions for MLB failures is implemented as a cumulative counter (CC), the CC being triggered by: the source gNB central unit (CU) receiving a Next Generation Application Protocol (NGAP) UE CONTEXT RELEASECOMMAND from the Access and Mobility Management Function (AMF), indicating an unsuccessful gNB handover; the source gNB receiving an RrcReestablishmentRequest from the User Equipment (UE), wherein reestablishmentCause is set to handoverFailure, and re-establishment occurs at the source gNB; the handover execution monitoring timer in the source gNB expiring; or the source gNB receiving an Xn Application Protocol (XnAP) RETRIEVE UE CONTEXT REQUEST from another gNB that is not the target gNB, wherein re-establishment occurs at that other gNB.

[0334] Example 31 includes the apparatus described in Example 21 or any other example herein, wherein the performance measurement is related to handover within a next-generation node B (gNB) for MLB.

[0335] Example 32 includes the apparatus described in Example 31 or any other example herein, wherein the performance measurement results include: the number of gNB in-gNB handovers performed for an MLB request; or the number of gNB in-gNB handovers performed for a successful MLB.

[0336] Example 33 includes the apparatus described in Example 32 or any other example herein, wherein the number of gNB intra-handover executions for the MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRC Reconfiguration message to the user equipment (UE) requesting a gNB intra-handover from the source new radio cell central unit (NRCellCU) to the target NRCellCU for the MLB.

[0337] Example 34 includes the apparatus described in Example 32 or any other example herein, wherein the number of successful intra-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when the target New Radio Cell Central Unit (NRCellCU) receives an RRC ReconfigurationComplete message from the User Equipment (UE) indicating a successful intra-gNB handover for the MLB.

[0338] Example 35 includes the apparatus described in Example 21 or any other example herein, wherein the performance measurement results include the number of classification handover failures caused by MLBs within the system, which are implemented as corresponding sub-counters for the respective handover failure types.

[0339] Example 36 includes the apparatus described in Example 35 or any other example herein, wherein the handover failure type includes premature handover, late handover, and handover to the wrong cell event.

[0340] Example 37 includes the apparatus described in any of Examples 21 to 36 or any other example herein, wherein the apparatus is suitable for a service producer.

[0341] Example 38 includes the apparatus described in Example 37 or any other example herein, wherein the service producer is located inside the gNB or connected to the gNB externally.

[0342] Example 39 includes the apparatus described in Example 37 or any other example herein, wherein the service producer includes a managed service producer (MnS-P).

[0343] Example 40 includes the apparatus described in any one of Examples 21 to 36 or any other example herein, wherein the service consumer includes a managed service consumer (MnS-C).

[0344] Example 41 includes a method comprising: generating performance measurements for handover related to mobility load balancing (MLB); and causing the performance measurements to be reported to a service consumer via a service producer.

[0345] Example 42 includes the method described in Example 41 or any other example herein, wherein the performance measurement result is implemented as an accumulation counter (CC) triggered by a corresponding condition.

[0346] Example 43 includes the method described in Example 41 or any other example herein, wherein the performance measurement is related to the handover between next-generation node Bs (gNBs) for MLB.

[0347] Example 44 includes the method described in Example 43 or any other example herein, wherein the performance measurement results include: the number of gNB handover preparations for an MLB request; the number of gNB handover preparations for a successful MLB request; the number of gNB handover preparations for a failed MLB request; the number of gNB handover executions for a successful MLB request; or the number of gNB handover executions for a failed MLB request.

[0348] Example 45 includes the method described in Example 44 or any other example herein, wherein the number of gNB handover preparations for the MLB request is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) sends a HANDOVER REQUIRED message to the Access and Mobility Management Function (AMF); or the source gNB CU sends a HANDOVER REQUEST message to the target gNB CU.

[0349] Example 46 includes the method described in Example 44 or any other example herein, wherein the number of successful gNB handover preparations for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER COMMAND message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER REQUEST ACKNOWLEDGE message from the target gNB CU.

[0350] Example 47 includes the method described in Example 44 or any other example herein, wherein the number of gNB handover preparations for MLB failure is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER PREPARATION FAILURE message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER PREPARATION FAILURE message from the target gNB CU.

[0351] Example 48 includes the method described in Example 44 or any other example herein, wherein the number of gNB handovers performed for the MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRCReconfiguration message to the user equipment (UE) requesting a gNB handover from the source gNB central unit (CU) to the target gNB CU for the MLB.

[0352] Example 49 includes the method described in Example 44 or any other example herein, wherein the number of successful inter-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE message from the target gNB CU; or after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE COMMAND from the Access and Mobility Management Function (AMF).

[0353] Example 50 includes the method described in Example 44 or any other example herein, wherein the number of inter-gNB handover executions for MLB failures is implemented as a cumulative counter (CC), the CC being triggered by: the source gNB central unit (CU) receiving a Next Generation Application Protocol (NGAP) UE CONTEXT RELEASECOMMAND from the Access and Mobility Management Function (AMF), indicating an unsuccessful inter-gNB handover; the source gNB receiving an RrcReestablishmentRequest from the User Equipment (UE), where reestablishmentCause is set to handoverFailure, indicating a re-establishment at the source gNB; the handover execution monitoring timer in the source gNB expiring; or the source gNB receiving an Xn Application Protocol (XnAP) RETRIEVE UE CONTEXT REQUEST from another gNB that is not the target gNB, indicating a re-establishment at that other gNB.

[0354] Example 51 includes the method described in Example 41 or any other example herein, wherein the performance measurement is related to the handover within a next-generation node B (gNB) for MLB.

[0355] Example 52 includes the method described in Example 51 or any other example herein, wherein the performance measurement results include: the number of gNB in-gNB switchovers performed for an MLB request; or the number of gNB in-gNB switchovers performed for a successful MLB.

[0356] Example 53 includes the method described in Example 52 or any other example herein, wherein the number of intra-gNB handover executions for the MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRC Reconfiguration message to the user equipment (UE) requesting an intra-gNB handover from the source new radio cell central unit (NRCellCU) to the target NRCellCU for the MLB.

[0357] Example 54 includes the method described in Example 52 or any other example herein, wherein the number of successful intra-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when the target New Radio Cell Central Unit (NRCellCU) receives an RRC ReconfigurationComplete message from the User Equipment (UE) indicating a successful intra-gNB handover for the MLB.

[0358] Example 55 includes the method described in Example 41 or any other example herein, wherein the performance measurement results include the number of class-specific handover failures caused by MLBs within the system, which are implemented as corresponding sub-counters for the respective handover failure types.

[0359] Example 56 includes the method described in Example 55 or any other example herein, wherein the handover failure type includes premature handover, late handover, and handover to the wrong cell event.

[0360] Example 57 includes the method described in any of Examples 41 to 56 or any other example herein, wherein the method is applicable to next-generation node B (gNB).

[0361] Example 58 includes the method described in Example 57 or any other example herein, wherein the service producer is located inside or connected to the gNB externally.

[0362] Example 59 includes the method described in any of Examples 41 to 56 or any other example herein, wherein the service consumer includes a managed service consumer (MnS-C).

[0363] Example 60 includes the method described in any of Examples 41 to 56 or any other example herein, wherein the service producer includes a managed service producer (MnS-P).

[0364] Example 61 includes a method comprising: collecting performance measurements for handover related to mobility load balancing (MLB); and reporting the performance measurements to a service consumer.

[0365] Example 62 includes the method described in Example 61 or any other example herein, wherein the performance measurement result is implemented as an accumulation counter (CC) triggered by a corresponding condition.

[0366] Example 63 includes the method described in Example 61 or any other example herein, wherein the performance measurement is related to the handover between next-generation node Bs (gNBs) for MLB.

[0367] Example 64 includes the method described in Example 63 or any other example herein, wherein the performance measurement results include: the number of gNB handover preparations for an MLB request; the number of gNB handover preparations for a successful MLB request; the number of gNB handover preparations for a failed MLB request; the number of gNB handover executions for a successful MLB request; or the number of gNB handover executions for a failed MLB request.

[0368] Example 65 includes the method described in Example 64 or any other example herein, wherein the number of gNB handover preparations for the MLB request is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) sends a HANDOVER REQUIRED message to the Access and Mobility Management Function (AMF); or the source gNB CU sends a HANDOVER REQUEST message to the target gNB CU.

[0369] Example 66 includes the method described in Example 64 or any other example herein, wherein the number of successful gNB handover preparations for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER COMMAND message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER REQUEST ACKNOWLEDGE message from the target gNB CU.

[0370] Example 67 includes the method described in Example 64 or any other example herein, wherein the number of gNB handover preparations for MLB failure is implemented as a cumulative counter (CC), the CC being triggered when: the source gNB central unit (CU) receives a HANDOVER PREPARATION FAILURE message from the Access and Mobility Management Function (AMF); or the source gNB CU receives a HANDOVER PREPARATION FAILURE message from the target gNB CU.

[0371] Example 68 includes the method described in Example 64 or any other example herein, wherein the number of gNB handovers performed for the MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRCReconfiguration message to the user equipment (UE) requesting a gNB handover from the source gNB central unit (CU) to the target gNB CU for the MLB.

[0372] Example 69 includes the method described in Example 64 or any other example herein, wherein the number of successful inter-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when: after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE message from the target gNB CU; or after a successful inter-gNB handover for the MLB, the source gNB central unit (CU) receives a UE CONTEXT RELEASE COMMAND from the Access and Mobility Management Function (AMF).

[0373] Example 70 includes the method described in Example 64 or any other example herein, wherein the number of inter-gNB handover executions for MLB failures is implemented as a cumulative counter (CC), the CC being triggered by: the source gNB central unit (CU) receiving a Next Generation Application Protocol (NGAP) UE CONTEXT RELEASECOMMAND from the Access and Mobility Management Function (AMF), indicating an unsuccessful inter-gNB handover; the source gNB receiving an RrcReestablishmentRequest from the User Equipment (UE), where reestablishmentCause is set to handoverFailure, indicating a re-establishment at the source gNB; the handover execution monitoring timer in the source gNB expiring; or the source gNB receiving an Xn Application Protocol (XnAP) RETRIEVE UE CONTEXT REQUEST from another gNB that is not the target gNB, indicating a re-establishment at that other gNB.

[0374] Example 71 includes the method described in Example 61 or any other example herein, wherein the performance measurement is related to the handover within a next-generation node B (gNB) for MLB.

[0375] Example 72 includes the method described in Example 71 or any other example herein, wherein the performance measurement results include: the number of gNB in-gNB switchovers performed for an MLB request; or the number of gNB in-gNB switchovers performed for a successful MLB.

[0376] Example 73 includes the method described in Example 72 or any other example herein, wherein the number of intra-gNB handover executions for the MLB request is implemented as a cumulative counter (CC), the CC being triggered by sending an RRC Reconfiguration message to the user equipment (UE) requesting an intra-gNB handover from the source new radio cell central unit (NRCellCU) to the target NRCellCU for the MLB.

[0377] Example 74 includes the method described in Example 72 or any other example herein, wherein the number of successful intra-gNB handovers performed for the MLB is implemented as a cumulative counter (CC), the CC being triggered when the target New Radio Cell Central Unit (NRCellCU) receives an RRC ReconfigurationComplete message from the User Equipment (UE) indicating a successful intra-gNB handover for the MLB.

[0378] Example 75 includes the method described in Example 61 or any other example herein, wherein the performance measurement results include the number of classification handover failures caused by MLBs within the system, which are implemented as corresponding sub-counters for the respective handover failure types.

[0379] Example 76 includes the method described in Example 75 or any other example herein, wherein the handover failure type includes premature handover, late handover, and handover to the wrong cell event.

[0380] Example 77 includes the method described in any of Examples 61 to 76 or any other example herein, wherein the method is applicable to a service producer.

[0381] Example 78 includes the method described in Example 77 or any other example herein, wherein the service producer is located inside the gNB or connected to the gNB externally.

[0382] Example 79 includes the method described in Example 77 or any other example herein, wherein the service producer includes a managed service producer (MnS-P).

[0383] Example 80 includes the method described in any of Examples 61 to 76 or any other example herein, wherein the service consumer includes a managed service consumer (MnS-C).

[0384] Example 81 includes an apparatus comprising components for performing the method of any one of Examples 41 to 60.

[0385] Example 82 includes an apparatus comprising components for performing the method of any one of Examples 61 to 80.

[0386] Example 83 includes a computer-readable medium storing instructions that, when executed by processing circuitry, cause the processing circuitry to perform the method of any one of Examples 41 to 60.

[0387] Example 84 includes a computer-readable medium storing instructions that, when executed by processing circuitry, cause the processing circuitry to perform the method of any one of Examples 61 to 80.

[0388] While some embodiments have been illustrated and described herein for purposes of description, various alternative and / or equivalent embodiments or implementations devised to achieve the same purpose may replace the illustrated and described embodiments without departing from the scope of this disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is readily understood that the embodiments described herein are limited only by the appended claims and their equivalents.

Claims

1. An apparatus comprising: Memory; as well as The processor circuitry coupled to the memory, The processor circuit is used for: Performance measurements are generated for handover related to Mobility Load Balancing (MLB); and This enables service producers to report the performance measurement results to service consumers. The memory is used to store the performance measurement results.

2. The apparatus according to claim 1, wherein, The performance measurement results are implemented as an accumulation counter (CC) triggered by corresponding conditions.

3. The apparatus according to claim 1, wherein, The performance measurement results are related to the handover between next-generation node Bs (gNBs) for MLB.

4. The apparatus according to claim 3, wherein, The performance measurement results include: Number of gNB handover preparations for MLB requests; Number of times preparation is required for a successful gNB handover in MLB; Number of times to prepare for gNB handover in case of MLB failure; Number of gNB handover executions for MLB requests; The number of successful gNB handover executions for MLB; or The number of times the gNB switchover is executed when the MLB fails.

5. The apparatus according to claim 4, wherein, The number of gNB handover preparations for the MLB request is implemented as a cumulative counter (CC), and the triggering condition for the CC is: The source gNB central unit (CU) sends a HANDOVER REQUIRED message to the Access and Mobility Management Function (AMF); or The source gNB CU sends a HANDOVER REQUEST message to the target gNB CU.

6. The apparatus according to claim 4, wherein, The number of successful gNB handover preparations for MLB is implemented as a cumulative counter (CC), and the trigger condition for the CC is: The source gNB centralized unit (CU) receives a HANDOVER COMMAND message from the Access and Mobility Management Function (AMF); or The source gNB CU receives a HANDOVER REQUEST ACKNOWLEDGE message from the target gNB CU.

7. The apparatus according to claim 4, wherein, The number of gNB handover preparations for MLB failures is implemented as a cumulative counter (CC), and the triggering condition for the CC is: The source gNB central unit (CU) receives a HANDOVER PREPARATIONFAILURE message from the Access and Mobility Management Function (AMF); or The source gNB CU receives a HANDOVER PREPARATION FAILURE message from the target gNB CU.

8. The apparatus according to claim 4, wherein, The number of gNB handovers performed in response to the MLB request is implemented as a cumulative counter (CC). The trigger condition for the CC is: sending an RRCReconfiguration message to the user equipment (UE) to request an inter-gNB handover from the source gNB central unit (CU) to the target gNB CU for the MLB.

9. The apparatus according to claim 4, wherein, The number of successful gNB handovers for MLB is implemented as a cumulative counter (CC), and the triggering condition for the CC is: After a successful inter-gNB handover for MLB, the source gNB central unit (CU) receives the UECONTEXT RELEASE message from the target gNB CU; or After a successful gNB handover for MLB, the source gNB central unit (CU) receives the UE CONTEXT RELEASE COMMAND from the Access and Mobility Management Function (AMF).

10. The apparatus according to claim 4, wherein, The number of gNB handover executions for MLB failures is implemented as a cumulative counter (CC), and the triggering condition for the CC is: The source gNB central unit (CU) receives the Next Generation Application Protocol (NGAP) UECONTEXT RELEASE COMMAND from the Access and Mobility Management Function (AMF), indicating that the handover between gNBs was unsuccessful; The source gNB receives an RrcReestablishmentRequest from the user equipment (UE), where reestablishmentCause is set to handoverFailure, and a re-establishment occurs at the source gNB; The switchover execution monitoring timer in the source gNB expires; or The source gNB receives the Xn Application Protocol (XnAP) RETRIEVE UE CONTEXTREQUEST from another gNB that is not the target gNB, where a re-establishment occurs at that other gNB.

11. The apparatus according to claim 1, wherein, The performance measurement results are related to the handover within the next-generation node B (gNB) for MLB.

12. The apparatus according to claim 11, wherein, The performance measurement results include: The number of gNB-based switchover executions for MLB requests; or The number of successful gNB intra-switch executions for MLB.

13. The apparatus according to claim 12, wherein, The number of intra-gNB handover executions for the MLB request is implemented as a cumulative counter (CC). The trigger condition for the CC is: sending an RRC Reconfiguration message to the user equipment (UE) to request an intra-gNB handover from the source new radio cell central unit (NRCellCU) to the target NRCellCU for the MLB.

14. The apparatus according to claim 12, wherein, The number of successful intra-gNB handovers for MLB is implemented as a cumulative counter (CC). The trigger condition for the CC is: the target New Radio Cell Central Unit (NRCellCU) receives an RRC ReconfigurationComplete message from the User Equipment (UE), indicating that a successful intra-gNB handover for MLB has been performed.

15. The apparatus according to claim 1, wherein, The performance measurement results include the number of classification handover failures caused by MLB within the system, which are implemented as corresponding sub-counters for the corresponding handover failure types.

16. The apparatus according to claim 15, wherein, The handover failure types include premature handover, late handover, and handover to the wrong cell.

17. The apparatus according to any one of claims 1 to 16, wherein, This device is suitable for next-generation node B (gNB).

18. The apparatus according to claim 17, wherein, The service provider is located inside the gNB or connected to the gNB from the outside.

19. The apparatus according to any one of claims 1 to 16, wherein, The service consumers include managed service consumers (MnS-C).

20. The apparatus according to any one of claims 1 to 16, wherein, The service producers include managed service producers (MnS-P).

Images