Maximum reception timing difference for multi-panel reception

Abstract

Apparatus, methods, and computer-readable media for user equipment (UE) in a 5G nu-radio (NR) network are disclosed. The UE encodes an announcement signaling indicating its ability to support simultaneous reception of two downlink (DL) signals, decodes a configuration signaling for bidirectional high-speed deployment, and decodes two DL signals received simultaneously during deployment. The reception timing difference between subframe boundaries of the DL signals is within a preset maximum range. The configuration signaling includes a high-speed deployment type and a field for measurement in frequency range 2 (FR2). The UE may be a power class 6 (PC6) device that supports simultaneous reception in FR2-1. Multiple reception channels enable simultaneous signal reception. The corresponding base station decodes the UE's announcement signaling and encodes the configuration and DL signals for transmission to the UE.

Description

Background Art

[0001] Mobile communication has evolved greatly from the early voice systems to today's highly sophisticated integrated communication platforms. Due to the increase in the number of various types of devices that communicate with various network devices, the usage of 3GPP LTE systems is increasing. With the popularity of mobile devices (user equipment or UE) in modern society, the demand for various network devices in many diverse environments is on the rise. The fifth generation (5G) wireless system is expected to debut soon, offering even higher speeds, better connectivity, and improved usability. Next-generation 5G networks (or NR systems) and beyond (e.g., 6G networks) are expected to enhance throughput, coverage, and robustness while reducing latency, operating costs, and capital expenditures. 5G NR (and beyond) networks continue to evolve based on 3GPP LTE-Advanced, with potential new radio access technologies (RATs) added to enrich people's lives with seamless wireless connection solutions and provide high-speed and abundant content and services. Since the current cellular network frequencies are in a saturated state, higher frequencies such as millimeter wave (mmWave) frequencies may be advantageous due to their high bandwidth.

[0002] Further operation enhancements of LTE systems and NR systems in licensed and unlicensed spectrums are expected in future releases of communication systems after 5G. Such operation enhancements include technologies for setting the maximum reception timing difference (MRTD) for multi-panel reception of user equipment (UE).

[0003] The figures are not necessarily drawn to scale, and the same numbers may indicate similar components in different figures. The same numbers with different letter suffixes may represent different instances of similar components. The figures schematically illustrate, by way of example, various aspects described in this specification and are not limiting.

Brief Description of the Drawings

[0004] [Figure 1A] The network architecture can be described according to several aspects. [Figure 1B] This represents a non-roaming 5G system architecture according to several aspects. [Figure 1C] This represents a non-roaming 5G system architecture according to several aspects. [Figure 2] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 3] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 4] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 5] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 6] This document illustrates an example of an artificial intelligence (AI)-assisted communication architecture for communication between the UE and RAN, according to several aspects. [Figure 7] An example of a RAN partitioning architecture is presented according to several aspects. [Figure 8] The diagram shows a block diagram of communication devices such as evolved node B (eNB), next-generation node B (gNB) (or other RAN nodes), NCR, access point (AP), radio station (STA), mobile station (MS), or user equipment (UE), according to several aspects. [Modes for carrying out the invention]

[0005] The following description and drawings adequately illustrate the aspects to the extent that a person skilled in the art can carry them out. Other aspects may incorporate structural, logical, electrical, process, and other modifications. Parts and features of some aspects may be included in or superseded by those of other aspects. The aspects described in the claims encompass all available equivalents of the claims.

[0006] Figures 1A to 8 represent various systems, devices, and components that may implement aspects of the disclosed embodiments in different communication systems, such as LTE (EUTRA) networks and 5G-NR (and later) networks. The UEs, base stations (e.g., gNBs), and / or other nodes (e.g., satellite or other computing nodes) discussed herein may be configured to perform the disclosed technologies.

[0007] Figure 1A shows a network architecture that follows several aspects. A communication network 140A is shown, which includes user equipment (UE) 101 and UE102. UE101 and UE102 are represented 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 devices such as personal digital assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, drones, or any other computing devices including wired and / or wireless communication interfaces. UE101 and UE102 may be collectively referred to as UE101, which may be used to perform one or more of the technologies disclosed herein.

[0008] Any of the wireless links described herein (for example, used in communication network 140A or any other described network) may operate in accordance with exemplary wireless communication technologies and / or standards.

[0009] 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, carrier aggregation is a technique in which multiple carrier signals operating on different frequencies are used to carry communications for a single UE, thereby increasing the bandwidth applicable to a single device. In some aspects, carrier aggregation can be used when one or more component carriers operate on unlicensed frequencies.

[0010] The aspects described herein may be used with respect to any spectrum management method, including, for example, dedicated licensed spectra, unlicensed spectra, and (licensed) shared spectra (e.g., Licensed Shared Access (LSA) at 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz, and higher frequencies, and Spectrum Access Systems (SAS) at 3.55–3.7 GHz and higher frequencies).

[0011] The aspects described herein can be applied to different Single Carrier or OFDM flavors (CP-OFDM, SC-FDMA, SC-OFDM, Filter Bank-Based Multicarrier (FBMC), OFDMA, etc.) and especially to 3GPP NR (New Radio) by assigning OFDM carrier data bit vectors to corresponding symbolic resources.

[0012] In some respects, both UE101 and UE102 may include Internet of Things (IoT) UEs or Cellular IoT (CIoT) UEs and may include a network access layer designed for low-power IoT applications that utilize short-term UE connectivity. In some respects, both UE101 and UE102 may include Narrowband (NB) IoT UEs (e.g., Enhanced NB-IoT (eNB-IoT) UEs and Further Enhanced (Fe-NB-IoT) UEs). IoT UEs may utilize technologies such as Public Land Mobile Networks (PLMNs), Proximity-Based Services (ProSe) or Device-to-Device (D2D) communications, sensor networks, or Machine-to-Machine (M2M) or Machine-Type Communications (MTC) to exchange data with MTC servers or devices over the IoT network. M2M or MTC data exchange may be machine-initiated data exchange. The IoT network may include interconnecting IoT UEs and may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connectivity. IoT UE can run background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity within IoT networks.

[0013] Both UE101 and UE102 may include an Enhanced MTC (eMTC) UE or a Further Enhanced MTC (FeMTC) UE.

[0014] UE101 and UE102 may be configured to connect to a radio access network (RAN) 110, for example, to be communicatively coupled. RAN 110 may be, for example, a Universal Mobile Telecommunications System (UMTS), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or other types of RAN. UE101 and UE102 utilize connections 103 and 104, respectively. Each connection includes a physical communication interface or layer (discussed in more detail below), and in this example, connections 103 and 104 are represented as air interfaces enabling communication coupling, and may conform to cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, PTT over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long-Term Evolution (LTE) protocol, 5th generation (5G) protocol, and New Radio (NR) protocol.

[0015] In some respects, UE101 and UE102 may further exchange direct communication via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink interface, which includes, but is not limited to, one or more logical channels, including a physical sidelink control channel (PSCCH), a physical sidelink sharing channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).

[0016] UE102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 can include a local radio connection, such as any IEEE 802.11 protocol-compliant connection, which may include a Wireless Fidelity (Wi-Fi®) router in AP106. In this example, AP106 is shown to connect to the internet without connecting to the core network of the radio system (described in more detail below).

[0017] RAN110 may include one or more access nodes that enable connections 103 and 104. These access nodes (ANs) may be called base stations (BS), node B, evolved node B (eNB), next-generation node B (gNB), RAN network nodes, etc., and may include ground stations (e.g., ground 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 transmit / receive points (TRPs). In cases where communication nodes 111 and 112 are node B (e.g., eNB or gNB), one or more TRPs may function within the communication cell of node B. RAN110 may include one or more RAN nodes that provide macrocells, e.g., macroRAN nodes, and one or more RAN nodes that provide femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low-power (LP) RAN nodes or unlicensed spectrum-based secondary RAN nodes.

[0018] Either communication node 111 or 112 can terminate the air interface protocol and be the first point of contact for UE101 and UE102. In some respects, either communication node 111 or 112 can fulfill 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 data packet scheduling, and mobility management. For example, 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.

[0019] RAN110 is shown to be communicably coupled to the core network (CN) 120 via the S1 interface 113. In some aspects, CN120 may be an Evolved Packet Core (EPC) network, a Next Generation Packet Core (NPC) network, or other types of CN (e.g., shown in Figures 1B and 1C). In this aspect, the S1 interface 113 is divided into two parts: the S1-U interface 114, which carries user traffic data between communication nodes 111 and 112 and the Serving Gateway (S-GW) 122, and the S1 Mobility Management Entity (MME) interface 115, which is a signaling interface between communication nodes 111 and 112 and the MME 121.

[0020] On this side, CN120 includes MME121, S-GW122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME121 may have a control plane and functions similar to those of a conventional Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME121 may manage aspects of mobility in access, such as gateway selection and tracking area list management. HSS124 may include a database for network users, containing subscription-related information to support the processing of communication sessions by network entities. CN120 may include one or more HSS124 depending on the number of mobile subscribers, device capacity, network architecture, etc. For example, HSS124 can support routing / roaming, authentication, authorization, naming / addressing resolution, location dependency, etc.

[0021] S-GW122 can terminate the S1 interface 113 towards RAN110 and route data packets between RAN110 and CN120. Further, S-GW122 can serve as a local mobility anchor point for handovers between RAN nodes and also provide an anchor for inter-3GPP mobility. Other roles of S-GW122 include lawful interception, charging, and some policy application.

[0022] The P-GW123 may terminate its SGi interface toward the PDN. The P-GW123 may route data packets between the EPC network (e.g., CN120) and external networks, such as the network containing the application server 184 (alternatively referred to as the Application Function (AF)), via the Internet Protocol (IP) interface 125. The P-GW123 may also communicate data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Generally, the application server 184 can be an element providing applications that use IP bearer resources in the core network (e.g., UMTS Packet Service (PS) domains, LTE PS data services, etc.). In this aspect, the P-GW123 is shown to be communicably coupled to the application server 184 via the IP interface 125. The application server 184 can also be configured to support one or more communication services for UE101 and UE102 via CN120 (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.).

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

[0024] In some aspects, the communication network 140A can be an IoT network or a 5G network that uses communication in licensed (5G NR) spectrum and unlicensed (5G NR-U) spectrum. One of the current IoT enablers is Narrowband IoT (NB-IoT).

[0025] The NG system architecture can include the RAN 110 and a 5G core network (e.g., CN 120). The RAN 110 in the NG system can be referred to as NG-RAN. The RAN 110 can include multiple nodes such as gNBs and NG-eNBs. The CN 120 (also referred to as the 5G core network or 5GC) can include an Access and Mobility Management Function (AMF) and / or a User Plane Function (UPF). The AMF and UPF can be communicatively coupled to the gNB and NG-eNB via the NG interface. More specifically, in some aspects, the gNB and NG-eNB can be connected to the AMF via the NG-C interface and to the UPF via the NG-U interface. The gNB and NG-eNB can be connected to each other via the Xn interface.

[0026] In some respects, the NG system architecture can utilize various internode reference points, as provided by the 3GPP Technical Specification (TS) 23.501 (e.g., V15.4.0, 2018-12). In some respects, gNB and NG-eNB can be implemented as base stations, mobile edge servers, small cells, home eNBs, RAN network nodes, etc. In some respects, a gNB can be a master node (MN), and an NG-eNB can be a secondary node (SN) in a 5G architecture. In some respects, the master / primary node can operate in licensed bandwidth, and the secondary node can operate in unlicensed bandwidth.

[0027] Figure 1B represents a non-roaming 5G system architecture that follows several aspects. Referring to Figure 1B, the 5G system architecture is represented in a reference point representation. More specifically, UE101 can communicate with one or more other 5G core (5GC) network entities in addition to RAN110. The 5G system architecture 140B includes several network functions (NFs), such as Access and Mobility Management Function (AMF) 132, Location Management Function (LMF) 133, Session Management Function (SMF) 136, Policy Control Function (PCF) 148, Application Function (AF) 150, User Plane Function (UPF) 134, Network Slice Selection Function (NSSF) 142, Authentication Server Function (AUSF) 144, and Integrated Data Management (UDM) / Home Subscriber Server (HSS) 146. The UPF 134 can provide connectivity to a data network (DN) 152, which may include, for example, operator services, internet access, or third-party services. AMF132 may be used to manage access control and mobility, and may also include network slice selection functionality. SMF136 may be configured to set up and manage various sessions according to network policies. UPF134 may be deployed in one or more configurations according to desired service types. PCF148 may be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM146 may be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0028] The LMF133 can be used in combination with 5G positioning capabilities. In some aspects, the LMF133 receives measurement and support information from the RAN110 and a mobile device (e.g., UE101) via the NL interface through the AMF132 to calculate the position of the UE101. In some aspects, the NR Positioning Protocol A (NRPPa) can be used to carry positioning information between the NG-RAN and the LMF133 via the Next Generation Control Plane Interface (NG-C). In some aspects, the LMF133 configures the UE using the LTE Positioning Protocol (LPP) via the AMF132. The RAN110 configures the UE101 using the Radio Resource Control (RRC) protocol via the LTE-Uu interface and the NR-Uu interface.

[0029] In several aspects, the 5G system architecture 140B configures various reference signals to enable positioning measurements. Examples of reference signals that may be used for positioning measurements include the downlink positioning reference signal (NR PRS) and the uplink sounding reference signal (SRS) for positioning. The downlink positioning reference signal (PRS) is a reference signal configured to support downlink-based positioning methods.

[0030] In several respects, the 5G system architecture 140B, along with the IP Multimedia Subsystem (IMS) 168B, includes multiple IP multimedia core network subsystem entities, such as Call Session Control Functions (CSCFs). More specifically, the IMS 168B includes CSCFs that can operate as a proxy CSCF (P-CSCF) 162B, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not shown in Figure 1B), or an interrogating CSCF (I-CSCF) 166B. The P-CSCF 162B may be configured to be the first point of contact for the UE 102 within the IMS 168B. The S-CSCF 164B may be configured to handle session state within the network, and the E-CSCF may be configured to handle specific aspects of an emergency session, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF166B may be configured to act as a point of contact within the operator's network for all IMS connections destined for the network operator's subscribers or roaming subscribers currently located within the network operator's service area. In some aspects, the I-CSCF166B may connect to other IP multimedia networks 170, for example, IMS operated by another network operator.

[0031] In some respects, the UDM / HSS146 can be coupled to an application server (AS) 160B, which may include a telephony application server (TAS) or other ASs. The AS160B can be coupled to the IMS168B via the S-CSCF164B or I-CSCF166B.

[0032] The reference point representation indicates that interactions can exist between corresponding NF services. For example, Figure 1B shows N1 (between UE102 and AMF132), N2 (between RAN110 and AMF132), N3 (between RAN110 and UPF134), N4 (between SMF136 and UPF134), N5 (between PCF148 and AF150) (not shown), N6 (between UPF134 and DN152), N7 (between SMF136 and PCF148), N8 (between UDM / HSS146 and AMF132), N9 (between two UPFs (not shown)), N10 (between UDM / HSS146 and SMF136), N11 (AM The following reference points are represented: N12 (between F132 and SMF136), N13 (between AUSF144 and AMF132), N14 (between two AMFs (not shown)), N15 (between PCF148 and AMF132 in a non-roaming scenario, or between PCF148, the visited network, and AMF132 in a roaming scenario (not shown)), N16 (between two SMFs (not shown)), and N22 (between AMF132 and NSSF142). Other reference point representations not shown in Figure 1B can also be used.

[0033] Figure 1C represents a 5G system architecture 140C and a service-based representation. In addition to the network entities shown in Figure 1B, the 5G system architecture 140C may also include a network exposure function (NEF) 154 and a network repository function (NRF) 156. In some respects, the 5G system architecture can be service-based, and interactions between network functions can be represented by corresponding point-to-point reference points Ni or as service-based interfaces.

[0034] In some respects, as shown in Figure 1C, service-based representations can be used to represent network functions within the control plane that allow other authorized network functions to access services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf158H (service-based interface represented by AMF132), Nsmf158I (service-based interface represented by SMF136), Nnef158B (service-based interface represented by NEF154), Npcf158D (service-based interface represented by PCF148), Nudm158E (service-based interface represented by UDM / HSS146), Naf158F (service-based interface represented by AF150), Nnrf158C (service-based interface represented by NRF156), Nnssf158A (service-based interface represented by NSSF142), and Nausf158G (service-based interface represented by AUSF144). Other service-based interfaces not shown in Figure 1C (e.g., Nudr, N5g-eir, and Nudsf) can also be used.

[0035] Figure 2 shows an example network architecture 200. Network architecture 200 can operate in accordance with the 3GPP Technical Specifications for LTE or 5G / NR systems and can implement the disclosed technologies (for example, the disclosed technologies may be comprised / implemented by one or more devices operating within network architecture 200). However, the example embodiments are not limited in this respect, and the examples described may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems.

[0036] Network architecture 200 includes UE202, which is any mobile or non-mobile computing device designed to communicate with RAN204 via an over-the-air connection. UE202 is coupled to RAN204 via a Uu interface, which may be applicable to both LTE and NR systems. Examples of UE202 applications include smartphones, tablet computers, wearable devices (e.g., smartwatches, fitness trackers, smart glasses, smart clothing / fabrics, head-mounted displays, smart shoes, and / or similar), desktop computers, workstations, laptop computers, automotive infotainment systems, automotive entertainment systems, instrument panels, head-up display (HUD) devices, automotive 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, network appliances, machine-type communication devices, machine-to-machine (M2M), device-to-device (D2D), machine-type communication (MTC) devices, Internet of Things (IoT) devices, smart alliances, flying drones or unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, digital signage, and single-board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel). There are, but are not limited to, any type of computing device such as Edison, plug computers, and / or any of the others discussed herein.

[0037] Additionally, or alternatively, UE202 can be a reduced capability (RedCap) UE, which is a UE with reduced capabilities as defined in section 4.2.21.1 of 3GPP TS 38.306 v17.4.0(2023-03-30) ("TS38306").

[0038] The network architecture 200 may include a set of UE202 directly coupled to one another via D2D, ProSe, PC5, and / or SL interfaces, and / or any other suitable interfaces as discussed herein. These UE202 may be M2M / D2D / MTC / IoT devices and / or vehicle systems communicating using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc. The UE202 may perform blind decoding trials of the SL channel / link according to the various examples of this application.

[0039] In some cases, the UE202 may also communicate with the AP206 via an Over-the-Air (OTA) connection. The AP206 manages a WLAN connection that can function to offload some / all network traffic from the RAN204. The connection between the UE202 and the AP206 may follow any IEEE 802.11 protocol. Furthermore, the UE202, RAN204, and AP206 may utilize cellular WLAN aggregation / integration (e.g., LWA / LWIP). In cellular WLAN aggregation, the UE202 may be configured to utilize both cellular radio resources and WLAN resources through the RAN204.

[0040] RAN204 includes one or more access network nodes (ANs)208. The ANs208 terminate the radio interface of UE202 by providing access to hierarchical protocols including RRC, PDCP, RLC, MAC, and PHY / L1 protocols. In this way, the ANs208 enable data / voice connectivity between CN220 and UE202. The ANs208 may be macrocell base stations or low-power base stations providing femtocells, picocells, or other similar cells with smaller coverage areas, lower user capacity, and higher bandwidth compared to macrocells, or any combination thereof. In such implementations, the ANs208 may be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, etc.

[0041] One exemplary implementation is a “CU / DU split” architecture in which AN208 is embedded as a gNB central unit (CU) that can communicate with one or more gNB distributed units (DUs), and each DU can communicate with one or more radio units (RUs) (also known as RRHs, RRUs, etc.) (see, for example, [TS38401]). In some implementations, one or more RUs may be individual RSUs. In some implementations, the CU / DU split may include an ng-eNB-CU and one or more ng-eNB-DUs instead of, or in addition to, gNB-CUs and gNB-DUs. AN208 used as a CU may be implemented as a separate device, or as one or more software entities running on a server computer as part of a virtual network including, for example, a virtual baseband unit (BBU) or BBU pool, a cloud RAN (CRAN), a radio equipment controller (REC), a radio cloud center (RCC), a centralized RAN (C-RAN), or a virtualized RAN (vRAN) (however, these terms may refer to different implementation concepts). Any other type of architecture, deployment, and / or configuration can also be used.

[0042] A pair of ANs can be coupled to each other via an X2 interface (if RAN204 is an LTE RAN or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 210) or an Xn interface (if RAN204 is an NG-RAN 214). The X2 / Xn interface may be split into a control / user plane interface in some examples, which may allow ANs to communicate information regarding handover, data / context transfer, mobility / load management, interference coordination, etc.

[0043] Each AN of RAN204 can manage one or more cells, cell groups, component carriers, etc., and provide an air interface for network access to UE202. UE202 can be connected simultaneously to sets of cells provided by the same or different AN208s of RAN204. For example, UE202 and RAN204 can use carrier aggregation to enable UE202 to connect to sets of component carriers corresponding to Pcells or Scells, respectively. In a dual-connection scenario, the first AN208 may be a master node providing an MCG, and the second AN208 may be a secondary node providing an SCG. The first / second AN208s may be any combination of eNBs, gNBs, NG-eNBs, etc.

[0044] RAN204 may provide an air interface via the licensed spectrum or the unlicensed spectrum. To operate in the unlicensed spectrum, a node may use LAW, eLAA, and / or feLAA mechanisms based on CA technology with PCell / Scell. Before accessing the unlicensed spectrum, a node may perform medium / carrier sensing operations based, for example, on the Listen Before Talk (LBT) protocol.

[0045] Additionally, or alternatively, each UE202 supplies radio information to one or more AN208s and / or one or more edge computer nodes (e.g., edge servers / hosts). The radio information may take the form of one or more measurement reports, which may include, for example, intensity measurements, signal quality measurements, etc. Each measurement report is tagged with the location of the measurement (e.g., the current location of the UE202) and a timestamp.For example, measurements collected by and / or included in measurement reports by the UE202 include bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), number of interrupts, out-of-order delivery of data packets, transmission power, bit error rate, 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 + noise + distortion vs. noise + distortion (SINAD) ratio, carrier vs. interference and noise ratio (CINR), adduable white Gaussian noise (AWGN), and energy-to-noise density ratio per bit (Eb / N0). ), Energy vs. Interference Density Ratio per Chip (Ec / I0), Energy vs. Noise Density Ratio per Chip (Ec / N0), Peak vs. Average Power Cost (PAPR), Reference Signal Received Power (RSRP), Reference Signal Received Path Power (RSRPP), Reference Signal Received Quality (RSRQ), Received Signal Strength Indicator (RSSI), Received Channel Power Indicator (RCPI), Received Signal vs. 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), SSB_RP (Measured at the UE antenna connector or radiated interface boundary, NR Sidelink Synchronized Signal Block (S-SSB) measurements including the received (linear) average power of the resource elements carrying the SSB signal and channel, relative time difference (RTD), receiver (Rx) time delay, Rx timing error, transmitter (Tx) time delay, Tx timing error, NR E-CID, observation arrival time difference (OTDOA), mean noise and interference (ANPI), GNSS timing of cell frames for UE positioning of E-UTRAN or 5G-NR (e.g., timing between AP or RAN node reference time and GNSS intrinsic 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 GNN satellite signal), GNSS carrier phase measurements (e.g., the number (integer and fractional parts) of the carrier phase period of the i-th GNSS satellite signal measured after locking onto the signal, also known as cumulative delta range (ADR)).), may include one or more of the following: channel interference measurement, thermal noise power measurement, received interference power measurement, power histogram measurement, channel load measurement, STA statistics, and / or other similar measurements. RSRP, RSSI, and RSRQ measurements may include RSRP, RSSI, and / or RSRQ measurements of cell-specific reference signals, channel status information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks for 3GPP networks (e.g., LTE or 5G / NR), and RSRP, RSSI, RSRQ, RCPI, RSNI, and / or ANPI measurements of various beacons, bound initial link setup (FILS) discovery frames, or probe response frames for WLAN / WiFi (e.g., [IEEE802.11]) networks. Other measurements may be used additionally or alternatively, 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 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 Std 802.11-2020, pp.1-4379 (26 Feb. 2021)("[IEEE80211]"). Additionally, or alternatively, any of the aforementioned measurements (or combinations of measurements) may be collected by one or more AN208s and supplied to the edge computer node.

[0046] Additionally, or alternatively, the measurements may include measurements related to data radio bearers (DRBs) (e.g., the number of DRBs attempted to be set up, the number of DRBs successfully set up, the number of active DRBs released, the activity time of a DRB session, the number of DRBs attempted to be resumed, the number of DRBs successfully resumed, etc.), and radio resource control (RRC). Measurements related to (e.g., average number of RRC connections, maximum number of RRC connections, average number of saved inactive RRC connections, maximum number of saved inactive RRC connections, number of attempted, successful, and / or failed RRC connection establishments, etc.), measurements related to UE context (UECNTX), and measurements related to radio resource utilization (RRU) (e.g., total DL PRB usage, total UL PRB usage, distribution of total DL PRB usage, distribution of total UL PRB usage, DL PRB used for data traffic, UL PRB used for data traffic) Measurements related to Registration Management (RM), Session Management (SM) (e.g., number of PDU sessions requested for setup, number of PDU sessions successfully set up, number of PDU sessions that failed to set up, etc.), GTP Management (GTP), IP Management (IP), Policy Association (PA), Mobility Management (MM) (e.g., for InterRAT, IntraRAT, and / or Intra / Interfrequency Handover and / or Conditional Handover, the number of requested, successful, and / or failed handover preparations, the number of requested, successful, and / or failed handover resource allocations, the number of requested, successful, and / or failed handover Measurements include: number of 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 virtualized resources (VR); measurements related to carriers (CARR); measurements related to QoS flows (QF) (e.g., number of active QoS flows released, number of QoS flows attempted to release, activity time of QoS flows in a session, activity time of UE202 in a session, number of QoS flows attempted to set up, number of QoS flows successfully established, number of QoS flows that failed to set up, number of initial QoS flows attempted to set up, number of initial QoS flows successfully established, number of initial QoS flows that failed to set up, number of QoS flows attempted to change, number of QoS flows that were successfully changed, number of QoS flows that failed to change, etc.).Measurements related to Application Triggering (AT), Short Message Service (SMS), Power, Energy, and Environment (PEE), NF Services (NFS), Packet Flow Description (PFD), Random Access Channel (RACH), Measurement Reporting (MR), Layer 1 Measurement (L1M), Network Slice Selection (NSS), Paging (PAG), Non-IP Data Delivery (NIDD), External Parameter Provisioning (EPP), Traffic Influence (TI), Connectivity Establishment (CE), Service Parameter Provisioning (SPP), Background Data Transfer Policy (BDTP), Data Management (DM), and / or 3GPP TS 28.552 v17.3.1(202-06-24)("[TS28552]"), 3GPP TS 32.425 This may include one or more of the other performance measurements discussed in v17.1.0(202-06-24)("[TS32425]"), etc.

[0047] Wireless information may be reported in response to trigger events and / or periodically. Additionally or alternatively, individual UE202s may report wireless information with low or high periodicity depending on the data transfer to be performed and / or other information relating to the data transfer. Additionally or alternatively, edge computer nodes may request measurements from AN208 with low or high periodicity, or AN208 may provide measurements to edge computer nodes with low or high periodicity. Additionally or alternatively, edge computer nodes may obtain other relevant data, such as key performance indicators (KPIs), from other edge computer nodes, core network functions (NFs), application functions (AFs), and / or other UE202s, either together with or separately from measurement reports.

[0048] Additionally, or alternatively, if there are discrepancies in observed data from one or more UEs, one or more RAN nodes, and / or core network NFs (e.g., missing reports, data errors, etc.), simple imputation may be performed to supplement the obtained observed data, such as substituting values ​​from previous reports and / or historical data or applying extrapolation filters. Additionally, or alternatively, acceptable ranges for observed data may be predetermined or set. For example, CQI and MCS measurements may be set to fall only within ranges defined by the appropriate 3GPP standards. If reported data values ​​do not make sense (e.g., values ​​exceed the acceptable range), such values ​​may be discarded in the current learning / training episode or epoch. For example, a delay range may be defined or set during packet delivery, and packets that are determined to have been received after the packet delivery delay range may be discarded.

[0049] The UE202 can also perform reference signal (RS) measurement and reporting procedures to provide the network with information regarding the quality of one or more radio channels and / or the communication medium as a whole, and this information can be used to optimize various aspects of the communication system. For example, the measurement and reporting procedures performed by UE202 include 3GPP TS 38.211 v17.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 TS 38.214 V17.4.0(2023-01-04)("[TS38214]"), [TS36215], 3GPP TS 38.101-1 V18.0.0(2023-01-12)("[TS38.101-1]"), 3GPP This may include what is described in TS 38.104 V18.0.0(2023-01-10)("[TS38104]"), 3GPP TS 38.133 V18.0.0(2023-01-12)("[TS38133]"), [TS38331], etc. Physical signals and / or Rscan include demodulation reference signals (DM-RS), phase tracking reference signals (PT-RS), positioning reference signals (PRS), channel status information reference signals (CSI-RS), synchronization signal blocks (SSB), primary synchronization signals (PSS), secondary synchronization signals (SSS), and sounding reference signals (SRS).

[0050] In any of the examples described herein, any suitable data acquisition and / or measurement mechanism may be used to acquire observational data. For example, data marking (e.g., sequence numbering), packet tracing, signal measurement, data sampling, and / or time stamping techniques may be used to determine any of the aforementioned metrics / observations. Data acquisition may be based on the occurrence of an event that triggers data acquisition. Additionally or alternatively, data acquisition may occur at the start or end of an event. Data acquisition may be continuous, intermittent, and / or have start and end times. Data acquisition techniques / mechanisms may be specific to hardware configurations / implementations or non-hardware configurations, or may be based on various software parameters (e.g., OS type and version, etc.). Various configurations may be used to define any of the aforementioned data acquisition parameters. Such configurations may 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., MAMS [RFC8743]), IEEE / WiFi (e.g., [IEEE80211], [WiMAX], [IEEE16090], etc.), and / or other standards such as those described herein.

[0051] In a V2X scenario, UE202 or AN208 may be or act as a Roadside Unit (RSU), which may refer to any transport infrastructure entity used for V2X communication. The RSU may be implemented in or by a suitable AN or fixed (or relatively fixed) UE. An RSU implemented in or by a UE may be called a “UE-type RSU,” an “eNB-type RSU” in an eNB, and a “gNB-type RSU” in a gNB. For example, an RSU is a computing device installed along a road and coupled with radio frequency circuitry to provide connectivity support to passing vehicle UEs. The RSU may also include applications / software for sensing and controlling oncoming vehicle and pedestrian traffic, along with internal data storage circuitry for storing intersection map geometry, traffic statistics, and media. The RSU may provide very low-latency communication required for high-speed events such as collision avoidance and traffic warnings. Additionally or alternatively, the RSU may provide other cellular / WLAN communication services. The RSU components may be packaged in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller for providing wired connectivity (e.g., Ethernet®) to a traffic signal controller or backhaul network. Furthermore, one or more V2X RATs may be employed, allowing V2X nodes to communicate directly with each other, with infrastructure equipment (e.g., AN208) and / or other devices / nodes. In some implementations, at least two different V2X RATs may be used, including a WLAN V2X (W-V2X) RAT based on IEEE V2X technology (e.g., US DSRC or European ITS-G5) and a cellular V2X (C-V2X) RAT based on 3GPP V2X technology (e.g., LTE V2X, 5G / NR V2X, etc.). For example, a C-V2X RAT may utilize a C-V2X air interface, and a WLAN V2X RAT may utilize a W-V2X air interface.

[0052] W-V2X RAT includes, for example, IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture, IEEE Standards Association, IEEE 1609.0-2019 (April 10, 2019) ("[IEEE16090]"), V2X Communications Message Set Dictionary, SAE Int'l (July 23, 2020) ("[J2735_202007]"), Intelligent Transport Systems in the 5GHz frequency band (ITS-G5), [IEEE80211p] (which includes WAVE, DSRC, and the Layer 1 (L1) and Layer 2 (L2) portions of ITS-G5), and / or IEEE Standard for Air Interface for Broadband Wireless Access Systems, IEEE Std 802.16-2017, pp.1-2726 (March 2, 2018) ("[WiMAX]"). The term "DSRC" refers to vehicle communications in the 5.9 GHz frequency band commonly used in the United States, while "ITS-G5" refers to vehicle communications in the 5.9 GHz frequency band in Europe. Because any number of different RATs that may be used in any geographic or political region are applicable (including [IEEE80211p]RATs), the terms "DSRC" (particularly used in the United States) and "ITS-G5" (particularly used in Europe) may be used synonymously throughout this disclosure. The access layer for the ITS-G5 interface is outlined in ETSI EN 302 663 V1.3.1 (2020-01) (hereinafter "[EN302663]"), which describes the access layer of the ITS-S reference architecture. The ITS-G5 access layer incorporates features of the distributed congestion control (DCC) method described in ETSI TS 102 687 V1.2.1(2018-04) ("TS102687").The access layer for interfaces based on 3GPP LTE-V2X is outlined in, in particular, ETSI EN 303 613 V1.1.1 (2020-01) and 3GPP TS 23.285 v16.2.0 (2019-12), while 3GPP 5G / NR-V2X is outlined in, in particular, 3GPP TR 23.786 v16.1.0 (2019-06) and 3GPP TS 23.287 v18.0.0 (2023-03-31) ("[TS23287]").

[0053] In an example where RAN204 is an E-UTRAN210 containing one or more eNB212s, the E-UTRAN210 provides an LTE air interface (Uu) with parameters and characteristics described in at least 3GPP TS 36.300 v17.2.0(2022-09-30) ("[TS36300]"). In an example where RAN204 is a next-generation (NG)-RAN214 containing a set of gNG216s, each gNB216 connects to a 5G-enabled UE202 using a 5G-NR air interface (sometimes called a Uu interface) with parameters and characteristics described in [TS38300] among several 3GPP standards. If NG-RAN214 contains a set of ng-eNB218s, one or more ng-eNB218s connect to the UE202 via a 5G Uu interface and / or an LTE-Uu interface. The gNB216 and ng-eNB218 connect to the 5GC240 via their respective NG interfaces, which include the N2 interface, the N3 interface, and / or other interfaces. The gNB216 and ng-eNB218 are connected via the Xn interface. Furthermore, each gNB216 is connected via its respective Xn interface, and each ng-eNB218 is connected via its respective Xn interface. In some examples, the NG interface can be divided into two parts: the NG user plane (NG-U) interface (e.g., the N3 interface) which carries traffic data between the nodes of the NG-RAN214 and UPF248, and the NG control plane (NG-C) (e.g., the N2 interface) which is the signaling interface between the nodes of the NG-RAN214 and AMF244.

[0054] NG-RAN214 can provide a 5G-NR air interface (sometimes called a Uu interface) with characteristics such as variable SCS, CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL, polar codes, repeating codes, single codes, and Reed-Müller codes for control, and LDPC for data. The 5G-NR air interface may depend on CSI-RS and PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface does not have to use CRS, but may use PBCH DMRS for PBCH demodulation, PTRS for PDSCH phase tracking, and a tracking reference signal for time tracking. The 5G-NR air interface may operate in the FR1 band, which includes the Sub-6GHz band, or the FR2 band, which includes the 24.25GHz to 52.6GHz band. The 5G-NR air interface may include SSB, which is the downlink resource grid area including PSS / SSS / PBCH.

[0055] 5G-NR air interfaces can utilize BWPs for various purposes. For example, BWPs can be used to dynamically adapt SCSs. For instance, a UE202 can be configured with multiple BWPs, each BWP configuration having a different SCS. When a BWP change is instructed to the UE202, the transmission SCS is also changed. Another use case for BWPs relates to power saving. In particular, multiple BWPs can be configured for the UE202 with different amounts of frequency resources (e.g., PRBs) to support data transmission under different traffic load scenarios. BWPs with fewer PRBs can be used for data transmission with lower traffic loads, allowing for power savings in the UE202 and, in some cases, in the gNB216. BWPs with more PRBs can be used for scenarios with higher traffic loads.

[0056] In some implementations, an individual gNB216 may include a pair of gNB-CUs and gNB-DUs. Additionally or alternatively, a gNB216 may include one or more RUs. In such implementations, a gNB-CU may be connected to each gNB-DU via its respective F1 interface. In the case of network sharing via multiple cell ID broadcasts, each cell identity associated with a subset of PLMNs corresponds to a gNB-DU, and the gNB-CUs are connected to share the same physical layer of the cell resources. For resilience, a gNB-DU may be connected to multiple gNB-CUs by appropriate implementation. Furthermore, a gNB-CU may be divided into gNB-CU control plane (gNB-CU-CP) functions and gNB-CU user plane (gNB-CU-UP) functions. A gNB-CU-CP is connected to a gNB-DU via the F1 control plane interface (F1-C), a gNB-CU-UP is connected to a gNB-DU via the F1 user plane interface (F1-U), and a gNB-CU-UP is connected to a gNB-CU-CP via the E1 interface. In some implementations, one gNB-DU is connected to only one gNB-CU-CP, and one gNB-CU-UP is connected to only one gNB-CU-CPU. For resilience, a gNB-DU and / or gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation. One gNB-DU may be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and one gNB-CU-UP may be connected to multiple DUs under the control of the same gNB-CU-CP. Data transfer between gNB-CU-UPs during handover between gNB-CU-CPs within a gNB may be supported by Xn-U.

[0057] Similarly, an individual ng-eNB218 may include a pair of ng-gNB-CU and ng-gNB-DU. In such an implementation, the ng-gNB-CU and each ng-eNB-DU are connected via their respective W1 interfaces. An ng-eNB may include an ng-eNB-Cu-CP, one or more ng-eNB-CU-UPs, and one or more ng-eNB-DUs. An ng-eNB-DU is connected to the ng-eNB-CU-CP via the W1-C interface and to the ng-eNB-CU-UP via the W1-U interface. The general principles described herein with respect to the gNB aspects also apply to the ng-eNB aspects and their corresponding E1 and W1 interfaces unless explicitly specified otherwise.

[0058] The node hosting the user plane portion of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and in the case of EN-DN, MeNB or SgNB depending on the bearer partition) monitors for user inactivity. Furthermore, it notifies nodes with control plane connections to the core network (e.g., via E1, X2, etc.) of this inactivity or (re)activation. The node hosting the RLC protocol layer (e.g., gNB-DU) also monitors for user inactivity and may further notify the node hosting the control plane (e.g., gNB-CU or gNB-CU-UP) of this inactivity or (re)activation.

[0059] In such implementations, NG-RAN214 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The architecture of NG-RAN214 (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 associated TNL protocol and functionality are defined, for example, in [TS38401]. The TNL provides services for user plane transport and / or signaling transport. In an NG-Flex configuration, each NG-RAN node is connected to all AMF244s, and these AMFs are AMF sets within an AMF region, supporting at least one slice, which is also supported by the NG-RAN node. AMF sets and AMF regions are defined in [TS23501].

[0060] RAN204 is communicatively coupled to CN220, which includes network elements and / or network functions (NFs) that provide various functions to support data and communication services to customers / subscribers (e.g., UE202). The components of CN220 may be implemented on one physical node or on separate physical nodes. In some examples, NFV can be used to virtualize some or all of the functions provided by the network elements of CN220 on physical computing / storage resources such as servers and switches. Logical instances of CN220 are sometimes called network slices, and some logical instances of CN220 are sometimes called network subslices.

[0061] CN220 may be LTE CN222 (also known as Evolved Packet Core (EPC) 220). EPC222 may include MME224, SGW226, SGSN228, HSS230, PGW232, and PCRF234 coupled to each other via interfaces (or “reference points”) as shown in the figure. A brief description of the NFs within EPC222 follows.

[0062] The MME224 implements mobility management functions, tracking the current location of the UE202 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, etc. The SGW226 terminates the S1 interface toward the RAN210 and routes data packets between the RAN210 and the EPC222. The SGW226 can be a local mobility anchor point for handovers between RAN nodes and may also provide an anchor for inter-3GPP mobility. Other roles include lawful interception, billing, and some policy enforcement. The SGSN228 tracks the location of the UE202 and performs security functions and access control. The SGSN228 also performs inter-EPC node signaling for mobility between different RAN networks, selection of PDN and S-GW as defined by the MME224, selection of the MME224 for handover, etc. An S3 reference point between MME224 and SGSN228 enables information exchange between users and bearers for inter-3GPP access network mobility in idle / active states. HSS230 contains a database for network users, including join-related information to support the handling of communication sessions by network entities. HSS230 can support routing / roaming, authentication, authorization, naming / addressing resolution, location dependency, etc. An S6a reference point between HSS230 and MME224 may enable the transfer of join and authentication data for authenticating / authorizing user access to EPC222. PGW232 may terminate the SGi interface toward a data network (DN) 236, which may contain an application (app) / content server 238. PGW232 routes data packets between EPC222 and the data network 236. PGW232 is communicably coupled to SGW226 by an S5 reference point to facilitate user plane tunneling and tunnel management. PGW232 may further include nodes (e.g., PCEF) for policy enforcement and billing data collection.Furthermore, the SGi reference point can connect PGW232 to the same or a different data network 236 in a communicative manner. PGW232 can be connected to PCRF234 via a Gx reference point. PCRF234 is the policy and billing control element of EPC222. PCRF234 is connected to app / content server 238 in a communicative manner to determine appropriate QoS and billing parameters for the service flow. PCRF234 also provisions relevant rules within the PCEF (via the Gx reference point) with appropriate TFT and QCI.

[0063] CN220 may be a 5GC240 including AUSF242, AMF244, SMF246, UPF248, NSSF250, NEF252, NRF254, PCF256, UDM258, and AF260, which are coupled to each other via various interfaces as shown in the figure. The NFs within the 5GC240 are briefly described below.

[0064] AUSF242 stores data for UE202 authentication and handles authentication-related functions. AUSF242 provides a common authentication framework for various access types.

[0065] The AMF244 enables other functions of the 5GC240 to communicate with the UE202 and RAN204 and subscribe to notifications regarding mobility events related to the UE202. The AMF244 is also involved in registration management (e.g., for registering the UE202), connectivity management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF244 provides transport for SM messages between the UE202 and SMF246 and acts as a transparent proxy for routing SM messages. The AMF244 also provides transport for SMS messages between the UE202 and SMSF. The AMF244 interacts with the AUSF242 and UE202 to perform various security anchor and context management functions. Furthermore, the AMF244 is the endpoint of the RAN-CP interface, including the N2 reference point between the RAN204 and the AMF244. The AMF244 is also the termination point for NAS(N1) signaling and performs NAS ciphering and integrity protection.

[0066] The AMF244 also supports NAS signaling with the UE202 via the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF can be the endpoint of the N2 interface between the RAN204 and the AMF244 in the case of the control plane, and can be the endpoint of the N3 reference point between the RAN214 and the UPF248 in the case of the user plane. Thus, the AMF244 handles N2 signaling from the SMF246 and AMF244 for PDU sessions and quality of service, encapsulates / decapsulates packets for IPSec and N3 tunneling, marks N3 user plane packets on the uplink, and applies quality of service corresponding to the N3 packet marking, taking into account the quality of service requirements associated with such marking received via N2. The N3IWF relays UL and DL control plane NAS signaling between the UE202 and AMF244 via the N1 reference point between the UE202 and AMF244, and can also relay uplink and downlink user plane packets between the UE202 and UMF248. The N3IWF also provides a mechanism for establishing an IPSec tunnel with the UE202. The AMF244 has a Namf service-based interface and can be the endpoint of the N14 reference point between two AMF244s and the N17 reference point between the AMF244 and the 5G-EIR (not shown in Figure 2).

[0067] SMF246 is involved in SM (tunnel management and session establishment between UPF248 and AN208), allocation and management of UE IP addresses (including optional authorization), selection and control of UP functions, setting traffic steering on UPF248 to route traffic to appropriate destinations, termination of interfaces toward policy control functions, partial control of policy enforcement, billing and quality of service, lawful interception (for SM events and interfaces to L1 systems), termination of the SM portion of NAS messages, downlink data notification, initiation of AN-specific SM information sent to AN208 via N2 through AMF244, and determination of the session's SSC mode. SMF refers to the management of PDU sessions, and PDU session or "session" refers to the PDU connectivity service that provides or enables the exchange of PDUs between UE202 and DN236. SMF246 may also include the following features to support the extension of edge computing (see, for example, [TS23548]): the ability to select EASDF261 as the DNS server for PDU sessions and provide its address to the UE; the use of EASDF261 services as defined in [TS23548]; and provisioning and updating ECS ​​address configuration information to the UE to support the application layer architecture as defined in [TS23558]. The procedure for discovering and selecting EASDF261 is described in section 6.3.23 of [TS23501].

[0068] UPF248 functions as an anchor point for mobility within and between RATs, an external PDU session point for the interconnect to data network 236, and a branching point to support multi-homed PDU sessions. UPF248 also performs packet routing and forwarding, packet inspection, application of the user plane portion of policy rules, lawful interception of packets (UP collection), traffic utilization reporting, user plane quality of service processing (e.g., packet filtering, gating, UL / DL rate application), uplink traffic verification (e.g., SDF vs. QoS flow mapping), transport-level packet marking on uplinks and downlinks, and downlink packet buffering and downlink data notification triggers. UPF248 may include an uplink classifier to support routing of traffic flows to the data network.

[0069] The NSSF250 selects a set of network slice instances to serve the UE202. The NSSF250 also determines, if necessary, the mapping to authorized NSSAIs and subscribed S-NSSAIs. The NSSF250 also determines the set of AMFs to be used to serve the UE202, or, based on appropriate configuration, a list of candidate AMFs by querying the NRF254 if necessary. The selection of a set of network slice instances for the UE202 may be triggered by the interaction of the AMF244, to which the UE202 is registered, with the NSSF250, which may result in changes to the AMF244. The NSSF250 may interact with the AMF244 via the N22 reference point and communicate with other NSSFs in the visited network via the N31 reference point (not shown).

[0070] NEF252 securely exposes services and functions provided by 3GPP NFs to third parties, internal public / republishing, AF260, edge computing systems, or fog computing systems (e.g., edge computing nodes). In such cases, NEF252 can authenticate, authorize, or throttle AFs. NEF252 can also translate information exchanged with AF260 and information exchanged with internal network functions. For example, NEF252 can translate between AF service identifiers and internal 5GC information. NEF252 can also receive information from other NFs based on the exposed functions of those NFs. This information may be stored in NEF252 as structured data or in a data storage NF using a standardized interface. Stored information can be republished by NEF252 to other NFs and AFs, or used for other purposes such as analysis.

[0071] The NRF254 supports service discovery functionality, receiving NF discovery requests from NF instances and providing information about discovered NF instances to the requesting NF instance. The NRF254 also maintains information about available NF instances and the services they support. The NRF254 also supports service discovery functionality, receiving NF discovery requests from NF instances or SCPs (not shown) and providing information about discovered NF instances to the NF instance or SCP.

[0072] PCF256 can not only provide and enforce policy rules for control plane functions, but can also support an integrated policy framework for managing network behavior. PCF256 can also implement a front-end for accessing subscription information related to policy decisions within the UDM258's Integrated Data Repository (UDR). In addition to communicating with functions via reference points as illustrated, PCF256 features an Npcf service-based interface.

[0073] The UDM258 processes subscription-related information to support the handling of communication sessions by network entities and stores subscription data for the UE202. For example, subscription data may be communicated between the UDM258 and the AMF244 via an N8 reference point. The UDM258 may include two parts: the Application Front End and the UDR. The UDR may store subscription and policy data for the UDM258 and PCF256, and / or structured data and application data for publication for the NEF252 (including PFDs for application discovery and application request information for multiple UE202s). A Nudr service-based interface may be provided by the UDR to allow the UDM258, PCF256, and NEF252 to access specific sets of data stored and to enable reading, updating (e.g., adding or changing), deleting, and subscribing to notifications of changes in the relevant data within the UDR. The UDM258 may include a UDM-FE responsible for credential processing, location management, subscription management, etc. Several different frontends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as illustrated, the UDM258 may have a Nudm service-based interface.

[0074] The Edge Application Server Discovery Function (EASDF) 261 has a Neasdf service-based interface and connects to the SMF 246 via an N88 interface. One or more EASDF instances may be deployed within the PLMN, and the interaction between the 5GC NF and the EASDF 261 takes place within the PLMN. The EASDF 261 includes one or more functions of registering with the NRF 254 for discovery and selection of the EASDF 261, processing DNS according to instructions from the SMF 246, and / or terminating DNS security when used. The processing of DNS in accordance with instructions from SMF246 includes one or more of the following functions: receiving DNS message processing rules and / or BaselineDNSPattern from SMF246, exchanging DNS messages with UE202, forwarding DNS messages to C-DNS or L-DNS for DNS queries, adding EDNC client subnet (ECS) options to DNS queries for FQDNs, reporting information about received DNS messages to SMF246, and / or buffering / discarding DNS messages from UE202 or DNS servers. The EASDF has a direct user-plane connection to the PSA UPF via N6 for the transmission of DNS signaling exchanged with the UE (e.g., without using any NAT). The deployment of NAT between EASDF261 and PSA UPF248 may or may not be supported. Further aspects of EASDF261 are described in [TS23548].

[0075] AF260 influences application traffic routing, provides access to NEF252, and interacts with the policy framework for policy control. AF260 can act on the (re)selection and traffic routing of UPF248. Based on operator deployment, if AF260 is considered a trusted entity, network operators may allow AF260 to directly interact with the relevant NF. In some implementations, AF260 is used for edge computing implementations.

[0076] The 5GC240 can enable edge computing by selecting operator / third-party services that are geographically close to the point where the UE202 is installed on the network. This can reduce latency and network load. In an edge computing implementation, the 5GC240 can select a UPF248 that is close to the UE202 and perform traffic steering from the UPF248 to the DN236 via the N6 interface. This can be based on the UE's subscription data, the UE's location, and information provided by the AF260. In this way, the AF260 can act on the (re)selection and traffic routing of the UPF.

[0077] The data network (DN) 236 may represent various network operator services, internet access, or third-party services that may be provided by one or more servers, for example, including an application (app) / content server 238. DN236 may be an external public operator, private PDN, or intra-operator packet data network, for example, for the provisioning of IMS services. In this example, the app server 238 may be connected to IMS via an S-CSCF or I-CSCF. In some implementations, DN236 may represent one or more local area DNs (LADNs) that are accessible by the UE 202 within one or more specific areas. Outside these specific areas, the UE 202 cannot access the LADN / DN236.

[0078] Additionally, or alternatively, DN236 may be an edge DN236, which is a (local) DN that supports the architecture enabling edge applications. In such an example, app server 238 may represent a physical hardware system / device that provides app server functionality, and / or application software that resides in the cloud or on an edge computing node that runs the server functionality. In some examples, app / content server 238 provides an edge host environment that provides the support necessary for running the edge application server.

[0079] In some examples, 5GS can use one or more edge computing nodes to provide interfaces and offload the processing of wireless communication traffic. In such examples, the edge computing nodes may be contained within or coexist with one or more RAN210,214. For example, an edge computing node can provide connectivity between RAN214 and UPF248 in 5GC240. The edge computing node can use one or more NFV instances instantiated in the virtualization infrastructure within the edge computing node to handle wireless connections to and from RAN214 and UPF248.

[0080] In some embodiments, edge computing nodes provide a distributed computing environment for hosting applications and services, and also provide storage and processing resources to process data and / or content closer to subscribers (e.g., users of UE202) to reduce response times. Edge computing nodes also support multitenancy runtime and hosting environments for applications, including, among other things, virtual appliance 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, and compute offloading. Computation offloading involves offloading compute tasks, workloads, applications, and / or services from UE202, CN220, DN236, and / or servers to edge computing nodes, or vice versa. For example, a device application or client application running on a UE202 may offload application tasks or workloads to one or more edge computing nodes. In another example, an edge computing node may offload application tasks or workloads to a set of UE202s (e.g., for distributed machine learning computations).

[0081] An edge computing node may include or be part of an edge system that uses one or more edge computing technologies (ECTs) (also known as “edge computing frameworks”). An edge computing node may also be called an “edge host” or “edge server”. An edge system includes a set of edge servers and edge management systems (not shown) necessary to run edge computing applications within an operator network or a subset of an operator network. An edge server is a physical computer system that may include an edge platform and / or virtualization infrastructure, providing compute, storage, and network resources to edge computing applications. Each edge server is located at the edge of its corresponding access network and is configured to provide compute resources and / or various services (e.g., offloading compute tasks and / or workloads as described herein, cloud computing capabilities, IT services, and other similar resources and / or services) relatively close to the UE202. The VI of an edge computing node provides a virtualized environment and virtualized resources to the edge host, and edge computing applications may run on the VI as VMs and / or application containers.

[0082] In one exemplary implementation, ECT is 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 (2022-06), ETSI GS MEC 010-1 v1.1.1(2017-10), ETSI GS MEC 010-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 MEC 021 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 The MEC framework (collectively referred to hereby as "[MEC]") described in v2.1.1(2020-10), filed on 1 April 2020 ([US'834]), and in application PCT / US2020 / 066969 ([PCT'696]) filed by Intel on 23 December 2020, and / or operates in accordance with the MEC framework. The contents of each of these documents are incorporated herein by reference in their entirety.This exemplary implementation (and / or any other exemplary implementation described herein) is based on 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), and ETSI GS NFV-MAN 001. This may include NFV and / or other similar virtualization technologies (collectively referred to as "[ETSINFV]") as described in V1.1.1 (2014-12) and / or Israel et al., OSM Release FIVE Technical Overview, ETSI Open Source MANO, OSM White Paper, 1st ed. (January 2019), https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf. The contents of each of these documents are incorporated herein by reference in their entirety.Other virtualization technologies and / or service orchestration and automation platforms may be used, such as those described in the 3GPP Service-Based Management Architecture (SBMA) described in E2E Network Slicing Architecture, GSMA, Official Doc. 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 TS 28.533 v17.1.0 (2021-12-23) ([TS28533]). The contents of each of these documents are incorporated herein by reference in their entirety.

[0083] In another exemplary implementation, ECT is and / or operates according to the O-RAN framework. Typically, suppliers of front-end and back-end devices and telecommunications operators work closely together to ensure compatibility. The flip side of this working model is that plug-and-play with other devices can be extremely difficult, potentially hindering innovation. To address this and promote openness and interoperability at all levels, several key players interested in the wireless field (telecommunications operators, device manufacturers, academic institutions, etc.) established the Open RAN Alliance (“O-RAN”) in 2018. The O-RAN network architecture is a set of building blocks for designing a virtualized RAN on programmable hardware with AI / ML-powered radio access control. Various aspects of the O-RAN architecture are described in the following documents: O-RAN Architecture Description v07.00, O-RAN Alliance WG1 (October 2022) ("O-RAN.WG1.O-RAN-Architecture-Description"); O-RAN Operations and Maintenance Architecture Specification v04.00, O-RAN Alliance WG1 (February 2021) ("O-RAN.WG1.OAM-Archtecture"); O-RAN Operations and Maintenance Interface Specification v04.00, O-RAN Alliance WG1 (February 2021) ("O-RAN.WG1.O1Interface.0"); O-RAN Information Model and Data Models Specification v01.00, O-RAN Alliance WG1 (February 2021); O-RAN Working Group 1 Slicing Architecture v08.00 (October 2022); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Application Protocol v03.02 (July 2021); O-RAN Working Group 1 Use Cases Detailed Specification v09.00 (October 2022) (“[O-RAN.WG1.User-Cases]”); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: General Aspects and Principles v03.00 (October 2022) (“[O-RAN.WG2.A1GAP]”); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Type Definitions v04.00 (October 2021); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Transport Protocol v02.00 (October 2022); O-RAN Working Group 2 AI / ML workflow description and requirements v01.03 O-RAN Alliance WG2 (October 2021) (“[O-RAN.WG2.AIML]”); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) Non-RT RIC Architecture v02.01 (October 2022); O-RAN Working Group 2 Non-RT RIC: Functional Architecture v01.01, O-RAN Alliance WG2 (June 2021); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG): R1 interface: General Aspects and Principles v03.00, O-RAN Alliance WG2 (October 2022); O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles v02.02 (July 2022) (“[O-RAN.WG3.E2GAP]”); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) v02.01 (March 2022) (“[O-RAN.WG3.E2SM]”); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM), Cell Configuration and Control v01.00 (October 2022) (“[O-RAN.WG3.E2SM-CCC]”); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) KPM v02.03 (October 2022) (“[O-RAN.WG3.E2SM-KPM]”); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Function Network Interface (NI) v01.00 (February 2020) (“[ORAN-WG3.E2SM-NI]”); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Control v01.03 (October 2022) (“[O-RAN.WG3.E2SM-RC]”); O-RAN Working Group 3, Near-Real-time Intelligent Controller, E2 Application Protocol (E2AP) v02.03 (October 2022) (“[O-RAN.WG3.E2AP]”); O-RAN Working Group 3 (Near-Real-time RAN Intelligent Controller and E2 Interface Working Group): Near-RT RIC Architecture v03.00 (October 2022) (“[O-RAN.WG3.RICARCH]”); O-RAN Working Group 4 (Open Fronthaul Interfaces WG) Control, User and Synchronization Plane Specification v09.00 (July 2022) (“[O-RAN-WG4.CUS.0]”); O-RAN Fronthaul Working Group 4 Cooperative Transport Interface Transport Control Plane Specification v02.00, O-RAN Alliance WG4 (June 2021); O-RAN Fronthaul Working Group 4 Cooperative Transport Interface Transport Management Plane Specification v02.00 (June 2021); O-RAN Fronthaul Working Group 4 (Open Fronthaul Interfaces WG): Management Plane Specification v09.00 (July 2022) (“[O-RAN.WG4.MP.0]”); O-RAN Alliance Working Group 5 O1 Interface specification for O-CU-UP and O-CU-CP v04.00 (October 2022); O-RAN Alliance Working Group 5 O1 Interface specification for O-DU v05.00 (October 2022); O-RAN Open F1 / W1 / E1 / X2 / Xn Interfaces Working Group Transport Specification v01.00, O-RAN Alliance WG5 (April 2020); O-RAN Working Group 6 (Cloudification and Orchestration) Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN v04.00 (October 2022) (“[O-RAN.WG6.CADS]”); O-RAN Cloud Platform Reference Designs v02.00, O-RAN Alliance WG6 (February 2021); O-RAN Working Group 6 O2 Interface General Aspects and Principles v02.00 (October 2022); O-RAN Working Group 6 (Cloudification and Orchestration Work Group); O-RAN Acceleration Abstraction Layer General Aspects and Principles v04.00 (October 2022); O-RAN Working Group 6: O-Cloud Notification API Specification for Event Consumers v03.00 (“[O-RAN.WG6.O-Cloud Notification API]”; O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Indoor Pico Cell with Fronthaul Split Option 6 v02.00, O-RAN Alliance WG7 (October 2021) (“[O-RAN.WG7.IPC-HARD-Opt6]”); O-RAN WG7 Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 7-2 v03.00, O-RAN Alliance WG7 (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt7-2]”); O-RAN WG7 Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 8 v03.00 (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt8]”); O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Outdoor Micro Cell with Split Architecture Option 7.2 v03.00, O-RAN Alliance WG (October 2022) (“[O-RAN.WG7.OMC-HAD-Opt7-2]”); O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Outdoor Macro Cell with Split Architecture Option 7.2 v03.00, O-RAN Alliance WG7 (July 2022) (“[O-RAN.WG7.OMAC-HRD]”); O-RAN Open X-haul Transport Working Group Management interfaces for Transport Network Elements v04.00, O-RAN Alliance WG9 (July 2022); O-RAN Open X-haul Transport Working Group Synchronization Architecture and Solution Specification v02.00, O-RAN Alliance WG9 (March 2022); O-RAN Open Xhaul Transport WG9 WDM-based Fronthaul Transport v2.0,O-RAN Alliance WG9(March 2022);O-RAN Open Transport Working Group 9 Xhaul Packet Switched Architectures and Solutions v03.00,O-RAN Alliance WG9(July 2022)(“[O-RAN.WG9.XPSAAS]”);O-RAN Operations and Maintenance Architecture v07.00,O-RAN Alliance WG10(July 2022)(“[O-RAN.WG10.OAM-Architecture]”);O-RAN Operations and Maintenance Interface Specification v07.00,O-RAN Alliance WG10(July 2022);O-RAN Operations and Maintenance Interface Specification v08.00,O-RAN Alliance WG10(October 2022)(“[O-RAN.WG10.O1-Interface.0]”);O-RAN: Towards an Open and Smart RAN,O-RAN Alliance,White This information is contained in the Paper (October 2018) and U.S. Patent Application No. 17 / 484743, filed on September 24, 2021 (collectively referred to as "[O-RAN]"). The contents of each of these documents are incorporated herein by reference in their entirety.

[0084] In another exemplary implementation, ECT uses 3GPP TS 23.558 v18.1.0(2022-12-23)([TS23558]), 3GPP TS 23.501v18.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([TS23222]), and 3GPP TS 33.122 v18.0.0(2022-12-16)([TS33122]), and 3GPP TS 29.222 v17.1.0(2021-06-25)([TS29222]), 3GPP TS 23.502 3GPP TS 23.682 v17.3.0(2002-06-15)([TS23682]), 3GPP TS The 3rd Generation Partnership Project (3GPP) System Aspects Working Group 6 (SA6) Architecture for enabling Edge Applications (referred to as “3GPP Edge Computing”) and / or operating in accordance with 3GPP Edge Computing (collectively referred to as “[SA6Edge]”), as described in 23.434 v18.3.0(2022-12-23)([TS23434]) and 3GPP TS 23.401 v18.0.0(2022-12-21). The contents of each of these documents are incorporated herein by reference in their entirety.

[0085] In another exemplary implementation, ECT is and / or operates in accordance with the Intel Smart Edge Open framework (formerly known as OpenNESS) ("ISEO"), as described in the Intel Smart Edge Open Developer Guide, version 21.09 (September 30, 2021), available from https: / / smart-edge-open.github.io / . The contents of this document are incorporated herein by reference in their entirety.

[0086] In another exemplary implementation, ECT refers to Kanugovi et al., Multi-Access Management Services (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (March 2020) ("[RFC8743]"), Ford et al., TCP Extensions for Multipath Operation with Multiple Addresses, IETF RFC 8684 (March 2020), De Coninck et al., Multipath Extensions for QUIC (MP-QUIC), IETF draft-deconinck-quic-multipath-07, IETA, QUIC Working Group (May 3, 2021), Zhu et al., User-Plane Protocols for Multiple Access Management Service, IETF draft-zhu-intarea-mams-user-protocol-09, IETA, INTAREA (March 4, 2020), and Zhu et al., Generic Multi-Access (GMA) Convergence It operates in accordance with the Multi-Access Management Service (MAMS) framework described in Encapsulation Protocols, IETF RFC 9188 (February 2022) (collectively referred to as "[MAMS]").

[0087] The aforementioned examples of edge computing frameworks / ECTs and service deployments are merely illustrative of ECTs, and it should be understood that this disclosure may apply to numerous other or additional edge computing / networking technologies in various combinations and layouts of devices located at the edge of a network, including the various edge computing networks / systems described herein. Furthermore, the technologies disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also apply to this disclosure. Examples of such edge computing / networking technologies include [MEC]; [O-RAN]; [ISEO]; [SA6Edge]; Content Delivery Networks (CDNs) (also known as “Content Delivery Networks”); Mobility Service Provider (MSP) edge computing and / or Mobility as a Service (MasS) provider systems (e.g., used in AECC architectures); Nebula edge cloud systems; Fog computing systems; Cloudlet edge cloud systems; Mobile Cloud Computing (MCC) systems; Central Office Re-architected as a Datacenter (CORD), Mobile CORD (M-Cord), and / or Converged Multi-Access and Core (COMAC) systems, among others. 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.

[0088] The 5GC240 interface includes reference point and service-based interfaces. The reference points are: N1 (between UE202 and AMF224), N2 (between RAN214 and AMF244), N3 (between RAN214 and UPF248), N4 (between SMF246 and UPF248), N5 (between PCF256 and AF260), N6 (between UPF248 and DN236), N7 (between SMF246 and PCF256), N8 (between UDM258 and AMF244), N9 (between two UPF248s), N10 (between UDM258 and SMF246), and N1 This includes N1 (between AMF244 and SMF246), N12 (between AUSF242 and AMF244), N13 (between AUSF242 and UDM258), N14 (between two AMF244s; not shown), N15 (between PCF256 and AMF244 in a non-roaming scenario, or between PCF256 and AMF244 in a visiting network in a roaming scenario), N16 (between two SMF246s; not shown), and N22 (between AMF244 and NSSF250). Other reference point representations not shown in Figure 2 may also be used. The service-based representation in Figure 2 represents NFs in the control plane, and NFs in the control plane enable other authorized NFs to access their services. Service-based interfaces (SBIs) include Namf (SBI presented by AMF244), Nsmf (SBI presented by SMF246), Nnef (SBI presented by NEF252), Npcf (SBI presented by PCF256), Nudm (SBI presented by UDM258), Naf (SBI presented by AF260), Nnrf (SBI presented by NRF254), Nnssf (SBI presented by NSSF250), and Nausf (SBI presented by AUSF242). Other service-based interfaces not shown in Figure 2 (e.g., Nudr, N5g-eir, and Nudsf) may also be used. In some examples, NEF252 can provide an interface to an edge computing node that can be used to handle wireless connectivity with RAN214.

[0089] In some implementations, the network architecture 200 may include an SMSF that is involved in confirming and verifying SMS subscriptions and relaying SM messages between the UE 202 and other entities (e.g., SMS-GMSC / IWMSC / SMS routers). SMS may also interact with the AMF 244 and UDM 258 for procedures that notify the UE 202 that it is available for SMS forwarding (e.g., setting a UE unreachable flag and notifying the UDM 258 when the UE 202 becomes available for SMS).

[0090] 5GS may also include indirect communication (see, e.g., section 7.1.1 of 3GPP TS 23.501); delegated discovery (see, e.g., section 7.1.1 of 3GPP TS 23.501); forwarding and routing of messages to destination NF / NF services; communication security (e.g., authentication of NF service consumers to access NF service producer APIs) (see, e.g., 3GPP TS 33.501); load balancing, monitoring, overload control, etc.; and discovery and selection functions for UDM258, AUSF242, UDR259, PCF256 by accessing subscriber data stored in UDRs based on UE's SUPI, SUCI, or GPSI (see section 6.3 of [TS23501]). The load balancing, monitoring, and overload control functions provided by SCP may be specific to the implementation. SCP may be deployed in a distributed manner. There may be more than one SCP in the communication paths between various NF services. SCPs are not NF instances, but they can be deployed in a distributed, redundant, and scalable manner.

[0091] Figure 3 schematically represents the wireless network 300 according to various embodiments. The wireless network 300 may include a UE302 that wirelessly communicates with AN304. The UE302 and AN304 are similar to components of the same name described elsewhere in this specification and may be substantially interchangeable.

[0092] UE302 can be communicatively coupled to AN304 via connection 306. Connection 306 is represented as an air interface enabling the communication coupling and can follow cellular communication protocols such as LTE or 5G NR protocols operating at mmWave or Sub-6GHz frequencies.

[0093] UE302 may include a host platform 308 coupled with a modem platform 310. The host platform 308 may include an application processing circuit 312 which can be coupled with a protocol processing circuit 314 of the modem platform 310. The application processing circuit 312 may execute various applications of UE302 that source / sink application data. The application processing circuit 312 may further implement one or more layer operations that send application data to and receive application data from a data network. These layer operations may include transport (e.g., UDP) operations and internet (e.g., IP) operations.

[0094] The protocol processing circuit 314 may implement one or more layer operations to facilitate the transmission or reception of data via the connection 306. Layer operations implemented by the protocol processing circuit 314 may include, for example, MAC operations, RLC operations, PDCP operations, RRC operations, and NAS operations.

[0095] The modem platform 310 may further include a digital baseband circuit 316 which may include one or more layer operations that are “below” the layer operations performed by the protocol processing circuit 314 in the network protocol stack. These operations may include PHY operations that include, for example, HARQ-ACK functionality, scrambling / descrambling, coding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bitmetric determination, multi-antenna port precoding / decoding which may include space-time, space-frequency, or space coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and one or more other related functions.

[0096] The modem platform 310 may further include a transmitting circuit 318, a receiving circuit 320, an RF circuit 322, and an RF front end (RFFE) 324. The RFFE 324 may include or be connected to one or more antenna panels 326. Briefly, the transmitting circuit 318 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc. The receiving circuit 320 may include an analog-to-digital converter, a mixer, an IF component, etc. The RF circuit 322 may include a low-noise amplifier, a power amplifier, a power monitoring component, etc. The RFFE 324 may include filters (e.g., surface / bulk acoustic wave filters), switches, an antenna tuner, a beamforming component (e.g., a phase array antenna component), etc. The selection and arrangement of the components of the transmitting circuit 318, receiving circuit 320, RF circuit 322, RFFE 324, and one or more antenna panels 326 (commonly referred to as “transmitting / receiving components”) may be specific to the details of the implementation, such as whether the communication is TDM or FDM, or whether it is in mmWave or Sub-6GHz frequency. In some embodiments, the transmitting / receiving components may be arranged in multiple parallel transmit / receiving chains, or on the same or different chips / modules, etc.

[0097] In some embodiments, the protocol processing circuit 314 may include one or more instances of a control circuit (not shown) that provides control functions for the transmit / receive components.

[0098] Reception of the UE can be established by and through one or more antenna panels 326, RFFE 324, RF circuit 322, receiving circuit 320, digital baseband circuit 316, and protocol processing circuit 314. In some embodiments, one or more antenna panels 326 can receive transmissions from AN304 by receiving beamforming signals received by multiple antennas / antenna elements of one or more antenna panels 326.

[0099] The UE's transmission can be established by and through the protocol processing circuit 314, the digital baseband circuit 316, the transmitting circuit 318, the RF circuit 322, the RFFE 324, and one or more antenna panels 326. In some embodiments, the transmitting component of the UE 302 may apply spatial filters to the data to be transmitted so as to form a transmission beam radiated by the antenna elements of one or more antenna panels 326.

[0100] Similar to the UE302, the AN304 may include a host platform 328 coupled with a modem platform 330. The host platform 328 may include an application processing circuit 332 coupled with the protocol processing circuit 334 of the modem platform 330. The modem platform may further include a digital baseband circuit 336, a transmit circuit 338, a receive circuit 340, an RF circuit 342, an RFFE 344, and an antenna panel 346. The components of the AN304 are similar to the components of the same name in the UE302 and may be substantially interchangeable. In addition to performing the data transmission / reception described above, the components of the AN304 may perform various logical functions, including RNC functions such as radio bearer management, dynamic uplink and downlink radio resource management, and data packet scheduling.

[0101] Figure 4 is a block diagram representing components according to several exemplary embodiments that can read instructions from a machine-readable or computer-readable medium (e.g., a non-temporary machine-readable storage medium) and perform one or more of the methods described herein. Specifically, Figure 4 shows a schematic representation of hardware resources 400, each comprising 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 a bus 440 or other interface circuitry. In embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 402 may be executed to provide an execution environment in which one or more network slices / subslice utilize the hardware resources 400.

[0102] One or more processors 410 may include, for example, processors 412 and 414. One or more processors 410 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a composite 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), other processors (including those described herein), or any suitable combination thereof.

[0103] The memory / storage device 420 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 420 may also include, but is not limited to, any type of volatile, non-volatile, or quasi-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, or solid-state storage.

[0104] One or more communication resources 430 may include interconnects or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 404 or one or more databases 406 or other network elements via the 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.

[0105] Instruction 450 may include software, programs, applications, applets, APPs, or other executable code that causes at least one of the one or more processors 410 to perform one or more of the methods described herein. Instruction 450 may reside, whole or in part, in at least one of the one or more processors 410 (e.g., in the processor's cache memory), a memory / storage device 420, or any suitable combination thereof. Furthermore, any part of instruction 450 may be transferred to the 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.

[0106] Figure 5 shows another exemplary network architecture 500. Network architecture 500 may operate in accordance with the 3GPP technical specifications or technical reports for 6G systems. In some examples, network architecture 500 may operate concurrently with network architecture 200. For example, in some examples, network architecture 500 may share one or more frequency resources or bandwidth resources with network architecture 200. As one specific example, a UE (e.g., UE502) may be configured to operate in both network architecture 500 and network architecture 200. Such a configuration may be based on a UE that includes circuitry configured for communication using the frequency and bandwidth resources of both network architectures 200 and 500. In general, some elements of network architecture 500 may share one or more characteristics with elements of network architecture 200. For brevity and clarity, such elements may not be repeated in the description of network architecture 500.

[0107] The network architecture 500 may include UE502. UE502 may include any mobile or non-mobile computing device designed to communicate with RAN508 via a wireless connection. UE502 may be, for example, similar to UE202. UE502 may include, but is not limited to, smartphones, tablet computers, wearable computing devices, desktop computers, laptop computers, automotive infotainment, in-car entertainment devices, instrument panels, head-up display devices, onboard 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, network appliances, machine-type communication devices, M2M or D2D devices, IoT devices, etc.

[0108] Although not explicitly shown in Figure 5, in some examples, the network architecture 500 may include multiple UEs directly coupled to one another via sidelink interfaces. The UEs may be M2M / D2D devices communicating using physical sidelink channels such as PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc., but not limited to these. Similarly, although not explicitly shown in Figure 5, UE502 may be communicably coupled to APs such as AP206, as described with respect to Figure 2. Furthermore, although not explicitly shown in Figure 5, in some examples, RAN508 may include one or more ANs such as AN208, as described with respect to Figure 2. RAN508 and / or the ANs of RAN508 may be referred to as base stations (BS) or RAN nodes, or by other terms or names.

[0109] The UE502 and RAN508 may be configured to communicate via an air interface which may be called a sixth-generation (6G) air interface. A 6G air interface may include one or more features such as communication in 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 enables wireless communication together with radar-based sensing through 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. Such frequency ranges may also be additionally or alternatively referred to as “millimeter wave” or “mmWave” frequency ranges.

[0110] The RAN508 can enable communication between the UE502 and the 6G core network (CN)510. Specifically, the RAN508 can assist in the transmission and reception of data between the UE502 and the 6G CN510. The 6G CN510 may include various functions such as NSSF550, NEF552, NRF554, PCF556, UDM558, AF560, SMF546, and AUSF542. The 6G CN510 may further include UPF548 and DN539, as shown in Figure 5.

[0111] Furthermore, RAN508 may include various additional functions that are additions or replacements for the functions of legacy cellular networks, such as 4G or 5G networks. Two such functions are Computation Control Functions (Comp CF)524 and Computation Service Functions (Comp SF)536. Comp CF524 and Comp SF536 may be parts or functions of the compute service plane. Comp CF524 may be a control plane function that provides functions such as managing Comp SF536, generating and managing compute task contexts (e.g., create, read, modify, delete), and interacting with the underlying compute infrastructure for compute resource management. Comp SF536 may be a user plane function that acts as a gateway for interfaceping compute service users (e.g., UE502) with compute nodes behind Comp SF instances. Some functions of Comp SF536 include the ability to parse compute service data received from users and compute tasks that can be executed on compute nodes, the ability to maintain a service mesh ingress gateway or service API gateway, the enforcement of service and billing policies, performance monitoring, and telemetry collection. In some cases, a Comp SF536 instance can function as a user plane gateway for a cluster of compute nodes. A Comp CF524 instance may control one or more Comp SF536 instances.

[0112] Two other such functions are the Communication Control Function (Comm CF) 528 and the Communication Service Function (Comm SF) 538, which may be part of the communication service plane. The Comm CF 528 may be a control plane function for managing the Comm SF 538, creating / configuring / releasing communication sessions, and managing the communication session context. The Comm SF 538 may be a user plane function for data transport. The Comm CF 528 and Comm SF 538 can be considered upgrades to the SMF246 and UPF248 described in Figure 2 for a 5G system. The upgrades provided by the Comm CF 528 and Comm SF 538 can enable service-aware transport. For conventional (e.g., 4G or 5G) data transport, the SMF246 and UPF248 may still be used.

[0113] Two other such functions are the Data Control Function (Data CF) 522 and the Data Service Function (Data SF) 532, which may be parts of the data service plane. The Data CF 522 may be a control plane function and provides functions such as managing the Data SF 532, creating / configuring / releasing data services, and managing the data service context. The Data SF 532 is a user plane function and may act as a gateway between data service users (e.g., various functions of UE502 and 6G CN510) and data service endpoints behind the gateway. Specific functions may include parsing data service user data and forwarding it to the corresponding data service endpoint, generating billing data, and reporting data service status.

[0114] Another such function may be a Service Orchestration and Chaining Function (SOCF) 520, which can discover, integrate, and connect communication / computation / data services provided by functions within the network. Upon receiving a service request from a user, the SOCF 520 may interact with one or more of the Comp CF 524, Comm CF 528, and Data CF 522 to identify instances of Comp SF 536, Comm SF 538, and Data SF 532, configure service resources, and generate a service chain. The service chain may include multiple instances of Comp SF 536, Comm SF 538, and Data SF 532 and their associated compute endpoints. Workload processing and data movement can then occur within the generated service chain. The SOCF 520 may also be involved in maintaining, updating, and releasing the generated service chain.

[0115] Another such function may be a Service Registration Function (SRF) 514, which can function as a registry of system services provided on the user plane, such as services provided by service endpoints behind the Comp SF536 and Data SF532 gateways, or services provided by UE502. SRF514 can be considered a counterpart to NRF254, which can function as a registry of network functions.

[0116] Other such functions may include evolved service communication proxy (eSCP) and service infrastructure control function (SICF)526. These can provide service communication infrastructure for control plane services and user plane services. eSCP may relate to 5G service communication proxy (SCP) with added user plane service communication proxy functionality. Thus, eSCP is represented in two parts: eSCP-C512 for control plane service communication proxy and SCP-U534 for user plane service communication proxy. SICF526 can control and configure eSCP instances with respect to service traffic routing policies, access rules, load balancing configurations, performance monitoring, etc.

[0117] Another such function is found in the AMF544. The AMF544 is similar to the AMF244 but may have additional functions. Specifically, the AMF544 may include a potential redistribution of functions, such as moving the message forwarding function from the AMF544 to the RAN508.

[0118] Another such function is the service orchestration exposure function (SOEF)518. The SOEF518 can be configured to expose the orchestration and chaining of services to external users, such as applications.

[0119] UE502 may include an additional function called a computing client service function (comp CSF) 504. The comp CSF 504 may have both control plane and user plane functions and may interact with corresponding network-side functions such as SOCF520, Comp CF524, Comp SF536, Data CF522, and / or Data SF532 for service discovery, request / response, compute task workload exchange, etc. The comp CSF 504 may also work with network-side functions to determine whether a compute task should be performed on elements of UE502, RAN508, and / or 6G CN510.

[0120] UE502 and / or Comp CSF504 may include a service mesh proxy 506. The service mesh proxy 506 may function as a proxy for service-to-service communications within the user plane. The functions of the service mesh proxy 506 may include one or more of the following: addressing, security, load balancing, etc.

[0121] Figure 6 shows an exemplary artificial intelligence (AI)-assisted communication architecture for communication between the UE605 and the RAN610. More specifically, as will be described in further detail below, AI / machine learning (ML) models may be used or leveraged to assist wireless communication between the UE605 and the RAN610.

[0122] In this example, UE605 and RAN610 operate in accordance with the 3GPP technical specifications and / or the technical reports for 6G systems. In some examples, wireless cellular communication between UE605 and RAN610 may be part of, or concurrently with, network architecture 500, 200, and / or other network parts described herein.

[0123] UE605 is similar to UE202, UE302, UE502, UE702, Hardware Resource 400, and / or other UEs or devices, such as any of those described herein, and may share one or more functions with them. UE605 may be, but is not limited to, smartphones, tablet computers, wearable computer devices, desktop computers, laptop computers, automotive infotainment, in-car entertainment devices, instrument panels, head-up display devices, onboard 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, network appliances, machine-type communication devices, M2M or D2D devices, IoT devices, etc. RAN610 is similar to RAN214, RAN508, and / or other RANs described herein, and may share one or more functions with them.

[0124] As is clear from Figure 6, AI-related elements in UE605 may be similar to those in RAN610. For illustrative purposes, the descriptions of the various elements are given from the perspective of UE605. However, it should be understood that such descriptions or representations also apply to elements with the same names / numbers in RAN610 unless explicitly stated otherwise.

[0125] As described above, the UE605 may include various elements or functions related to AI / ML. Such elements may be implemented as hardware, software, firmware, and / or any 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 computer program), or firmware as the other elements.

[0126] One such element may be a data repository 615. The data repository 615 may be involved in the collection and storage of data. Specifically, the data repository 615 may collect and store RAN configuration parameters, measurement data, performance KPIs (key performance indicators), model performance metrics, etc., for model training, updating, and inference. More generally, the collected data is stored in the repository. The stored data may be discovered and extracted from the data repository 615 by another element. For example, as is obvious, the inference data selection / filter element 650 may read data from the data repository 615. In various examples, the UE 605 may be configured to discover and request data from the data repository 615 in the RAN, and vice versa. More generally, the data repository 615 of the UE 605 may be communicatively coupled with the data repository 615 of the RAN 610, so that the respective data repositories of the UE and RAN can share the collected data.

[0127] Other such elements may be the training data selection / filtering function block 620. The training data selection / filtering function block 620 may be configured to generate a training dataset, a validation dataset, and a test dataset for model training. The training data may be extracted from the data repository 615. The data may be selected / filtered based on a specific AI / ML model to be trained. The data may optionally be transformed / expanded / preprocessed (e.g., normalized) before being loaded into the dataset. The training data selection / filtering function block 620 may label the data in the dataset for supervised learning. The generated dataset may then be fed to the model training function block 625.

[0128] As described above, other such elements may be the model training function block 625. This function block may be involved in training and updating (retraining) the AI / ML model. The selected model may be trained using the dataset supplied from the training data selection / filtering function block (including training, validation, and testing). The model training function block 625 may generate trained and tested AI / ML models that are ready for deployment. The generated trained and tested models may be stored in the model repository 635.

[0129] The model repository 635 may be involved in the storage and retrieval of AI / ML models (both trained and untrained). Trained / updated models may be stored in the model repository 635. Models and model parameters may be discovered and requested by other functional blocks (e.g., the training data selection / filtering functional block 620 and / or the model training functional block 625). In some examples, UE605 may discover and request an AI / ML model from the model repository 635 of RAN610. Similarly, RAN610 may discover and request an AI / ML model from the model repository 635 of UE605. In some examples, RAN610 may configure the models and / or model parameters in the model repository 635 of UE605.

[0130] Other such elements may be the Model Management Function Block 640. The Model Management Function Block 640 may be involved in managing the AI / ML models generated by the Model Training Function Block 625. Such management functions may include deploying trained models, monitoring model performance, etc. In model deployment, the Model Management Function Block 640 may allocate and schedule hardware and / or software resources for inference based on the received trained and tested models. As used herein, “inference” refers to the process of using the trained AI / ML model to generate data analysis, actions, policies, etc., based on input inference data. In performance monitoring, based on wireless performance KPIs and model performance metrics, the Model Management Function Block 640 may decide to terminate a running model, start retraining a model, select a different model, etc. For example, the Model Management Function Block 640 of RAN610 may be able to configure model management policies in the UE, as shown.

[0131] Other such elements may be the inference data selection / filtering element 650. The inference data selection / filtering element 650 may be involved in generating a dataset for model inference in the inference function block 645, as described below. Specifically, inference data may be extracted from the data repository 615. The inference data selection / filtering element 650 may select and / or filter the data based on the deployed AI / ML model. The data may be transformed / enhanced / preprocessed according to the same transformation / enhanced / preprocessing as the training data selection / filtering described for the function block 620. The generated inference dataset may be supplied to the inference function block 645.

[0132] Other such elements may be the inference function block 645. The inference function block 645 may be involved in performing the inferences described above. Specifically, the inference function block 645 may consume the inference dataset supplied by the inference data selection / filtering element 650 and generate one or more results. Such results may include data analysis, actions, policies, etc. The results may be supplied to the performance measurement function block 630.

[0133] The performance measurement function block 630 is configured to measure model performance metrics (e.g., accuracy, model bias, runtime delay, etc.) of the deployed and running model based on the inference results for monitoring purposes. Model performance data may be stored in the data repository 615.

[0134] Figure 7 illustrates aspects of an example RAN partitioning architecture. Figure 7 shows an exemplary network deployment including an example next-generation fronthaul (NGF) deployment 700a, where UE702 is connected via an air interface to RU730 (also known as “remote radio unit 730,” “remote radio head 730,” or “RRH730”), RU730 is connected via NGF interface (NGFI)-I to digital unit (DU) 731, DU731 is connected via NGFI-II to central unit (CU) 732, and CU732 is connected via backhaul interface to core network (CN) 742. In a 3GPP NG-RAN implementation (see, e.g., [TS38401]), DU731 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 otherwise indicated by the context). UE702 may be the same as or similar to UE202 and / or any other UE or user / client device described herein.

[0135] In some implementations, the NGF deployment 700a may be deployed in a distributed RAN (D-RAN) architecture where CU732, DU731, and RU730 are located at cell sites, and CN742 is located at a centralized site. Alternatively, the NGF deployment 700a may be deployed in a centralized RAN (C-RAN) architecture with centralized processing of one or more baseband units (BBUs) at a centralized site. In a C-RAN architecture, radio components are divided into separate components, and these separate components can be located in different locations. In one example C-RAN implementation, only RU720 is located at a cell site, and DU731, CU732, and CN742 are centralized or located at a central location. In another example C-RAN implementation, RU730 and DU731 are located at cell sites, and CU732 and CN742 are located at a centralized site. In another embodiment of C-RAN, only RU730 is located at the cell site, DU731 and CU732 are located at the RAN hub site, and CN742 is at the centralized site.

[0136] The CU732 is a central controller that can serve or otherwise connect to one or more DU731s and / or multiple RU730s. The CU732 is a network (logical) node that hosts the higher / upper layers of the network protocol functional partitioning. For example, in the 3GPP NG-RAN and / or O-RAN architecture, the CU732 hosts the Radio Resource Control (RRC) layer, the Service Data Adaptive Protocol (SDAP) layer, and the Packet Data Convergence Protocol (PDCP) layer of the Next Generation NodeB (gNB), or hosts the RRC and PDCP protocol layers if it is included in or operates as an en-gNB of an E-UTRA-NR gNB. The SDAP sublayer performs mapping between QoS flows and data radio bearers (DRBs) and marks QoS flow IDs (QFIs) in both DL and UL packets. The PDCP sublayer performs data transfer on the user plane or control plane, maintains PDCP sequence numbers (SNs), compresses and decompresses headers using the Robust Header Compression (ROHC) protocol and / or the Ethernet Header Compression (EHC) protocol, encrypts and decrypts, provides integrity protection and integrity verification, offers timer-based SDU discarding, routes split bearers, duplicates and duplicate discarding, sorts and delivers in order, and / or delivers out of order. In various implementations, the CU732 terminates each F1 interface connected to the corresponding DU731 (see, for example, [TS38401]).

[0137] CU732 may include a CU-Control Plane (CP) entity (referred to here as "CU-CP732") and a CU-User Plane (UP) entity (referred to here as "CU-UP732"). CU-CP732 is a logical node that hosts the control plane portions of the RRC layer and PDCP protocol layer of CU732 (e.g., gNB-CU of en-gNB or gNB). CU-CP terminates the E1 interface connected to CU-UP, and the F1-C interface is connected to DU731. CU-UP732 is a logical node that hosts the user plane portion of the PDCP protocol layer (e.g., for NB-CU732 of en-gNB), and the user plane portion of the PDCP protocol layer and the SDAP protocol layer (e.g., for gNB-CU732 of gNB). CU-UP732 terminates the E1 interface connected to CU-CP732 and the F1-U interface connected to DU731.

[0138] The DU731 controls radio resources such as time and frequency band locally and in real time, and allocates resources to one or more UEs. The DU731 is a network (logical) node that hosts the middle and / or lower layers of the network protocol functional partitioning. For example, in the 3GPP NG-RAN and / or O-RAN architecture, the DU731 hosts the Radio Link Control (RLC) Medium Access Control (MAC) and the High-PHY layer of the gNB or en-gNB, whose operation is at least partially controlled by the CU732. The RLC sublayer operates in one or more of the following modes: TM (Transparent Mode), UM (Unacknowledged Mode), and AM (Acknowledged Mode). The RLC sublayer performs the forwarding of upper-layer PDUs, sequence numbering independent of PDCP numbers (UM and AM), error correction by ARQ (AM only), segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs, SDU reconstruction (AM and UM), duplicate detection (AM only), RLC SDU discarding (AM and UM), RLC re-establishment, and / or protocol error detection (AM only). The MAC sublayer performs mapping between logical channels and transport channels, multiplexing / demultiplexing of MAC SDUs belonging to one or different logical channels to and from transport blocks (TBs) transmitted and received with the physical layer on the transport channel, reporting scheduling information, error correction by HARQ (one HARQ entity per cell in the case of CA), priority processing between UEs by dynamic scheduling, priority processing between logical channels of a single UE by logical channel prioritization, priority processing between duplicate resources of a single UE, and / or padding. In some implementations, the DU731 operates as an Integrated Access and Backhaul (IAB) node, for example, when the DU731 operates as an Integrated Access and Backhaul (BAP) node, using the Backhaul Adaptation Protocol (BAP) layer (see, for example, 3GPP TS 38.340 v16.5.0 (July 7, 2021)).) and / or the F1 Application Protocol (F1AP) (see, for example, 3GPP TS 38.470 v16.5.0 (July 1, 2021)) can be hosted. A single DU731 supports one or more cells, and a single cell is supported by only one DU731. The DU731 terminates the F1 interface connected to the CU732. Additionally or alternatively, a DU731 may be connected to one or more RRH / RU730s.

[0139] A RU730 is a transmit / receive point (TRP) or other physical node that handles radio frequency (RF) processing functions. A RU730 is a network (logical) node that hosts lower layers based on lower layer functional partitioning. For example, in the 3GPP NG-RAN and / or O-RAN architecture, a RU730 hosts the Low-PHY layer functions and RF processing of a radio interface based on lower layer functional partitioning. A RU730 may be similar to a 3GPP transmit / receive point (TRP) or RRH, but specifically includes the Low-PHY layer. Examples of Low-PHY functions include Fast Fourier Transform (FFT), Inverse Fast Fourier Transform (IFFT), and Physical Random Access Channel (PRACH) extraction.

[0140] CU732, DU731, and RU730 are connected through their respective links, which may be any suitable wired links (e.g., fiber, copper, etc.) and / or wireless links. In some implementations, various combinations of CU732, DU731, and RU730 may correspond to one or more of AN208 in Figure 2. Further aspects of CU732, DU731, and RU730 are described in [O-RAN], [TS38401], [TS38410], and [TS38300], the contents of which are incorporated herein by reference in their entirety.

[0141] In some implementations, the fronthaul gateway function (FHGW) may be located between the DU731 and the RU / RRU730 (not shown in Figure 7), where the interface between the DU731 and the FHGW is an open fronthaul (e.g., Option 7-2x) interface, and the interface between the FHGW function and the RU / RRU730 is an open fronthaul (e.g., Option 7-2x) interface or any other suitable interface (e.g., Option 7, Option 8, etc.) including those that do not support open fronthaul (e.g., Option 7-2x). The FHGW may be packaged with one or more other functions (e.g., Ethernet switching) in a physical device or appliance. In some implementations, the RAN controller may be coupled to communicate with the CU732 and / or DU731.

[0142] NGFI (also known as "xHaul") is a two-stage fronthaul architecture that separates the traditional RRU730-to-BBU connection in the C-RAN architecture into two levels, Level I and Level II. As shown by Deployment 700a in Figure 7, Level I connects the RU730 to the DU731 via NGFI-I, and Level II connects the DU731 to the CU732 via NGFI-II. The NGFI-I and NGFI-II connections may be wired or wireless, and any suitable RAT, such as any of those described herein, may be used. The purpose of the two-stage architecture is to improve deployment flexibility by distributing (dividing) the RAN node protocol functions between the CU732 and DU731 so that latency is mitigated. Generally, NGFI-I interfaces with the lower layers of the functional division, which have stringent latency and data rate requirements. In contrast, NGFI-II interfaces with the higher layers of the functional division relative to the layers of NGFI-I, thus relaxing the requirements of the fronthaul link. Examples of NGFI fronthaul interfaces and functional partitioning architectures include O-RAN7.2x fronthaul (see [O-RAN.WG9.XPSAAS] and [O-RAN-WG4.CUS.0], etc.), and C-RAN fronthaul based on eCPRI (Enhanced Common Public Radio Interface) (see, for example, Common Public Radio Interface: eCPRI Interface Specification, eCPRI Specification v2.0 (May 10, 2019), Common Public Radio Interface: Requirements for the eCPRI Transport Network, eCPRI Transport Network v1.2 (June 25, 2018), and [O-RAN-WG.4.CUS.0]).), RoE (Radio over Ethernet) based C-RAN fronthaul (e.g., IEEE Standard for Radio over Ethernet Encapsulations and Mappings, IEEE Standards Association, IEEE 1914.3-2018 (October 5, 2018) (see "[IEEE1914.3]")). Further aspects of NGFI include [O-RAN.WG9.XPSAAS], [O-RAN-WG4.CUS.0], IEEE Standard for Packet-based Fronthaul Transport Networks, IEEE Standards Association, IEEE 1914.1-2019 (April 21, 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, This is also explained in arXiv:1803.07673v1 [cs.NI](March 20, 2018)("[Nasrallah]"), and the content of each of these is incorporated by referencing the full text.

[0143] In one example, deployment 700a may implement a low-level split (LLS) (also known as "lower layer functional split 7-2x" or "split option 7-2x") performed between RU730 (e.g., O-RU in the O-RAN architecture) and DU731 (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], [O-RAN.WG7.OMC-HRD-Opt7-2]). In this embodiment, 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 include, for example, 3GPP NG-RAN functional splitting (e.g., [TS38401] and 3GPP TR 38.801 v14.0.0 (April 3, 2017)), the Small Cell Forum for Split Option 6 (e.g., 5G small cell architecture and product definitions: Configurations and Specifications for companies deploying small cells 2020-2025, Small Cell Forum, document 238.10.01 (July 5, 2020) ("[SCF238]"), and 5G NR FR1 Reference Design: The case for a common, modular architecture for 5G NR FR1 small cell distributed radio units, Small Cell Forum, document See 251.10.01 (December 15, 2021) ("[SCF251]") and [O-RAN.WG7.IPC-HRD-Opt6]. The contents of each of these documents are incorporated into this application by reference in their entirety.), and / or other relevant interfaces described in other standards or specifications, such as O-RAN White Box Hardware Split Option 8 (e.g., [O-RAN.WG7.IPC-HRD-Opt8]), may be used.

[0144] Additionally, or alternatively, CU732, DU731, and / or RU730 may be IAB nodes. IAB enables radio relay in NG-RAN, and relay nodes (referred to as “IAB nodes”) support access and backhauling via 3GPP 5G / New Radio (NR) links / interfaces. The terminating node for NR backhauling on the network side is called an “IAB donor” and corresponds to a RAN node (e.g., gNB) with additional capabilities to support IAB. Backhauling can occur via a single hop or multiple hops. All IAB nodes connected to an IAB donor via one or more hops form a directed acyclic graph (DAG) topology with the IAB donor as its root. The IAB donor provides centralized resource, topology, and route management for the IAB topology. The IAB architecture is shown and described in [TS38300].

[0145] While NGF Deployment 700a presents CU732, DU731, RRH730, and CN742 as separate entities, other implementations may bundle, combine, or otherwise integrate some or all of these network nodes into a single device or element, including collapsing some internal interfaces (e.g., F1-C, F1-U, E1, E2, etc.). At least the following implementations are possible: (i) integrating CU732 and DU731 (e.g., CU-DU), which is connected to RRH730 via NGFI-I; (ii) integrating DU731 and the integrated RRH731 (e.g., CU-DU), which is connected to CU732 via NGFI-II; (iii) integrating the RAN controller and CU732, which is connected to DU731 via NGFI-II; (iv) integrating CU732, DU731, and RU730, which is connected to CN742 via a backhaul interface; (v) integrating the network controller (or intelligent controller) with CU732, DU731, and RU730. Any of the above embodiments including CU732 may also include integrating CU-CP732 and CP-UP732.

[0146] Figure 7 also shows an example RAN disaggregation deployment 700b (also called “Disaggregated RAN700b”), where UE702 is connected to RRH730, and RRH730 is communicably coupled to one or more of the RAN functions (RANF) 1-N (where N is a number). RANF1-N are separated and geographically distributed across several component segments and network nodes. In some implementations, each RANF1-N is a software (SW) element operated by a physical computing node, and RRH730 includes radio frequency (RF) circuitry (e.g., an RF propagation module for a specific RAT). In this example, RANF1 operates on a physical computing node located in the same location as RRH730, while the remaining RANFs are located far away from RRH730. Furthermore, in this example, CN742 is also separated into CN NF1-x (where x is a number) in the same or similar manner as RANF1-N. However, in other implementations, CN742 is not isolated.

[0147] Network disaggregation (or disaggregated networking) involves dividing networking equipment into functional components and allowing each component to be deployed individually. This may include separating software elements (e.g., NFs) from specific hardware elements and / or enabling software-defined networking (SDN) and / or NF virtualization (NFV) using APIs. RAN disaggregation involves network disaggregation and virtualization of various RANFs (e.g., RANF1-N in Figure 7). RANF1-N can be located in different physical locations within a RAN deployment in various topologies based on their use cases. This enables the distribution and deployment of RANFs across different geographical regions and allows for RANF breakouts to support various use cases (e.g., low-latency use cases) and flexible RAN implementations. Disaggregation provides a common or uniform RAN platform that can assume different profiles depending on the deployment location. This reduces the number of fixed-function devices and lowers the total cost of ownership compared to existing RAN architectures. Examples of RAN disaggregation frameworks include TIP (Telecom Infra Project) OpenRAN, Cisco® Open vRAN, [O-RAN], OOPT (Open Optical & Packet Transport), and ROADM (Reconfigurable Optical Add Drop Multiplexer).

[0148] In the first embodiment, RANF1~N isolate the RAN hardware and software using commercial off-the-shelf (COTS) hardware and open interfaces (e.g., NGFI-I and NGFI-II). In this embodiment, each RANF1~N may be a virtual BBU or vRAN controller operating on a COTS computing infrastructure with hardware acceleration for BBU / vRANF.

[0149] In the second embodiment, RANF1~N isolate one or more layers of the RAT protocol stack. As an example of this implementation, RANF1 is a DU731 running on a first COTS computing infrastructure with hardware acceleration for BBU / vRANF, and RANF2 is a virtual CU732 running on a second COTS computing infrastructure.

[0150] In the third embodiment, RANF1~N separates control plane functions from user plane functions. As an example of this implementation, RANF1 is a DU731 operating on a COTS computing infrastructure with hardware acceleration for BBU / vRANF, RANF2 is a virtual CU-CP732 operating on a COTS computing infrastructure, and a third RANF (e.g., RANF3 (not shown in Figure 7)) is a virtual CU-UP732 operating on the same or a different COTS computing infrastructure as the virtual CU-CP732. Additionally or alternatively, in this implementation, one or more CN NF1~x may be CN-UP functions, and one or more other CH NF1~x may be CN-CP functions.

[0151] In the fourth embodiment, RANF1~N isolate an example of [IEEE802]RAT. As an example of this implementation, RRH730 implements the WiFi PHY layer, RANF1 implements the Wi-Fi MAC sublayer, RANF1 implements the Wi-Fi Logical Link Control (LLC) sublayer, RANF2 implements one or more Wi-Fi upper layer protocols (e.g., network layer, transport layer, session layer, presentation layer, and / or application layer), etc.

[0152] In the fifth embodiment, RANF1~N separate different O-RAN RANFs, including E2SM. As an example of this implementation, RANF1 implements Near-RT RIC, RANF2 implements E2SM-KPM, RANF3 implements E2SM-CCC, RANF4 implements E2SM RAN control, RANF5 implements E2SM-NI, RANF6 implements functions to provide A1 services, and so on.

[0153] In any of the implementations described herein, the lower layers of the RAN protocol stack may feature real-time (RT) functions and relatively complex signal processing algorithms, while the upper layers of the RAN protocol stack may feature non-RT functions. In these implementations, the RT functions and signal processing algorithms can be implemented in the DU731 and / or RRH730, either using dedicated network elements or in COTS hardware extended with dedicated hardware accelerators.

[0154] Figure 7 also shows various functional partitioning options 700c for both DL and UL directions. Traditional RAN is an integrated network architecture based on Distributed RAN (D-RAN), which aggregates all RANFs into fewer network elements. As mentioned above, the disaggregated RAN architecture overcomes various shortcomings of the D-RAN model by providing flexible functional partitioning options. Disaggregated RAN divides an integrated network system into several functional components, which can then be rearranged individually as needed without hindering their ability to work together to provide overall network services. Partitioning option 700c is primarily a partition between CU732 and DU731, but may also include a partition between CU732, DU731, and RU730. For each option 700c, the protocol entities on the left side of the figure are included in the RANF implementing CU732, and the protocol entities on the right side of the figure are included in the RANF implementing DU731. For example, Option 2's functional partitioning involves separating non-RT processing (e.g., RRC layer and PDCP layer) from RT processing (e.g., RLC layer, MAC layer, and PHY layer), where a RANF implementing CU732 handles the networking functions of the RRC and PDCP layers, and a RANF implementing DU731 handles the baseband processing functions of the RLC layer (including High-RLC and Low-RLC), MAC layer (including High-MAC and Low-MAC), and PHY layer. In some implementations, the PHY layer is further partitioned between DU731 and RU730, where a RANF implementing DU731 handles the High-PHY layer functions and RU730 handles the Low-PHY layer functions. In some implementations, Low-PHY entities may be operated by RU730 regardless of the selected functional partitioning option. Under Option 2's partitioning, a RANF implementing CU732 can connect to multiple DU731s (e.g., CU732 is centralized).This eliminates changes to RRC and PFCP anchors during handovers between DU731s, allowing a centralized CU732 to pool resources among multiple DU731s. Thus, Option 2's functional partitioning can improve resource efficiency. The specific functional partitioning option used may vary depending on service requirements and network deployment scenarios and may be implementation-specific. In some implementations, all functional partitioning options may be selected, with each protocol stack entity being operated by its respective RANF (for example, 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 until the eighth RANF operates the Low-PHY layer). Other partitioning options are also possible, as described 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].

[0155] In one or more embodiments, at least one of the components described in one or more of the aforementioned figures may be configured to perform one or more operations, techniques, processes, and / or methods described herein (including the examples given in the following Examples section). For example, a baseband circuit related to one or more of the aforementioned figures may be configured to operate according to one or more of the examples described below. As another example, a circuit related to a UE, base station, satellite, network element, etc., as described above in relation to one or more of the aforementioned figures, may be configured to operate according to one or more of the examples described below in the Examples section.

[0156] The term "application" can refer to a complete and deployable package or environment for implementing specific functionality within an operating environment. Terms such as "AI / ML application" may refer to an application that includes several artificial intelligence (AI) / machine learning (ML) models and application-level descriptions. In some embodiments, an AI / ML application may be used to constitute or implement one or more of the disclosed aspects.

[0157] The terms “machine learning” or “ML” refer to the use of computer systems that implement algorithms and / or statistical models to perform specific tasks without using explicit instructions, but instead relying on patterns and inference. An ML algorithm constructs or estimates a mathematical model (such as an “ML model”) based on sample data (such as “training data” or “model training information”) to make predictions or decisions without being explicitly programmed to perform such tasks. Generally, an ML algorithm is a computer program that learns from experience with respect to some task and some performance metric, and an ML model may be any object or data structure produced after an ML algorithm has been trained on one or more training datasets. After training, an ML model may be used to make predictions on new datasets. The terms “ML algorithm” refer to a different concept from the terms “ML model,” but as used herein, these terms may be used synonymously.

[0158] The terms "machine learning model" and "ML model" can also refer to ML methods and concepts used by ML-assisted solutions. An "ML-assisted solution" is a solution that uses ML algorithms in operation to address a specific use case. ML models include supervised learning (e.g., linear regression, k-nearest neighbors (KNN), decision tree algorithm, support machine vectors, 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 banded learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model may have many submodels as components, and an ML model may train all submodels together. Individually trained ML models can also be concatenated in an ML pipeline during inference. An "ML pipeline" is a set of features, functions, or feature entities specific to an ML-assisted solution, and an ML pipeline may include a data pipeline, a model training pipeline, a model evaluation pipeline, and one or more data sources within the actor. An "actor" is an entity that hosts an ML-assisted solution using the output of an ML model inference. The term "ML training host" refers to an entity, such as a network function, that hosts the training of a model. The term "ML inference host" refers to an entity, such as a network function, that hosts a model during inference modes (including both model execution and optional online learning, where applicable). The ML host informs the actor of the output of the ML algorithm, and the actor decides on an action ("action" is performed by the actor as a result of the output of the ML-assisted solution). The term "model inference information" refers to the information used as input to the ML model to determine the inference. The data used to train the ML model and the data used to determine the inference may overlap, but "training data" and "inference data" refer to different concepts.

[0159] This disclosure defines or otherwise provides the operation and functionality of a UE supporting an MRTD configuration for Power Class 6 (PC6) UE multi-panel reception in a cellular system. The following discussion may be applicable to any type of UE or base station, such as any of the UEs or base stations shown in Figures 1A-18.

[0160] In several respects, the PC6 UE consists of two different panels and can receive signals from two different transmit / receive points (TRPs). To support this feature, the UE may be configured to handle the timing difference between signals from the two TRPs. By specifying the UE MRTD requirement, the 3GPP specification ensures that the UE receives both signals accurately. This further ensures the performance of the PC6 UE operating under fast train (HST) bidirectional deployment at frequency 2 (FR2).

[0161] When a PC6 UE supports multi-panel simultaneous reception and reports the corresponding signaling IE to the network through the UE capability signaling report, and the network configures the UE within FR2 and HST bidirectional deployment, the UE can handle the maximum reception timing difference between subframe boundaries of signals received using two panels. The maximum reception timing difference can be set to 8 μs. This process and requirement ensure good performance of the PC6 UE performing multi-panel simultaneous reception under HST bidirectional deployment.

[0162] The disclosed technology describes the processes and requirements for a PC6 UE with multi-panel simultaneous reception operating under HST bidirectional deployment in FR2. The disclosed technology can be used to facilitate fair performance when the UE receives from two different TRPs using two different receiving panels.

[0163] In an HST FR2 deployment, the timing difference between consecutive remote radio heads (RRHs) / TRPs is considered to be greater than 3 μs (for example, a typical RRH distance of 700 meters corresponds to a propagation delay of ~2.33 μs). Under commonly accepted assumptions for cell phase synchronization, a maximum timing difference of 3 μs between any TRPs can be set. To sum the values, the UE can be configured to handle a maximum timing difference of at least 5.33 μs between RRHs. This is a much larger value than the cyclic prefix (CP) length of 0.59 μs in a typical 120 kHz configuration in FR2.

[0164] In some respects, a UE may be configured to support a timing difference between signals received from its two panels that is longer than the CP length used in HST FR2 deployment. In some respects, UEs that do not support an MRTD longer than the CP are not required and are considered not to support multi-panel simultaneous receive operation.

[0165] In several respects, a UE implementation with interband carrier aggregation between FR2 carriers is configured to support a maximum MRTD of 8 μs. This value can be derived based on the UE implementation.

[0166] In some respects, the UE may be configured to handle the relative reception timing difference between subframe boundaries of signals received using two different panels in FR2.

[0167] For PC6 UEs that support multi-panel simultaneous reception (indicated by UE capability signaling such as simultaneousReceptionDiffTypeD-r16), if the network sets high-speed configuration parameters for the UE (e.g., highSpeedMeasFlagFR2 and highSpeedDeploymentTypeFR2 are set bidirectionally), the UE may be configured to handle the maximum reception timing difference as defined in Table 1 below. The specified timing difference may be defined as the difference between subframe boundaries of signals received by the UE using two different panels, respectively.

[0168] In some respects, the disclosed MRTD configuration applies when a single carrier is configured to be PC6 UE.

[0169] Table 1: Maximum receive timing difference requirements for PC6 UE with multi-panel simultaneous reception [Table 1]

[0170] In several aspects, the PC6 UE is configured to handle the relative reception timing difference between subframe boundaries of signals received using two different panels in FR2.

[0171] In several respects, the maximum reception timing difference requirement applies to PC6 UEs that support multi-panel simultaneous reception [simultaneousReceptionDiffTypeD-r16]. An indication by the UE in the signaling element means that the UE supports simultaneous reception via multi-panel functionality. The names of the signaling elements in brackets [] are further updatable.

[0172] In some respects, the maximum receive timing difference setting applies when the network has highSpeedMeasFlagFR2 and highSpeedDeploymentTypeFR2 set bidirectionally to the UE.

[0173] In some respects, bidirectional deployment can be used as a deployment for HST in 3GPP. It is a deployment where the base station TRP transmits signals / beams in both directions along the line. In some respects, directional reversal can also be used, but may not be relevant in the disclosed technology.

[0174] In several respects, the UE can handle the maximum receive timing difference, as shown in Table 1 above.

[0175] In some respects, the MRTD configuration specified in the sub-clause applies when a single carrier is configured for the PC6 UE.

[0176] In some respects, the UE may be configured to support the MRTD as defined in the above claims.

[0177] Figure 8 shows a block diagram of a communication device such as an evolved node B (eNB), a next-generation node B (gNB) (or other RAN nodes such as a base station), a network-controlled repeater (NCR), an access point (AP), a radio station (STA), a mobile station (MS), or a user equipment (UE), according to several aspects and for performing one or more of the technologies disclosed herein. In alternative aspects, the communication device 800 can operate as a standalone device or can be connected to other communication devices (e.g., networked).

[0178] A circuit (e.g., a processing circuit) is a collection of circuits implemented in the tangible entities of device 800, including hardware (e.g., simple circuits, gates, logic, etc.). Circuit components can be flexible over time. A circuit includes components that can perform specified operations individually or in combination during operation. For example, circuit hardware can be designed invariantly (hardwired) to perform a particular operation. For example, the hardware of a circuit may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a machine-readable medium that has been physically modified to encode instructions for a particular operation (e.g., magnetic, electrical, movable arrangement of invariant mass particles, etc.).

[0179] When connecting physical components, the fundamental electrical properties of the hardware components are changed, for example, from insulator to conductor, or vice versa. Instructions allow embedded hardware (e.g., execution units or load mechanisms) to configure components of circuits within the hardware through variable connections so that they perform specific parts of operation when in operation. Thus, in one example, a machine-readable medium element is communicatively coupled to or part of other components of the circuit when the device is operating. For example, any of the physical components may be used in more than one component of more than one circuit. For example, under operation, an execution unit may be used in a first circuit of a first circuit configuration at one point in time and reused at another point in time by a second circuit of the first circuit configuration or a third circuit of a second circuit configuration. Further examples of such components relating to device 800 are as follows:

[0180] In several aspects, device 800 can operate as a standalone device or can be connected to other devices (e.g., networked). In a networked deployment, communication device 800 can operate as a server communication device, a client communication device, or both in a server-client network environment. For example, communication device 800 can operate as a peer communication device in a peer-to-peer (P2P) (or other distributed) network environment. Communication device 800 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smartphone, web appliance, network router, switch or bridge, or any communication device capable of executing instructions that specify the actions to be performed by the communication device. Furthermore, although only a single communication device is represented, the term “communication device” should also be understood to include any set of communication devices that individually or collectively execute a set (or set) of instructions to perform one or more of the methods described herein, such as cloud computing, software-as-a-service (SaaS), and other computer cluster configurations.

[0181] The examples described herein may include, or operate within, logic or a set of components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specific operation and may be configured or arranged in a particular manner. In one example, a circuit may be arranged in a particular manner as a module (e.g., internally or relative to an external entity such as another circuit). In one example, 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 parts, or applications) as modules that operate to perform a specific operation. In one example, the software may reside on a medium readable by a communication device. In one example, the software, when executed by the underlying hardware of a module, causes the hardware to perform a specific operation.

[0182] Accordingly, the term “module” is understood to encompass tangible entities, i.e., entities that are physically configured, specifically configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a particular way or to perform some or all of the operations described herein. Considering an example where a module is temporarily configured, each module does not need to be instantiated at any given point in time. For example, if a module has a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as different modules at different points in time. The software, therefore, can configure the hardware processor to constitute one module at one point in time and another module at another.

[0183] The communication device (e.g., UE) 800 may include a hardware processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 804, static memory 806, and storage devices 816 (e.g., a hardware drive, tape drive, flash storage, or other block or storage devices), some or all of which may communicate with each other via an interlink 808 (e.g., a bus).

[0184] The communication device 800 may further include a display device 810, an input device 812 (e.g., a keyboard), and a user interface (UE) navigation device 814 (e.g., a mouse). In one example, the display device 810, the input device 812, and the UE navigation device 814 may be touchscreen displays. The communication device 800 may further include a signal generating device 818 (e.g., a speaker), a network interface device 820, and one or more sensors 821, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The communication device 800 may also include an output controller 828, such as a serial connection (e.g., Universal Serial Bus (USB)), a parallel connection, or other wired or wireless connection (e.g., infrared (IR), near-field communication (NFC)) for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0185] The storage device 816 may include a device-readable medium 822 that stores one or more sets of data structures or instructions 824 (e.g., software) that embody or utilize one or more of the technologies or functions described herein. In some respects, the registers of the hardware processor 802, the main memory 804, the static memory 806, and / or the storage device 816 may (whole or at least partially) be or include the device-readable medium 822 that stores one or more sets of data structures or instructions 824 that are embody or utilize one or more of the technologies or functions described herein. In one example, one or any combination of the hardware processor 802, the main memory 804, the static memory 806, or the storage device 816 may constitute the device-readable medium 822.

[0186] As used herein, the term “device-readable medium” is interchangeable with “computer-readable medium” or “machine-readable medium.” Although device-readable medium 822 is represented as a single medium, the term “communication device-readable medium” may include a single or multiple mediums configured to store instructions 824 (e.g., a centralized or distributed database and / or associated caches and servers). The term “communication device-readable medium” includes the terms “machine-readable medium” or “computer-readable medium” and may include any medium that can store, encode, or carry instructions (e.g., instructions 824) executed by communication device 800, causing communication device 800 to execute one or more of the technologies of this disclosure, or any medium that can store, encode, or carry data structures used by or associated with such instructions. Examples of non-limiting communication device-readable mediums include solid-state memory and optical and magnetic media. Specific examples of communication device-readable media include non-volatile memory such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as internal hard disks and removable media, magneto-optical disks, random access memory (RAM), and CD-ROM and DVD-ROM disks. In some examples, communication device-readable media include non-temporary communication device-readable media. In some examples, communication device-readable media may include communication device-readable media that are not temporary propagating signals.

[0187] Instruction 824 may also be transmitted or received via a communication network 826 using a transmission medium, through a network interface device 820 using one of several transport protocols. In one example, the network interface device 820 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to the communication network 826. In one example, the network interface device 820 may include multiple antennas to wirelessly transmit using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technology. In some examples, the network interface device 820 may wirelessly transmit using multiple-user MIMO technology.

[0188] The term “transmission medium” should be understood to include any intangible medium capable of storing, encoding, or carrying instructions executed by the communication device 800, including digital or analog communication signals or other intangible medium to facilitate the communication of such software. In this regard, the transmission medium in the context of this disclosure is a device-readable medium.

[0189] The terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” mean the same thing and may be used synonymously in this disclosure. The terms are defined to include both machine storage media and transmission media. Thus, the terms include both storage devices / mediums and carrier / modulated data signals.

[0190] The implementation described in the subject may include one or more features, either individually or in combination, as illustrated by example.

[0191] Example 1 is a device for user equipment (UE) configured for operation in a fifth-generation nu-radio (5G-NR) network, It comprises a processing circuit and a memory coupled to the processing circuit, The aforementioned processing circuit is Encode an announcement signaling that indicates the UE's ability to support the simultaneous reception of two downlink (DL) signals, Decode the configuration signaling for bidirectional high-speed deployment. The first DL signal and the second DL signal, which were simultaneously received during bidirectional high-speed decryption, are decoded using a reception timing difference between subframe boundaries that is less than or equal to a preset maximum value. The memory is configured to store the configuration signaling. It is a device.

[0192] In Example 2, in the subject matter of Example 1, the notification signaling is simultaneous reception-based signaling.

[0193] In Example 3, in the subject matter of Example 1 or Example 2, the configuration signaling is a fast configuration signaling that includes a first field indicating that the UE is operating in the bidirectional fast deployment.

[0194] In Example 4, in the subject of Example 3, the first field is the highSpeedDeploymentTypeFR2-r17 field.

[0195] In Example 5, in the subject matter of Example 3 or Example 4, the configuration signaling further includes a second field indicating that the UE is further configured for high-speed measurement while operating in frequency range 2 (FR2).

[0196] In Example 6, in the subject of Example 5, the second field is the highSpeedMeasFlagFR2 field.

[0197] In Example 7, in any subject matter of Examples 1 to 6, the notification signaling further indicates that the UE is a power class 6 (PC6) UE that supports the simultaneous reception of two DL signals in the frequency range 2-1 (FR2-1).

[0198] In Example 8, the subject matter of any of Examples 1 to 7 further comprises at least two receiving chains coupled to the processing circuit, the at least two receiving chains simultaneously receiving the first DL signal and the second DL signal while the UE is operating in the bidirectional high-speed deployment.

[0199] In Example 9, in any subject of Examples 1 to 8, the maximum reception timing difference is 8 microseconds (8 μs), and the subcarrier interval associated with the first DL signal and the second DL signal is 120 kHz.

[0200] Example 10 further includes a transceiver circuit coupled to the processing circuit and two or more antennas coupled to the transceiver circuit, in the subject matter of any of Examples 1 to 9.

[0201] Example 11 stores instructions to be executed by one or more processors of a base station, the instructions to configure the base station for operation on a 5th generation NE-Radio (5G-NR) or later network, and the base station, This demonstrates the ability of a user equipment (UE) to support the simultaneous reception of two downlink (DL) signals, by decoding the notification signaling received from the UE, For operation in bidirectional high-speed deployment, the configuration signaling constituting the UE is encoded for transmission to the UE, Encode the first DL signal and the second DL signal related to simultaneous reception during bidirectional high-speed deployment due to the reception timing difference between subframe boundaries that is less than or equal to a preset maximum value, for transmission to the UE. It is a computer-readable storage medium that enables the execution of operations including [specific actions].

[0202] In Example 12, in the subject matter of Example 11, the notification signaling is simultaneous reception-based signaling.

[0203] Example 13 stores instructions to be executed by one or more processors of a user device (UE), the instructions constitute the UE for operation on a 5th generation NE-Radio (5G-NR) or later network, and the UE, Encoding notification signaling for transmission to the base station that indicates the UE's ability to support the simultaneous reception of two downlink (DL) signals, Decoding the configuration signaling for bidirectional high-speed deployment, The first DL signal and the second DL signal, which were simultaneously received during the bidirectional high-speed deployment, are decoded using a reception timing difference between subframe boundaries that is less than or equal to the previously set maximum value. It is a computer-readable storage medium that enables the execution of operations including [specific actions].

[0204] In Example 14, in the subject matter of Example 13, the notification signaling is simultaneous reception-based signaling.

[0205] In Example 15, in the subject matter of Example 13 or Example 14, the configuration signaling is a fast configuration signaling that includes a first field indicating that the UE is operating in the bidirectional fast deployment.

[0206] In Example 16, in the subject of Example 15, the first field is the highSpeedDeploymentTypeFR2-r17 field.

[0207] In Example 17, in the subject matter of Example 15 or Example 16, the configuration signaling further includes a second field indicating that the UE is further configured for high-speed measurement while operating in frequency range 2 (FR2).

[0208] In Example 18, in the subject of Example 17, the second field is the highSpeedMeasFlagFR2 field.

[0209] In Example 19, in any subject matter of Examples 13 to 18, the notification signaling further indicates that the UE is a power class 6 (PC6) UE that supports the simultaneous reception of two DL signals in the frequency range 2-1 (FR2-1).

[0210] In Example 20, in any subject matter of Examples 13 to 19, the UE has at least two receive chains coupled to the one or more processors, and the operation includes receiving the first DL signal and the second DL signal simultaneously through the at least two receive chains while the UE is operating in the bidirectional high-speed deployment.

[0211] Example 21 is at least one machine-readable medium that, when executed by a processing circuit, contains instructions causing the processing circuit to perform an operation to implement any of Examples 1 to 20.

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

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

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

[0215] While specific illustrative aspects have been described, it is clear that various changes and modifications can be made to those aspects without departing from the broader scope of this disclosure. Therefore, the specification and drawings should be interpreted as explanatory rather than restrictive. Accordingly, this detailed description should not be taken as restrictive, and the scope of the various aspects, along with the entire scope of equivalences to which the attached claims are granted, is defined solely by those claims.

[0216] [Claiming priority] This application claims priority to international application PCT / CN2023 / 112218, filed on 10 August 2023, with the title of the invention "MAXIMUM RECEIVE TIMING DIFFERENCE FOR USER EQUIPMENT MULTI-PANEL RECEPTIONS," the prior application is incorporated herein by reference in its entirety.

Claims

1. A device for user equipment (UE) configured for operation in a fifth-generation nu-radio (5G-NR) network, It comprises a processing circuit and a memory coupled to the processing circuit, In order to configure the UE for operation on the 5G-NR network, the processing circuit is: Encode notification signaling for transmission to the base station that indicates the UE's ability to support the simultaneous reception of two downlink (DL) signals. For operation in bidirectional high-speed deployment, the UE decodes the configuration signaling received from the base station, The first DL signal and the second DL signal, which were simultaneously received during the aforementioned bidirectional high-speed deployment, are decoded. The reception timing difference between the subframe boundary of the first DL signal and the subframe boundary of the second DL signal is less than or equal to the preset maximum reception timing difference. The memory is configured to store the configuration signaling. Device.

2. The aforementioned notification signaling is signaling based on simultaneous reception. The apparatus according to claim 1.

3. The configuration signaling is a high-speed configuration signaling that includes a first field indicating that the UE is operating in the bidirectional high-speed deployment. The apparatus according to claim 1.

4. The first field is the highSpeedDeploymentTypeFR2-r17 field. The apparatus according to claim 3.

5. The configuration signaling further includes a second field indicating that the UE is further configured for high-speed measurement while operating in frequency range 2 (FR2). The apparatus according to claim 3.

6. The second field is the highSpeedMeasFlagFR2 field. The apparatus according to claim 5.

7. The notification signaling further indicates that the UE is a power class 6 (PC6) UE that supports the simultaneous reception of two DL signals in frequency range 2-1 (FR2-1). The apparatus according to any one of claims 1 to 6.

8. The processing circuit further comprises at least two receiving chains coupled to it. The at least two receiving chains simultaneously receive the first DL signal and the second DL signal while the UE is operating in the bidirectional high-speed deployment. The apparatus according to any one of claims 1 to 6.

9. The aforementioned maximum reception timing difference is 8 microseconds (8 μs). The subcarrier interval associated with the first DL signal and the second DL signal is 120 kHz. The apparatus according to any one of claims 1 to 6.

10. A transceiver circuit coupled to the processing circuit, Two or more antennas coupled to the transceiver circuit and The apparatus according to any one of claims 1 to 6, further comprising:

11. The instructions include instructions executed by one or more processors of the base station, the instructions configure the base station for operation on a fifth-generation nuradio (5G-NR) or later network, and the base station, This demonstrates the ability of a user device (UE) to support the simultaneous reception of two downlink (DL) signals, by decoding notification signaling received from the UE, For operation in bidirectional high-speed deployment, the configuration signaling that constitutes the UE is encoded for transmission to the UE, The first DL signal and the second DL signal related to simultaneous reception during the aforementioned bidirectional high-speed deployment are encoded for transmission to the UE, wherein the reception timing difference between the subframe boundary of the first DL signal and the subframe boundary of the second DL signal is less than or equal to a preset maximum reception timing difference. Perform an action that includes Computer program.

12. The aforementioned notification signaling is signaling based on simultaneous reception. The computer program according to claim 11.

13. The instructions include instructions executed by one or more processors of a user device (UE), the instructions constitute the UE for operation on a fifth-generation nu-radio (5G-NR) or later network, and the UE, Encoding notification signaling for transmission to the base station that indicates the UE's ability to support the simultaneous reception of two downlink (DL) signals, To enable operation in bidirectional high-speed deployment, the UE is configured to decode the configuration signaling received from the base station, The process involves decoding the first DL signal and the second DL signal, which are simultaneously received during the aforementioned bidirectional high-speed deployment, wherein the reception timing difference between the subframe boundary of the first DL signal and the subframe boundary of the second DL signal is less than or equal to a preset maximum reception timing difference. Perform an action that includes Computer program.

14. The aforementioned notification signaling is signaling based on simultaneous reception. The computer program according to claim 13.

15. The configuration signaling is a high-speed configuration signaling that includes a first field indicating that the UE is operating in the bidirectional high-speed deployment. The computer program according to claim 13.

16. The first field is the highSpeedDeploymentTypeFR2-r17 field. The computer program according to claim 15.

17. The configuration signaling further includes a second field indicating that the UE is further configured for high-speed measurement while operating in frequency range 2 (FR2). The computer program according to claim 15.

18. The second field is the highSpeedMeasFlagFR2 field. The computer program according to claim 17.

19. The notification signaling further indicates that the UE is a power class 6 (PC6) UE that supports the simultaneous reception of two DL signals in frequency range 2-1 (FR2-1). A computer program according to any one of claims 13 to 18.

20. The UE has at least two receiving chains coupled to one or more processors, and the operation is, The UE includes receiving the first DL signal and the second DL signal simultaneously via at least two receiving chains while operating in the bidirectional high-speed deployment mode. A computer program according to any one of claims 13 to 18.

Images