Gapless cross-radio access technology (RAT) measurement

Abstract

The present invention relates to a computer readable storage medium having stored therein instructions for execution by one or more processors of a UE. These instructions configure the UE for cross-RAT NR-EUTRAN measurements in a 5G NR network and a more advanced network, and cause the UE to perform operations including encoding notification signaling to be transmitted to the base station. The notification signaling indicates the capability of the UE to perform a measurement gap-free cross-RAT NR-EUTRAN measurement. Configuration signaling received from a base station is decoded. The configuration signaling will configure a periodicity and a minimum available time associated with an effective measurement window (EMW) that does not overlap with the measurement gap. A cross-RAT NR-EUTRAN measurement is performed within the EMW, the measurement having a duration within a minimum available time.

Description

[0001] Cross-reference to related applications This application claims priority to International Application No. PCT / CN2023 / 110952, filed August 3, 2023, entitled “Gapless Measurement Across Radio Access Technologies (RATs)”, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communications have evolved significantly from early voice systems to today's highly complex integrated communication platforms. The application of 3GPP LTE systems has increased along with the growing number of different types of devices communicating with various network devices. The proliferation of mobile devices (User Equipment) in modern society continues to drive demand for a wide range of networking equipment in many different environments. The advent of fifth-generation (5G) wireless systems is expected to deliver significant improvements in speed, connectivity, and availability. Next-generation 5G networks (or NR networks) and more advanced network technologies (such as 6G networks) promise to increase throughput, coverage, and robustness while reducing latency and operating and capital expenditures. 5G NR (and more advanced network technologies) networks will continue to evolve based on 3GPP LTE-Advanced and other potential New Radio Access Technologies (RATs) to enrich people's lives with fast, rich content and services through seamless wireless connectivity solutions. As current cellular network frequencies are nearing saturation, higher frequencies such as millimeter wave (mmWave) frequencies offer significant advantages due to their high bandwidth.

[0003] In future versions of 5G and more advanced communication systems, it is expected that the operation of LTE and NR systems in licensed and unlicensed spectrum will be further enhanced. Such enhanced operation may include techniques for gapless cross-Radio Access Technology (RAT) New Radio-Evolved Universal Terrestrial Radio Access Network (NR-EUTRAN) measurements. Attached Figure Description

[0004] In accompanying drawings that are not necessarily drawn to scale, the same reference numerals may describe similar components in different views. Similar reference numerals with different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate the various aspects discussed in this document in an illustrative rather than restrictive manner.

[0005] Figure 1A The network architecture is shown based on several aspects.

[0006] Figure 1B and Figure 1C The non-roaming 5G system architecture is shown based on some aspects.

[0007] Figure 2 , Figure 3 , Figure 4 and Figure 5 Various systems, architectures, devices, and components are shown that can implement aspects of the disclosed implementation methods.

[0008] Figure 6 An exemplary Artificial Intelligence (AI)-assisted communication architecture for communication between the UE and the RAN is shown, based on several aspects.

[0009] Figure 7 An exemplary RAN-separated architecture is shown based on some aspects.

[0010] Figure 8 The diagram illustrates an NR-LTE measurement arrangement configured based on the Effective Measurement Window (EMW) according to several aspects.

[0011] Figure 9 A block diagram is shown for communication equipment (such as evolved Node B (eNB), next-generation Node B (gNB) (or another RAN node), NCR, access point (AP), radio station (STA), mobile station (MS) or user equipment (UE)) based on some aspects. Detailed Implementation

[0012] The following description and accompanying drawings fully illustrate the various aspects to enable those skilled in the art to implement them. Other aspects may include variations in structure, logic, electrical, process, etc. Parts and features of some aspects may be included in or substitute for parts and features of other aspects. The aspects set forth in the claims cover all available equivalents of these claims.

[0013] Figures 1A to 9 Various systems, devices, and components are shown that can implement aspects of the disclosed implementation methods in different communication systems, such as LTE (EUTRA) and 5G-NR (and more advanced versions) networks. The UEs, base stations (such as gNBs), and / or other nodes (e.g., satellites or other computing nodes) discussed herein can be configured to perform the disclosed techniques.

[0014] Figure 1AA network architecture based on several aspects is illustrated. The communication network 140A is shown as including user equipment (UE) 101 and UE 102. UE 101 and UE 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device (such as a personal data assistant (PDA), pager, laptop computer, desktop computer, wireless phone, drone, or any other computing device including wired and / or wireless communication interfaces). UE 101 and UE 102 may be collectively referred to herein as UE 101, and UE 101 may be used to perform one or more of the techniques disclosed herein.

[0015] Any wireless link described herein (e.g., used in communication network 140A or any other network shown) may operate according to any exemplary wireless communication technology and / or standard.

[0016] LTE and LTE-Advanced are standards for high-speed data wireless communication for UEs (such as mobile phones). In LTE-Advanced and various wireless systems, multiple carrier signals operating at different frequencies can be used to carry the communication of a single UE, thereby increasing the bandwidth available to a single device, based on carrier aggregation technology. In some aspects, carrier aggregation can be employed, where one or more component carriers operate on unlicensed frequencies.

[0017] The aspects described herein can be applied to any spectrum management scenario, including dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (such as Licensed Shared Access (LSA) in 2.3-2.4 GHz, 3.4-3.6 GHz, and 3.6-3.8 GHz, and other frequency and spectrum access systems (SAS) in 3.55-3.7 GHz and other frequencies).

[0018] By assigning OFDM carrier data bit vectors to corresponding symbol resources, the aspects described herein can also be applied to different single-carrier or OFDM variants (CP-OFDM, SC-FDMA, SC-OFDM, FilterBank-Based Multicarrier (FBMC), OFDMA, etc.), especially 3GPP NR (New Radio).

[0019] In some aspects, either UE 101 or UE 102 may include an Internet-of-Things (IoT) UE or a Cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications utilizing short-lived UE connectivity. In some aspects, either UE 101 or UE 102 may include a narrowband (NB) IoT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). IoT UEs may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with MTC servers or devices via a Public Land Mobile Network (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. IoT networks include interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the interconnected network infrastructure) with short-lived connectivity. IoT UEs can execute background applications (e.g., keep-alive messages, state updates, etc.) to facilitate connectivity in IoT networks.

[0020] In some respects, either UE 101 or UE 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0021] UE 101 and UE 102 are configured to connect to (e.g., communications coupled) a radio access network (RAN) 110. For example, RAN 110 may be a Universal Mobile Telecommunications System (UMTS), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. UE 101 and UE 102 utilize connections 103 and 104, respectively, each connection including a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as air interfaces for implementing communications coupling and may conform to cellular communication protocols such as GSM, CDMA, Push-to-Talk (PTT), PTT over Cellular (POC), UMTS, 3GPP LTE, 5G, NR, etc.

[0022] In one aspect, UE 101 and UE 102 may further exchange communication data directly via ProSe interface 105. Alternatively, ProSe interface 105 may be referred to as a sidelink interface, which includes 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)).

[0023] UE 102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection (such as a connection compliant with any IEEE 802.11 protocol), and AP 106 may include a Wireless Fidelity (WiFi®) router. In this example, AP 106 is shown connected to an interworking network but not to the core network of the wireless system (described in further detail below).

[0024] RAN 110 may include one or more access nodes that implement connections 103 and 104. These access nodes (ANs) may be referred to as base stations (BS), NodeBs, evolved NodeBs (eNBs), next-generation NodeBs (gNBs), RAN network nodes, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). In some aspects, communication nodes 111 and 112 may be transmission / reception points (TRPs). When communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may operate within the communication cell of the NodeB. RAN 110 may include one or more RAN nodes (e.g., macro RAN nodes) for providing macro cells and one or more RAN nodes (e.g., low-power (LP) RAN nodes or secondary RAN nodes based on unlicensed spectrum) for providing femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells).

[0025] Either communication node 111 or 112 can terminate the air interface protocol and can be the first point of contact for UE101 and UE102. In some respects, either communication node 111 or 112 can implement various logical functions for RAN110, including but not limited to Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and packet scheduling, and mobility management. In one instance, either communication node 111 and / or 112 can be a next-generation node B (gNB), an evolved Node B (eNB), or another type of RAN node.

[0026] RAN 110 is shown as being communicatively coupled to the core network (CN) 120 via S1 interface 113. In some respects, CN 120 may be an Evolved Packet Core (EPC) network, a Next-Gen Packet Core (NPC) network, or some other type of CN (e.g., such as...). Figure 1B and Figure 1C(As shown). In this respect, the S1 interface 113 is split into two parts: the S1-U interface 114, which carries user traffic data between communication nodes 111, 112 and the Serving Gateway (S-GW) 122; and the S1-Mobility Management Entity (MME) interface 115, which is the signaling interface between communication nodes 111, 112 and the MME 121.

[0027] In this respect, CN 120 includes an MME 121, an S-GW 122, a Packet Data Network (PDN) Gateway (P-GW) 123, and a Home Subscriber Server (HSS) 124. The MME 121 can functionally resemble the control plane of a traditional Serving General Packet Radio Service (GPRS) Support Node (SGSN). The MME 121 can manage mobility aspects of access (such as gateway selection and tracking area list management). The HSS 124 can include a database for network users, including subscription-related information, to support network entities in handling communication sessions. CN 120 can include one or more HSS 124s, depending on the number of mobile subscribers, equipment capacity, network organization, etc. For example, the HSS 124 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0028] The S-GW 122 can terminate the S1 interface 113 toward RAN 110 and route packets between RAN 110 and CN 120. Furthermore, the S-GW 122 can serve as a local mobility anchor for cross-RAN node handovers and can also provide an anchor for cross-3GPP mobility. Other responsibilities of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0029] P-GW 123 can terminate the SGi interface toward the PDN. P-GW 123 can route data packets between the EPC network (e.g., CN 120) and external networks (such as a network including application server 184 (alternatively referred to as Application Function (AF)) via Interoperability Protocol (IP) interface 125. P-GW 123 can also transmit data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Typically, application server 184 may be an element providing IP bearer resources used with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data service, etc.). In this respect, P-GW 123 is shown as communicatively coupled to application server 184 via IP interface 125. Application server 184 can 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 and UE 102 via CN 120.

[0030] P-GW 123 can further be a node for policy enforcement and charging data collection. The Policy and Charging Rules Function (PCRF) 126 is the policy and charging control element of CN 120. In non-roaming scenarios, in some aspects, a single PCRF can exist in the Home Public Land Mobile Network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In roaming scenarios with local traffic routing, two PCRFs can exist associated with the UE's IP-CAN session: the Home PCRF (H-PCRF) within the HPLMMN and the Visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). PCRF 126 can be communicatively coupled to the application server 184 via P-GW 123.

[0031] In some respects, the communication network 140A can be an IoT network or a 5G network, including 5G NR networks that communicate under licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current enabling technologies for IoT is narrowband IoT (NB-IoT).

[0032] The NG system architecture may include RAN 110 and a 5G core network (e.g., CN 120). RAN 110 in the NG system may be referred to as NG-RAN. RAN 110 may include multiple nodes (such as gNB and NG-eNB). CN 120 (also known as the 5G core network or 5GC) may include Access and Mobility Functions (AMF) and / or User Plane Functions (UPF). AMF and UPF may be communicatively coupled to gNB and NG-eNB via NG interfaces. More specifically, in some aspects, gNB and NG-eNB may connect to AMF via NG-C interfaces and to UPF via NG-U interfaces. gNB and NG-eNB may be mutually coupled via Xn interfaces.

[0033] In some aspects, the NG system architecture can adopt various node reference points provided by 3GPP Technical Specification (TS) 23.501 (e.g., V15.4.0, 2018-12). In some aspects, each of the gNB and NG-eNB can be implemented as a base station, mobile edge server, small cell, home eNB, RAN network node, etc. In some aspects, in the 5G architecture, the gNB can be the master node (MN), while the NG-eNB can be a secondary node (SN). In some aspects, the master / primary node can operate in licensed frequency bands, while the secondary node can operate in unlicensed frequency bands.

[0034] Figure 1B The non-roaming 5G system architecture is illustrated based on several aspects. See also Figure 1BThe diagram illustrates the 5G system architecture 140B in reference point representation. More specifically, the UE 102 can communicate with the RAN 110 and one or more other 5G core (5GC) network entities. The 5G system architecture 140B includes multiple network functions (NFs), such as the Access and Mobility Management Function (AMF) 132, the Location Management Function (LMF) 133, the Session Management Function (SMF) 136, the Policy Control Function (PCF) 148, the Application Function (AF) 150, the User Plane Function (UPF) 134, the Network Slice Selection Function (NSSF) 142, the Authentication Server Function (AUSF) 144, and the Unified Data Management (UDM) / Home Subscriber Server (HSS) 146. UPF 134 can provide connectivity to a data network (DN) 152, which may include, for example, operator services, inter-network access, or third-party services. AMF 132 can be used to manage access control and mobility, and may also include network slicing selection functionality. SMF 136 can be configured to establish and manage various sessions based on network policies. Depending on the required service type, UPF 134 can be deployed in one or more configurations. PCF 148 can be configured to provide a policy framework employing network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0035] LMF 133 can be used in conjunction with 5G positioning functionality. In some aspects, LMF 133 receives measurement results and auxiliary information from RAN 110 and mobile devices (e.g., UE 101) via the NLs interface through AMF 132 to calculate the location of UE 101. In some aspects, NR Positioning Protocol A (NRPPa) can be used to carry positioning information between the NG-RAN and LMF 133 via the Next-Generation Control Plane Interface (NG-C). In some aspects, LMF 133 uses the LTE Positioning Protocol (LPP) to configure the UE via AMF 132. RAN 110 uses the Radio Resource Control (RRC) protocol via the LTE-Uu and NR-Uu interfaces to configure UE 101.

[0036] In some aspects, the 5G system architecture 140B is configured with different reference signals to enable positioning measurements. Exemplary reference signals that can be used for positioning measurements include the Positioning Reference Signal (PRS) in the downlink and the Sounding Reference Signal (SRS) for positioning in the uplink. The Downlink Positioning Reference Signal (PRS) is a reference signal configured to support downlink-based positioning methods.

[0037] In some aspects, the 5G system architecture 140B includes an IP Multimedia Subsystem (IMS) 168B and multiple IP Multimedia Core Network Subsystem entities (such as the Call Session Control Function (CSCF)). More specifically, IMS 168B includes a CSCF, which can act as a Proxy CSCF (P-CSCF) 162BE, a Serving CSCF (S-CSCF) 164B, and an Emergency CSCF (E-CSCF). Figure 1B(Not shown in the image) or query the CSCF (Interrogating CSCF, I-CSCF) 166B. The P-CSCF 162B can be configured as the first contact point for UE102 within IMS 168B. The S-CSCF 164B can be configured to handle session states within the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions (such as routing emergency requests to the correct emergency center or PSAP). The I-CSCF 166B can be configured to act as a contact point within an operator's network for all IMS connections destined for subscribers of that network operator or roaming subscribers currently within that network operator's service area. In some respects, the I-CSCF 166B can connect to another IP multimedia network 170 (e.g., an IMS operated by a different network operator).

[0038] In some respects, the UDM / HSS 146 can be coupled to an Application Server (AS) 160B, which may include a Telephony Application Server (TAS) or another AS. The AS 160B can be coupled to the IMS 168B via the S-CSCF 164B or the I-CSCF 166B.

[0039] The reference point representation illustrates that interactions can exist between corresponding NF services. For example, Figure 1BThe following reference points are shown: N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM / HSS 146 and AMF 132, not shown), N9 (between the two UPFs, not shown), N10 (between UDM / HSS 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136, not shown), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and AMF 132, not shown). N14 (between PCF 144 and UDM / HSS 146, not shown), N14 (between two AMFs, not shown), N15 (between PCF 148 and AMF 132 in non-roaming situations, or between PCF 148 and the visited network and AMF 132 in roaming situations, not shown), N16 (between two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Alternatively, [further details can be provided]. Figure 1B Other reference point representations not shown in the diagram.

[0040] Figure 1C The 5G system architecture 140C and its service-based representation are shown. Besides... Figure 1B In addition to the network entities shown, the 5G system architecture 140C may also include a Network Exposure Function (NEF) 154 and a Network Repository Function (NRF) 156. In some aspects, the 5G system architecture can be service-based, and the interaction between network functions can be represented by corresponding point-to-point reference points Ni or as service-based interfaces.

[0041] In some aspects, such as Figure 1CAs shown, service-based representations can be used to represent network functions within the control plane that enable other authorized network functions to access their services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf 158H (a service-based interface provided by AMF 132), Nsmf158I (a service-based interface provided by SMF 136), Nnef 158B (a service-based interface provided by NEF 154), Npcf 158D (a service-based interface provided by PCF 148), Nudm 158E (a service-based interface provided by UDM / HSS 146), Naf 158F (a service-based interface provided by AF 150), Nnrf 158C (a service-based interface provided by NRF 156), Nnssf 158A (a service-based interface provided by NSSF 142), and Nausf 158G (a service-based interface provided by AUSF 144). It is also possible to use... Figure 1C Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf).

[0042] Figure 2 An exemplary network architecture 200 is illustrated. Network architecture 200 can operate in a manner consistent with 3GPP technical specifications for LTE or 5G / NR systems and can implement the disclosed technologies (e.g., the disclosed technologies can be configured / implemented by one or more devices operating within network architecture 200). However, the exemplary implementation is not limited to this, and the examples can be applied to other networks (such as future 3GPP systems, etc.) that benefit from the principles described herein.

[0043] Network architecture 200 may include UE 202, which is any mobile or non-mobile computing device designed to communicate with RAN 204 via an over-the-air connection. UE 202 is communicatively coupled to RAN 204 via a Uu interface, which can be used for both LTE and NR systems. Examples of UE 202 include, but are not limited to, smartphones, tablets, wearable devices (e.g., smartwatches, fitness trackers, smart glasses, smart clothing / fabrics, head-mounted displays, and / or smart shoes), desktop computers, workstations, laptops, in-vehicle infotainment systems, in-vehicle entertainment systems, dashboards, head-up display (HUD) devices, in-vehicle diagnostic equipment, desktop mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networking application devices, machine-to-machine (M2M), device-to-device (D2D), machine-type communication (MTC) devices, Internet of Things (IoT) devices, smart application devices, unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, electronic signage, and single-board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel). Edison et al.), plug-in computers and / or any type of computing device (such as any computing device discussed in this article).

[0044] Alternatively, UE 202 may be a RedCap UE, which is a RedCap UE as defined in Clause 4.2.21.1 of 3GPP TS 38.306v17.4.0 (2023-03-30) (“[TS38306]”).

[0045] Network architecture 200 may include a group of UEs 202 that are directly coupled to each other via D2D, ProSe, PC5 and / or SL interfaces and / or any other suitable interface (such as any interface discussed herein). These UEs 202 may be M2M / D2D / MTC / IoT devices and / or vehicle systems that communicate using physical-side link channels (such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.). Based on various examples herein, UE 202 may perform blind decoding attempts on the SL channel / link.

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

[0047] RAN 204 includes one or more Access Network Nodes (ANs) 208. AN 208 terminates one or more air interfaces for UE 202 by providing access to layer protocols, including RRC, PDCP, RLC, MAC, and PHY / L1 protocols. In this way, AN 208 implements the data / voice connection between CN 220 and UE 202. AN 208 can be a macrocell base station or a low-power base station, used to provide coverage for femtocells, picocells, or other similar cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells, or some combination thereof. In these implementations, AN 208 can be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, etc.

[0048] One exemplary implementation is a “CU / DU separation” architecture, in which the AN 208 is implemented as a gNB Central Unit (CU) communicatively coupled to one or more gNB Distributed Units (DUs), where each DU may be communicatively coupled to one or more Radio Units (RUs) (also known as RRHs or RRUs, etc.) (see example [TS38401]). In some implementations, the one or more RUs may be individual RSUs. In some implementations, the CU / DU separation architecture may include an ng-eNB-CU and one or more ng-eNB-DUs, as alternatives to or supplements to the gNB-CU and gNB-DU. The AN 208 used as the CU can be implemented in a discrete device or as one or more software entities running on a server computer, for example, as part of a virtual network that includes a virtual baseband unit (BBU) or BBU pool, cloud RAN (CRAN), radio equipment controller (REC), radio cloud center (RCC), centralized RAN (C-RAN), and / or virtualized RAN (vRAN), etc. (however, these terms can refer to different implementation concepts). Any other type of architecture, layout, and / or configuration can be adopted.

[0049] This group of ANs can be coupled to each other via the X2 interface (if RAN 204 is an LTE RAN or an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 210) or the Xn interface (if RAN 204 is an NG-RAN 214). In some instances, the X2 / Xn interfaces, which can be divided into control / user plane interfaces, allow the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

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

[0051] RAN 204 can provide an air interface via licensed or unlicensed spectrum. To operate in unlicensed spectrum, nodes can employ LAA, eLAA, and / or feLAA mechanisms based on CA technology with Pcells / Scells. Before accessing unlicensed spectrum, nodes can perform media / carrier sensing operations based on, for example, a listen-before-talk (LBT) protocol.

[0052] Additionally or alternatively, individual UE 202 provides radio information to one or more AN 208s and / or one or more edge computing nodes (e.g., edge servers / hosts, etc.). The radio information may take the form of one or more measurement reports and may include, for example, signal strength measurements and / or signal quality measurements. Each measurement report is tagged with a timestamp and measurement location (e.g., the current location of UE 202). As an example, the measurement results collected by UE 202 and / or included in the measurement report may include one or more of the following: bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), number of interruptions, out-of-order packet delivery, transmit power, bit error rate, bit error ratio (BER), block error rate (BLER), packet error ratio (PER), packet loss rate, packet reception rate (PRR), data rate, peak data rate, end-to-end (e2e) delay, signal-to-noise ratio (SNR), signal-to-noise and interference ratio (SINR), signal-plus-noise-plus-distortion to noise-plus-distortion ratio (SINAD), and carrier-to-interference ratio (CRI). The following parameters are listed: plus Noise Ratio (CINR), Additive White Gaussian Noise (AWGN), Energy to Noise Power Spectral Density Ratio per Bit (Eb / N0), Energy to Interference Power Spectral Density Ratio per Chip (Ec / I0), Energy to Noise Power Spectral Density Ratio per Chip (Ec / N0), Peak-to-Average Power Ratio (PAPR), Reference Signal Received Power (RSRP), Reference Signal Received Path Power (RSRPP), Reference Signal Received Quality (RSRQ), and Received Signal Strength Indicator.RSSI, Received Channel Power Indicator (RCPI), Received Signal To Noise Indicator (RSNI), Received Signal Code Power (RSCP), Reference Signal Carrier Phase (RSCP), Reference Signal Carrier Phase Difference (RSCPD), Carrier Phase Positioning (CPP), Reference Signal Time Difference (RSTD), Sidelink Synchronization Signal Block (S-SSB) measurement results (including SSB_RP (the received (linear) average power of the resource element carrying the NR SSB signal and channel, measured at the UE antenna connector or radiating interface boundary) and / or measurement results), Relative Time Difference (RTD), Receiver (Rx) Time Delay, Rx Timing Error, Transmitter (Tx) Time Delay, Tx Timing Error, NR E-CID, Observed Time Difference of Arrival. Of Arrival (OTDOA), Average Noise plus Interference (ANPI), GNSS timing for cell frames used for UE positioning in E-UTRAN or 5G / NR (e.g., timing between AP or RAN node reference time and GNSS-specific reference time for a given GNSS), GNSS code measurements (e.g., GNSS code phase (integer and fractional parts) of the spreading code of the i-th GNSS satellite signal), GNSS carrier phase measurements (e.g., the number of carrier phase cycles (integer and fractional parts) of the i-th GNSS satellite signal measured since lock-on to the signal; also known as Accumulated Delta Range (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, power histogram measurements, channel load measurements, STA statistics, and / or similar other measurements. RSRP, RSSI, and / or RSRQ measurements may include: for 3GPP networks (e.g.,RSRP, RSSI, and / or RSRQ measurements of cell-specific reference signals, channel state information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks for LTE or 5G / NR networks; and RSRP, RSSI, RSRQ, RCPI, RSNI, and / or ANPI measurements of various beacons, Fast Initial Link Setup (FILS) discovery frames, or probe response frames for WLAN / WiFi (e.g., [IEEE 80211]) networks. Additional or alternative locations may use other measurement results, such as 3GPP TS 36.214 v17.0.0 (2022-03-31) (“[TS36214]”), 3GPP TS 38.215 v17.3.0 (2023-03-30) (“[TS38215]”), 3GPP TS 38.314 v17.2.0 (2023-01-13) (“[TS38314]”) and / or IEEE Standard for Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std802.11-2020, pp.1-4379 (26 Feb. 2021) Measurement results as described in (“[IEEE 80211]”, etc.). Additionally or alternatively, any of the above measurement results (or combinations of measurement results) may be collected by one or more AN 208s and provided to one or more edge computing nodes.

[0053] Additionally or alternatively, the measurement results may include one or more of the following: measurements related to the Data Radio Bearer (DRB) (e.g., the number of DRBs attempted to be established, the number of DRBs successfully established, the number of active DRBs released, the in-session activity time of the DRB, the number of DRBs attempted to be resumed, the number of DRBs successfully resumed, etc.); measurements related to Radio Resource Control (RRC) (e.g., the average number of RRC connections, the maximum number of RRC connections, the average number of stored inactive RRC connections, the maximum number of stored inactive RRC connections, the number of attempted, successful, and / or failed RRC connection establishments, etc.); measurements related to the UE context (UECNTX); and measurements related to Radio Resource Utilization (RRU) (e.g., total DL PRB usage, total UL PRB usage, the distribution of total DL PRB usage, the distribution of total UL PRB usage, DL PRB usage for data traffic, UL PRB usage for data traffic). Measurements related to: PRB, DL total available PRB, UL total available PRB, etc.; Measurements related to Registration Management (RM); Measurements related to Session Management (SM) (e.g., number of PDU sessions requested; number of successfully established PDU sessions; number of failed PDU sessions, etc.); Measurements related to GTP Management (GTP); Measurements related to IP Management (IP); Measurements related to Policy Association (PA); Measurements related to Mobility Management (MM) (e.g., for cross-RAT, intra-RAT, and / or same-frequency / different-frequency handovers and / or conditional handovers: number of requested, successful, and / or failed handover preparations; number of requested, successful, and / or failed handover resource allocations; number of requested, successful, and / or failed handover executions; average and / or maximum time for requested handover executions; number of successful and / or failed handover executions per beam pair, etc.); Measurements related to one or more Virtualized Resources (VRs); Measurements related to Carrier Response (CARRs).Measurements related to QoS Flow (QF) (e.g., number of active QoS flows released, number of QoS flows attempted to be released, in-session activity time of QoS flows, in-session activity time of UE 202, number of QoS flows attempted to be established, number of successfully established QoS flows, number of QoS flows that failed to be established, number of initial QoS flows attempted to be established, number of initial QoS flows that successfully established, number of initial QoS flows that failed to be established, number of QoS flows attempted to be modified, number of successfully modified QoS flows, number of QoS flows that failed to be modified, etc.); Measurements related to Application Triggering (AT); Measurements related to Short Message Service (SMS); Measurements related to Power, Energy and Environment (PEE); Measurements related to NF Service (NFS); Measurements related to Packet Flow Description (PFD); Measurements related to Random Access Channel (RACH); Measurements related to Measurement Report (MR); Measurements related to Layer 1 measurements (Layer 1...). Measurement results related to: Network Slice Selection (NSS); Paging (PAG); Non-IP Data Delivery (NIDD); External Parameter Provisioning (EPP); Traffic Influence (TI); Connection Establishment (CE); Service Parameter Provisioning (SPP); Background Data Transfer Policy (BDTP); Data Management (DM); and / or any other performance measurement results, such as those in 3GPP TS 28.552 v17.3.1 (2021-06-24) (“[TS28552]”) and / or 3GPP TS 32.425 v17.1.0 (2021-06-24) Measurement results discussed in (“[TS32425]”, etc.);

[0054] Radio information can be reported in response to triggering events and / or periodically. Additionally or alternatively, individual UE 202s may report radio information with low or high periodicity, depending on the data transmission to be performed and / or other information regarding the data transmission. Additionally or alternatively, one or more edge computing nodes may request measurement results from AN 208 with low or high periodicity, or AN 208 may provide measurement results to one or more edge computing nodes with low or high periodicity. Additionally or alternatively, one or more edge computing nodes may obtain other relevant data (such as Key Performance Indicators (KPIs)) from one or more other edge computing nodes, core network functions (NFs), application functions (AFs), and / or other UE 202s, which may be obtained together with or separately from the measurement report.

[0055] Additionally or alternatively, in cases where discrepancies exist in observation data from one or more UEs, one or more RAN nodes, and / or core network NFs (e.g., missing reports, erroneous data, etc.), simple interpolation can be performed to supplement the obtained observation data (e.g., replacing values ​​from previously reported and / or historical data and / or applying extrapolation filters, etc.). Additionally or alternatively, acceptable limits for observation data can be predetermined or configured. For example, CQI and MCS measurements can be configured to be performed only within ranges defined by appropriate 3GPP standards. If reported data values ​​are meaningless (e.g., the value exceeds the acceptable range / limit, etc.), these values ​​can be discarded for the current learning / training round or epoch. For example, during packet delivery, delay limits can be defined or configured, and packets determined to be received after the packet delivery delay limit can be discarded.

[0056] UE 202 can also perform determination of reference signal (RS) measurement and reporting procedures to provide the network with information about the quality of one or more radio channels and / or the overall communication medium, and this information can be used to optimize various aspects of the communication system. As an example, the measurement and reporting procedures performed by UE 202 may include those in 3GPP TS 38.211v17.4.0 (2023-01-04) (“[TS38211]”), 3GPP TS 38.212 v17.4.0 (2023-01-04) (“[TS38212]”), 3GPP TS 38.213 v17.4.0 (2023-01-04) (“[TS38213]”), 3GPP TS38.214 v17.4.0 (2023-01-04) (“[TS38214]”), [TS38215], and 3GPP TS 38.101-1 v18.0.0 (2023-01-12). The measurement and reporting procedures discussed in [TS38.101-1], 3GPP TS 38.104 v18.0.0 (2023-01-10) ("TS38104"), 3GPP TS 38.133 v18.0.0 (2023-01-12) ("TS38133"), and / or [TS38331] are as follows. Physical signals and / or Rscans include the Demodulation Reference Signal (DM-RS), Phase-Tracking Reference Signal (PT-RS), Positioning Reference Signal (PRS), Channel-State Information Reference Signal (CSI-RS), Synchronization Block (SSB), Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), and Sounding Reference Signal (SRS).

[0057] In any of the instances discussed herein, any suitable data collection and / or measurement mechanism can be used to collect observational data. For example, data tagging (e.g., sequence numbering, etc.), packet tracking, signal measurement, data sampling, and / or timestamping techniques can be employed to determine any of the aforementioned metrics / observations. Data collection can be based on the occurrence of an event that triggers data collection. Additionally or alternatively, data collection can occur at the start or end of an event. Data collection can be continuous, discontinuous, and / or have start and stop times. Data collection techniques / mechanisms can be hardware-specific or non-hardware-specific, or can be based on various software parameters (e.g., OS type and version, etc.). Various configurations can be used to define any of the aforementioned data collection parameters. These configurations can be defined by appropriate specifications / standards, such as 3GPP (e.g., [SA6Edge]), ETSI (e.g., [MEC]), O-RAN (e.g., [O-RAN]), Intel® Smart Edge Open (formerly OpenNESS) (e.g., [ISEO]), IETF (e.g., Multi-Access Management Service (MAMS) [RFC8743]), IEEE / WiFi (e.g., [IEEE80211], [WiMAX], [IEEE16090], etc.) and / or any other similar standards (such as the standards discussed in this article).

[0058] In a V2X scenario, UE 202 or AN 208 can be or act as a Roadside Unit (RSU), which can refer to any transportation infrastructure entity used for V2X communication. The RSU can be implemented in a suitable AN or a fixed (or relatively fixed) UE, or elsewhere. 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 instance, the RSU is a computing device coupled to a roadside radio frequency circuitry that provides connectivity support to passing vehicle UEs. The RSU may also include an internal data storage circuitry to store intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU can provide extremely low-latency communication required for high-speed events such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU can provide other cellular / WLAN communication services. RSU components can be encapsulated in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide wired connectivity (e.g., Ethernet) to traffic signal controllers or backhaul networks. Furthermore, one or more V2X RATs can be used, allowing V2X nodes to communicate directly with each other, with infrastructure equipment (e.g., AN 208), and / or other devices / nodes. In some implementations, at least two different V2X RATs can be used, including WLAN V2X (W-V2X) RATs based on IEEE V2X technologies (e.g., DSRC for the US and ITS-G5 for Europe) and cellular V2X (C-V2X) RATs based on 3GPP V2X technologies (e.g., LTE V2X, 5G / NR V2X, and subsequent technologies). In one instance, a C-V2X RAT may utilize a C-V2X air interface, while a WLAN V2X RAT may utilize a W-V2X air interface.

[0059] For example, the W-V2X RAT includes: IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture, IEEE Standards Association, IEEE 1609.0-2019 (10 Apr. 2019) (“[IEEE16090]”); V2X Communications Message Set Dictionary, SAE Int'l (23 Jul. 2020) (“[J2735_202007]”); Intelligent Transport Systems in the 5 GHz frequency band (ITS-G5); [IEEE80211p] (which is the Layer 1 (L1) and Layer 2 (L2) portions of WAVE, DSRC, and ITS-G5); and / or IEEE Standard for Air Interface for Broadband Wireless Access Systems, IEEE Std 802.16-2017, pp.1-2726 (02 Mar. 2018) (“[WiMAX]”). The term "DSRC" refers to vehicle communication in the 5.9 GHz band commonly used in the United States, while "ITS-G5" refers to vehicle communication in the 5.9 GHz band used in Europe. Since any number of different RATs that can be used in any geographic or political region are applicable (including the [IEEE 80211p] RAT), the terms "DSRC" (used in other areas of the United States) and "ITS-G5" (used in other areas of Europe) are used interchangeably in this disclosure. The access layer for the ITS-G5 interface is outlined in ETSI EN 302 663 V1.3.1 (2020-01) (hereinafter referred to as "[EN302663]"), and the access layer of the ITS-S reference architecture is described. The ITS-G5 access layer includes [IEEE 80211] (which now includes [IEEE 80211p]) and features of the Decentralized Congestion Control (DCC) approach discussed in ETSI TS 102 687 V1.2.1 (2018-04) (“[TS102687]”).ETSI EN 303 613 V1.1.1 (2020-01) and 3GPP TS 23.285 v16.2.0 (2019-12) outline the access layer (among other things) for one or more 3GPP LTE-V2X-based interfaces; while 3GPP TR23.786 v16.1.0 (2019-06) and 3GPP TS 23.287 v18.0.0 (2023-03-31) (“[TS23287]”) outline 3GPP 5G / NR-V2X (among other things).

[0060] In RAN 204, which is an instance of E-UTRAN 210 with one or more eNBs 212, the E-UTRAN 210 provides an LTE air interface (Uu) with at least the parameters and characteristics discussed in 3GPP TS 36.300 v17.2.0 (2022-09-30) (“[TS36300]”). In RAN 204, which is an instance of Next Generation (NG)-RAN 214 with a set of gNBs 216, each gNB 216 connects to a 5G-enabled UE 202 using a 5G-NR air interface (which may also be referred to as a Uu interface), the parameters and characteristics of which are discussed in [TS38300] and many other 3GPP standards. In the case where NG-RAN 214 includes a set of ng-eNBs 218, one or more ng-eNBs 218 connect to the UE 202 via 5G Uu and / or LTE Uu interfaces. gNB 216 and ng-eNB 218 connect to 5GC 240 via corresponding NG interfaces, including N2, N3, and / or other interfaces. gNB 216 and ng-eNB 218 connect via Xn interfaces. Furthermore, individual gNB 216 connects via corresponding Xn interfaces, and individual ng-eNB 218 connects via corresponding Xn interfaces. In some instances, the NG interface may be divided into two parts: an NG user plane (NG-U) interface (e.g., N3 interface), which carries traffic data between the nodes of NG-RAN 214 and UPF 248; and an NG control plane (NG-C) interface (e.g., N2 interface), which is the signaling interface between the nodes of NG-RAN 214 and AMF 244.

[0061] NG-RAN 214 can provide a 5G-NR air interface (also known as a Uu interface) with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, simplex codes and Reed-Muller codes for control, and LDPC for data. The 5G-NR air interface can rely on CSI-RS, PDSCH / PDCCH DMRS similar to those of the LTE air interface. The 5G-NR air interface may not use CRS, but can use PBCH DMRS for PBCH demodulation; PTRS for PDSCH; and a tracking reference signal for time tracking. The 5G-NR air interface can operate on the FR1 band, which includes frequency bands below 6 GHz, or the FR2 band, which includes frequency 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 that includes PSS / SSS / PBCH.

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

[0063] In some implementations, an individual gNB 216 may include one gNB-CU and a set of gNB-DUs. Additionally or alternatively, the gNB 216 may include one or more RUs. In these implementations, the gNB-CU may be connected to each gNB-DU via a corresponding F1 interface. In the case of network sharing that broadcasts multiple cell IDs, each cell identifier associated with a subset of the PLMN corresponds to a gNB-DU and is connected to the gNB-CU to share cell resources at the same physical layer. For flexibility, a gNB-DU can be connected to multiple gNB-CUs through appropriate implementation. Furthermore, the gNB-CU can be divided into gNB-CU control plane (gNB-CU-CP) and gNB-CU user plane (gNB-CU-UP) functions. The gNB-CU-CP is connected to the gNB-DU via the F1 control plane interface (F1-C), the gNB-CU-UP is connected to the gNB-DU via the F1 user plane interface (F1-U), and the gNB-CU-UP is connected to the gNB-CU-CP via an E1 interface. In some implementations, a gNB-DU connects to only one gNB-CU-CP, and a gNB-CU-UP connects to only one gNB-CU-CP. For flexibility, a gNB-DU and / or a gNB-CU-UP can be connected to multiple gNB-CU-CPs through appropriate implementation. A gNB-DU can connect to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and a gNB-CU-UP can connect to multiple DUs under the control of the same gNB-CU-CP. Data forwarding between gNB-CU-UPs during intra-gNB handover within a gNB can be supported by Xn-U.

[0064] Similarly, an individual ng-eNB 218 may include one ng-eNB-CU and a set of ng-eNB-DUs. In these implementations, the ng-eNB-CU and each ng-eNB-DU are connected via a corresponding W1 interface. An ng-eNB may include one ng-eNB-CU-CP, one or more ng-eNB-CU-UPs, and one or more ng-eNB-DUs. The g-eNB-CU-CP and ng-eNB-CU-UP are connected via E1 interfaces. The ng-eNB-DUs are connected to the ng-eNB-CU-CP via a W1-C interface and to the ng-eNB-CU-UP via a W1-U interface. Unless otherwise expressly stated, the general principles described herein regarding gNBs also apply to ng-eNBs and the corresponding E1 and W1 interfaces.

[0065] Nodes carrying the user plane portion of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and MeNB or SgNB for EN-DC (depending on bearer separation)) perform user inactivity monitoring. Furthermore, these nodes notify nodes with control plane connections to the core network (e.g., via E1 or X2). Nodes carrying the RLC protocol layer (e.g., gNB-DU) can perform user inactivity monitoring and further notify nodes carrying the control plane (e.g., gNB-CU or gNB-CU-CP) of their inactivity or (re)activation status.

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

[0067] RAN 204 is communicatively coupled to CN 220, which includes network elements and / or network functions (NFs) to provide various functions supporting data and telecommunications services to customers / subscribers (e.g., UE 202). Components of CN 220 can be implemented in a single physical node or in separate physical nodes. In some instances, NFV can be used to virtualize any or all of the functionality provided by the network elements of CN 220 onto physical compute / storage resources such as servers, switches, etc. A logical instantiation of CN 220 can be referred to as a network slice, and a logical instantiation of a portion of CN 220 can be referred to as a network subslice.

[0068] CN 220 can be LTE CN 222 (also known as Evolved Packet Core Network (EPC) 222). EPC 222 can include MME 224, SGW 226, SGSN 228, HSS 230, PGW 232, and PCRF 234, which are coupled to each other through interfaces (or "reference points"), as shown in the figure. The following is a brief introduction to the NFs in EPC 222.

[0069] MME 224 performs mobility management functions to track the current location of UE 202 for paging, bearer activation / deactivation, handover, gateway selection, authentication, etc. SGW 226 terminates the S1 interface toward RAN 210 and routes data packets between RAN 210 and EPC 222. SGW 226 can serve as a local mobility anchor for cross-RAN node handovers and can also provide an anchor for cross-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement. SGSN 228 tracks the location of UE 202 and performs security functions and access control. SGSN 228 also performs the following functions: performs cross-EPC node signaling for mobility between different RAT networks; performs PDN and S-GW selection specified by MME 224; and performs MME 224 selection for handovers, etc. Through the S3 reference point between MME 224 and SGSN 228, user and bearer information exchange is possible for cross-3GPP access network mobility in idle / active states. HSS 230 includes a database for network users, including subscription-related information to support network entities in handling communication sessions. HSS 230 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc. The S6a reference point between HSS 230 and MME 224 enables the transmission of subscription and authentication data for user access to EPC 222 for authentication / authorization. PGW 232 can terminate the SGi interface toward Data Network (DN) 236, which may include application / content server 238. PGW 232 can route data packets between EPC 222 and Data Network 236. PGW 232 is communicatively coupled to SGW 226 via S5 reference point for user plane tunneling and tunnel management. PGW 232 may further include nodes (e.g., PCEF) for policy enforcement and billing data collection. Furthermore, the SGi reference point can communicatively couple PGW 232 to the same or different Data Network 236. PGW 232 can be communicatively coupled to PCRF 234 via the Gx reference point. PCRF 234 is the policy and charging control element of EPC 222. PCRF 234 is communicatively coupled to application / content server 238 to determine appropriate QoS and charging parameters for service flows. PCRF 234 also configures relevant rules to PCEF (via the Gx reference point) using appropriate TFTs and QCIs.

[0070] CN 220 can be 5GC 240, including AUSF 242, AMF244, SMF 246, UPF 248, NSSF 250, NEF 252, NRF 254, PCF 256, UDM 258, and AF 260, which are coupled to each other through various interfaces as shown in the figure. The following is a brief introduction to the NFs in 5GC 240.

[0071] AUSF 242 stores data for UE 202 authentication and handles authentication-related functions. AUSF 242 facilitates a common authentication framework for various access types.

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

[0073] AMF 244 also supports NAS signaling transmission with UE 202 via the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF can be the termination point of the N2 interface between RAN 204 and AMF 244 for the control plane, and can be the termination point of the N3 reference point between RAN 214 and 248 for the user plane. Therefore, AMF 244 can process N2 signaling from SMF 246 and AMF 244 for PDU sessions and QoS, encapsulate / decapsulate packets for IPSec and N3 tunneling, mark N3 user plane packets in the uplink, and implement QoS corresponding to the marking of N3 packets received via N2. The N3IWF can also relay uplink and downlink control plane NAS signaling between UE 202 and AMF 244 via the N1 reference point between UE 202 and AMF 244, and can relay uplink and downlink user plane packets between UE 202 and UPF 248. The N3IWF also provides a mechanism for establishing an IPsec tunnel with UE 202. AMF 244 can expose an interface based on Namf services and can be the N14 reference point between two AMF 244s and between AMF 244 and 5G-EIR (…). Figure 2 The terminus of the N17 reference point (not shown in the image) between the reference points.

[0074] SMF 246 is responsible for: SM (e.g., session establishment, tunnel management between UPF 248 and AN 208); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring traffic routing at UPF 248 to route traffic to the correct destination; termination of interfaces for policy control functions; control of policy enforcement, billing, and quality of service; 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 messages, sent via AMF 244 through N2 to AN 208; and determining the SSC mode of the session. SM refers to the management of the PDU session, and a PDU session or "session" refers to the PDU connection service that provides or implements PDU exchange between UE202 and DN 236. SMF 246 may also include the following functions to support edge computing enhancements (e.g., see [TS23548]): selecting EASDF 261 and configuring its address for the UE as a DNS server for PDU sessions; using the EASDF 261 services defined in [TS23548]; and supporting the application layer architecture defined in [TS23558] and configuring and updating ECS ​​address configuration information for the UE. The discovery and selection procedure for EASDF 261 is discussed in § 6.3.23 of [TS23501].

[0075] UPF 248 acts as an anchor point for mobility within and across RATs, an external PDU session point interconnecting with data network 236, and a branch point supporting multi-homed PDU sessions. UPF 248 also performs packet routing and forwarding, performs packet inspection, enforces policy rules in the user plane portion, performs lawful packet interception (UP collection), performs traffic utilization reporting, performs QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), performs uplink traffic authentication (e.g., SDF to QoS flow mapping), performs transport layer packet marking in uplink and downlink, and performs downlink packet buffering and downlink data notification triggering. UPF 248 may include an uplink classifier to support routing traffic flows to the data network.

[0076] NSSF 250 can select a set of network slice examples to serve UE 202. If needed, NSSF 250 can also determine the allowed NSSAIs and their mappings to subscribed S-NSSAIs. NSSF 250 can also determine, based on appropriate configuration and possibly by querying NRF 254, a set of AMFs to be used to serve UE 202 or a list of candidate AMFs 244. A set of network slice examples can be selected for UE 202 upon triggering AMF 244, to which UE 202 registers by interacting with NSSF 250, which may cause changes to AMF 244. NSSF 250 interacts with AMF 244 via reference point N22 and can communicate with another NSSF in the visited network via reference point N31 (not shown).

[0077] The NEF 252 securely exposes services and capabilities provided by 3GPP NFs to third parties, internal exposure / re-exposure, AF 260, edge computing, or fog computing systems (e.g., edge computing nodes). In these instances, the NEF 252 can authenticate, authorize, or suppress AFs. The NEF 252 can also translate information exchanged with AF 260 and with internal network functions. For example, the NEF 252 can translate between the AF-Service-Identifier and internal 5GC information. The NEF 252 can also receive information from other NFs based on their exposure capabilities. This information can be stored as structured data on the NEF 252 or stored at a data storage NF using a standardized interface. The stored information can then be re-exposed by the NEF 252 to other NFs and AFs or used for other purposes (such as analysis).

[0078] NRF 254 supports service discovery functionality, receiving NF discovery requests from NF examples and providing information about the discovered NF examples to the requesting NF example. NRF 254 also maintains information about available NF examples and the services they support. NRF 254 also supports service discovery functionality where NRF 254 receives NF discovery requests from NF examples or SCPs (not shown) and provides information about the discovered NF examples to the NF examples or SCPs.

[0079] The PCF 256 provides and enforces policy rules to control plane functions, and also supports a unified policy framework for managing network behavior. The PCF 256 can also implement a frontend to access subscription information related to policy decisions in the Unified Data Repository (UDR) of the UDM 258. In addition to communicating with functions via reference points as shown in the figure, the PCF 256 also demonstrates an interface based on Npcf services.

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

[0081] The Edge Application Server Discovery Function (EASDF) 261 demonstrates an interface based on the Neasdf service and connects to the SMF 246 via the N88 interface. One or more EASDF instances can be deployed within a PLMN, and interactions between one or more 5GC NFs and EASDF 261 occur within the PLMN. EASDF 261 includes one or more of the following functions: registering with the NRF 254 for EASDF 261 discovery and selection; processing DNS messages according to instructions from the SMF 246; and / or terminating DNS security (if enabled). Processing DNS messages according to instructions from SMF 246 includes one or more of the following functions: receiving DNS message processing rules and / or baseline DNS patterns from SMF 246; exchanging DNS messages with / with UE 202; forwarding DNS messages to C-DNS or L-DNS for DNS queries; adding EDNS Client Subnet (ECS) options for DNS queries against FQDN; reporting information related to received DNS messages to SMF 246; and / or buffering / discarding DNS messages from UE 202 or a DNS server. EASDF establishes a direct user plane connection with PSA UPF via N6 (e.g., without any NAT) to transmit DNS signaling exchanged with the UE. NAT deployment between EASDF 261 and PSA UPF 248 may or may not be supported. Other aspects of EASDF 261 are discussed in [TS23548].

[0082] AF 260 provides application impact on traffic routing, access to NEF 252, and interaction with the policy framework for policy control. AF 260 can influence UPF 248 selection (reselection) and traffic routing. Based on operator deployment, network operators may allow AF 260 to interact directly with the relevant NF when it is considered a trusted entity. In some implementations, AF 260 is used for edge computing.

[0083] The 5GC 240 enables edge computing by selecting an operator / third-party service geographically close to the point where UE 202 is attached to the network. This reduces latency and load on the network. In the edge computing implementation, the 5GC 240 can select a UPF 248 close to UE 202 and perform traffic routing from UPF 248 to DN 236 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by AF 260, allowing AF 260 to influence UPF selection (reselection) and traffic routing.

[0084] Data network (DN) 236 can represent various network operator services, inter-network access, or third-party services, which can be provided by one or more servers (e.g., including application / content server 238). DN 236 can be an external public operator, a private PDN, or an operator's internal packet data network, for example, used to provide IMS services. In this example, application server 238 can be coupled to IMS via S-CSCF or I-CSCF. In some implementations, DN 236 can represent one or more Local Area DNs (LADNs), which are DNs 236 (or DN Names, DNNs) accessible to UE 202 in one or more specific areas. Outside of these specific areas, UE 202 cannot access LADNs / DN 236.

[0085] Additionally or alternatively, DN 236 may be an edge DN 236, which is a (native) DN that supports the architecture used to enable edge applications. In these instances, application server 238 may represent the physical hardware system / device that provides application server functionality and / or application software residing in the cloud or at an edge computing node performing one or more server functions. In some instances, application / content server 238 provides an edge-hosted environment that provides the support required for edge application server execution.

[0086] In some instances, 5GS can utilize one or more edge computing nodes to provide interfaces and offload the processing of wireless communication traffic. In these instances, the edge computing nodes can be included in or deployed in one or more RAN 210, 214 locations. For example, an edge computing node can provide connectivity between RAN 214 and UPF 248 within a 5GC 240. The edge computing node can utilize one or more NFV instances instantiated on virtualized infrastructure within the edge computing node to handle wireless connectivity with RAN 214 and UPF 248.

[0087] In some implementations, edge computing nodes provide a distributed computing environment for application and service hosting, and also provide storage and processing resources so that data and / or content can be processed very close to the subscriber (e.g., the user of UE 202) for faster response times. Edge computing nodes also support one or more multi-tenant runtime and hosting environments for applications, including virtual device applications that can be delivered as packaged virtual machine (VM) images, middleware applications and infrastructure services, content delivery services (including content caching), mobile big data analytics, compute offloading, etc. Compute offloading involves offloading compute tasks, workloads, applications, and / or services from UE 202, CN 220, DN236, and / or one or more servers 238 to edge computing nodes, and vice versa. For example, a device application or client application running in UE 202 can offload application tasks or workloads to one or more edge computing nodes. In another instance, an edge computing node can offload application tasks or workloads to a group of UE 202 (e.g., for use by distributed machine learning compute and / or other operations).

[0088] An edge computing node may include an edge system (also referred to as an “edge computing framework”, etc.) or a portion thereof, which employs one or more edge computing technologies (ECT). An edge computing node may also be referred to as an “edge host” or “edge server.” An edge system includes a collection of edge servers and edge management systems (not shown) required to run edge computing applications within a carrier network or a subset of carrier networks. An edge server is a physical computer system that may include an edge platform and / or virtualization infrastructure and provides computing, storage, and networking resources to edge computing applications. Each edge server is located at the edge of the corresponding access network and is configured to provide computing resources and / or various services (e.g., computing task and / or workload offloading, cloud computing capabilities, IT services, and other similar resources and / or services, as discussed herein) relatively close to UE 202. The VI of an edge computing node provides a virtualization environment and virtualization resources for the edge host, and edge computing applications may run as VMs and / or application containers on top of the VI.

[0089] In one exemplary implementation, ECT is a MEC framework and / or operates according to the MEC framework, as discussed in the following documents: ETSI GR MEC 001 v3.1.1 (2022-01); ETSI GS MEC 003 v3.1.1 (2022-03); ETSI GS MEC 009 v3.1.1 (2021-06); ETSI GS MEC 010-1 v1.1.1 (2017-10); ETSI GS MEC010-2 v2.2.1 (2022-02); ETSI GS MEC 011 v2.2.1 (2020-12); ETSI GS MEC 012 V2.2.1 (2022-02); ETSI GS MEC 013 V2.2.1 (2022-01); ETSI GS MEC 014 v2.1.1 (2021-03); ETSI GS MEC 015 v2.1.1 (2020-06); ETSI GS MEC 016 v2.2.1 (2020-04); ETSI GS MEC021 v2.2.1 (2022-02); ETSI GR MEC 024 v2.1.1 (2019-11); ETSI GS MEC 028 V2.2.1 (2021-07); ETSI GS MEC 029 v2.2.1 (2022-01); ETSI MEC GS 030 v2.1.1 (2020-04); ETSI GR MEC 031 v2.1.1 (2020-10); U.S. Provisional Application No. 63 / 003,834 (“[US'834]”) filed April 1, 2020; and International Application No. PCT / US2020 / 066969 (“[PCT'696]”) filed December 23, 2020 (collectively, “[MEC]”), the entire contents of which are hereby incorporated herein by reference.This exemplary implementation (and / or any other exemplary implementation discussed herein) may also include NFV and / or other similar virtualization technologies, such as those discussed in the following documents: ETSI GR NFV 001 V1.3.1 (2021-03); ETSI GS NFV 002 V1.2.1 (2014-12); ETSI GR NFV 003 V1.6.1 (2021-03); ETSI GS NFV 006 V2.1.1 (2021-01); ETSI GS NFV-INF 001 V1.1.1 (2015-01); ETSI GS NFV-INF 003 V1.1.1 (2014-12); ETSI GS NFV-INF 004 V1.1.1 (2015-01); ETSI GS NFV-MAN 001 v1.1.1 (2014-12); and / or Israel et al., OSM Release FIVE Technical Overview, ETSI Open Source MANO, OSM White Paper, 1st ed. (Jan. 2019) (https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf) (collectively, “[ETSINFV]”), the entire contents of which are hereby incorporated herein by reference.Other virtualization technologies and / or service orchestration and automation platforms may be used, such as those discussed in the following documents: E2E Network Slicing Architecture, GSMA, OfficialDoc.NG.127, v1.0 (03 Jun. 2021), https: / / www.gsma.com / newsroom / wp-content / uploads / / NG.127-v1.0-2.pdf; Open Network Automation Platform (ONAP) documentation, Release Istanbul, v9.0.1 (17 Feb. 2022), https: / / docs.onap.org / en / latest / index.html (“[ONAP]”); and 3GPP Service Based Management Architecture (SBMA) as discussed in 3GPP TS 28.533 v17.1.0 (2021-12-23) (“[TS28533]”), the entire contents of which are hereby incorporated herein by reference.

[0090] In another exemplary implementation, ECT operates within and / or according to the O-RAN framework. Typically, front-end and back-end equipment vendors and operators work closely together to ensure compatibility. The downside of this working model is that plug-and-play with other equipment becomes very difficult, which can hinder innovation. To address this issue and promote openness and interoperability at all levels, several key players interested in the wireless field (e.g., operators, equipment manufacturers, and / or academic institutions) formed the Open RAN Alliance (“O-RAN”) in 2018. The O-RAN network architecture is a set of building blocks for designing virtualized RANs on programmable hardware, where radio access control is supported by AI / ML. Various aspects of the O-RAN architecture are described in the following documents: O-RAN Architecture Descriptionv07.00, O-RAN Alliance WG1 (Oct. 2022) ("[O-RAN.WG1.O-RAN-Architecture-Description]"); O-RAN Operations and Maintenance Architecture Specificationv04.00, O-RAN Alliance WG1 (Feb. 2021) ("[O-RAN.WG1.OAM-Architecture]"); O-RANOperations and Maintenance Interface Specification v04.00, O-RAN Alliance WG1 (Feb. 2021) ("[O-RAN.WG1.O1-Interface.0]"); O-RAN Information Model and DataModels Specification v01.00, O-RAN Alliance WG1 (Feb. 2021) 2021); O-RAN WorkingGroup 1 Slicing Architecture v08.00 (Oct. 2022); O-RAN Working Group 2 (Non-RTRIC and A1 interface WG) A1 interface: Application Protocol v03.02 (Jul.2021); O-RAN Working Group 1 Use Cases Detailed Specification v09.00 (Oct.2022) (“[O-RAN.WG1.Use-Cases]”);O-RAN Working Group 2 (Non-RT RIC and A1interface WG) A1 interface: General Aspects and Principles v03.00 (Oct. 2022)(“[O-RAN.WG2.A1GAP]”);O-RAN Working Group 2 (Non-RT RIC and A1 interface WG)A1 interface: Type Definitions v04.00 (Oct. 2021);O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Transport Protocol v02.00 (Oct.2022);O-RAN Working Group 2 AI / ML workflow description and requirementsv01.03 O-RAN Alliance WG2 (Oct. 2021) (“[O-RAN.WG2.AIML]”);O-RAN WorkingGroup 2 (Non-RT RIC and A1 interface WG) Non-RT RIC Architecture v02.01 (Oct.2022);O-RAN Working Group 2 Non-RT RICFunctional Architecture v01.01, O-RANAlliance WG2 (Jun. 2021);O-RAN Working Group 2 (Non-RT RIC and A1 interfaceWG)R1 interface: General Aspects and Principles v03.00, O-RAN Alliance WG2(Oct. 2022);O-RAN Working Group 3 Near-Real-time RAN Intelligent ControllerArchitecture&E2 General Aspects and Principles v02.02 (Jul. 2022) (“[O-RAN.WG3.E2GAP]”);O-RAN Working Group 3 Near-Real-time Intelligent ControllerE2 Service Model (E2SM) v02.01 (Mar. 2022) (“[O-RAN.WG3.E2SM]”);O-RAN WorkingGroup 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM), CellConfiguration and Control v01.00 (Oct. 2022) (“[O-RAN.WG3.E2SM-CCC]”);O-RANWorking Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM)KPM v02.03 (Oct. 2022) (“[O-RAN.WG3.E2SM-KPM]”);O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Function NetworkInterface (NI) v01.00 (Feb. 2020) (“[ORAN-WG3.E2SM-NI]”);O-RAN Working Group3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Controlv01.03 (Oct. 2022) (“[O-RAN.WG3.E2SM-RC]”);O-RAN Working Group 3, Near-Real-time Intelligent Controller, E2 Application Protocol (E2AP) v02.03 (Oct.2022) (“[O-RAN.WG3.E2AP]”);O-RAN Working Group 3 (Near-Real-time RANIntelligent Controller and E2 Interface Working Group): Near-RT RICArchitecture v03.00 (Oct. 2022) (“[O-RAN.WG3.RICARCH]”);O-RAN Working Group 4(Open Fronthaul Interfaces WG) Control, User and Synchronization PlaneSpecification v09.00 (Jul. 2022) (“[O-RAN-WG4.CUS.0]”);O-RAN FronthaulWorking Group 4 Cooperative Transport Interface Transport Control PlaneSpecification v02.00, O-RAN Alliance WG4 (Jun. 2021);O-RAN Fronthaul WorkingGroup 4 Cooperative Transport Interface Transport Management PlaneSpecification v02.00 (Jun. 2021);O-RAN Fronthaul Working Group 4 (OpenFronthaul Interfaces WG): Management Plane Specification v09.00 (Jul. 2022)(“[O-RAN.WG4.MP.0]”);O-RAN Alliance Working Group 5 O1 Interfacespecification for O-CU-UP and O-CU-CP v04.00 (Oct. 2022);O-RAN AllianceWorking Group 5 O1 Interface specification for O-DU v05.00 (Oct. 2022);O-RANOpen F1 / W1 / E1 / X2 / Xn Interfaces Working Group Transport Specification v01.00,O-RAN Alliance WG5 (Apr. 2020);O-RAN Working Group 6 (Cloudification andOrchestration) Cloud Architecture and Deployment Scenarios for O-RANVirtualized RAN v04.00 (Oct.2022) (“[O-RAN.WG6.CADS]”);O-RAN Cloud PlatformReference Designs v02.00, O-RAN Alliance WG6 (Feb. 2021);O-RAN Working Group6 O2 Interface General Aspects and Principles v02.00 (Oct. 2022);O-RANWorking Group 6 (Cloudification and Orchestration Work Group);O-RANAcceleration Abstraction Layer General Aspects and Principles v04.00 (Oct.2022);O-RAN Working Group 6: O-Cloud Notification API Specification for EventConsumers v03.00 (“[O-RAN.WG6.O-Cloud Notification API]”);O-RAN White BoxHardware Working Group Hardware Reference Design Specification for IndoorPico Cell with Fronthaul Split Option 6 v02.00, O-RAN Alliance WG7 (Oct.2021) (“[O-RAN.WG7.IPC-HRD-Opt6]”);O-RAN WG7 Hardware Reference DesignSpecification for Indoor Picocell (FR1) with Split Architecture Option 7-2v03.00, O-RAN Alliance WG7 (Oct. 2021) (“[O-RAN.WG7.IPC-HRD-Opt7-2]”);O-RANWG7 Hardware Reference Design Specification for Indoor Picocell (FR1) withSplit Architecture Option 8 v03.00 (Oct. 2021) (“[O-RAN.WG7.IPC-HRD-Opt8]”);O-RAN White Box Hardware Working Group Hardware Reference DesignSpecification for Outdoor Micro Cell with Split Architecture Option 7.2v03.00, O-RAN Alliance WG7 (Oct. 2022) (“[O-RAN.WG7.OMC-HRD-Opt7-2]”);O-RANWhite Box Hardware Working Group Hardware Reference Design Specification forOutdoor Macro Cell with Split Architecture Option 7.2 v03.00, O-RAN AllianceWG7 (Jul. 2022) (“[O-RAN.WG7.OMAC-HRD]”);O-RAN Open X-haul Transport WorkingGroup Management interfaces for Transport Network Elements v04.00, O-RANAlliance WG9 (Jul. 2022);O-RAN Open X-haul Transport Working GroupSynchronization Architecture and Solution Specification v02.00, O-RANAlliance WG9 (Mar. 2022);O-RAN Open Xhaul Transport WG9 WDM-based FronthaulTransport v2.0, O-RAN Alliance WG9 (Mar. 2022);O-RAN Open Transport WorkingGroup 9 Xhaul Packet Switched Architectures and Solutions v03.00, O-RANAlliance WG9 (Jul. 2022) (“[O-RAN.WG9.XPSAAS]”);O-RAN Operations andMaintenance Architecture v07.The following documents are hereby incorporated herein by reference: O-RAN Alliance WG10 (Jul. 2022) (“[O-RAN.WG10.OAM-Architecture]”); O-RAN Operations and Maintenance Interface Specification v07.00, O-RAN Alliance WG10 (Jul. 2022); O-RAN Operations and Maintenance Interface Specification v08.00, O-RAN Alliance WG10 (Oct. 2022) (“[O-RAN.WG10.O1-Interface.0]”); O-RAN: Towards an Open and Smart RAN, O-RANAlliance, White Paper (Oct. 2018); and US App. No. 17 / 484,743 filed on 24 Sep. 2021 (collectively referred to as “[O-RAN]”).

[0091] In another exemplary implementation, ECT is the 3rd Generation Partnership Project (3GPP) System Aspect Working Group 6 (SA6) architecture (referred to as "3GPP Edge Computing") for implementing edge applications and / or operates according to this architecture, which is discussed in the following documents: 3GPP TS 23.558 v18.1.0 (2022-12-23) ("[TS23558]"); 3GPP TS 23.501 v18.0.0 (2022-12-21) ("[TS23501]"); 3GPP TS 23.548 v17.4.0 (2022-09-22) ("[TS23548]"); 3GPP TR 23.700-98 v18.0.0 (2022-12-23) ("[TR23700-98]"); 3GPP TS 23.222 v18.0.0 (2022-12-23) ("[TS23222]"); TS 33.122 v18.0.0 (2022-12-16) ("[TS33122]"); 29.222v17.1.0 (2021-06-25) ("[TS29222]"); 3GPP TS 23.502 v18.0.0 (2022-12-21) ("[TS23502]"); 3GPP TS 29.522 v18.0.0 (2022-12-16) ("[TS29522]"); 3GPP TS29.122 v18.0.0 (2022-12-16) (“[TS29122]”); 3GPP TS 23.682 v17.3.0 (2022-06-15) (“[TS23682]”); 3GPP TS 23.434 v18.3.0 (2022-12-23) (“[TS23434]”); and 3GPP TS23.401 v18.0.0 (2022-12-21) (collectively, “[SA6Edge]”), the entire contents of which are hereby incorporated herein by reference.

[0092] In another exemplary implementation, ECT is the Intel® Smart Edge Open framework (formerly known as OpenNESS) and / or works based on the framework, which is discussed in the following literature: Intel® Smart Edge Open Developer Guide, version 21.09 (30 Sep. 2021), available at: https: / / smart-edge-open.github.io / (“[ISEO]”), the entire contents of which are hereby incorporated by reference.

[0093] In another exemplary implementation, ECT operates according to the Multi-Access Management Services (MAMS) framework, which is discussed in the following literature: Kanugovvi et al., Multi-Access Management Services (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (Mar. 2020) (“[RFC8743]”); Ford et al., TCP Extensions for Multipath Operation with Multiple Addresses, IETF RFC8684, (Mar. 2020); De Coninck et al., Multipath Extensions for QUIC (MP-QUIC), IETF draft-deconinck-quic-multipath-07, IETA, QUIC Working Group (03-May-2021); Zhu et al., User-Plane Protocols for Multiple Access Management Service, IETF draft-zhu-intarea-mams-user-protocol-09, IETA, INTAREA (04-Mar-2020); and Zhu et al., Generic Multi-Access (GMA) Convergence Encapsulation Protocols, IETF RFC 9188 (Feb. 2022) (collectively, “[MAMS]”), the entire contents of which are hereby incorporated herein by reference.

[0094] It should be understood that the above-described edge computing framework / ECT and service deployment examples are merely illustrative examples of ECT, and this disclosure can be applied to many other or additional edge computing / networking technologies in various combinations and layouts of devices located at the edge of networks including the various edge computing networks / systems described herein. Furthermore, the technologies disclosed herein can relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures can also be applied to this disclosure. Examples of these edge computing / networking technologies include: [MEC]; [O-RAN]; [ISEO]; [SA6Edge]; Content Delivery Network (CDN) (also known as "Content Delivery Network", etc.); Mobility Service Provider (MSP) edge computing and / or Mobility as a Service (MaaS) provider systems (e.g., for AECC architecture); Nebula edge cloud system; fog computing system: Cloudlet edge cloud system; Mobile Cloud Computing (MCC) system; and / or Central Office Re-architected as a Datacenter (CORD), Mobile CORD (M-CORD), and / or Converged Multi-Access and Core (COMAC) system, etc. Furthermore, the technologies disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be used for the purposes of this disclosure.

[0095] The 5GC 240 interface includes reference points and service-based interfaces. Reference points include N1 (between UE 202 and AMF 244), N2 (between RAN 214 and AMF 244), N3 (between RAN 214 and UPF 248), N4 (between SMF 246 and UPF 248), N5 (between PCF 256 and AF 260), N6 (between UPF 248 and DN 236), N7 (between SMF 246 and PCF 256), N8 (between UDM 258 and AMF 244), N9 (between the two UPF 248 points), N10 (between UDM 258 and SMF 246), N11 (between AMF 244 and SMF 246), N12 (between AUSF 242 and AMF 244), and N13 (between AUSF 242 and UDM 244). N14 (between two AMF244s, not shown), N15 (between PCF 256 and AMF 244 in non-roaming situations, or between PCF 256 and AMF 244 in the visited network in roaming situations), N16 (between two SMF 246s, not shown), and N22 (between AMF 244 and NSSF 250). Also available are... Figure 2 Other reference point representations not shown in the diagram. Figure 2 The service-based representation in the code represents NFs within the control plane that enable other authorized NFs to access their services. Service-Based Interfaces (SBIs) include Namf (SBI shown in AMF 244), Nsmf (SBI shown in SMF 246), Nnef (SBI shown in NEF 252), Npcf (SBI shown in PCF 256), Nudm (SBI shown in UDM 258), Naf (SBI shown in AF 260), Nnrf (SBI shown in NRF 254), Nnssf (SBI shown in NSSF 250), and Nausf (SBI shown in AUSF 242). It is also possible to use... Figure 2 Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf). In some instances, the NEF 252 can provide an interface to edge computing nodes that can be used to handle wireless connections with the RAN 214.

[0096] In some implementations, network architecture 200 may include an SMSF responsible for SMS subscription checks and authentication, and relaying SM messages from UE 202 / other entities (such as SMS-GMSC / IWMSC / SMS-router) to other entities / UE 202. SMS may also interact with AMF 244 and UDM 258 to perform notification procedures for when UE 202 is available for SMS delivery (e.g., setting a UE unreachable flag and notifying UDM 258 when UE 202 is available for SMS).

[0097] 5GS may also include SCPs (or instances of SCPs) supporting indirect communication (see, for example, Section 7.1.1 of 3GPP TS 23.501); delegated discovery (see, for example, Section 7.1.1 of 3GPP TS 23.501); one or more message forwarding and routing to the destination NF / NF service; communication security (e.g., authorization for NF service consumers to access NF service producer APIs) (see, for example, 3GPP TS 33.501); load balancing, monitoring, overload control, etc.; and discovery and selection functions based on UE SUPI, SUCI, or GPSI for accessing subscription data stored in a UDR, including one or more UDM 258s, one or more AUSF 242s, one or more UDRs, and one or more PCF 256s (see, for example, [TS23501] § 6.3). The load balancing, monitoring, and overload control functions provided by SCPs can be tailored to specific implementations. SCPs can be deployed in a distributed manner. More than one SCP can exist in the communication paths between various NF services. Although SCP is not an NF example, it can be deployed in a distributed, redundant, and scalable manner.

[0098] Figure 3 A wireless network 300 according to various embodiments is schematically illustrated. The wireless network 300 may include a UE 302 that communicates wirelessly with an AN 304. The UE 302 and the AN 304 may be similar to and substantially interchangeable with components with similar names described elsewhere herein.

[0099] UE 302 can be communicatively coupled to AN 304 via connection 306. Connection 306 is shown as the air interface for implementing the communication coupling and can comply with cellular communication protocols (such as LTE or 5GNR protocols operating at mmWave or frequencies below 6 GHz).

[0100] UE 302 may include a bearer platform 308 coupled to modem platform 310. Bearer platform 308 may include application processing circuitry 312, which may be coupled to protocol processing circuitry 314 of modem platform 310. Application processing circuitry 312 may run various applications for UE 302 to source / terminate application data. Application processing circuitry 312 may also implement one or more layer operations to transmit / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) and interconnection (e.g., IP) operations.

[0101] The protocol processing circuitry system 314 can implement one or more layer operations to facilitate the transmission or reception of data via connection 306. For example, the layer operations implemented by the protocol processing circuitry system 314 may include MAC, RLC, PDCP, RRC, and NAS operations.

[0102] The modem platform 310 may also include a digital baseband circuitry system 316 that can implement one or more layer operations that are performed "below" the layer operations executed by the protocol processing circuitry system 314 in the network protocol stack. For example, these operations may include one or more of the following PHY operations: HARQ-ACK function, 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 coding, space-frequency coding, and / 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.

[0103] The modem platform 310 may also include a transmitting circuit system 318, a receiving circuit system 320, an RF circuit system 322, and an RF front end (RFFE) 324, which may include or be connected to one or more antenna panels 326. In short, the transmitting circuit system 318 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; the receiving circuit system 320 may include an analog-to-digital converter, a mixer, an IF component, etc.; the RF circuit system 322 may include a low-noise amplifier, a power amplifier, a power point tracking component, etc.; and the RFFE 324 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 the transmitter circuit system 318, receiver circuit system 320, RF circuit system 322, RFFE 324, and one or more antenna panels 326 (collectively referred to as the "transmit / receive assembly") depend on the details of the specific implementation, such as whether the communication is in TDM or FDM mode, or whether it is conducted in mmWave or at frequencies below 6 GHz. In some implementations, the transmit / receive assembly may be arranged as multiple parallel transmit / receive links or may be located in the same or different chips / modules.

[0104] In some implementations, the protocol processing circuitry system 314 may include one or more control circuitry examples (not shown) to provide control functions for the transmit / receive components.

[0105] UE reception can be established by and via one or more antenna panels 326, RFFE 324, RF circuitry 322, receiver circuitry 320, digital baseband circuitry 316, and protocol processing circuitry 314. In some embodiments, one or more antenna panels 326 can receive transmissions from AN 304 by receiving beamforming signals, which are received by multiple antennas / antenna elements of one or more antenna panels 326.

[0106] UE transmission can be established by and via protocol processing circuitry 314, digital baseband circuitry 316, transmit circuitry 318, RF circuitry 322, RFFE 324, and one or more antenna panels 326. In some embodiments, the transmit assembly of UE 302 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of one or more antenna panels 326.

[0107] Similar to UE 302, AN 304 may include a bearer platform 328 coupled to a modem platform 330. Bearer platform 328 may include an application processing circuitry system 332 coupled to a protocol processing circuitry system 334 of the modem platform 330. The modem platform may also include a digital baseband circuitry system 336, a transmit circuitry system 338, a receive circuitry system 340, an RF circuitry system 342, an RFFE circuitry 344, and an antenna panel 346. Components of AN 304 may be similar to and substantially interchangeable with components of UE 302 that have similar names. In addition to performing the data transmission / reception described above, components of AN 304 may perform various logical functions, including, for example, RNC functions (such as radio bearer management, uplink and downlink dynamic radio resource management, and packet scheduling).

[0108] Figure 4 This is a block diagram illustrating components according to some exemplary embodiments, which are capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any or more of the methods discussed herein. Specifically, Figure 4 The illustration shows hardware resources 400, including one or more processors (or processor cores) 410, one or more memory / storage devices 420, and one or more communication resources 430, each of which can be communicatively coupled via bus 440 or other interface circuitry. In implementations utilizing node virtualization (e.g., NFV), a hypervisor 402 can be executed to provide an execution environment for one or more network slices / subslices to utilize hardware resources 400.

[0109] For example, one or more processors 410 may include processors 412 and 414. For example, one or more processors 410 may be a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0110] Memory / storage device 420 may include main memory, disk storage, or any suitable combination thereof. Memory / storage device 420 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 memory, etc.).

[0111] One or more communication resources 430 may include interconnect or network interface controllers, components, or other suitable devices that communicate with one or more peripheral devices 404 or one or more databases 406 or other network elements via network 408. For example, one or more communication resources 430 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth Low Energy®) components, Wi-Fi® components, and other communication components.

[0112] Instructions 450 may include software, programs, applications, applets, or other executable code for causing at least any one of one or more processors 410 to perform any one or more of the methods discussed herein. Instructions 450 may reside wholly or partially in at least one of one or more processors 410 (e.g., the processor's cache), memory / storage device 420, or any suitable combination thereof. Furthermore, any portion of instructions 450 may be transferred to hardware resource 400 from any combination of one or more peripheral devices 404 or one or more databases 406. Thus, the memory of one or more processors 410, the memory / storage device 420, one or more peripheral devices 404, and one or more databases 406 are examples of computer-readable and machine-readable media.

[0113] Figure 5Another exemplary network architecture 500 is illustrated. Network architecture 500 can operate in a manner consistent with 3GPP technical specifications or technical reports for 6G systems. In some instances, network architecture 500 can operate simultaneously with network architecture 200. For example, in some instances, network architecture 500 can share one or more frequency or bandwidth resources with network architecture 200. As a specific example, a UE (e.g., UE 502) can be configured to operate simultaneously in both network architecture 500 and network architecture 200. This configuration can be based on a UE that includes circuitry configured to communicate with the frequency and bandwidth resources of network architectures 200 and 500. Typically, several elements of network architecture 500 can share one or more features with elements of network architecture 200. For the sake of brevity and clarity, these elements will not be described again in the description of network architecture 500.

[0114] Network architecture 500 may include UE 502, which may include any mobile or non-mobile computing device designed to communicate with RAN 508 via an over-the-air connection. For example, UE 502 may be similar to UE 202. UE 502 may be, but is not limited to, smartphones, tablets, wearable computing devices, desktop computers, laptops, in-vehicle infotainment systems, in-vehicle entertainment devices, dashboards, head-up displays, in-vehicle diagnostic equipment, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networking application devices, machine-type communication devices, M2M or D2D devices, IoT devices, etc.

[0115] Although not in Figure 5 While explicitly stated, in some instances, network architecture 500 may include a group of UEs directly coupled to each other via sidelink interfaces. The UEs may be M2M / D2D devices communicating using physical sidelink channels (such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.). Similarly, although not explicitly stated... Figure 5 The document explicitly states that, however, UE 502 can be communicatively coupled with an AP (such as AP 206), as in combination with... Figure 2 As stated above. Furthermore, although not in Figure 5 The document explicitly states that, however, in some instances, RAN 508 may include one or more ANs (e.g., AN 208), such as in combination. Figure 2 The RAN 508 and / or the AN of RAN 508 may be referred to as a base station (BS), RAN node, or some other term or name.

[0116] UE 502 and RAN 508 can be configured to communicate via an air interface, which 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 joint communication and sensing. As used herein, the term "joint communication and sensing" may 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 may refer to communication in the frequency range of 80 GHz and above. Additionally or alternatively, these frequency ranges may be referred to as "millimeter wave" or "mmWave" frequency ranges.

[0117] RAN 508 enables communication between UE 502 and the 6G core network (CN) 510. Specifically, RAN 508 facilitates data transmission and reception between UE 502 and the 6G CN 510. The 6G CN 510 can include various functions (such as NSSF550, NEF 552, NRF 554, PCF 556, UDM 558, AF 560, SMF 546, and AUSF 542). Furthermore, the 6G CN 510 may also include UPF 548 and DN 539, such as... Figure 5 As shown.

[0118] Furthermore, RAN 508 may include various additional functions that complement or replace the functions of traditional cellular networks (such as 4G or 5G networks). Two such functions may include a Compute Control Function (Comp CF) 524 and a Compute Service Function (Comp SF) 536. Comp CF 524 and Comp SF 536 may be components or functions of the Compute Service plane. Comp CF 524 may be a control plane function that provides functions such as management of Comp SF 536, generation and management of compute task contexts (e.g., creation, reading, modification, deletion), and interaction with the underlying compute infrastructure used for compute resource management. Comp SF 536 may be a user plane function that acts as a gateway connecting compute service users (such as UE 502) and compute nodes behind the Comp SF example via an interface. Some functions of Comp SF 536 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 acquisition, etc. In some instances, the Comp SF 536 example can act as a user plane gateway for a cluster of compute nodes. The Comp CF 524 example can control one or more Comp SF 536 examples.

[0119] The other two types of functions may include a Communication Control Function (Comm CF) 528 and a Communication Service Function (Comm SF) 538, which may be components of the communication service plane. Comm CF 528 may be a control plane function for managing Comm SF 538, communication session creation / configuration / release, and managing the communication session context. Comm SF 538 may be a user plane function for data transmission. Comm CF 528 and Comm SF 538 can be considered upgrades to SMF 246 and UPF 248, previously designed for… Figure 2 The 5G system described in the document describes these features. Upgrades provided by Comm CF 528 and Comm SF538 enable service-aware transport. For legacy data transmission (e.g., 4G or 5G), SMF 246 and UPF 248 can still be used.

[0120] The other two types of functions may include a Data Control Function (Data CF) 522 and a Data Service Function (Data SF) 532, which can be components of the data service plane. Data CF 522 can be a control plane function and provides functions such as Data SF 532 management, data service creation / configuration / release, and data service context management. Data SF 532 can be a user plane function and acts as a gateway between data service users (such as various functions of UE 502 and 6G CN 510) 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.

[0121] Another such function could be the Service Orchestration and Chaining Function (SOCF) 520, which discovers, orchestrates, and links communication / computing / data services provided by functions within a network. Upon receiving a service request from a user, SOCF 520 can interact with one or more of the Comp CF 524, Comm CF 528, and Data CF 522 to identify the Comp SF 536, Comm SF 538, and DataSF 532 instances, configure service resources, and generate a service chain that can contain multiple Comp SF 536, Comm SF 538, and Data SF 532 instances and their associated compute endpoints. Workload processing and data movement can then be performed within the generated service chain. SOCF 520 can also be responsible for maintaining, updating, and releasing the created service chains.

[0122] Another such function could be the Service Registration Function (SRF) 514, which can act as a registry for system services provided in the user plane, such as those provided by the service endpoints behind the Comp SF 536 gateway and the Data SF 532 gateway, and those provided by the UE 502. SRF 514 can be considered the counterpart to NRF 254, which can act as a registry for network functions.

[0123] Other such capabilities may include an Evolved Service Communication Proxy (eSCP) and a Service Infrastructure Control Function (SICF) 526, which provides service communication infrastructure for both control plane and user plane services. The eSCP can be associated with the 5G Service Communication Proxy (SCP), adding user plane service communication proxy capabilities. Therefore, the eSCP is represented in two parts: eCSP-C 512 and eSCP-U 534, used for the control plane service communication proxy and user plane service communication proxy, respectively. SICF 526 can control and configure the eCSP instance in areas such as service traffic routing policies, access rules, load balancing configuration, and performance monitoring.

[0124] Another such feature is AMF 544. AMF 544 can be similar to 244, but with additional functionality. Specifically, AMF 544 can include potential function refactoring (such as transferring message forwarding functionality from AMF 544 to RAN508).

[0125] Another such feature is the Service Orchestration Exposure Function (SOEF) 518. SOEF can be configured to expose service orchestration and linking services to external users (such as applications).

[0126] UE 502 may include additional functionality known as the Computing Client Service Function (comp CSF) 504. comp CSF 504 may have both control plane and user plane functions and can interact with corresponding network-side functions (such as SOCF 520, Comp CF 524, Comp SF 536, DataCF 522, and / or Data SF 532) to perform service discovery, request / response, and computational task workload exchange. Comp CSF 504 can also work with network-side functions to determine whether computational tasks should run on one of the elements of UE 502, RAN 508, and / or 6G CN 510.

[0127] UE 502 and / or Comp CSF 504 may include a service mesh proxy 506. The service mesh proxy 506 may act as a proxy for service-to-service communication in the user plane. The capabilities of the service mesh proxy 506 may include one or more of addressing, security, and / or load balancing.

[0128] Figure 6 An exemplary artificial intelligence (AI)-assisted communication architecture for communication between UE 605 and RAN 610 is illustrated, based on several aspects. More specifically, as described in further detail below, AI / machine learning (ML) models can be used or utilized to facilitate over-the-air communication between UE 605 and RAN 610.

[0129] In this example, UE 605 and RAN 610 operate in accordance with 3GPP technical specifications and / or technical reports for 6G systems. In some instances, radio cellular communication between UE 605 and RAN 610 may be part of or concurrent with network architectures 500, 200, and / or other network architectures described herein.

[0130] UE 605 may be similar to UE 202, UE 302, UE 502, UE 702, Hardware Resource 400, and / or some other UE or device (such as any of those described herein), and shares one or more features with them. UE 605 may be, but is not limited to, smartphones, tablets, wearable computing devices, desktop computers, laptops, in-vehicle infotainment systems, in-vehicle entertainment devices, dashboards, head-up display devices, in-vehicle diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networking application devices, machine-type communication devices, M2M or D2D devices, IoT devices, etc. RAN 610 may be similar to RAN 214, RAN 508, and / or some other RANs described herein, and shares one or more features with them.

[0131] from Figure 6 As can be seen, the AI-related elements of UE 605 can be similar to those of RAN 610. For the purposes of this discussion, the descriptions of the various elements will be provided from the perspective of UE 605. However, it should be understood that this discussion or description will apply to elements with the same names / numbers in RAN 610, unless otherwise explicitly stated.

[0132] As described above, UE 605 may include various elements or functions related to AI / ML. These elements may be implemented as hardware, software, firmware, and / or some combination thereof. For example, one or more elements may be implemented as part of the same hardware (e.g., a chip or multiprocessor chip), software (e.g., a computing program), or firmware that is another element.

[0133] One such element could be a data repository 615. The data repository 615 can be responsible for data collection and storage. Specifically, the data repository 615 can collect and store RAN configuration parameters, measurement data, key performance indicators (KPIs), model performance metrics, etc., for use in model training, updates, and inference. More generally, the collected data is stored in the repository. Other elements can discover and retrieve the stored data from the data repository 615. For example, it can be seen that the inference data selection / filtering element 650 can retrieve data from the data repository 615. In various instances, the UE 605 can be configured to discover and request data from the data repository 615 in the RAN, and vice versa. More generally, the UE 605's data repository 615 can be communicatively coupled to the RAN 610's data repository 615 so that the UE and the RAN's respective data repositories can share the collected data.

[0134] Another such component could be training data selection / filtering function block 620. Training data selection / filtering function block 620 can be configured to generate training, validation, and test datasets for model training. Training data can be extracted from data repository 615. Data can be selected / filtered based on the specific AI / ML model to be trained. The data can optionally be transformed / enhanced / preprocessed (e.g., normalized) before being loaded into the dataset. Training data selection / filtering function block 620 can label data in the supervised learning dataset. The resulting dataset can then be fed into model training function block 625 for model training.

[0135] As described above, another such element could be model training function block 625. This function block can be responsible for training and updating (retraining) the AI / ML model. The selected model can be trained using the feed dataset (including training, validation, and testing datasets) from the training data selection / filtering function block. Model training function block 625 can produce a trained and tested AI / ML model ready for deployment. The resulting trained and tested model can be stored in model repository 635.

[0136] Model repository 635 is responsible for storing and exposing AI / ML models (trained and untrained AI / ML models). One or more trained / updated models can be stored in model repository 635. Other functional blocks (e.g., training data selection / filtering functional block 620 and / or model training functional block 625) can discover and request models and model parameters. In some instances, UE 605 can discover and request AI / ML models from RAN 610's model repository 635. Similarly, RAN 610 can discover and / or request AI / ML models from UE 605's model repository 635. In some instances, RAN 610 can configure models and / or model parameters in UE 605's model repository 635.

[0137] Another such component could be model management function block 640. Model management function block 640 can be responsible for managing the AI / ML models generated by model training function block 625. These management functions can include deployment of trained models, model performance monitoring, etc. In model deployment, model management function block 640 can allocate and schedule hardware and / or software resources for use inference based on the received trained and tested models. As used herein, "inference" refers to the process of using one or more trained AI / ML models based on input inference data to generate data analysis results, actions, policies, etc. In performance monitoring, based on wireless performance KPIs and model performance metrics, model management function block 640 can decide to terminate model operation, start model retraining, select another model, etc. For example, model management function block 640 of RAN 610 can configure model management policies in UE 605, as shown in the figure.

[0138] Another such element could be inference data selection / filtering element 650. Inference data selection / filtering element 650 can be responsible for generating the dataset for model inference at inference function block 645, as described below. Specifically, inference data can be extracted from data repository 615. Inference data selection / filtering element 650 can select and / or filter data based on the deployed AI / ML model. The data can be transformed / enhanced / preprocessed in the same manner as the transformation / augmentation / preprocessing described for training data selection / filtering for function block 620. The resulting inference dataset can be fed into inference function block 645.

[0139] Another such element could be inference function block 645. Inference function block 645 can be responsible for performing the inference as described above. Specifically, inference function block 645 can consume the inference dataset provided by inference data selection / filtering element 650 and generate one or more results. These results may include data analysis results, actions, strategies, etc. The results can be provided to performance measurement function block 630.

[0140] Performance measurement function block 630 can be configured to measure model performance metrics (e.g., accuracy, model bias, runtime latency, etc.) of the deployed and executed model based on one or more inference results for monitoring purposes. Model performance data can be stored in data repository 615.

[0141] Figure 7 An exemplary RAN separation architecture aspect is illustrated. Figure 7 An exemplary network deployment including an exemplary Next Generation Fronthaul (NGF) deployment 700a is illustrated, wherein UE 702 is connected via an air interface to RU 730 (also referred to as “remote radio unit 730”, “remote radio head 730”, or “RRH 730”), RU 730 is connected via NGF interface (NGFI)-I to Digital Unit (DU) 731, DU 731 is connected via NGFI-II to Central Unit (CU) 732, and CU 732 is connected via a backhaul interface to Core Network (CN) 742. In a 3GPP NG-RAN implementation (see, for example, [TS38401]), DU 731 may be a distributed unit (for the purposes of this disclosure, the term “DU” may refer to a digital unit and / or a distributed unit unless the context otherwise specifies). UE 702 may be the same as or similar to UE 202 and / or any other UE or user / client equipment discussed herein.

[0142] In some implementations, the NGF Deployment 700a can be deployed in a Distributed RAN (D-RAN) architecture, where CU 732, DU 731, and RU 730 are located at the cell site, while CN 742 is located at the centralized site. Alternatively, the NGF Deployment 700a can be deployed in a Centralized RAN (C-RAN) architecture, where one or more Baseband Units (BBUs) are centrally processed at the centralized site. In a C-RAN architecture, radio components are broken down into discrete components that can be located in different locations. In one exemplary C-RAN implementation, only RU 730 is located at the cell site, while DU 731, CU 732, and CN 742 are centralized or located in a central position. In another exemplary C-RAN implementation, RU 730 and DU 731 are located at the cell site, while CU 732 and CN 742 are located at the centralized site. In another C-RAN implementation example, only RU730 is located at the cell site, DU 731 and CU 732 are located at the RAN central site, and CN 742 is located at the centralized site.

[0143] The CU 732 is the central controller, which can serve or otherwise connect to one or more DU 731s and / or RU 730s. The CU 732 is a higher / upper-layer network (logical) node carrying network protocol function decompositions. For example, in 3GPP NG-RAN and / or O-RAN architectures, the CU 732 carries the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) layers of the Next Generation Node B (gNB), or, when included in or operating as an E-UTRA-NR gNB (en-gNB), carries the RRC and PDCP protocol layers. The SDAP sublayer performs the mapping between Quality of Service flows and Data Radio Bearers (DRBs) and marks Quality of Service Flow IDs (QFIs) in DL and UL packets. The PDCP sublayer performs the following functions: transmits user plane or control plane data; maintains PDCP sequence numbers (SNs); performs header compression and decompression using the Robust Header Compression (ROHC) protocol and / or the Ethernet Header Compression (EHC) protocol; encrypts and decrypts; provides integrity protection and authentication; provides timer-based SDU dropping; routes for split bearers; duplicates and duplicates; reorders and ordered delivery; and / or out-of-order delivery. In various implementations, the CU 732 terminates the corresponding F1 interface connected to the corresponding DU 731 (see, for example, [TS38401]).

[0144] CU 732 may include a CU-Control Plane (CP) entity (referred to herein as "CU-CP 732") and a CU-User Plane (UP) entity (referred to herein as "CU-UP 732"). CU-CP 732 is a logical node carrying the control plane portion of the RRC layer and PDCP protocol layer of CU 732 (e.g., gNB-CU for en-gNB or gNB). CU-CP terminates the E1 interface connected to CU-UP, and the F1-C interface is connected to DU 731. CU-UP 732 is a logical node carrying the user plane portion of the PDCP protocol layer (e.g., gNB-CU 732 for en-gNB) and the user plane portion of the PDCP protocol layer and the SDAP protocol layer (e.g., gNB-CU 732 for gNB). CU-UP 732 terminates the E1 interface connected to CU-CP 732 and the F1-U interface connected to DU 731.

[0145] The DU 731 locally controls radio resources (such as time and frequency bands) in real time and allocates resources to one or more UEs. The DU 731 is a network (logical) node carrying the intermediate and / or lower layers of network protocol functions. For example, in 3GPP NG-RAN and / or O-RAN architectures, the DU 731 carries the Radio Link Control (RLC), Medium Access Control (MAC), and High-Physical (PHY) layers of the gNB or en-gNB, and its operation is at least partially controlled by the CU 732. The RLC sublayer operates in one or more of Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC sublayer performs the following functions: transmission of upper-layer PDUs; sequential numbering (UM and AM) independent of PDCP sequence numbers; error correction via ARQ (AM only); segmentation (AM and UM) and re-segmentation (AM only); reassembly of SDUs (AM and UM); duplicate detection (AM only); RLC SDU discarding (AM and UM); RLC reconstruction; and / or protocol error detection (AM only). The MAC sublayer performs the following functions: mapping between logical channels and transport channels; multiplexing MAC SDUs belonging to one or different logical channels into a transport block (TB) delivered to the physical layer on the transport channel / demultiplexing MAC SDUs belonging to one or different logical channels from a transport block (TB) delivered from the physical layer on the transport channel; scheduling information reporting; error correction via HARQ (in the case of CA, each cell has one HARQ entity); prioritization among UEs by means of dynamic scheduling; prioritization among logical channels of a UE by means of logical channel priority ordering; prioritization among overlapping resources of a UE; and / or padding. In some implementations, such as when the DU 731 operates as an Integrated Access and Backhaul (IAB) node, the DU 731 can carry the Backhaul Adaptation Protocol (BAP) layer (see, for example, 3GPP TS 38.340 v16.5.0 (2021-07-07)) and / or the F1 application protocol (F1AP) (see, for example, 3GPP TS38.470 v16.5.0 (2021-07-01)). One DU 731 supports one or more cells, and a cell is supported by only one DU 731.DU 731 terminates the F1 interface connected to CU 732. DU 731 may be connected to one or more RRH / RU 730s, either additionally or alternatively.

[0146] The RU 730 is a Transmit / Receive Point (TRP) or other physical node that handles radio frequency (RF) processing functions. The RU 730 is a low-level network (logical) node based on low-level function decomposition. For example, in 3GPP NG-RAN and / or O-RAN architectures, the RU 730 carries low-PHY layer functions and RF processing for the radio interface based on low-level function decomposition. The RU 730 can be similar to a 3GPP Transmit / Receive Point (TRP) or RRH, but specifically includes a low-PHY layer. Examples of low-PHY functions include Fast Fourier Transform (FFT), Inverse FFT (IFFT), Physical Random Access Channel (PRACH) extraction, etc.

[0147] Each of the CU 732, DU 731, and RU 730 is connected via corresponding links, which can be any suitable wireless and / or wired (e.g., fiber optic, copper, etc.) links. In some implementations, various combinations of the CU 732, DU 731, and RU 730 can correspond to... Figure 2 One or more AN 208. Other aspects of CU 732, DU 731 and RU 730 are discussed in [O-RAN], [TS38401], [TS38410] and [TS38300], the entire contents of which are hereby incorporated herein by reference.

[0148] In some implementations, the Fronthaul Gateway Function (FHGW) can be set between the DU 731 and the RU / RRU 730. Figure 7 (Not shown in the diagram), wherein the interface between DU 731 and FHGW is an Open Fronthaul (e.g., Option 7-2x) interface, and the interface between the FHGW function and RU / RRU 730 is an Open Fronthaul (e.g., Option 7-2x) interface or any other suitable interface (e.g., Option 7 or Option 8, etc.), including interfaces that do not support Open Fronthaul (e.g., Option 7-2x). FHGW may be encapsulated in a physical device or apparatus along with one or more other functions (e.g., Ethernet switching and / or other functions, etc.). In some implementations, the RAN controller may be communicatively coupled to CU 732 and / or DU731.

[0149] NGFI (also known as "xHaul") is a two-tier fronthaul architecture that divides the traditional connection between the RRU 730 and BBU in the C-RAN architecture into two tiers: Tier I and Tier II. Tier I connects the RU 730 to the DU 731 via NGFI-I, and Tier II connects the DU 731 to the CU 732 via NGFI-II, as shown below. Figure 7The deployment is shown in 700a. The connection between NGFI-I and NGFI-II can be wired or wireless, and they can utilize any suitable RAT (such as any RAT discussed herein). The purpose of the two-tier architecture is to distribute (split) RAN node protocol functions between the CU 732 and DU 731 to reduce latency and thus provide greater deployment flexibility. Generally, NGFI-I connects to the lower layers of the split functions via interfaces, which have strict latency and data rate requirements. In contrast, NGFI-II connects to the higher layers of the split functions relative to NGFI-I via interfaces, thereby reducing the requirements for the fronthaul link. Examples of NGFI fronthaul interfaces and functional split architectures include: O-RAN 7.2x fronthaul (see, for example, [O-RAN.WG9.XPSAAS] and [O-RAN-WG4.CUS.0]); C-RAN fronthaul based on the enhanced Common Public Radio Interface (CPRI) (see, for example, Common Public Radio Interface: eCPRI Interface Specification, eCPRI Specification v2.0 (2019-05-10), Common Public Radio Interface: Requirements for the eCPRI Transport Network, eCPRI Transport Network v1.2 (2018-06-25), and [O-RAN-WG4.CUS.0]); and / or C-RAN fronthaul based on Radio over Ethernet (RoE) (see, for example, IEEE Standards Association, IEEE 1914.3-2018 (05 Oct. 2018)). ("[IEEE1914.3]") etc.Other aspects of NGFI are also discussed in the following references: [O-RAN.WG9.XPSAAS]; [O-RAN-WG4.CUS.0]; IEEE Standard for Packet-based Fronthaul Transport Networks, IEEE Standards Association, IEEE1914.1-2019 (21 Apr. 2020) (“[IEEE1914.1]”), [IEEE1914.3]; and Nasrallah et al., Ultra-Low Latency (ULL) Networks: A Comprehensive Survey Covering the IEEE TSN Standard and Related ULL Research, arXiv:1803.07673v1 [cs.NI] (20 Mar. 2018) (“[Nasrallah]”), the entire contents of which are hereby incorporated herein by reference.

[0150] In one instance, deploying 700a can implement a Low-Level Split (LLS) (also known as “Low-Level Functional Split 7-2x” or “Split Option 7-2x”), which operates between RU 730 (e.g., O-RU in the O-RAN architecture) and DU 731 (e.g., O-DU in the O-RAN architecture) (see, for example, [O-RAN.WG7.IPC-HRD-Opt7-2], [O-RAN.WG7.OMAC-HRD], [O-RAN.WG7.OMC-HRD-Opt7-2]). In this exemplary implementation, NGFI-I is the Open Fronthaul Interface described in the O-RAN Open Fronthaul Specification (see, for example, [O-RAN-WG4.CUS.0]). Other LLS options can also be used, such as the relevant interfaces described in other standards or specifications, for example: 3GPP NG-RAN function split (see, for example, [TS38401] and 3GPP TR 38.801 v14.0.0 (2017-04-03)); Small Cell Forum for split option 6 (see, for example, 5G small cell architecture and product definitions: Configurations and Specifications for companies deploying small cells 2020-2025, Small Cell Forum, document 238.10.01 (05 Jul. 2020) (“[SCF238]”); 5G NRFR1 Reference Design: The case for a common, modular architecture for 5G NRFR1 small cell distributed radio units, Small Cell Forum, document 251.10.01 (15 Dec. 2021) (“[SCF251]”); and [O-RAN.WG7.IPC-HRD-Opt6], the entire contents of which are hereby incorporated herein by reference); and / or O-RAN white-box hardware split option 8 (e.g., [O-RAN.WG7.IPC-HRD-Opt8]).

[0151] Alternatively or concurrently, CU 732, DU 731, and / or RU 730 can be IAB nodes. IABs enable wireless relaying in NG-RAN, where relay nodes (referred to as "IAB nodes") support access and backhaul via 3GPP 5G / NR links / interfaces. The terminating node of the NR backhaul on the network side is called the "IAB donor," which represents a RAN node (e.g., a gNB) with additional IAB support. Backhauls can be performed via single-hop or multi-hop connections. All IAB nodes connected to the IAB donor via single-hop or multi-hop connections form a Directed Acyclic Graph (DAG) topology rooted at the IAB donor. The IAB donor centrally manages resources, topology, and routing for the IAB topology. The IAB architecture is illustrated and described in [TS38300].

[0152] Although NGF Deployment 700a presents CU 732, DU 731, RRH 730, and CN 742 as separate entities, in other implementations, some or all of these network nodes may be bundled, combined, or otherwise integrated into a single device or component, including folding some internal interfaces (e.g., F1-C, F1-U, E1, E2, etc.). At least the following implementations are possible: (i) integrating CU 732 and DU 731 (e.g., forming a CU-DU), which is connected to RRH 730 via NGFI-I; (ii) integrating DU 731 and the integrated RRH 730 (e.g., CU-DU), the resulting assembly being connected to CU 732 via NGFI-II; (iii) integrating the RAN controller and CU 732, the resulting assembly being connected to DU 731 via NGFI-II; (iv) integrating CU 732, DU 731, and RU 730, the resulting assembly being connected to CN 742 via a backhaul interface; and (v) integrating the network controller (or intelligent controller), CU 732, DU 731, and RU 730. Any of the above exemplary implementations involving CU 732 may also include: integrating CU-CP 732 and CP-UP 732.

[0153] Figure 7An exemplary RAN decoupling deployment 700b (also known as “Decoupled RAN 700b”) is also illustrated, in which UE 702 is connected to RRH 730, and RRH 730 is communicatively coupled to one or more RAN functions (RANFs) 1-N (where N is a number). RANFs 1-N are decoupled and geographically distributed across several component segments and network nodes. In some implementations, each RANF 1-N is a software (SW) element operated by a physical computing node, and RRH 730 includes radio frequency (RF) circuitry (e.g., an RF propagation module and / or other circuitry for a specific RAT). In this example, RANF 1 operates on a physical computing node located in the same place as RRH 730, while other RANFs are located further away from RRH 730. Furthermore, in this example, CN 742 is similarly decoupled into CN NF 1-x (where x is a number) in the same or similar manner as RANFs 1-N. However, in other implementations, CN 742 is not decoupled.

[0154] Network decoupling (or decoupling of the network) involves breaking down network devices into functional components and allowing each component to be deployed independently. This may include separating SW elements (e.g., NFs) from specific HW elements, and / or using APIs to implement Software-Defined Networking (SDN) and / or NF virtualization (NFV). RAN decoupling involves various RANFs (e.g., Figure 7 Network decoupling and virtualization of RANFs 1-N in RAN deployments. Based on use cases, RANFs 1-N can be placed in different physical sites across various topologies within a RAN deployment. This enables the distribution and deployment of RANFs across different geographical regions and allows for the splitting of RANFs to support a variety of use cases (e.g., low-latency use cases) and flexible RAN implementations. Decoupling provides a general or unified RAN platform capable of presenting different profiles depending on its deployment location. This reduces fixed-function equipment and total cost of ownership compared to existing RAN architectures. Exemplary RAN decoupling frameworks include Telecom Infra Project (TIP) OpenRAN™, Cisco® Open vRAN™, [O-RAN], Open Optical & Packet Transport (OOPT), and / or Reconfigurable Optical Add Drop Multiplexer (ROADM).

[0155] In a first exemplary implementation, RANF 1-N decouples the RAN HW and SW through Commercial Off-the-Shelf (COTS) HW and open interfaces (e.g., NGFI-I and NGFI-II). In this exemplary implementation, each RANF 1-N can be a virtual BBU or vRAN controller running on a COTS computing infrastructure, which can accelerate the HW of the BBU / vRANF.

[0156] In a second exemplary implementation, RANF 1-N decouples one or more layers of the RAT protocol stack. As an example of this implementation, RANF 1 is a DU 731 running on the first COTS computing infrastructure, which can perform hardware acceleration of BBU / vRANF; while RANF 2 is a virtual CU 732 running on the second COTS computing infrastructure.

[0157] In the third exemplary implementation, RANF 1-N decouples the control plane functions and the user plane functions. As an example of this implementation, RANF 1 is a DU 731 running on the COTS computing infrastructure, which can hardware accelerate the BBU / vRANF; RANF 2 is a virtual CU-CP 732 running on the COTS computing infrastructure; and the third RANF (e.g., RANF 3) Figure 7 (Not shown) is a virtual CU-UP 732 running on the same or a different COTS computing infrastructure as the virtual CU-CP 732. Additionally or alternatively, in this implementation, one or more CN NF 1-x may be CN-UP functions, and one or more other CN NF 1-x may be CN-CP functions.

[0158] In the fourth exemplary implementation, RANF 1-N decouples the layers of the [IEEE 802] RAT. As an example of this implementation, RRH 730 implements the WiFi PHY layer, RANF 1 implements the WiFi MAC sublayer, RANF 2 implements the WiFi Logical Link Control (LLC) sublayer, RANF 2 implements one or more WiFi upper-layer protocols (e.g., network layer, transport layer, session layer, presentation layer, and / or application layer), and so on.

[0159] In the fifth exemplary implementation, RANF 1-N decouple the different O-RAN RANFs, including E2SM. As an example of this implementation, RANF 1 implements near-RT RIC, RANF 2 implements E2SM-KPM, RANF 3 implements E2SM-CCC, RANF 4 implements E2SM RAN control, RANF 5 implements E2SM-NI, RANF 6 implements functions for providing AI services, and so on.

[0160] In any of the implementations discussed in this paper, the lower layers of the RAN protocol stack can be characterized by real-time (RT) functions and relatively complex signal processing algorithms, while the higher layers of the RAN protocol stack can be characterized by non-RT functions. In these implementations, the RT functions and signal processing algorithms can be implemented using dedicated network elements in the DU 731 and / or RRH 730, or in COTS hardware enhanced by a dedicated HW accelerator.

[0161] Figure 7Various functional splitting options 700c for DL ​​and UL directions are also shown. Traditional RANs are integrated network architectures based on the Distributed RAN (D-RAN) model, where D-RAN integrates all RANs into a few network elements. As mentioned above, the decoupled RAN architecture provides flexible functional splitting options to overcome various shortcomings of the D-RAN model. Decoupled RAN divides the integrated network system into several functional components, which can then be repositioned individually as needed without hindering their ability to work together to provide overall network services. Splitting option 700c primarily splits between CU 732 and DU 731, but may include splits between CU 732, DU 731, and RU 730. For each option 700c, the protocol entities on the left side of the figure are included in the RANF implementing CU 732, while the protocol entities on the right side of the figure are included in the RANF implementing DU 731. For example, Option 2's function splitting involves separating non-RT processing (e.g., RRC and PDCP layers) from RT processing (e.g., RLC, MAC, and PHY layers). The RANF implementing CU 732 performs network functions for the RRC and PDCP layers, while the RANF implementing DU 731 performs baseband processing functions for RLC (including high and low RLC), MAC (including high and low MAC), and PHY layers. In some implementations, the PHY layer is further divided between DU 731 and RU 730, with the RANF implementing DU 731 performing high PHY layer functions, while RU 730 handles low PHY layer functions. In some implementations, the low PHY entity can be operated by RU 730 regardless of which function splitting option is selected. Under Option 2 splitting, the RANF implementing CU 732 can connect to multiple DU 731s (e.g., CU 732 is centralized). This eliminates the need to change the RRC and PDCP anchor points during handovers across DU 731s and allows the centralized CU 732 to aggregate resources across several DU 731s. In these ways, Option 2 splitting improves resource efficiency. The specific splitting options used can vary depending on service requirements and network deployment scenarios, and can be tailored to specific implementations. It should also be noted that in some implementations, all splitting options can be selected, where each protocol stack entity is operated by a corresponding RANF (e.g., the first RANF operates the RRC layer, the second RANF operates the PDCP layer, the third RANF operates the high RLC layer, and so on, up to the eighth RANF operating the low PHY layer).Other splitting options are also possible, such as those discussed in [O-RAN.WG7.IPC-HRD-Opt6], [O-RAN.WG7.IPC-HRD-Opt7-2], [O-RAN.WG7.IPC-HRD-Opt8], [O-RAN.WG7.OMAC-HRD], and [O-RAN.WG7.OMC-HRD-Opt7-2].

[0162] For one or more embodiments, at least one of the components outlined in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods discussed herein (including the examples listed in the Examples section below). For example, a baseband circuit system associated with one or more of the foregoing figures may be configured to operate according to one or more examples set forth below. As another example, circuitry associated with a UE, base station, satellite, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more examples set forth below in the Examples section.

[0163] The term "application" can refer to a complete and deployable package or environment that implements a specific function within an operating environment. The term "AI / ML application," etc., can refer to an application that includes some artificial intelligence (AI) / machine learning (ML) models and an application-level description. In some implementations, an AI / ML application can be used to configure or implement one or more exposed aspects.

[0164] The term "machine learning" or "ML" refers to the use of computer systems that implement algorithms and / or statistical models to perform one or more specific tasks without the use of explicit instructions, relying instead on patterns and reasoning. ML algorithms build or estimate one or more mathematical models (called "ML models") based on sample data (referred to as "training data" or "model training information," etc.) to make predictions or decisions, rather than being explicitly programmed to perform these tasks. Typically, ML algorithms are computer programs that learn from experience with some tasks and some performance metrics, and ML models can be any object or data structure created after training an ML algorithm with one or more training datasets. After training, the ML model can be used to make predictions on new datasets. While the term "ML algorithm" refers to a concept different from the term "ML model," these terms are used interchangeably in this disclosure as discussed herein.

[0165] The terms "machine learning model" and "ML model" can also refer to the ML methods and concepts used in ML-assisted solutions. An "ML-assisted solution" is a solution that uses ML algorithms to solve a specific use case during runtime. ML models include supervised learning (e.g., linear regression, K-Nearest Neighbor (KNN), decision tree algorithms, support vector machines, Bayesian algorithms, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, Principal Component Analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-armed learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model can have many sub-models as components, and the ML model can train all sub-models simultaneously. Individually trained ML models can also be chained together in an ML pipeline during inference. An "ML pipeline" is a set of functionalities, features, or functional entities specific to an ML-assisted solution; an ML pipeline can include a data pipeline, a model training pipeline, a model evaluation pipeline, and one or more data sources from actors. An “Agent” is an entity that carries the ML-assisted solution using the inference output of an ML model. The term “ML training agent” refers to an entity that carries the model training (e.g., a network function). The term “ML inference agent” refers to an entity that carries the model during inference mode (if applicable, this includes model execution and any online learning). The ML agent informs the Agent of the output of the ML algorithm, and the Agent selects an action (“action” is performed by the Agent as an output of the ML-assisted solution). The term “model inference information” refers to information used as input to the ML model to determine one or more inference results; data used to train the ML model and data used to determine inference results may overlap, but “training data” and “inference data” refer to different concepts.

[0166] This disclosure defines or otherwise provides the behavior and capabilities of a UE in a cellular system to support gapless cross-RAT NR-EUTRAN measurements. The following discussion can be applied to any type of communication device (such as a UE or base station), including combinations of... Figures 1A to 9 Any UE or base station under discussion.

[0167] The disclosed technology specifies the requirements for instructing a UE to have "nogap-noncsg" capability and to perform measurements across RAT LTE carriers without measurement gaps without disrupting the serving cell. A UE with this capability can meet the cell identification period and measurement period requirements and report the measurement results to the network accordingly.

[0168] Measurements without gaps or interruptions improve system data performance. Effective measurement window configuration helps resolve measurement conflicts between different target frequency layers.

[0169] In some respects, when the UE indicates support for gapless measurements across RAT LTE target frequencies, an effective measurement window (EMW) is used. This requires the UE to perform LTE CRS measurements for the duration of the effective measurement window, so that the network explicitly knows when the UE is measuring the target.

[0170] When a UE indicates to the network that it supports gapless cross-RAT LTE measurements, the network configures an effective measurement window configuration for the UE, regardless of whether there is an interruption, rather than a measurement gap configuration. The configuration of the effective measurement window includes at least the periodicity of the window timing, the duration of each window within each period, and the time offset of each window within the period.

[0171] With this definition, a UE can follow the configuration of an effective measurement window to measure the target LTE CRS only within the configured window. If a UE capability with "interruptions" is indicated, an interruption will occur within the UE when the UE must retune to and retune back to the target LTE frequency; this occurs at the beginning and end of the effective measurement window, or both. For gapless cross-RAT LTE measurements, interruptions are permitted at the beginning and end of each effective measurement window for UEs capable of "interrupted" gapless measurements. However, interruptions are not permitted for UEs indicating support for "uninterrupted" gapless measurements.

[0172] During the effective measurement window duration, the network schedules UEs in the serving cell as usual. Knowing that the UE will only perform measurements within the window duration, the network can correctly schedule measurements for the UE so that there are no conflicts between the effective window and the SMTC / SSB / measurement gap. This is the benefit of an effective measurement window. Figure 8 This illustrates a typical use case for scheduling measurements through the configuration of an effective measurement window.

[0173] Figure 8 An NR-LTE measurement arrangement 800 based on an effective measurement window (EMW) configuration is shown, according to some aspects.

[0174] like Figure 8 As shown, by configuring the time offset of the effective measurement window, measurements across the RAT LTE CRS do not overlap with any NR measurements. In this way, system performance is optimized. No existing requirements for NR measurements were observed to be affected. For the UE, only one effective measurement window is configured at a time, therefore the timing of the window bearer is shared across all target LTE frequency layers.

[0175] To achieve this optimal performance, the periodicity of the configured effective measurement window must be equal to or greater than the periodicity of any of the SSB, SMTC, and measurement gap configurations for any frequency layer configured as the measurement target for the UE. Simultaneously, the time offset of the effective measurement window configuration must differ from the time offset of any SMTC or measurement gap configured for the UE.

[0176] The following configuration is related to the measurement cycle requirements for use case b-1 (gapless and uninterrupted measurement of UE).

[0177] For UEs that support gapless and uninterrupted cross-RAT EUTRA measurements and indicate NeedForGapNCSG-InfoEUTRA-r18 “nogap-noncsg”, cross-RAT measurements are defined as gapless measurements if the UE indicates “nogap-noncsg” for cross-RAT measurements via NeedForGapNCSG-InfoEUTRA-r18.

[0178] When the effective measurement window is configured and specified based on the total duration of the available measurement windows for each configuration, the parameter T InterEMW It can be used for gapless cross-RAT requirements.

[0179] Table 1 below indicates the minimum available time for cross-RAT measurements when a valid measurement window is configured.

[0180] Table 1 When the UE is configured with a valid measurement window to identify and measure across RAT cells without gaps or interruptions, and the UE is able to perform "nogap-noncsg" in NeedForGapNCSG-infoEUTRA, the UE should be able to perform T according to the following expression. Identify,E-UTRAN FDD or TDD Internal identification of new detectable FDD or TDD cells: T Identify, E-UTRAN FDD or TDD = 480 xT interEMW / 480 x Ceil(K EMW ).

[0181] When DRX is not used and the UE indicates the "nogap-noncsg" capability to perform these measurements without gaps or interruptions in NeedForGapNCSG-infoEUTRA, and when a valid measurement window is configured for gapless cross-RAT EUTRA measurements, the UE physical layer can be configured to report RSRP, RSRQ, and RS-SINR measurement results to higher layers, where the measurement period T is given in the table below. Measure, E-UTRAN FDD or T Measure, E-UTRAN TDD .

[0182] Table 2 below indicates the measurement cycle and measurement bandwidth when DRX is not configured.

[0183] Table 2 In Table 2, T EMW It is the periodicity of the configuration of the effective measurement window, and K EMW It equals the total number of LTE frequency layers configured, which the UE measures without gaps or interruptions.

[0184] When DRX is employed and the UE indicates the "nogap-noncsg" capability for these measurements in NeedForNCSG-infoEUTRA, and when a valid measurement window is configured for gapless cross-RAT EUTRA measurements, the UE physical layer should be able to perform the measurements as specified in the table below. Identify, E-UTRAN FDD or TDD It can identify new detectable E-UTRAN FDD or TDD cells.

[0185] Table 3 indicates the configuration used to identify new detectable E-UTRAN FDD or TDD cells when DRX is configured.

[0186] Table 3 When DRX is employed and the UE indicates the "nogap-noncsg" capability for these measurements in NeedForGapNCSG-infoEUTRA, and when an effective measurement window is configured for gapless cross-RAT EUTRA measurements, the UE physical layer should be able to report RSRP, RSRQ, and RS-SINR measurement results to higher layers, where the measurement period T is given in the table below. measure, E-UTRAN FDD or TDD .

[0187] Table 4 indicates the configuration for measuring E-UTRAN FDD or TDD cells when DRX is configured.

[0188] Table 4 In Table 4, K EMW It equals the total number of LTE frequency layers configured, which the UE measures without gaps or interruptions.

[0189] In some cases, the UE should not apply any requirements when the configured effective measurement window period is less than the specified period or less than any configured SSB / SMTC / measurement gap period. In these situations, performance cannot be guaranteed because conflicts between EMW measurements and other measurements are unavoidable.

[0190] Figure 9 A block diagram is shown of communication devices (such as Evolved Node-B (eNB), New Generation Node-B (gNB) (or another RAN node such as a base station), Network-Controlled Repeater (NCR), Access Point (AP), Wireless Station (STA), Mobile Station (MS), or User Equipment (UE)) to perform one or more of the techniques disclosed herein. Alternatively, the communication device 900 may operate as a standalone device or may be connected to other communication devices (e.g., networked with them).

[0191] A circuit system (e.g., a processing circuit system) is a collection of circuits implemented in the tangible entity of device 900, including hardware (e.g., simple circuits, gates, logic, etc.). The membership of a circuit system can change over time. A circuit system includes members that can perform a specific operation individually or in combination during operation. For example, circuit system hardware can be permanently designed to perform a specific operation (e.g., hardwired). For example, the hardware of a circuit system can include variable-connection physical components (e.g., execution units, transistors, simple circuits, etc.) and machine-readable media including physical modifications (e.g., magnetic modifications, electrical modifications, movable placement of invariant mass particles, etc.) to encode instructions for a specific operation.

[0192] When physical components are connected, the underlying electrical characteristics of the hardware components change, for example, from an insulator to a conductor, and vice versa. Instructions enable embedded hardware (e.g., an execution unit or loading mechanism) to create members of a circuit system within the hardware via variable connections to perform specific operations during operation. Thus, in one instance, a machine-readable medium element is either part of the circuit system or communicatively coupled to other components of the circuit system when the device is running. For example, any physical component can be used as more than one member of more than one circuit system. For example, during operation, an execution unit may be used by a first circuit of a first circuit system at a certain point in time and reused at different times by a second circuit of the first circuit system or a third circuit of the second circuit system. Other examples of these components of device 900 are as follows.

[0193] In some respects, device 900 can operate as a standalone device or can be connected to other devices (e.g., networked with them). In a network deployment, communication device 900 can function as a server communication device, a client communication device, or both in a server-client network environment. For example, communication device 900 can act as a peer-to-peer (P2P) (or other distributed) network environment. Communication device 900 can be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smartphone, network application device, network router, switch, or bridge, or any communication device capable of executing instructions (sequentially or otherwise) specifying the actions to be taken by the communication device. Furthermore, although only a single communication device is shown, the term "communication device" should also be understood to include any collection of communication devices that individually or jointly execute a set (or more) of instructions to perform any of the methods discussed herein, such as cloud computing, Software as a Service (SaaS), and other computer cluster configurations.

[0194] As described herein, an instance may include logic or components, modules, or mechanisms, or on which operations can be performed. A module is a tangible entity (e.g., hardware) capable of performing a specified operation and may be configured or arranged in a particular manner. In one instance, circuitry may be arranged as a module in a specified manner (e.g., arranged internally or relative to external entities such as other circuitry). In one instance, all or part of one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) to perform a specified operation. In one instance, software may reside on a communication device-readable medium. In one instance, when executed by the underlying hardware of the module, the software causes the hardware to perform the specified operation.

[0195] Therefore, the term "module" is understood to encompass tangible entities that are physically constructed, specifically configured (e.g., hardwired) or temporarily (e.g., transiently) configured (e.g., programmed) entities that function in a particular manner or perform part or all of the operations described herein. Given that modules are instances of temporary configurations, each module need not be instantiated at any given time. For example, in the case where a module comprises a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as corresponding different modules at different times. For instance, the software can accordingly configure the hardware processor to constitute a particular module in one instance and a different module in another different instance.

[0196] The communication device (e.g., UE) 900 may include a hardware processor 902 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 904, static memory 906, and storage device 916 (e.g., a hard disk drive, a tape drive, flash memory, or other block device or storage device), some or all of which may communicate with each other via an interconnect link 908 (e.g., a bus).

[0197] The communication device 900 may also include a display device 910, an input device 912 (e.g., a keyboard), and a user interface (UI) navigation device 914 (e.g., a mouse). In one example, the display device 910, input device 912, and UI navigation device 914 may be a touchscreen display. Furthermore, the communication device 900 may also include a signal generating device 918 (e.g., a speaker), a network interface device 920, and one or more sensors 921 (e.g., a Global Positioning System (GPS) sensor, a compass, an accelerometer, or another sensor). The communication device 900 may include an output controller 928 (e.g., serial (e.g., Universal Serial Bus, USB), parallel, or other wired or wireless (e.g., infrared (IR), Near Field Communication (NFC), etc.) connection)) to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0198] Storage device 916 may include device-readable medium 922 storing one or more sets of data structures or instructions 924 (e.g., software) that embody or utilize any one or more of the techniques or functions described herein. In some aspects, the hardware processor 902, main memory 904, static memory 906, and / or registers of storage device 916 may be or ( wholly or at least partially) comprise device-readable medium 922 storing one or more sets of data structures or instructions 924 that embody or utilize any one or more of the techniques or functions described herein. In one instance, one or any combination of hardware processor 902, main memory 904, static memory 906, or storage device 916 may constitute device-readable medium 922.

[0199] As used herein, the term "device-readable medium" may be used interchangeably with "computer-readable medium" or "machine-readable medium." Although device-readable medium 922 is shown as a single medium, the term "communication device-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) configured to store instructions 924. The term "communication device-readable medium" includes the terms "machine-readable medium" or "computer-readable medium" and may include any medium capable of storing, encoding, or carrying instructions (e.g., instructions 924) executable by communication device 900 and causing communication device 900 to perform any one or more of the technologies of this disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with those instructions. Non-limiting examples of communication device-readable media may include solid-state memory as well as optical and magnetic media. Specific examples of communication device readable media may include non-volatile memory (such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks (such as internal hard disks and removable hard disks); magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM optical discs). In some instances, communication device readable media may include non-transitory communication device readable media. In some instances, communication device readable media may include communication device readable media that do not transmit signals transiently.

[0200] Commands 924 can also be transmitted or received via a communication network 926 employing a transmission medium, using any of several transmission protocols through network interface device 920. In one example, network interface device 920 may include one or more physical jacks (e.g., Ethernet jacks, coaxial jacks, or telephone jacks) or one or more antennas for connection to communication network 926. In one example, network interface device 920 may include multiple antennas to perform wireless communication using at least one of Single-Input Multiple-Output (SIMO), MIMO, or Multiple-Input Single-Output (MISO) technologies. In some examples, network interface device 920 may utilize multi-user MIMO technology for wireless communication.

[0201] The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions executable by the communication device 900 and comprising digital or analog communication signals, or another intangible medium facilitating communication by such software. In this context, the transmission medium is a device-readable medium.

[0202] The terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” refer to the same thing and are used interchangeably in this disclosure. These terms are defined to include both machine storage media and transmission media. Therefore, these terms include both storage devices / media and carrier / modulated data signals.

[0203] The implementation of the subject matter may include one or more features, which may be used individually or in combination, as illustrated by examples below.

[0204] Example 1 is an apparatus for configuring a user equipment (UE) to operate in a fifth generation new radio (5G NR) network, including a processing circuitry system and a memory, wherein the processing circuitry system is configured to perform the following operations: encode notification signaling to be transmitted to a base station, the notification signaling instructing the UE to perform gapless cross-radio access technology (cross-RAT) new radio (NR)-evolved universal terrestrial radio access network (EUTRAN) measurements; decode configuration signaling received from the base station to configure periodicity and minimum available time associated with an effective measurement window (EMW) that does not overlap with measurement gaps; and perform cross-RAT NR-EUTRAN measurements within the EMW, wherein the measurements have a duration within the minimum available time.

[0205] In Example 2, the topic described in Example 1 is followed, wherein the notification signaling is NeedForGapNCSG-InfoEUTRA signaling.

[0206] In Example 3, based on the topics described in Examples 1 and 2, the configuration signaling indicates that the EMW is associated with one of the configuration IDs 0, 1, 2, 3, 4, or 5.

[0207] In Example 4, based on the subject described in Examples 1 to 3, the configuration signaling indicates that the EMW is associated with one of the repetition periods of 40ms, 80ms, 40ms, 80ms, 40ms, and 80ms, which correspond to configuration IDs 0, 1, 2, 3, 4, and 5, respectively.

[0208] In Example 5, based on the topics described in Examples 1 through 4, the minimum available time of the EMW is associated with one of the periods of 60ms, 30ms, 60ms, 30ms, 60ms, and 30ms corresponding to configuration IDs 0, 1, 2, 3, 4, and 5, respectively.

[0209] In Example 6, based on the subject matter described in Examples 1 through 5, the processing circuitry is further configured to identify new Frequency Division Duplex (FDD) cross-RAT cells within a time period based on the minimum available time associated with the EMW.

[0210] In Example 7, based on the subject matter described in Examples 1 through 6, the processing circuitry is further configured to perform measurements on the new FDD across RAT cells within a measurement bandwidth comprising six resource blocks (RBs).

[0211] In Example 8, based on the subject matter described in Examples 1 through 7, the processing circuitry is further configured to identify new FDDs across RAT cells within a time period based on the length of the Discontinuous Reception (DRX) period used by the UE.

[0212] In Example 9, the subject matter according to Examples 1 to 8 further includes a transceiver circuit system coupled to the processing circuit system and two or more antennas coupled to the transceiver circuit system.

[0213] In Example 10, a computer-readable storage medium stores instructions that are executed by one or more processors of a base station to configure the base station to perform cross-RAT NR-EUTRAN measurements in 5G NR networks and more advanced networks, causing the base station to perform the following operations: decode notification signaling received from a UE instructing the UE to perform cross-RAT NR-EUTRAN measurements without measurement gaps; encode configuration signaling to be transmitted to the UE to configure periodicity and minimum available time associated with EMWs that do not overlap with measurement gaps; and decode cross-RAT NR-EUTRAN measurement results received from the UE, the measurement results having a duration within the minimum available time.

[0214] In Example 11, based on the topic described in Example 10, the notification signaling is NeedForGapNCSG-InfoEUTRA signaling.

[0215] In Example 12, following the topics described in Examples 10 and 11, the configuration signaling indicates that the EMW is associated with one of the configuration IDs 0, 1, 2, 3, 4, or 5.

[0216] In Example 13, a computer-readable storage medium stores instructions that are executed by one or more processors of a UE to configure the UE to perform cross-RAT NR-EUTRAN measurements in 5G NR networks and more advanced networks, causing the UE to perform the following operations: encode notification signaling to be transmitted to a base station, the notification signaling instructing the UE to perform cross-RAT NR-EUTRAN measurements without measurement gaps; decode configuration signaling received from the base station to configure periodicity and minimum available time associated with an EMW that does not overlap with measurement gaps; and perform cross-RAT NR-EUTRAN measurements within the EMW, the measurements having a duration within the minimum available time.

[0217] In Example 14, based on the topic described in Example 13, the notification signaling is NeedForGapNCSG-InfoEUTRA signaling.

[0218] In Example 15, based on the topics described in Examples 13 and 14, the configuration signaling indicates that the EMW is associated with one of the configuration IDs 0, 1, 2, 3, 4, or 5.

[0219] In Example 16, based on the subject matter described in Examples 13 through 15, the configuration signaling indicates that the EMW is associated with one of the repetition periods of 40ms, 80ms, 40ms, 80ms, 40ms, and 80ms, which correspond to configuration IDs 0, 1, 2, 3, 4, and 5, respectively.

[0220] In Example 17, based on the topics described in Examples 13 through 16, the minimum available time of the EMW is associated with one of the periods of 60ms, 30ms, 60ms, 30ms, 60ms, and 30ms corresponding to configuration IDs 0, 1, 2, 3, 4, and 5, respectively.

[0221] In Example 18, based on the topics described in Examples 13 through 17, these operations also include: identifying new FDDs across RAT cells within a time period based on the minimum available time associated with the EMW.

[0222] In Example 19, based on the topics described in Examples 13 through 18, these operations also include: performing measurements on a new FDD across RAT cells within a measurement bandwidth comprising six resource blocks (RBs).

[0223] In Example 20, based on the subject matter described in Examples 13 through 19, these operations also include: identifying new FDD across RAT cells within a time period based on the discontinuous reception (DRX) cycle length used by the UE.

[0224] Example 21 is at least one machine-readable medium including instructions that, when executed by a processing circuitry system, cause the processing circuitry system to perform operations to implement any one of Examples 1 to 20.

[0225] Example 22 is an apparatus that includes means for implementing any one of Examples 1 to 20.

[0226] Example 23 is a system for implementing any one of Examples 1 through 20.

[0227] Example 24 is a method for implementing any one of Examples 1 through 20.

[0228] While one aspect has been described with reference to a specific exemplary aspect, it will be apparent that various modifications and alterations can be made to these aspects without departing from the broader scope of this disclosure. Therefore, this specification and accompanying drawings should be considered illustrative rather than restrictive. Consequently, the understanding of this detailed description should not be limited, and the scope of each aspect is defined only by the appended claims and all their equivalents.

Claims

1. An apparatus for a user equipment (UE) configured to operate in a Fifth Generation New Radio (5G NR) network, the apparatus comprising: processing circuitry, wherein the processing circuitry is to configure the UE to conduct cross radio access technology (cross-RAT) New Radio (NR)-Evolved Universal Terrestrial Radio Access Network (EUTRAN) measurements in the 5G NR network, the processing circuitry to: encode notification signaling to be transmitted to a base station, the notification signaling indicating a capability of the UE to perform a no measurement gap cross-RAT NR-EUTRAN measurement; decode configuration signaling received from the base station, the configuration signaling to configure a periodicity and a minimum available time associated with an effective measurement window (EMW), the EMW not overlapping with the measurement gap; and perform a cross-RAT NR-EUTRAN measurement within the EMW, the cross-RAT NR-EUTRAN measurement having a duration within the minimum available time; and a memory coupled to the processing circuitry and configured to store the configuration signaling.

2. The apparatus of claim 1, wherein the notification signaling is a NeedForGapNCSG-InfoEUTRA signaling.

3. The apparatus of claim 1, wherein the configuration signaling indicates that the EMW is associated with one of configuration IDs 0, 1, 2, 3, 4, or 5.

4. The apparatus of claim 3, wherein the configuration signaling indicates that the EMW is associated with one of a repetition period of 40 ms, 80 ms, 40 ms, 80 ms, 40 ms, and 80 ms, the repetition periods corresponding to the configuration IDs 0, 1, 2, 3, 4, and 5.

5. The apparatus of claim 3, wherein a minimum available time of the EMW is associated with one of a periodicity of 60 ms, 30 ms, 60 ms, 30 ms, 60 ms, and 30 ms corresponding to the configuration IDs 0, 1, 2, 3, 4, and 5.

6. The apparatus of claim 1, wherein the processing circuitry is to: identify a new frequency division duplex (FDD) cross-RAT cell within a time period based on the minimum available time associated with the EMW.

7. The apparatus of claim 6, wherein the processing circuitry is to: perform a measurement on the new FDD cross-RAT cell within a measurement bandwidth comprising six resource blocks (RBs).

8. The apparatus of claim 6, wherein the processing circuitry is to: identify the new FDD cross-RAT cell within a time period based on a discontinuous reception (DRX) cycle length used by the UE.

9. The apparatus of any one of claims 1 to 8, further comprising: transceiver circuitry coupled to the processing circuitry; and two or more antennas coupled to the transceiver circuitry. ​ ​ ​ 10. A computer-readable storage medium storing instructions for execution by one or more processors of a base station to configure the base station to perform cross radio access technology (cross-RAT) New Radio (NR)-Evolved Universal Terrestrial Radio Access Network (EUTRAN) measurements in a Fifth Generation New Radio (5G NR) network and a more advanced network and to cause the base station to: decode notification signaling received from a user equipment (UE), the notification signaling indicating a capability of the UE to perform a no measurement gap cross-RAT NR-EUTRAN measurement; encode configuration signaling to be transmitted to the UE, the configuration signaling to configure a periodicity and a minimum available time associated with an effective measurement window (EMW) that does not overlap with the measurement gap; and decode a cross-RAT NR-EUTRAN measurement result received from the UE, the cross-RAT NR-EUTRAN measurement result having a duration within the minimum available time.

11. The computer-readable storage medium of claim 10, wherein the notification signaling is NeedForGapNCSG-InfoEUTRA signaling.

12. The computer-readable storage medium of claim 10, wherein the configuration signaling indicates that the EMW is associated with one of configuration IDs 0, 1, 2, 3, 4, or 5.

13. A computer-readable storage medium storing instructions for execution by one or more processors of a user equipment (UE) to configure the UE to perform cross radio access technology (cross-RAT) New Radio (NR)-Evolved Universal Terrestrial Radio Access Network (EUTRAN) measurements in a Fifth Generation New Radio (5G NR) network and a more advanced network and to cause the UE to: encode notification signaling to be transmitted to a base station, the notification signaling indicating a capability of the UE to perform a no measurement gap cross-RAT NR-EUTRAN measurement; decode configuration signaling received from the base station, the configuration signaling to configure a periodicity and a minimum available time associated with an effective measurement window (EMW) that does not overlap with the measurement gap; and perform a cross-RAT NR-EUTRAN measurement within the EMW, the cross-RAT NR-EUTRAN measurement having a duration within the minimum available time.

14. The computer-readable storage medium of claim 13, wherein the notification signaling is NeedForGapNCSG-InfoEUTRA signaling.

15. The computer-readable storage medium of claim 13, wherein the configuration signaling indicates that the EMW is associated with one of configuration IDs 0, 1, 2, 3, 4, or 5. ​ ​ ​ ​ ​ ​ ​ 16. The computer-readable storage medium of claim 15, wherein the configuration signaling indicates that the EMW is associated with one of a repetition period of 40ms, 80ms, 40ms, 80ms, 40ms, and 80ms, the repetition period corresponding to the configuration IDs 0, 1, 2, 3, 4, and 5.

17. The computer-readable storage medium of claim 15, wherein the minimum available time of the EMW is associated with one of the periods of 60ms, 30ms, 60ms, 30ms, 60ms, and 30ms corresponding to the configuration IDs 0, 1, 2, 3, 4, and 5.

18. The computer-readable storage medium of claim 13, wherein the operation comprises: New Frequency Division Duplex (FDD) cross-RAT cells are identified within a time period based on the minimum available time associated with the EMW.

19. The computer-readable storage medium of claim 18, wherein the operation comprises: Measurements are performed across RAT cells for the new FDD within a measurement bandwidth comprising six resource blocks (RBs).

20. The computer-readable storage medium of claim 18, wherein the operation comprises: The new FDD across RAT cells is identified within a time period based on the discontinuous reception (DRX) cycle length used by the UE.

Images