Transmission power control for cross-link interference management

Abstract

A computer readable storage medium stores instructions executed by one or more processors of a UE, configures the UE for cross-link interference management in a 5G NR and higher version network, and causes the UE to perform operations including decoding first and second configuration signaling received from a base station. The first configuration signaling indicates a first set of one or more symbols and a second set of one or more symbols associated with the TDD DL-UL configuration. The second configuration signaling includes at least one UL power control parameter associated with the first set of one or more symbols. The UL data is encoded to transmit the UL data during the second set of symbols at a power level based on the at least one UL power control parameter.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 502,031, filed May 12, 2023, entitled “Downlink (DL) and Uplink (UL) Transmission Power Control for Cross-Link Interference Management,” which is incorporated by reference in its entirety for all purposes. BACKGROUND

[0003] Mobile communications have evolved from early voice systems to today’s highly sophisticated integrated communication platforms. As the number of different types of devices communicating with various network devices has increased, the usage of 3GPP LTE systems has also grown. The popularity of mobile devices (user equipment or UEs) in modern society continues to drive the demand for various networked devices in many different environments. The fifth generation (5G) wireless systems are on the horizon, promising to enable even higher speeds, connectivity, and availability. Next generation 5G networks (or NR networks) and beyond (e.g., 6G networks) are expected to improve throughput, coverage, and robustness, and reduce latency and operational and capital expenditures. 5G NR (and beyond) networks will be based on continued evolution of 3GPP LTE-Advanced and introduce more potential new radio access technologies (RATs) to enrich people’s lives with seamless wireless connectivity solutions that provide fast, rich content and services. As current cellular network frequencies have become saturated, higher frequencies (e.g., millimeter wave (mmWave) frequencies) can be more advantageous due to their high bandwidth.

[0004] Furthermore, in future 5G and beyond communication systems, enhanced operations of LTE and NR systems in licensed and unlicensed spectrum are expected. Such enhanced operations can include techniques for configuring downlink (DL) and uplink (UL) transmission power control to enable cross-link interference management. BRIEF DESCRIPTION OF DRAWINGS

[0005] In the drawings, which are not necessarily drawn to scale, like numerals can describe similar components in different views. Like numerals having different letter suffixes can represent different instances of similar components. The drawings illustrate generally, by way of example, aspects discussed in the present disclosure.

[0006] Figure 1A An architecture of a network is shown in accordance with some aspects.

[0007] Figure 1B And Figure 1C A non-roaming 5G system architecture is shown in accordance with some aspects.

[0008] Figure 2 ,Figure 3 、 Figure 4 and Figure 5 Various systems, devices, and components can implement aspects of the disclosed embodiments.

[0009] Figure 6 An artificial intelligence (AI) assisted communication architecture example between a UE and a RAN is shown in accordance with some aspects.

[0010] Figure 7 A RAN split architecture example is shown in accordance with some aspects.

[0011] Figure 8 Cross-link interference for a dynamic time division duplex (TDD) system is shown in accordance with some aspects.

[0012] Figure 9 Sub-band full duplex (SBFD) operation in a downlink (DL) symbol is shown in accordance with some aspects.

[0013] Figure 10 A block diagram of a communication device such as an evolved Node-B (eNB), a new generation Node-B (gNB) (or another RAN node), an access point (AP), a wireless station (STA), a mobile station (MS), or a user equipment (UE) is shown in accordance with some aspects. DETAILED DESCRIPTION

[0014] The following description and drawings are illustrative of the various aspects and are not intended to limit the scope, applicability, or configuration of these aspects in any way. Various changes could be made to the aspects recited herein by one skilled in the art relating to the structure and functionality of the aspects described herein without departing from the scope of the aspects. Therefore, the foregoing description and drawings are illustrative of the aspects and do not restrict the scope of these aspects. Aspects recited in the claims include all available equivalents of the elements recited therein.

[0015] Figures 1A-10 Various systems, devices, and components can implement aspects of the disclosed embodiments in different communication systems, such as 5G-NR (and beyond) networks. The UEs, base stations (such as gNB), and / or other nodes (such as satellites or other computing nodes) discussed in this disclosure can be configured to perform the techniques disclosed.

[0016] Figure 1AA network architecture in accordance with certain aspects is shown. The communication network 140A is shown to include user equipment (UE) 101 and UE 102. The UEs 101 and 102 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) but can also include any mobile or non-mobile computing device, such as personal data assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, drones, or any other computing device including wired and / or wireless communication interfaces. The UEs 101 and 102 can be collectively referred to as UE 101 in the present disclosure, and the UE 101 can be used to perform one or more of the techniques disclosed in the present disclosure.

[0017] Any of the radio links described in the present disclosure (e.g., as used in the network 140A or any other illustrated network) can operate in accordance with any exemplary radio communication technology and / or standard.

[0018] 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 by which multiple carrier signals operating at different frequencies can be used to carry communication for a single UE, thereby increasing the bandwidth available to a single device. In some aspects, carrier aggregation can be used in cases where one or more component carriers operate at unlicensed frequencies.

[0019] Aspects described in the present disclosure can be used in the context of any spectrum management scheme, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (such as License Shared Access (LSA) for 2.3-2.4 GHz, 3.4-3.6 GHz, 3.6-3.8 GHz, and other frequencies, and Spectrum Access System (SAS) for 3.55-3.7 GHz and other frequencies.

[0020] Aspects described in the present disclosure can also apply to different single-carrier or OFDM types (CP-OFDM, SC-FDMA, SC-OFDM, Filter Bank based Multi-Carrier (FBMC), OFDMA, etc.), and in particular 3GPP NR (New Radio), by allocating OFDM carrier data bit vectors to respective symbol resources.

[0021] In some aspects, any of the UEs 101 and 102 can comprise an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE, which can include a network access layer designed for low-power IoT applications utilizing short-lived UE connections. In some aspects, any of the UEs 101 and 102 can comprise a Narrowband (NB) IoT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). IoT UEs can utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) technologies. M2M or MTC technologies can refer to data communication technologies that allow devices to communicate with one another or a base station 105 without human intervention. For example, M2M or MTC technologies can refer to technologies facilitating the automated exchange of data between electronic devices or a machine and another device or a machine. M2M or MTC data exchanges can be machine-initiated exchanges that can be implemented between devices, or between a machine and another device, independent of human input. M2M or MTC technologies can also be used in the context of IoT networks that can include interconnecting IoT UEs, with a base station 105, which can include a device capable of communicating with a carrier network (e.g., a cell tower or a wireless access point) or an IoT server (e.g., a cloud server). M2M or MTC technologies can be used in the context of IoT networks that can include interconnecting IoT UEs with a base station 105, and with each other, or both.

[0022] In some aspects, any of the UEs 101 and 102 can comprise an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0023] The UEs 101 and 102 can be configured to connect, e.g., communicatively couple, with a radio access network (RAN) 110. The RAN 110 can be, for example, a Universal Mobile Telecommunications System (UMTS), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs 101 and 102 utilize connections 103 and 104, respectively, with the RAN 110; each connection 103 and 104 comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 103 and 104 are illustrated as an air interface to enable communicative coupling, and can be implemented using a cellular communications protocol such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a

[0024] In one aspect, UE 101 and UE 102 can also directly exchange communication data via ProSe interface 105. Optionally, ProSe interface 105 may be referred to as a sidelink interface, which includes one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0025] As shown in the figure, UE 102 is illustrated as being configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, according to which AP 106 may include Wi-Fi. Router. In this example, AP 106 is shown connected to the Internet, but not to the core network of the wireless system (described in further detail below).

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

[0027] Either communication node 111 or 112 can terminate the air interface protocol and can serve as the first contact point for UE 101 and UE 102. In some aspects, either communication node 111 or 112 can implement various logical functions for RAN 110, including but not limited to Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In one 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.

[0028] The RAN 110 is shown to include base stations 112a and 112b, which provide wireless access to the core network 120 for one or more mobile apparatuses 101a, 101b, and 101c. The base stations 112a, 112b, and 112c can each include one or more base transceiver stations, access points, Node-Bs, eNode-Bs, gNode-Bs, radio heads, or some other interface for a wireless access network. These base stations can be variously referred to as base stations, Node-Bs, eNode-Bs, gNode-Bs, or some other name, and can be implemented in various ways depending on the radio access technology. Figures 1B-1C The RAN 110 is shown to include base stations 112a and 112b, which provide wireless access to the core network 120 for one or more mobile apparatuses 101a, 101b, and 101c. The base stations 112a, 112b, and 112c can each include one or more base transceiver stations, access points, Node-Bs, eNode-Bs, gNode-Bs, radio heads, or some other interface for a wireless access network. These base stations can be variously referred to as base stations, Node-Bs, eNode-Bs, gNode-Bs, or some other name, and can be implemented in various ways depending on the radio access technology.

[0029] In this aspect, the CN 120 includes a MME 121, a S-GW 122, a packet data network (PDN) gateway (P-GW) 123, and a home subscriber server (HSS) 124. The MME 121 can be similar in function to a control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MME 121 can manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 124 can include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions. Depending on the number of mobile subscribers, the capacity of equipment, the organizational structure of the network, etc., the CN 120 can include one or several HSSs 124. The HSS 124 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0030] The S-GW 122 can terminate the S1 interface 113 towards the RAN 110 and routes data packets between the RAN 110 and the CN 120. The S-GW 122 can further be a local mobility anchor for inter-RAN handovers and also for intra-RAN handovers between base stations 112a, 112b, and 112c within the same RAN. Other responsibilities of the S-GW 122 can include lawful intercept, charging, and some policy enforcement.

[0031] The P-GW 123 can terminate an SGi interface toward a PDN. The P-GW 123 can route data packets between a EPC network (e.g., CN 120) and external networks such as networks including the application server 184 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 125. The P-GW 123 can also route data packets between other external networks 131 A, which can include the Internet, IP multimedia subsystem (IMS) network, and other networks that can be coupled to the CN 120. Generally, the application server 184 can be an element offering applications that use IP bearer resources for core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this aspect, the P-GW 123 is shown to be communicatively coupled to an application server 184 via an IP interface 125. The application server 184 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 101 and 102 via the CN 120.

[0032] The P-GW 123 can also be a node for policy enforcement and charging data collection. The policy and charging rules function (PCRF) 126 is the policy and charging control element of the CN 120. In a non-roaming scenario, in some aspects, there is a single PCRF 126 in the home public land mobile network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario, in some aspects, there are two PCRFs associated with the UE's IP-CAN session: a home PCRF (H-PCRF) within a HPLMN and a visited PCRF (V-PCRF) within a visited public land mobile network (VPLMN). The PCRF 126 can be communicatively coupled to the application server 184 via the P-GW 123.

[0033] In some aspects, the communication network 140A can be an IoT network or a 5G or 6G network, including a 5G New Radio network using communications in licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current implementers of IoT is Narrow Band IoT (NB-IoT).

[0034] The NG system architecture can include a RAN 110 and a 5G core network (e.g., CN 120). The RAN 110 in the NG system can be referred to as an NG-RAN. The RAN 110 can include multiple nodes, such as gNBs and NG-eNBs. The CN 120 (also referred to as a 5G core network or 5GC) can include an access and mobility function (AMF) and / or a user plane function (UPF). The AMF and UPF can be communicatively coupled to the gNBs and NG-eNBs via an NG interface. More specifically, in some aspects, the gNBs and NG-eNBs can be connected to the AMF by an NG-C interface and to the UPF by an NG-U interface. The gNBs and NG-eNBs can be coupled to each other via an Xn interface.

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

[0036] Figure 1B A non-roaming 5G system architecture is shown in accordance with some aspects. Reference is made to Figure 1B, the 5G system architecture 140B is shown in the figure in a reference point representation. More specifically, the UE 102 can communicate with the RAN 110 and one or more other 5G core (5GC) network entities. The 5G system architecture 140B includes a number of network functions (NFs) such as an Access and Mobility Management Function (AMF) 132, a Location Management Function (LMF) 133, a Session Management Function (SMF) 136, a Policy Control Function (PCF) 148, an Application Function (AF) 150, a User Plane Function (UPF) 134, a Network Slice Selection Function (NSSF) 142, an Authentication Server Function (AUSF) 144, and a Unified Data Management (UDM) / Home Subscriber Server (HSS) 146. The UPF 134 can provide connectivity with a Data Network (DN) 152 that can include, for example, operator services, Internet access, or third-party services. The AMF 132 can be used to manage access control and mobility, and can also include network slice selection functionality. The SMF 136 can be configured to establish and manage various sessions according to network policy. The UPF 134 can be deployed in one or more configurations depending on the desired service type. The PCF 148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to the PCRF in 4G communication systems). The UDM can be configured to store subscriber profiles and data (similar to the HSS in 4G communication systems).

[0037] The LMF 133 can be used in conjunction with 5G positioning functionality. In some aspects, the LMF 133 receives measurement data and assistance information from the radio access network (RAN) 110 and mobile devices (e.g., UE 101) from the AMF 132 via an NLs interface to compute the location of the UE 101. In some aspects, the NR Positioning Protocol A (NRPPa) can be used to transfer positioning information between the NG-RAN and the LMF 133 over the next generation control plane interface (NG-C). In some aspects, the LMF 133 configures the UE using the LTE Positioning Protocol (LPP) through the AMF 132. The RAN 110 configures the UE 101 using the Radio Resource Control (RRC) protocol over the LTE-Uu and NR-Uu interfaces.

[0038] In some aspects, the 5G system architecture 140B configures different reference signals to enable positioning measurements. Example reference signals that can be used for positioning measurements include a positioning reference signal (NR PRS) in the downlink and a sounding reference signal (SRS) for positioning in the uplink. The downlink positioning reference signal (PRS) is a reference signal configured to support downlink-based positioning methods.

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

[0040] In some respects, the UDM / HSS146 can be coupled to an application server (AS) 160B, which may include a telephone application server (TAS) or another AS. The AS160B can be coupled to the IMS168B via an S-CSCF 164B or an I-CSCF 166B.

[0041] Reference points indicate that interactions can exist between corresponding NF services. For example, Figure 1BThe following reference points are illustrated: N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM / HSS 146 and AMF 132, not shown), N9 (between two UPFs, not shown), N10 (between UDM / HSS 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136, not shown), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and UDM / HSS 146, not shown), N14 (between two AMFs, not shown), N15 (between PCF 148 and AMF 132 in case of non-roaming scenario, or between PCF 148 and visited network and AMF 132 in case of roaming scenario, not shown), N16 (between two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Other reference points not shown in Figure 1B

[0042] Figure 1C A 5G system architecture 140C and service-based representation are illustrated. In addition to the network entities illustrated in Figure 1B

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

[0044] Figure 2 An example network architecture 200 is depicted. The network architecture 200 can operate in a manner consistent with the 3GPP Technical Specifications for LTE or 5G / NR systems, and can implement the disclosed techniques (e.g., the disclosed techniques can be configured / implemented by one or more devices operating within the network architecture 200). However, example embodiments are not so limited, and the examples can apply to other networks that benefit from the principles described in this disclosure, such as future 3GPP systems, etc.

[0045] ​The network architecture 200 includes a UE 202, which can be any mobile or non- mobile computing device for communicating with a RAN 204 over a wireless connection. The UE 202 is communicatively coupled with the RAN 204 over a Uu interface, which can be applicable for LTE and NR systems. Examples of the UE 202 include, but are not limited to, a smartphone, a tablet computer, a wearable device (e.g., a smartwatch, a fitness tracker, smart glasses, smart clothing / fabric, a head-mounted display, a smart display, etc.), a desktop computer, a workstation, a laptop computer, an in-vehicle infotainment system, an in-vehicle entertainment system, an instrument cluster, a head-up display (HUD) device, an in-vehicle diagnostic device, a mobile instrument cluster, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networking device, a machine type communication device, machine-to-machine (M2M), device-to-device (D2D), machine type communication (MTC) device, Internet of Things (IoT) device, a smart appliance, a flying drone or unmanned aerial vehicle (UAV), a ground unmanned vehicle or self-driving car, a robot, an electronic price tag, a single-board computer (SBC) (e.g., Raspberry Pi, Arduino, Intel Edison, etc.), a plug-computer, and / or any type of computing device such as any of those discussed in the present disclosure.

[0046] Additionally or alternatively, the UE 202 can be a reduced capability (RedCap) UE, which is a reduced capability UE as specified in clause 4.2.21.1 in 3GPP TS 38.306 v17.4.0 (2023-03-30) (“[TS 38 306]”).

[0047] The network architecture 200 can include a group of UEs 202 that are directly connected with each other over a D2D, ProSe, PC5, and / or SL interface, and / or any other suitable interface such as those described in the present disclosure. These UEs 202 can be M2M / D2D / MTC / IoT devices and / or in-vehicle systems that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH. The UEs 202 can perform blind decoding attempts on SL channels / links in accordance with various examples described in the present disclosure.

[0048] In some examples, the UE 202 can also communicate with the AP 206 via a wireless (OTA) connection. The AP 206 manages the WLAN connection, which can be used to offload some or all of the network traffic from the RAN 204. The connection between the UE 202 and the AP 206 can follow any IEEE 802.11 protocol. Further, the UE 202, RAN 204, and AP 206 can use cellular-WLAN aggregation / integration (e.g., LWA / LWIP). Cellular-WLAN aggregation can involve the UE 202 being configured by the RAN 204 to use both cellular and WLAN resources.

[0049] The RAN 204 includes one or more access network nodes (ANs) 208. The ANs 208 terminate the air interface protocol and can also be a base station, an eNodeB, gNode B, RAN node, ng-eNB, Node B, RSU, TRxP, and the like. AN 208 provides the UEs 202 with access to the core network 220. The ANs 208 can communicate with each other, including the AN 208 acting as a relay for other ANs 208.

[0050] One example implementation is a “CU / DU split” architecture, in which the AN 208 is implemented as a gNode B Central Unit (CU) that is communicatively coupled with one or more gNode B Distributed Units (DUs), where each DU can be communicatively coupled with one or more Radio Units (RUs) (also referred to as RRHs, RRUs, etc.) (see, e.g., [TS 38.401]). In some implementations, one or more RUs can be standalone RSUs. In some implementations, the CU / DU split can include ng-eNB-CU and one or more ng-eNB-DUs, respectively, instead of or in addition to gNB-CU and gNB-DU. The AN 208 functioning as a CU can be implemented in a stand-alone equipment or as one or more software entities running on a server computer, as part of a virtual network comprising 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), a virtualized RAN (vRAN), and the like (although these terms can refer to different implementation concepts). Any other type of architecture, arrangement, and / or configuration can be used.

[0051] The set of ANs can be coupled with each other via an X2 interface (if the RAN 204 is an LTE RAN or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 210) or an Xn interface (if the RAN 204 is an NG-RAN 214). The X2 / Xn interface, which can be split into control / user planes in some examples, can allow the ANs to communicate information related to handovers, data / context transfers, mobility, load management, interference coordination, and the like.

[0052] The ANs of the RAN 204 can each manage one or more cells, cell groups, component carriers, and the like, in order to provide an over-the-air interface for network access by UEs 202. A UE 202 can be concurrently connected to a set of cells provided by a same or different AN 208 of the RAN 204. For example, the UE 202 and the RAN 204 can use carrier aggregation to allow the UE 202 to connect with a set of component carriers, each corresponding to a Pcell or Scell. In a dual connectivity scenario, a first AN 208 can be a master node providing a MCG and a second AN 208 can be a secondary node providing a SCG. The first / second AN 208 can be any combination of eNBs, gNBs, ng-eNBs, and the like.

[0053] The RAN 204 can provide the over-the-air interface for the UEs 202 using

[0054] Additionally or alternatively, each UE 202 provides radio information to one or more ANs 208 and / or one or more edge computing nodes (e.g., edge servers / host, etc.). The radio information can take the form of one or more measurement reports and can include, for example, signal strength measurements, signal quality measurements, etc. Each measurement report is tagged with a timestamp and a measurement location (e.g., the current location of the UE 202).For example, the measurements collected by the UE 202 and / or included in the measurement report can include one or more of: bandwidth (BW), network or cell load, latency, jitter, round trip time (RTT), number of interruptions, packet out-of-order delivery, transmission power, bit error rate, bit error rate (BER), block error rate (BLER), packet error rate (PER), packet loss rate, packet reception rate (PRR), data rate, peak data rate, end-to-end (e2e) latency, signal-to-noise ratio (SNR), signal-to-noise-and-interference ratio (SINR), signal-plus-noise-plus-distortion-to-noise-plus-distortion (SINAD) ratio, carrier-to-interference-plus-noise ratio (CINR), additive white Gaussian noise (AWGN), energy-per-bit-to-noise-power-density ratio (Eb / N0), energy-per-chip-to-interference-power-density ratio (Ec / I0), energy-per-chip-to-noise-power-density ratio (Ec / N0), peak-to-average power ratio (PAPR), reference signal received power (RSRP), reference signal received path power (RSRPP), reference signal received quality (RSRQ), received signal strength indicator (RSSI), received channel power indicator (RCPI), received signal-to-noise indicator (RSNI), received signal code power (RSCP), reference signal carrier phase (RSCP), reference signal carrier phase difference (RSCPD), carrier phase positioning (CPP), reference signal time difference (RSTD), sidelink synchronization signal block (S-SSB) measurements including single sideband reverse, (received (linear) average power of resource elements that carry NR SSB signals and channels measured at the UE antenna connector or radiation interface boundary) and / or similar, relative time difference (RTD), receiver (Rx) time delay, Rx timing error, transmitter (Tx) time delay, Tx timing error, NR E-CID, observed time difference of arrival (OTDOA), average noise plus interference (ANPI), GNSS timing of cell frames for UE positioning for E-UTRAN or 5G / NR (e.g., timing between the AP or RAN node reference time and the GNSS specific reference time for a given GNSS), GNSS code measurements (e.g., GNSS code phase of the spreading code of the i-th GNSS satellite signal (integer and fractional parts)), GNSS carrier phase measurements (e.g., number of carrier phase cycles (integer and fractional parts) of the i-th GNSS satellite signal measured since the lock-on signal; also known as accumulated distance increment (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, power histogram measurements, channel load measurements, STA statistics, and / or other similar measurements.RSRP, RSSI, and / or RSRQ measurements can include RSRP, RSSI, and / or RSRQ measurements for cell-specific reference signals, channel state information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks of 3GPP networks (e.g., LTE or 5G / NR), and RSRP, RSSI, RSRQ, RCPI, RSNI, and / or ANPI measurements for various beacons, fast initial link setup (FILS) discovery frames, or probe response frames of WLAN / WiFi (e.g., [IEEE 802.11]) networks. Other measurements such as those discussed in 3GPP TS 36.214 v17.0.0 (2022-03-31) (“[TS 36 214]”), 3GPP TS 38.215 v17.3.0 (2023-03-30) (“[TS 38 215]”), 3GPP TS 38.314 v17.2.0 (2023-01-13) (“[TS 38 314]”), IEEE 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 (Feb. 26, 2021) (“[IEEE 802.11]”), and / or the like can additionally or alternatively be used. Additionally or alternatively, any of the aforementioned measurement values (or combinations of measurement values) can be collected by one or more ANs 208 and provided to an edge computing node.

[0055] Additionally or alternatively, the measurements can include one or more of the following measurements: measurements related to data radio bearers (DRBs) (e.g., number of DRBs attempted setup, number of DRBs successfully setup, number of active DRBs released, session active time of DRBs, number of DRBs attempted resume, number of DRBs successfully resumed, etc.); measurements related to radio resource control (RRC) (e.g., average number of RRC connections, maximum number of RRC connections, average number of stored inactive RRC connections, maximum number of stored inactive RRC connections, number of RRC connection setups attempted, successful, and / or failed, etc.); measurements related to UE context (UECNTX); measurements related to radio resource utilization (RRU) (e.g., DL total PRB usage, UL total PRB usage, DL total PRB usage distribution, UL total PRB usage distribution, DL PRBs for data traffic, UL PRBs for data traffic, DL total available PRBs, UL total available PRBs, etc.); measurements related to registration management (RM); measurements related to session management (SM) (e.g., number of PDU sessions requested setup; number of PDU sessions successfully setup; number of PDU sessions setup failed, etc.); measurements related to GTP management (GTP); measurements related to IP management (IP); measurements related to policy association (PA); measurements related to mobility management (MM) (e.g., for inter-RAT, intra-RAT, and / or intra- / inter-frequency handovers and / or conditional handovers: number of handover preparations requested, successful, and / or failed; number of handover resource allocations requested, successful, and / or failed; number of handover executions requested, successful, and / or failed; average and / or maximum time of handover execution requested; number of successful and / or failed handover executions per beam pair, etc.); measurements related to virtualization 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 release, session active time of QoS flows, session active time of UE 202, number of QoS flows attempted setup, number of QoS flows successfully established, number of QoS flows setup failed, number of initial QoS flows attempted setup, number of initial QoS flows successfully established, number of initial QoS flows setup failed, number of QoS flows attempted modification, number of QoS flows successfully modified, number of QoS flows modification failed, etc.); measurements related to application triggers (AT); measurements related to short message service (SMS); measurements related to power, energy, and environment (PEE); measurements related to NF services (NFS); measurements related to packet flow descriptions (PFD); measurements related to random access channels (RACH); measurements related to measurement reports (MR); measurements related to layer 1 measurements (L1M);Measurements related to Network Slice Selection (NSS); Measurements related to Paging (PAG); Measurements related to Non-IP Data Delivery (NIDD); Measurements related to External Parameter Provisioning (EPP); Measurements related to Traffic Impact (TI); Measurements related to Connection Establishment (CE); Measurements related to Service Parameter Provisioning (SPP); Measurements related to Background Data Transfer Policy (BDTP); Measurements related to Data Management (DM); and / or any other performance measurements discussed in, such as, 3GPP TS 28.552 v17.3.1 (2021-06-24) (“[TS 28 552]”), 3GPP TS 32.425 v17.1.0 (2021-06-24) (“[TS 32 425]”), and / or the like.

[0056] The radio information can be reported in response to a triggering event and / or periodically. Additionally or optionally, the individual UEs 202 can report the radio information at a low periodicity or a high periodicity, depending on the data transmission to occur and / or other information about the data transmission. Additionally or optionally, the edge computing node can request the measurements from the AN 208 at a low periodicity or a high periodicity, or the AN 208 can provide the measurement results to the edge computing node at a low periodicity or a high periodicity. Additionally or optionally, the edge computing node can obtain other relevant data, such as Key Performance Indicators (KPIs), from other edge computing nodes, core network functions (NFs), application functions (AFs), and / or other UEs 202, which can be obtained together with the measurement reports or separately from the measurement reports.

[0057] Additionally or optionally, in case there are discrepancies in the observation data from one or more UEs, one or more RAN nodes, and / or core network NFs (e.g., missing reports, erroneous data, etc.), simple imputation can be performed to supplement the obtained observation data, such as, for example, replacing values from previous reports and / or historical data, applying extrapolation filters, etc. Additionally or optionally, acceptable bounds of the observation data can be predetermined or configured. For example, CQI and MCS measurement values can be configured to be only within a range defined by a suitable 3GPP standard. In case of reported data values that are not reasonable (e.g., the values are outside of the acceptable range / bounds, etc.), these values can be discarded in the current learning / training phase or period. For example, a delay bound can be defined or configured when data packets are delivered, and data packets determined to be received after the data packet transmission delay bound can be discarded.

[0058] The UE 202 can also perform a determination reference signal (RS) measurement and reporting procedure to provide information to the network about the overall quality of one or more wireless channels and / or communication mediums, and which can be used to optimize various aspects of the communication system. As an example, the measurement and reporting procedure performed by the UE 202 can include procedures discussed in 3GPP TS 38.211 v17.4.0 (2023-01-04) (“[TS 38.211]”), 3GPP TS 38.212 v17.4.0 (2023-01-04) (“[TS 38.212]”), 3GPP TS 38.213 v17.4.0 (2023-01-04) (“[TS 38.213]”), 3GPP TS 38.214 v17.4.0 (2023-01-04) (“[TS 38.214]”), [TS 38.215], 3GPP TS 38.101-1 v18.0.0 (2023-01-12), (“[TS 38.101-1]”), 3GPP TS 38.104 v18.0.0 (2023-01-10) (“[TS 38.104]”), 3GPP TS 38.133 v18.0.0 (2023-01-12) (“[TS 38.133]”), [TS 38.331], and / or the like. Physical signals and / or RSs include demodulation reference signals (DM-RS), phase tracking reference signals (PT-RS), positioning reference signals (PRS), channel state information reference signals (CSI-RS), synchronization signal blocks (SSB), primary synchronization signals (PSS), secondary synchronization signals (SSS), and sounding reference signals (SRS).

[0059] In any of the examples discussed in the present disclosure, observation data can be collected using any suitable data collection and / or measurement mechanism. For example, any of the aforementioned metrics / observations can be determined using data tagging (e.g., sequence numbering, etc.), data packet tracking, signal measurement, data sampling, and / or timestamping techniques. Data collection can be based on the occurrence of an event that triggers data collection. Additionally or alternatively, data collection can be performed at the initiation or termination of an event. Data collection can be continuous, discontinuous, and / or have a start and stop time. Data collection techniques / mechanisms can be specific to a hardware configuration / implementation, non-specific to hardware, or can be based on various software parameters (e.g., operating system type and version, etc.). Any of the aforementioned data collection parameters can be defined using various configurations. Such configurations can be defined by suitable specifications / standards, such as 3GPP (e.g., [SA6 Edge]), ETSI (e.g., [MEC]), O-RAN (e.g., [O-RAN]), SmartEdge Open (formerly OpenNESS) (e.g., [ISEO]), IETF (e.g., MAMS [RFC 8743]), IEEE / WiFi (e.g., [IEEE 802.11], [WiMAX], [IEEE 16090], etc.), and / or any other similar standards (e.g., standards discussed by the present disclosure).

[0060] In V2X scenarios, a UE 202 or an AN 208 can be or function as a Roadside Unit (RSU), which can refer to any transportation infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by a UE can be referred to as a “UE-type RSU”; an eNB can be referred to as an “eNB-type RSU”; a gNB can be referred to as a “gNB-type RSU”; and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside to provide connectivity for UEs of passing vehicles. An RSU can also include internal data storage circuitry to store intersection map geometry, traffic statistics, and media, as well as applications / software to perceive and control ongoing vehicle and pedestrian traffic. An RSU can provide the extremely low latency communications needed for safety-of- life applications such as collision avoidance, high-speed traffic warnings. Additionally or alternatively, an RSU can provide other cellular / WLAN communication services. The components of an RSU can be encased in a weather-sealed housing suitable for outdoor installation and can include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network. Further, one or more V2X RATs can be employed that allow V2X nodes to communicate directly with each other, with infrastructure equipment (e.g., AN 208), and / or other devices / nodes. In some implementations, at least two different V2X RATs can be used, including a WLAN V2X (W-V2X) RAT based on IEEE V2X technology (e.g., DSRC in the United States and ITS-G5 in Europe) and a cellular V2X (C-V2X) RAT based on 3GPP V2X technology (e.g., LTE V2X, 5G / NR V2X, and beyond). In one example, the C-V2X RAT can use a C-V2X air interface, while the WLAN V2X RAT can use a W-V2X air interface.

[0061] W-V2X RATs include, for example: IEEE Guide for Wireless Access in Vehicular Environments Architecture, IEEE Standards Association, IEEE 1609.0-2019 (April 10, 2019) (“[IEEE 16090]”); SAE International, V2X Communications Message Set Dictionary, SAE International (July 23, 2020) (“[J2735_202007]”); Intelligent Transport Systems in the 5GHz frequency band, [IEEE 802.11p] (which is the Layer 1 (L1) and Layer 2 (L2) portion of WAVE, DSRC, and ITS-G5), and / or IEEE Standard for Air Interface for Broadband Wireless Access Systems, IEEE Std 802.16-2017, pp. 1-2726 (March 2, 2018) (“[WiMAX]”). The term “DSRC” refers to vehicle communications in the 5.9 GHz band that is commonly used in the United States, while “ITS-G5” refers to vehicle communications in the 5.9 GHz band that is used in Europe. Because any number of different RATs can be used (including the [IEEE 802.11p] RAT), and these technologies can be used in any geographic or political region, the terms “DSRC” (used in regions such as the United States) and “ITS-G5” (used in regions such as Europe) can be used interchangeably in this disclosure. The Access Layer of the ITS-G5 interface is outlined in ETSI EN 302 663 V1.3.1 (2020-01) (hereinafter “[EN 302 663]”), and describes the Access Layer of the ITS-S reference architecture. The ITS-G5 Access Layer includes [IEEE 802.11] (which has now incorporated [IEEE 802.11p]), as well as functionality for Decentralized Congestion Control (DCC) methods discussed in ETSI TS 102 687 V1.2.1 (2018-04) (“[TS 102 687]”).Access stratum based on 3GPP LTE-V2X interface is outlined in ETSI EN 303613 V1.1.1 (2020-01), 3GPP TS 23.285 v16.2.0 (2019-12); and 3GPP 5G / NR-V2X is outlined in 3GPP TR 23.786 v16.1.0 (2019-06) and 3GPP TS 23.287 v18.0.0 (2023-03-31) (“[TS 23 287]”).

[0062] In examples where the RAN 204 is an E-UTRAN 210 with one or more eNBs 212, the E- UTRAN 210 provides an LTE air interface (Uu) with parameters and characteristics at least as specified in 3GPP TS 36.300 v17.2.0 (2022-09-30) (“[TS 36 300]”). In examples where the RAN 204 is a Next Generation (NG)-RAN 214 with a set of gNBs 216, each gNB 216 connects with 5G-capable UEs 202 using a 5G-NR air interface (which can also be referred to as a Uu interface) with parameters and characteristics as described in [TS 38 300] and many other 3GPP standards. When the NG-RAN 214 includes a set of ng-eNBs 218, one or more ng-eNBs 218 connect with UEs 202 through a 5G Uu and / or an LTE Uu interface. The gNBs 216 and ng-eNBs 218 connect with the 5GC 240 through respective NG interfaces, including a N2 interface, a N3 interface, and / or other interfaces. The gNBs 216 and ng-eNBs 218 connect through an Xn interface. Also, individual gNBs 216 connect through respective Xn interfaces, and individual ng-eNBs 218 connect through respective Xn interfaces. In some examples, the NG interface can be split into two parts: an NG-User (NG-U) interface, which carries traffic data between nodes of the NG-RAN 214 and a UPF 248 (e.g., the N3 interface), and an NG-Control (NG-C) interface, which is a signaling interface between nodes of the NG-RAN 214 and the AMF 244 (e.g., the N2 interface).

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

[0064] The 5G-NR air interface can use BWPs for various purposes. For example, BWPs can be used for dynamic adjustment of SCS. For example, a UE 202 can be configured with multiple BWPs, each configured with a different SCS. When a BWP change is indicated to the UE 202, the SCS of the transmissions is also changed. Another use case for BWPs is related to power saving. Specifically, a UE 202 can be configured with multiple BWPs and allocated different amounts of frequency resources (e.g., PRBs) for each BWP to support data transmission in different traffic load scenarios. A BWP containing a smaller amount of PRBs can be used for data transmission in a small traffic load, while allowing power saving at the UE 202, and in some cases at the gNB 216. For scenarios with higher traffic load, a BWP containing a larger amount of PRBs can be used.

[0065] In some implementations, a single gNB 216 can include one gNB-CU and a set of gNB-DUs. Additionally, or alternatively, a gNB 216 can include one or more RUs. In these implementations, a gNB-CU can be connected to each gNB-DU via a respective FI interface. In the case of network sharing with multi-cell ID broadcast, each cell identity associated with a subset of PLMNs corresponds to a gNB-DU, and a gNB-CU is connected to share the same cell resource physical layer. To enable flexibility, one gNB-DU can be connected to multiple gNB-CUs by appropriate implementations. Further, a gNB-CU can be split into a gNB-CU control plane (gNB-CU-CP) function and a gNB-CU user plane (gNB-CU-UP) function. A gNB-CU-CP is connected to a gNB-DU through an FI control plane interface (FI-C), a gNB-CU-UP is connected to a gNB-DU through an FI user plane interface (FI-U), and a gNB-CU-UP is connected to a gNB-CU-CP through an El 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-CP. To enable flexibility, one gNB-DU and / or one gNB-CU-UP can be connected to multiple gNB-CU-CPs by appropriate implementations. One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and one gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP. Xn-U can support data forwarding between gNB-CU-UPs during intra-gNB-CU-CP handover.

[0066] Similarly, a single ng-eNB 218 can include one ng-eNB-CU and a set of ng-eNB-DUs. In these implementations, an ng-eNB-CU and each ng-eNB-DU are connected through a respective W1 interface. One ng-eNB can include one ng-eNB-CU-CP, one or more ng-eNB-CU-UPs, and one or more ng-eNB-DUs. One ng-eNB-CU-CP and one ng-eNB-CU-UP are connected through an El interface. One ng-eNB-DU is connected to one ng-eNB-CU-CP through a W1-C interface and to one ng-eNB-CU-UP through a W1-U interface. The general principles described in this disclosure with respect to the gNB aspects apply to the ng-eNB aspects and the corresponding El and W1 interfaces, unless explicitly stated otherwise.

[0067] The node carrying the user plane part of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and EN-DC, MeNB or SgNB depending on the bearer split) performs the user inactivity state monitoring. In addition, it informs the node with which the control plane connection is established with the core network (e.g., over El, X2, etc.) about its inactivity or (re-)activation state. The node carrying the RLC protocol layer (e.g., gNB-DU) can perform the user inactivity state monitoring and further inform the node carrying the control plane (e.g., gNB-CU or gNB-CU-CP) about its inactivity or (re-)activation state.

[0068] In these implementations, the NG-RAN 214 is split into a radio network layer (RNL) and a transport network layer (TNL). The NG-RAN 214 architecture (e.g., NG-RAN logical nodes and interfaces between them) is part of the RNL. For each NG-RAN interface (e.g., NG, Xn, Fl, etc.), the related TNL protocol and

[0069] The RAN 204 is communicatively coupled to the CN 220, which includes network elements and / or network functions (NFs) that operate to provide various functionalities to support providing data and telecommunications services to customers / subscribers (e.g., the UEs 202). The components of the CN 220 can be implemented in one physical node or in multiple separate physical nodes. In some examples, NFV can be used to virtualize any or all of the functions of the network elements of the CN 220 onto physical computing resources.

[0070] The CN 220 can be an LTE CN 222 (also referred to as an evolved packet core (EPC) 222). The EPC 222 can include MMEs 224, SGWs 226, SGSNs 228, HSSs 230, PGWs 232, and PCRFs 234, which are coupled to one another over the illustrated interfaces (or“reference points”). The NFs in the EPC 222 are briefly described as follows.

[0071] The MME 224 implements mobility management functions to track locations of UEs 202 for the purpose of paging, bearer activation / deactivation, handovers, gateway selection, authentication, etc. The SGW 226 terminates an S1 interface towards the RAN 210 and routes data packets between the RAN 210 and the EPC 222. The SGW 226 can also be a local mobility anchor point for inter-RAN node handovers, as well as for handovers between different radio technologies. Other responsibilities can include lawful intercept, charging, and some policy enforcement activities. The SGSN 228 tracks locations of UEs 202 and performs security functions and access control. The SGSN 228 also performs inter-EPC node signaling for mobility between different RATs, PDN and S-GW selection for handovers, etc. The S3 reference point between the MME 224 and the SGSN 228 supports exchange of subscriber and bearer information between the SGSN 228 and the MME 224 for 3GPP access network inter mobility in idle / active modes. The HSS 230 includes a network node database that contains subscriber-related information to support the network entities’ handling of communication sessions. The HSS 230 can support functions such as routing / mobility, authentication, authorization, naming / addressing resolution, location dependencies, etc. The S6a reference point between the HSS 230 and the MME 224 can support transfer of subscription and authentication data for authenticating / authorizing user access to the EPC 222. The PGW 232 can terminate an SGi interface toward the data network (DN) 236, which can include an application (app) / content server 238. The PGW 232 routes data packets between the EPC 222 and the data network 236. The PGW 232 is communicatively coupled with the SGW 226 by means of an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 232 can further include a node for policy enforcement and charging data collection (e.g., PCEF). Additionally, an SGi reference point can communicatively couple the PGW 232 with the same or a different data network 236. The PGW 232 can be communicatively coupled via a Gx reference point with the PCRF 234. The PCRF 234 is the policy and charging control element of the EPC 222. The PCRF 234 communicates with the application / content server 238 to determine appropriate quality of service and charging parameters for service flows. The PCRF 234 also provisions related rules (via the Gx reference point) into the PCEF along with appropriate TFTs and QCIs.

[0072] The CN 220 can be a 5GC 240 including an AUSF 242, an AMF 244, a SMF 246, a UPF 248, a NSSF 250, a NEF 252, a NRF 254, a PCF 256, a UDM 258, and an AF 260 coupled with one another over various interfaces as shown. The NFs in the 5GC 240 are briefly introduced as follows.

[0073] The AUSF 242 stores data used for authentication of the UE 202 and handles authentication-related functionality. The AUSF 242 can provide a common authentication framework for various access types.

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

[0075] The AMF 244 also supports NAS signaling with the UE 202 over the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF can be a termination point for the N2 interface between the (R)AN 204 and the AMF 244 for the control plane, and can be a termination point for the N3 reference point between the RAN 214 and 248 for the user plane. Thus, the AMF 244 handles N2 signaling from the SMF 246 and the AMF 244 for PDU sessions and quality of service; encapsulates / decapsulates packets in IPSec and N3 tunnels; marks N3 user-plane packets in uplink; and performs quality of service corresponding to the N3 packet marking according to the quality of service requirements received in N2 related to this marking. The N3IWF can also relay UL and DL control plane NAS signaling between the UE 202 and the AMF 244 via the N1 reference point, and relay uplink and downlink user plane packets between the UE 202 and the UPF 248. The N3IWF also provides mechanisms for establishing IPsec tunnels with the UE 202. The AMF 244 can exhibit a Namf service-based interface, and can be a termination point for the N14 reference point between two AMFs 244 and the N17 reference point between the AMF 244 and a 5G-EIR (not shown). Figure 2

[0076] ​The SMF 246 is responsible for SM (e.g., session establishment, maintenance, etc., tunnel management between UPF 248 and AN 208); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at the UPF 248 to route traffic to the proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and quality of service; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent over N2 between AMF 244 and AN 208, via AMF 244; and determining SSC mode of a session. SM refers to management of a PDU session, and a PDU session or “session” refers to a PDU connectivity service that provides or supports the exchange of PDUs between the UE 202 and a DN 236. The SMF 246 can also include the following functions to support edge computing enhancements (see, e.g., [TS 23 548]): select an EAS DFF 261 and provide its address to the UE as a DNS server for a PDU session; use the EAS DFF 261 service defined in [TS 23 548]; and provide and update ECS address configuration information to the UE in support of the application layer architecture defined in [TS 23 558]. The discovery and selection procedures for EAS DFF 261 are discussed in [TS 23 501] § 6.3.23.

[0077] The UPF 248 acts as an anchor point for intra-RAT and inter-RAT mobility, a external PDU session point of interconnect to data networks 236, and a branching point for support of multi-homed PDU session. The UPF 248 also performs packet routing and forwarding, packet inspection, enforce user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for user plane traffic (e.g., packet filtering, gating, uplink / downlink rate enforcement), perform Uplink Traffic verification (e.g., SDF to QoS flow mapping), transport layer packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 248 can include an uplink classifier to support routing traffic to the data network.

[0078] The NSSF 250 selects a set of network slice instances serving the UE 202. If needed, the NSSF 250 also determines the allowed NSSAI and mapping of subscribed S-NSSAIs, if applicable. The NSSF 250 also determines a list of AMF(s) or a candidate AMF 244 for the UE 202 based on a suitable configuration and possibly by querying the NRF 254. The selection of a set of network slice instances for a UE 202 can be triggered by the AMF 244 where the UE 202 is registered by interacting with the NSSF 250; this can result in a change of AMF 244. The NSSF 250 interacts with the AMF 244 via an N22 reference point and can communicate with another NSSF in a visited network over an N31 reference point (not shown).

[0079] The NEF 252 securely exposes 3 GPP NF-provided services and capabilities to third parties, internal exposure / re-exposure, AFs 260, edge computing, or fog computing systems (e.g., edge computing nodes, etc.). In these examples, the NEF 252 can authenticate, authorize, or throttle the AFs. The NEF 252 can also translate information exchanged with the AFs 260 and information exchanged with internal network functions. For example, the NEF 252 can translate between an AF-Service-Identifier and an internal 5GC information. The NEF 252 can also receive information from other NFs exposed capabilities. This information can be stored at the NEF 252 as structured data, or in a data storage NF using standardized interfaces. The NEF 252 can then re-expose the stored information to other NFs and AFs, or use it for other purposes such as analytics.

[0080] The NRF 254 supports service discovery functions, receives NF discovery requests from NF instances, and provides information of discovered NF instances to the requesting NF instances. The NRF 254 also maintains information of available NF instances and their supported services. The NRF 254 also supports service discovery functions where the NRF 254 receives an NF Discovery Request from an NF instance or SCP (not shown) and provides information of discovered NF instances to the NF instance or SCP.

[0081] The PCF 256 provides policy rules to control plane functions and enforces these rules, and it can also support a unified policy framework to govern network behavior. The PCF 256 can also implement a front end for accessing subscription information related to policy decisions in the UDR of the UDM 258. In addition to the communication with functions shown by reference points, the PCF 256 exhibits an Npcf service-based interface.

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

[0083] Edge Application Server Discovery Function (EASDF) 261 exposes a service-based Neasdf interface and connects to SMF 246 via N88 interface. One or more EASDF instances can be deployed within a PLMN, and interactions between 5GC NFs and EASDF 261 occur within the PLMN. EASDF 261 includes one or more of the following functions: registers with NRF 254 for EASDF 261 discovery and selection; processes DNS messages according to instructions from SMF 246; and / or terminates DNS security (if used). Processing DNS messages according to instructions from SMF 246 includes one or more of the following functions: receives DNS message processing rules and / or BaselineDNSPattern from SMF 246; exchanges DNS messages with UE 202 / exchanges DNS messages from UE 202; forwards DNS messages to C-DNS or L-DNS for DNS query; adds EDNS Client Subnet (ECS) option to DNS query for FQDN; reports information related to received DNS messages to SMF 246; and / or buffers / drops DNS messages from UE 202 or DNS server. EASDF establishes a direct user plane connection (e.g., without any NAT) with PSA UPF over N6 for transport of DNS signaling exchanged with the UE. The deployment of NAT between EASDF 261 and PSA UPF 248 can be supported or not supported. Other aspects of EASDF 261 are discussed in [TS 23 548].

[0084] AF 260 provides application influence on traffic routing, provides access to NEF 252, and interacts with the policy framework for policy control. AF 260 can influence (re)selection of UPF 248 and traffic routing. Based on operator’s deployment, when AF 260 is considered a trusted entity, the network operator can allow AF 260 to directly interact with relevant NFs. In some implementations, AF 260 is used for edge computing implementations.

[0085] 5GC 240 can support edge computing by selecting operator / third party services that are geographically close to the point of network access for UE 202, thereby reducing network latency and load. In edge computing implementations, 5GC 240 can select a UPF 248 close to UE 202 and perform traffic steering from UPF 248 to DN 236 via N6 interface. This can be based on UE subscription data, UE location, and information provided by AF 260, thereby enabling AF 260 to influence (re)selection of UPF and traffic routing.

[0086] A data network (DN) 236 can represent various network operator services, Internet access, or third-party services, which can be provided by one or more servers, including, for example, an application (app) / content server 238. The DN 236 can be an external public operator, a private PDN, or an intra-operator group data network, e.g., for providing IMS services. In the present example, the application server 238 can be connected to the IMS via an S-CSCF or an I-CSCF. In some implementations, the DN 236 can represent one or more local area data networks (LADNs), i.e., DNs 236 (or DN names (DNNs)) that are accessible to the UE 202 within one or more specific areas. Outside these specific areas, the UE 202 cannot access the LADN / DN 236.

[0087] Additionally, or alternatively, the DN 236 can be an edge DN 236, a (local) DN that supports an edge application-enabled architecture. In these examples, the application server 238 can represent a physical hardware system / device that provides application server functionality, and / or application software that executes server functionality residing on a cloud or edge compute node. In certain examples, the application / content server 238 provides an edge hosting environment that provides the required support for execution of an edge application server.

[0088] In some examples, the 5GS can use one or more edge compute nodes to provide interface and offload handling of wireless communication traffic. In these examples, the edge compute nodes can be included in, or co-located with, one or more of the RANs 210, 214. For example, an edge compute node can provide connectivity between the RAN 214 and a UPF 248 in the 5GC 240. The edge compute node can use one or more NFV instances instantiated on a virtualization infrastructure within the edge compute node to handle wireless connectivity to and from the RAN 214 and the UPF 248.

[0089] In some implementations, the edge computing nodes provide a distributed computing environment for application and service hosting and provide storage and processing resources so that data and / or content can be processed close to the subscribers (e.g., users of UEs 202), enabling faster response times. The edge computing nodes also support multi-tenant runtime and hosting environments for applications, including virtual appliance applications, middleware applications, and infrastructure services that can be delivered as packaged virtual machine (VM) images, content delivery services (including content caching), mobile big data analytics, and compute offload, among others. Compute offload involves offloading compute tasks, workloads, applications, and / or services from UEs 202, CN 220, DN 236, and / or servers 238 to edge computing nodes, and vice versa. For example, a device application or client application operating in a UE 202 can offload application tasks or workloads to one or more edge computing nodes. In another example, an edge computing node can offload application tasks or workloads to a group of UEs 202 (e.g., for distributed machine learning computations and / or the like).

[0090] The edge computing nodes can include or become part of an edge system that employs one or more edge computing technologies (ECTs) (also referred to as “edge computing frameworks” or the like). The edge computing nodes can also be referred to as “edge hosts” or “edge servers.” An edge system includes a collection of edge servers and edge management systems (not shown) that are needed to operate edge computing applications within an operator network or a subset of an operator network. An edge server is a physical computer system that can include an edge platform and / or virtualization infrastructure and provides compute, storage, and network resources for edge computing applications. Each edge server is disposed at the edge of a respective access network and is used to provide compute resources and / or various services (e.g., compute task and / or workload offload, cloud computing capabilities, IT services, and other similar resources and / or services as discussed in the present disclosure) relatively close to UEs 202. A VI of an edge computing node provides a virtualization environment and virtualization resources for edge hosts, and edge computing applications can run on top of the VI as VMs and / or application containers.

[0091] In one example implementation, the ECT is a MEC framework and / or operates in accordance with a MEC framework, as discussed in ETSI GR MEC 001 v3.1.1 (2022-01), ETSI GS MEC 003 v3.1.1 (2022-03), ETSI GS MEC 009 v3.1.1 (2021-06), ETSI GS MEC 010-1 vl.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 v2.1.1 (2020-10), U.S. Provisional Application No. 63 / 003,834 filed April 1, 2020 (“[US’834]”), and International Application No. PCT / US2020 / 066969 filed December 23, 2020 (“[PCT’696]”) (collectively referred to herein as “[MEC]”), the entire contents of each of which are hereby incorporated by reference into the present disclosure.This example implementation (and / or any other example implementation discussed in this disclosure) can also include NFV and / or other similar virtualization technologies such as those discussed in ETSI GR NFV001 V1.3.1 (2021-03), ETSI GS NFV 002 V1.2.1 (2014-12), ETSI GR NFV 003 V1.6.1 (2021-03), ETSI GS NFV 006 V2.1.1 (2021-01), ETSI GS NFV-INF 001 V1.1.1 (2015-01), ETSI GS NFV-INF 003 V1.1.1 (2014-12), ETSI GS NFV-INF 004 V1.1.1 (2015-01), ETSI GS NFV-MAN 001 v1.1.1 (2014-12), and / or OSM Release FIVE Technical Overview, ETSI Open Source MANO, OSM Whitepaper, Version 1 (January 2019), https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf (collectively “[ETSI NFV]”), the entire contents of each of which are hereby incorporated by reference into this disclosure. Other virtualization technologies and / or service orchestration and automation platforms such as those discussed in E2E Network Slicing Architecture, GSMA, Official Doc. NG.127, v1.0 (June 3, 2021), https: / / www.gsma.org / newsroom / wp-content / uploads / / NG.127-v1.0-2.pdf, Open Network Automation Platform (ONAP) documentation, Release Istanbul, v9.0.1 (February 17, 2022), https: / / docs.onap.org / en / latest / index.html (“[ONAP]”), 3GPP Service Based Management Architecture (SBMA) discussed in 3GPP TS 28.533 v17.1.0 (2021-12-23) (“[TS 28 533]”), the entire contents of each of which are hereby incorporated by reference into this disclosure, can be used.

[0092] In another example implementation, the ECT is part of and / or operates according to the O-RAN framework. Typically, front- and back-end equipment vendors and operators work closely to ensure compatibility. A drawback of this mode of operation is that it becomes difficult to plug-and-play with other equipment, and this can hinder innovation. To address this issue and to promote openness and interoperability at each layer, a number of key players interested in the wireless space (e.g., operators, equipment manufacturers, academic institutions, and / or the like) formed the Open RAN Alliance (O-RAN) in 2018. The O-RAN network architecture is a building block for designing virtualized RANs on programmable hardware with AI / ML driven radio access control. Various aspects of the O-RAN architecture are discussed 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-Architecture]”); O-RAN Operations and Maintenance Interface Specification v04.00, O-RAN Alliance WG1 (February 2021) (“[O-RAN.WG1.O1-Interface.0]”); O-RAN Information and Data Models Specification v01.00, O-RAN Alliance WG1 (February 2021); O-RAN Working Group 1 Slice Architecture v08.00 (October 2022); O-RAN Working Group 2 (Non-RT RIC and AI Interface Working Group) AI Interface: Application Protocol v03.02 (July 2021); O-RAN Working Group 1 Use Cases Detailed Specification v09.00 (October 2022) (“[O-RAN.WG1.Use-Cases]”); O-RAN Working Group 2 (Non-RT RIC and AI Interface WG) AI Interface: General Aspects and Principles v03.00 (October 2022) (“[O-RAN.WG2.A1GAP]”); O-RAN Working Group 2 (Non-RT RIC and AI Interface Working Group) AI Interface: Type Definitions v04.00 (October 2021); O-RAN Working Group 2 (Non-RT RIC and AI Interface Working Group) AI 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) 2021) (“[O-RAN.WG2.AI-ML-Workflow]”); O-RAN Working Group 2 (Non-RT RIC and AI Interface Working Group) AI Interface: Service Specification v03.00 (October 2022) (“[O-RAN.WG2.A1-Service-Specification]”); and O-RAN Working Group 2 (Non-RT RIC and AI Interface Working Group) AI Interface: Security Specification v03.00 (October 2022) (“[O-RAN.WG2.A1-Security-Specification]”).AIML]”); O-RAN Work Group 2 (Non-RT RIC and AI Interface Work Group) Non-RT RIC Architecture v02.01 (October 2022); O-RAN Work Group 2 Non-RT RIC: Functional Architecture v01.01, O-RAN Alliance WG2 (June 2021); O-RAN Work Group 2 (Non-RT RIC and AI Interface Work Group): R1 Interface: General Aspects and Principles v03.00, O-RAN Alliance WG2 (October 2022); O-RAN Work Group 3 Near-RT RAN Intelligent Controller Architecture and E2 General Aspects and Principles v02.02 (July 2022) (“[O-RAN.WG3.E2GAP]”); O-RAN Work Group 3 Near-RT Intelligent Controller E2 Service Model (E2SM) v02.01 (March 2022) (“[O-RAN.WG3.E2SM]”); O-RAN Work Group 3 Near-RT Intelligent Controller E2 Service Model (E2SM), Cell Configuration and Control v01.00 (October 2022) (“[O-RAN.WG3.E2SM-CCC]”); O-RAN Work Group 3 Near-RT Intelligent Controller E2 Service Model (E2SM) KPM v02.03 (October 2022) (“[O-RAN.WG3.E2SM-KPM]”); O-RAN Work Group 3 Near-RT Intelligent Controller E2 Service Model (E2SM) RAN Function Network Interface (NI) v01.00 (February 2020) (“[ORAN-WG3.E2SM-NI]”); O-RAN Work Group 3 Near-RT Intelligent Controller E2 Service Model (E2SM) RAN Control v01.03 (October 2022) (“[O-RAN.WG3.E2SM-RC]”); O-RAN Work Group 3, Near-RT Intelligent Controller, E2 Application Protocol (E2AP) v02.03 (October 2022) (“[O-RAN.WG3.E2AP]”); O-RAN Work Group 3 (Near-RT RAN Intelligent Controller and E2 Interface Work Group): Near-RT RIC Architecture v03.00 (October 2022) (“[O-RAN.WG3.RICARCH]”); O-RAN Work Group 4 (Open Front-haul Interface Work Group) Control, User, and Synchronization Plane Specification v09.00 (July 2022) (“[O-RAN-WG4.CUS.0]”); O-RAN Front-haul Work Group 4 Coordinated Transport Interface Transport Control Plane Specification v02.00, O-RAN Alliance WG4 (June 2021); O-RAN Front-haul Work Group 4 Coordinated Transport Interface Transport Management Plane Specification v02.00 (June 2021); O-RAN Front-haul Work Group 4 (Open Front-haul Interface Work Group): Management Plane Specification v09.00 (July 2022) (“[O-RAN.WG4.MP.0]”); O-RAN Alliance Working Group 501 O-CU-UP and O-CU-CP Interface Specification v04.00 (October 2022); O-RAN Alliance Working Group 501 O-DU Interface Specification v05.00 (October 2022); O-RAN Open F1 / W1 / E1 / X2 / Xn Interface 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 Design v02.00, O-RAN Alliance WG6 (February 2021); O-RAN Working Group 602 Interface General Aspects and Principles v02.00 (October 2022); O-RAN Working Group 6 (Cloudification and Orchestration Working 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 Whitebox Hardware Working Group Indoor Picocell Hardware Reference Design Specification with Split Option 6 for the Front-Haul v02.00, O-RAN Alliance WG7 (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt6]”); O-RAN WG7 Indoor Picocell (FR1) Hardware Reference Design Specification (with Split Architecture Option 7-2 v03.00), O-RAN Alliance WG7 (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt7-2]”); O-RAN WG7 Indoor Picocell (FR1) Hardware Reference Design Specification (with Split Architecture Option 8 v03.00) (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt8]”); O-RAN Whitebox Hardware Working Group Hardware Reference Design for Outdoor Microcell with Split Architecture Option 7.2 v03.00, O-RAN Alliance WG7 (October 2022) (“[O-RAN.WG7.OMC-HRD-Opt7-2]”); O-RAN Whitebox Hardware Working Group Hardware Reference Design for Outdoor Macrocell 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 Transport Network Element Management Interface v04.00, O-RAN Alliance WG9 (July 2022); O-RAN Open X-haul Transport Working Group Synchronization Architecture and Solutions 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 Architecture 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.0AM-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.O]”); O-RAN: Towards an Open and Intelligent RAN, O-RAN Alliance White Paper (October 2018); and U.S. Application No. 17 / 484,743, filed September 24, 2021 (collectively, “[O-RAN]”), the entire contents of which are incorporated by reference into the present disclosure.

[0093] In another example implementation, the ECT is and operates according to the 3rd Generation Partnership Project (3GPP) System Aspects Working Group 6 (SA6) architecture for supporting edge applications (referred to as “3GPP Edge Computing”), as discussed in the following documents: 3GPP TS 23.558 v18.1.0 (2022-12-23) (“[TS 23558]”), 3GPP TS 23.501 v18.0.0 (2022-12-21) (“[TS 23501]”), 3GPP TS 23.548 v17.4.0 (2022-09-22) (“[TS 23548]”), 3GPP TR 23.700-98 v18.0.0 (2022-12-23) (“[TR 23700-98]”), 3GPP TS 23.222 v18.0.0 (2022-12-23) (“[TS 23222]”), TS 33.122 v18.0.0 (2022-12-16) (“[TS 33122]”), and 3GPP TS 29.222 v17.1.0 (2021-06-25) (“[TS 29222]”), 3GPP TS 23.502 v18.0.0 (2022-12-21) (“[TS 23502]”), 3GPP TS 29.522 v18.0.0 (2022-12-16) (“[TS 29522]”), 3GPP TS 29.122 v18.0.0 (2022-12-16) (“[TS 29122]”), 3GPP TS 23.682 v17.3.0 (2022-06-15) (“[TS 23682]”), 3GPP TS 23.434 v18.3.0 (2022-12-23) (“[TS 23434]”), and 3GPP TS 23.401 v18.0.0 (2022-12-21) (collectively “[SA6 Edge]”), the entire contents of each of the foregoing documents are hereby incorporated by reference into the present disclosure.

[0094] In another example implementation, the ECT is and / or operates according to the Smart Edge Open framework (formerly known as OpenNESS), as discussed in the Smart Edge Open Developer Guide, Version 21.09 (30 September 2021), which is available at https: / / smart-edge-open.github.io / (“[ISEO]”), the entire contents of which are hereby incorporated by reference into the present disclosure.

[0095] In another example implementation, the ECT operates according to the Multi-Access Management Services (MAMS) framework, as discussed in the following documents: Kanugovi et al., Multi-Access Management Services (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (March 2020) (“[RFC 8743]”); 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, IETF A, QUIC Working Group (May 3, 2021); Zhu et al., User Plane Protocol for Multi-Access Management Services, IETF draft-zhu-intarea-mams-user-protocol-09, IETF A, INTAREA (March 4, 2020); and Zhu et al., Generic Multi-Access (GMA) Convergence Encapsulation Protocol, IETF RFC 9188 (February 2022) (collectively, “[MAMS]”), the entire contents of each of the foregoing documents are hereby incorporated by reference into the present disclosure.

[0096] It should be appreciated that the above edge computing framework / ECT and service deployment examples are merely illustrative examples of ECT, and the present disclosure is applicable to many other or additional edge computing / networking technologies in various combinations and layouts of network edge-located devices including the various edge computing networks / systems described in the present disclosure. Moreover, the techniques disclosed in the present disclosure can relate to other IoT edge network systems and configurations, and other intermediary processing entities and architectures can also be applicable for the purposes of the present disclosure. Examples of such edge computing / networking technologies include [MEC]; [O-RAN]; [ISEO]; [SA6Edge]; Content Delivery Networks (CDNs) (also known as “Content Distribution Networks,” etc.); Mobility Service Provider (MSP) edge computing and / or Mobility as a Service (MaaS) 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, etc. Moreover, the techniques disclosed in the present disclosure can relate to other IoT edge network systems and configurations, and other intermediary processing entities and architectures can also be applicable for the purposes of the present disclosure.

[0097] The 5GC 240 interface includes reference points and service-based interfaces. Reference points include N1 (between UE 202 and AMF 244), N2 (between RAN 214 and AMF 244), N3 (between RAN 214 and UPF 248), N4 (between SMF 246 and UPF 248), N5 (between PCF 256 and AF 260), N6 (between UPF 248 and DN 236), N7 (between SMF 246 and PCF 256), N8 (between UDM 258 and AMF 244), N9 (between the two UPF 248 points), N10 (between UDM 258 and SMF 246), N11 (between AMF 244 and SMF 246), N12 (between AUSF 242 and AMF 244), N13 (between AUSF 242 and UDM 258), and N14 (between the two AMF points). N15 (between PCF 256 and AMF 244 in non-roaming scenarios; or between PCF 256 and AMF 244 in the visited network in roaming scenarios), N16 (between two SMF 246; not shown), and N22 (between AMF 244 and NSSF 250). Alternatively, you can use... Figure 2 Other reference point representations not shown in the diagram. Figure 2 Service-based representations represent NFs within the control plane that allow other authorized NFs to access their services. Service-based interfaces (SBIs) include Namf (SBI provided by AMF 244), Nsmf (SBI provided by SMF 246), Nnef (SBI provided by NEF252), Npcf (SBI provided by PCF 256), Nudm (SBI provided by UDM 258), Naf (SBI provided by AF 260), Nnrf (SBI provided by NRF 254), Nnssf (SBI provided by NSSF 250), and Nausf (SBI provided by AUSF242). Alternatively, [the following can be used]... Figure 2 Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf). In some examples, NEF 252 may provide an interface to edge computing node 236x, which can be used to handle wireless connectivity with RAN 214.

[0098] In some implementations, the network architecture 200 can include an SMSF, which is responsible for SMS subscription checking and verification, and forwarding of SM messages to / from the UE 202 to / from other entities, such as an SMS-GMSC / IWMSC / SMS-router. The SMS can also interact with the AMF 244 and the UDM 258 to perform a notification procedure that the UE 202 is available for SMS transfer. (e.g., setting a UE-Not-Reachable flag, and notifying the UDM 258 when the UE 202 is available for SMS).

[0099] 5GS can also include an SCP (or a single instance of the SCP) that supports indirect communication (e.g., see 3GPP TS 23.501 § 7.1.1); delegated discovery (e.g., see 3GPP TS 23.501 § 7.1.1); message forwarding and routing to target NFs / NF services, communication security (e.g., authorization of NF service consumers to access NF service producer APIs) (e.g., see 3GPP TS 33.501), load balancing, monitoring, overload control, etc., as well as discovery and selection functions for the UDM 258, AUSF 242, UDR 259, PCF 256, and access to subscription data stored in the UDR based on a SUPI, SUCI, or GPSI of a UE (e.g., see [TS 23.501] § 6.3). The load balancing, monitoring, and overload control functions provided by the SCP can vary from implementation to implementation. The SCP can be deployed in a distributed fashion. There can be multiple SCPs in the communication path between NF services. The SCP, although not an NF instance, can also be deployed in a distributed, redundant, scalable fashion.

[0100] Figure 3 A wireless network 300 according to various embodiments is schematically illustrated. The wireless network 300 can include a UE 302 in wireless communication with an AN 304. The UE 302 and the AN 304 can be similar to like-named components described elsewhere in the present disclosure, and can be substantially interchangeable.

[0101] The UE 302 can be communicatively coupled with the AN 304 via a connection 306. The connection 306 is shown as an over-the-air interface to enable communicative coupling, and can be consistent with a cellular communication protocol, such as an LTE protocol or a 5G NR protocol operating at mmWave or sub-6 GHz frequencies.

[0102] The UE 302 can include a host platform 308 coupled with a modem platform 310. The host platform 308 can include application processing circuitry 312, which can be coupled with protocol processing circuitry 314 of the modem platform 310. The application processing circuitry 312 can run various applications for the UE 302 that generate (source) or draw (sink) application data. The application processing circuitry 312 can also implement one or more layer operations to send application data to, or receive application data from, a data network. These layer operations can include transport (e.g., UDP) and internet (e.g., IP) operations.

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

[0104] The modem platform 310 can also include digital baseband circuitry 316 that can implement one or more of the layer operations in the “below” layers of the network protocol stack that are performed by the protocol processing circuitry 314. These operations can include, for example, PHY operations including one or more HARQ-ACK functions: scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, multiple antenna port precoding / decoding, which can include one or more of space-time, space-frequency, or spatial coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and other related functions.

[0105] The modem platform 310 can also include transmit circuitry 318, receive circuitry 320, radio frequency circuitry 322, and radio frequency front end (RFFE) 324, which can include or connect to one or more antenna panels 326. Briefly, the transmit circuitry 318 can include digital-to-analog converters, mixers, intermediate frequency (IF) components, etc.; the receive circuitry 320 can include analog-to-digital converters, mixers, IF components, etc.; the radio frequency circuitry 322 can include low-noise amplifiers, power amplifiers, power tracking components, etc.; the RFFE 324 can include filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and placement of components of the transmit circuitry 318, receive circuitry 320, RF circuitry 322, RFFE 324, and one or more antenna panels 326 (collectively, “transmit / receive components”) can be specific to details of a particular implementation, e.g., whether communications are TDM or FDM, at millimeter-wave or sub-6 GHz frequencies, etc. In some embodiments, the transmit / receive components can be arranged in multiple, parallel transmit / receive chains, can be disposed in the same or different chips / modules, etc.

[0106] In some embodiments, the protocol processing circuitry 314 can include one or more control circuit instances (not shown) to provide control functionality for the transmit / receive components.

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

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

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

[0110] Figure 4 is a block diagram illustrating components of a machine, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed in this disclosure. Specifically, the Figure 4 A diagrammatic representation of hardware resources 400 is shown including one or more processors (or processor cores) 410, one or more memory / storage devices 420, and one or more communication resources 430, each coupled via a bus 440 or other interface. For embodiments utilizing node virtualization (e.g., NFV), a virtual machine manager 402 can be executed to provide an execution environment for one or more network slices / sub-slices to utilize hardware resources 400.

[0111] The one or more processors 410 can include, among other things, processors 412 and processors 414. The one or more processors 410 can be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed in this disclosure), or any suitable combination thereof.

[0112] The memory / storage devices 420 can include main memory, disk storage, or any suitable combination thereof. The memory / storage devices 420 can include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

[0113] The one or more communication resources 430 can include interconnection 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, the one or more communication resources 430 can include wired communication components (e.g., coupled via USB, Ethernet, etc.), cellular communication components, NFC components, (Bluetooth® or Bluetooth® Low Energy) (Bluetooth® or Bluetooth® Low Energy) Low Energy)) components, components, and other communication components.

[0114] The instructions 450 can include software, programs, applications, applets, application programs, or other executable code for causing the one or more processors 410 to perform one or more methods discussed in the present disclosure. The instructions 450 can reside entirely or partially within at least one of the one or more processors 410 (e.g., within a cache of the processor), the memory / storage device 420, or any suitable combination thereof. Further, any portion of the instructions 450 can be transferred from any combination of the one or more peripheral devices 404 or the one or more databases 406 to the hardware resources 400. Accordingly, the memory of the one or more processors 410, the memory / storage device 420, the one or more peripheral devices 404, and the one or more databases 406 are examples of computer-readable and machine-readable media.

[0115] Figure 5 Another example network architecture 500 is shown. The network architecture 500 can operate in a manner consistent with 3GPP technical specifications or 6G system technical reports. In some examples, the network architecture 500 can operate concurrently with the network architecture 200. For example, in some examples, the network architecture 500 can share one or more frequency or bandwidth resources with the network architecture 200. As one specific example, a UE (e.g., the UE 502) can be configured to operate in both the network architecture 500 and the network architecture 200. Such a configuration can be based on the UE, including circuitry configured to communicate with frequency and bandwidth resources of the network architectures 200 and 500. Generally, some elements of the network 500 can share one or more characteristics with elements of the network architecture 200. For brevity and clarity, these elements can not be repeated in the description of the network 500.

[0116] The network 500 can include a UE 502, which can include any mobile or non- mobile computing device designed to communicate via over-the-air connections with the RAN 508. The UE 502 can be similar to, for example, the UE 202. The UE 502 can be, but is not limited to, a smartphone, a tablet computer, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment, an in-vehicle entertainment device, an instrument cluster, a head-up display device, an on-board diagnostic device, a mobile device for instrument clusters, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine class communication device, a M2M or D2D device, an IoT device, and the like.

[0117] Although Figure 5 not explicitly shown in the network 500, in some examples, the network 500 can include a group of UEs directly coupled with each other via a sidelink interface. These UEs can be M2M / D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, and the like. Similarly, although Figure 5 not explicitly shown in the network 500, the UE 502 can be communicatively coupled with an AP such as the AP 206, as described in connection with Figure 2 Additionally, although Figure 5 not explicitly shown in the network 500, in some examples, the RAN 508 can include one or more ANs such as the AN 208, as described in connection with Figure 2 The RAN 508 and / or the ANs of the RAN 508 can be referred to as base stations (BSs), RAN nodes, or using other terminology or names.

[0118] The UE 502 and the RAN 508 can be configured to communicate via an air interface referred to as a sixth generation (6G) air interface. The 6G air interface can include one or more features such as terahertz (THz) or sub-terahertz (sub-THz) bandwidth communication or joint communication and sensing. The term “joint communication and sensing” used in this disclosure can refer to a system that allows for wireless communication via various types of multiplexing as well as radar-based sensing. The THz or sub-THz bandwidth used in this disclosure can refer to communication in a frequency range of 80 GHz and above. Such a frequency range is additionally or alternatively referred to as a “millimeter wave” or “mmWave” frequency range.

[0119] The RAN 508 can allow for communication between the UE 502 and a 6G Core Network (CN) 510. Specifically, the RAN 508 can facilitate transmission and reception of data between the UE 502 and the 6G CN 510. The 6G CN 510 can include various functions, such as the NSSF 250, NEF 252, NRF 254, PCF 256, UDM 258, AF 260, SMF 246, and AUSF 242. The 6G CN 510 can also include the UPF 248 and the DN 236, as shown in Figure 5

[0120] Further, the RAN 508 can also include various additional functions that are in addition to or instead of traditional cellular network functions, such as for a 4G or 5G network. Two such functions can include a Compute Control Function (Comp CF) 524 and a Compute Service Function (Comp SF) 536. The Comp CF 524 and Comp SF 536 can be part of or functions of a Computing Service Plane. The Comp CF 524 can act as a control plane function, providing functions such as management of Comp SF 536, generation and management of compute task contexts (e.g., create, read, modify, delete), interacting with underlying compute infrastructure for compute resource management, etc. The Comp SF 536 can act as a user plane function, acting as a gateway connecting compute service users (e.g., UEs 502) and compute nodes behind the Comp SF instance. Some functions of the Comp SF 536 can include: parsing compute service data received from users into compute tasks executable by compute nodes, acting as a service mesh ingress gateway or service API gateway, enforcing service and billing policies, performance monitoring and telemetry data collection, etc. In some examples, a Comp SF 536 instance can act as a user plane gateway to a cluster of compute nodes. A Comp CF 524 instance can control one or more Comp SF 536 instances.

[0121] ​Two other such functions can include a Communication Control Function (Comm CF) 528 and a Communication Service Function (Comm SF) 538, which can be part of the communication service plane. The Comm CF 528 can be a control plane function to manage the Comm SF 538, communication session creation / configuration / release, and to manage communication session context. The Comm SF 538 can be a user plane function for data transport. The Comm CF 528 and Comm SF 538 can be considered an upgrade of the SMF 246 and UPF 248, which have been described in connection with 5G systems in Figure 2 The upgrade provided by the Comm CF 528 and Comm SF 538 can support service-aware transport. For legacy (e.g., 4G or 5G) data transport, the SMF 246 and UPF 248 can still be used.

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

[0123] Another such function can be a service orchestration and chaining function (SOCF) 520, which can discover, orchestrate, and chain communication / computation / data services provided by functions in the network. Upon receiving a service request from a user, the SOCF 520 can interact with one or more of the Comp CF 524, Comm CF 528, and Data CF 522 to identify Comp SF 536, Comm SF 538, and Data SF 532 instances, configure service resources, and generate a service chain, which can include multiple Comp SF 536, Comm SF 538, and Data SF 532 instances and their associated computation endpoints. Workload processing and data movement can then take place within the generated service chain. The SOCF 520 can also be responsible for maintaining, updating, and publishing the created service chain.

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

[0125] Other such functions can include an evolved service communication proxy (eSCP) and a service infrastructure control function (SICF) 526, which can provide service communication infrastructure for both control plane services and user plane services. The eSCP can be related to the 5G service communication proxy (SCP) with added user plane service communication proxy capabilities. Thus, the eSCP is split into two parts: eCSP-C 512 and eSCP-U 534 for control plane service communication proxy and user plane service communication proxy, respectively. The SICF 526 can control and configure eCSP instances according to service traffic routing policies, access rules, load balancing configurations, performance monitoring, etc.

[0126] Another such function is the AMF 544. The AMF 544 can be similar to the 244 but with additional functionality. In particular, the AMF 544 can include a potential functional split, such as moving message forwarding functionality from the AMF 544 to the RAN 508.

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

[0128] The UE 502 can include an additional function, referred to as a computing client service function (comp CSF) 504. The comp CSF 504 can have control plane and user plane functions, and can interact with corresponding network-side functions, such as the SOCF 520, the Comp CF 524, the Comp SF 536, the Data CF 522, and / or the Data SF 532, for service discovery, request / response, computing task workload exchange, etc. The comp CSF 504 can also collaborate with the network-side functions to decide whether a computing task should be run on the UE 502, the RAN 508, and / or elements of the 6G CN 510.

[0129] The UE 502 and / or the computing CSF 504 can include a service mesh proxy 506. The service mesh proxy 506 can act as a proxy for service-to-service communication communication in the user plane. The functions of the service mesh proxy 506 can include one or more of addressing, security, load balancing, etc.

[0130] Figure 6 An artificial intelligence (AI) assisted communication architecture example is depicted for communication between a UE 605 and a RAN 610. More specifically, as described in further detail below, AI / machine learning (ML) models can be used or leveraged to facilitate wireless communication between the UE 605 and the RAN 610.

[0131] In this example, the UE 605 and the RAN 610 operate in a manner consistent with 3GPP technical specifications and / or 6G system technical reports. In some examples, the wireless cellular communication between the UE 605 and the RAN 610 can be part of, or run concurrently with, the network architecture 500, 200, and / or other networks described in the present disclosure.

[0132] The UE 605 can be similar to and share one or more features of the UE 202, 202a, 202t, 202i, UE 302, UE 502, UE 702, hardware resources 400, and / or some other UE or device, such as any described in the present disclosure. The UE 605 can be, but is not limited to, a smartphone, a tablet computer, a wearable computer device, a desktop computer, a laptop computer, a vehicle infotainment system, a vehicle entertainment device, an instrument cluster, a head-up display device, an on-board diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a connected device, a machine type communication device, a M2M or D2D device, an IoT device, and / or the like. The RAN 610 can be similar to and share one or more features of the RAN 214, RAN 508, and / or some other RAN described in the present disclosure.

[0133] As shown in FIG. 6, the AI-related elements of the UE 605 can be similar to those of the RAN 610. For ease of discussion, the present disclosure will describe various elements from the perspective of the UE 605. However, it should be understood that such discussion or description also applies to the elements of the RAN 610 with the same name / number unless explicitly stated otherwise. Figure 6

[0134] As previously mentioned, the UE 605 can include various elements or functions related to AI / ML. These elements can be implemented as hardware, software, firmware, and / or some combination thereof. For example, one or more elements can be implemented as part of the same hardware (e.g., a chip or multi-processor chip), software (e.g., a computing program), or firmware as another element.

[0135] ​One such element can be a data repository 615. The data repository 615 can be responsible for data collection and storage. In particular, the data repository 615 can collect and store RAN configuration parameters, measurement data, performance key performance indicators (KPIs), model performance indicators, etc., for model training, updating, and inference. More generally, collected data is stored in the repository. The stored data can be discovered and extracted by other elements in the data repository 615. For example, as shown, an inference data selection / filtering element 650 can retrieve data from the data repository 615. In various examples, the UE 605 can be configured to discover and request data from the data repository 615 in the RAN, and vice versa. More generally, the data repository 615 of the UE 605 can be communicatively coupled with the data repository 615 of the RAN 610, so that the respective data repositories of the UE and the RAN can share collected data.

[0136] Another such element can be a training data selection / filtering functional block 620. The training data selection / filtering functional block 620 can be configured to generate training, validation, and test data sets for model training. The training data can be extracted from the data repository 615. The data can be selected / filtered according to the particular AI / ML model to be trained. The data can be selected for conversion / augmentation / preprocessing (e.g., normalization) before being loaded into the data sets. The training data selection / filtering functional block 620 can label the data in the data sets for supervised learning. The generated data sets can then be input into a model training functional block 625 for model training.

[0137] As mentioned above, another such element can be a model training functional block 625. This functional block can be responsible for training and updating (retraining) AI / ML models. The selected models can be trained using the input data sets (including training, validation, and test) from the training data selection / filtering functional block. The model training functional block 625 can generate trained and tested AI / ML models that are ready for deployment. The generated trained and tested models can be stored in a model repository 635.

[0138] The model library 635 can be responsible for storage and exposure of AI / ML models, including trained and untrained models. Trained / updated models can be stored in the model library 635. Models and model parameters can be discovered and requested by other functional blocks, such as the training data selection / filtering functional block 620 and / or the model training functional block 625. In some examples, the UE 605 can discover and request AI / ML models from the model library 635 of the RAN 610. Similarly, the RAN 610 can discover and / or request AI / ML models from the model library 635 of the UE 605. In some examples, the RAN 610 can configure models and / or model parameters in the model library 635 of the UE 605.

[0139] Another such element can be the model management functional block 640. The model management functional block 640 can be responsible for managing AI / ML models generated by the model training functional block 625. Such management functions can include deploying trained models, monitoring model performance, etc. In model deployment, the model management functional block 640 can allocate and schedule hardware and / or software resources for inference based on received trained and tested models. “Inference” as used in this disclosure refers to a process of using trained AI / ML models to generate data analytics, operations, policies, etc. based on inputted inference data. In performance monitoring, based on wireless performance KPIs and model performance indicators, the model management functional block 640 can decide to terminate a running model, initiate model retraining, select other models, etc. For example, as shown, the model management functional block 640 of the RAN 610 can configure model management policies in the UE 605.

[0140] Another such element can be the inference data selection / filtering element 650. The inference data selection / filtering element 650 can be responsible for generating data sets for model inference in the inference functional block 645, as described below. Specifically, inference data can be extracted from the data store 615. The inference data selection / filtering element 650 can select and / or filter data according to deployed AI / ML models. The data can be transformed / enhanced / pre-processed according to the same transformations / enhancements / pre-processing as described for training data selection / filtering in the functional block 620. The generated inference data sets can be inputted into the inference functional block 645.

[0141] Another such element can be the inference functional block 645. The inference functional block 645 can be responsible for performing inference as described above. Specifically, the inference functional block 645 can use the inference data sets provided by the inference data selection / filtering element 650 and generate one or more results. These results can include data analytics, operations, policies, etc. These results can be provided to the performance measurement functional block 630.

[0142] The performance measurement function block 630 can be configured to measure performance indicators (e.g., accuracy, model bias, run-time latency, etc.) of the deployed and executing model based on the inference results for monitoring purposes. The model performance data can be stored in the data store 615.

[0143] Figure 7 An example aspect of a RAN split architecture is depicted. Figure 7 An example network deployment is shown, including an example next generation fronthaul (NGF) deployment 700a in which a UE 702 connects to an RU 730 (also referred to as a “remote radio unit 730,” “remote radio head 730,” or “RRH 730”) via an air interface, the RU 730 connects to a digital unit (DU) 731 via an NGF interface (NGFI)-I, the DU 731 connects to a central unit (CU) 732 via an NGFI-II, and the CU 732 connects to a core network (CN) 742 via a backhaul interface. In a 3GPP NG-RAN implementation (see, e.g., [TS 38401]), the DU 731 can be a distributed unit (the term “DU” can refer to a digital unit and / or a distributed unit, unless the context indicates otherwise, with respect to the present disclosure). The UE 702 can be the same as or similar to the UE 202 and / or any other UE or user / client device discussed in the present disclosure.

[0144] In some implementations, the NGF deployment 700a can employ a distributed RAN (D-RAN) architecture in which the CU 732, DU 731, and RU 730 are located at a cell site, while the CN 742 is located at a centralized site. Alternatively, the NGF deployment 700a can employ a centralized RAN (C-RAN) architecture in which one or more baseband units (BBUs) are centrally located for processing. In a C-RAN architecture, radio components are split into discrete components that can be located in different locations. In one example C-RAN implementation, only the RU 730 is located at a cell site, while the DU 731, CU 732, and CN 742 are centralized or located at a central location. In another example C-RAN implementation, the RU 730 and DU 731 are located at a cell site, while the CU 732 and CN 742 are located at a centralized site. In another example C-RAN implementation, only the RU 730 is provided at a cell site, the DU 731 and CU 732 are located at a RAN hub site, and the CN 742 is located at a centralized site.

[0145] The CU 732 is a central controller that can serve or connect to one or more DUs 731 and / or multiple RUs 730. The CU 732 is a network (logical) node that hosts higher / more top-level of network protocol functional split. For example, in a 3GPP NG-RAN and / or O-RAN architecture, the CU 732 hosts the radio resource control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) layers of a next generation NodeB (gNB), or hosts the RRC and PDCP protocol layers when included in or operating as an e-UTRA-NR gNB (en-gNB). The SDAP sublayer performs mapping between quality of service flows and data radio bearers (DRBs), and marks quality of service flow IDs (QFIs) in DL and UL data packets. The PDCP sublayer performs transport of user plane or control plane data; maintains PDCP sequence numbers (SNs); performs header compression and decompression using Robust Header Compression (ROHC) and / or Ethernet Header Compression (EHC) protocols; ciphering and deciphering; integrity protection and verification; provides timer based SDU discard; routing for split bearers; duplication and duplicate discarding; reordering and in-order delivery; and / or out-of-order delivery. In various implementations, the CU 732 terminates individual Fl interfaces (see, e.g., [TS 38401]) that connect with respective DUs 731.

[0146] The CU 732 can include a CU control plane (CP) entity (referred to as “CU-CP 732” in the present disclosure) and a CU user plane (UP) entity (referred to as “CU-UP 732” in the present disclosure). The CU-CP 732 is a logical node hosting the control plane part of the RRC layer and the PDCP protocol layer of the CU 732 (e.g., gNB-CU for an en-gNB or gNB). The CU-CP terminates the El interface connected with the CU-UP, and the Fl-C interface connected with the DUs 731. The CU-UP 732 is a logical node hosting the user plane part of the PDCP protocol layer (e.g., gNB-CU 732 for an en-gNB), and the user plane part of the PDCP protocol layer and the SDAP protocol layer (e.g., gNB-CU 732 for a gNB). The CU-UP 732 terminates the El interface connected with the CU-CP 732 and the Fl-U interface connected with the DUs 731.

[0147] The DU 731 controls wireless resources, such as time and frequency bands, in real time locally and allocates the resources to one or more UEs. The DU 731 is a network (logical) node that hosts the middle and / or bottom layers of the split of network protocol functions. For example, in a 3GPP NG-RAN and / or O-RAN architecture, the DU 731 hosts the radio link control (RLC) layer, medium access control (MAC) layer, and high-physical (PHY) layer of a gNB or en-gNB, and its operation is controlled at least in part by the CU 732. The RLC sublayer operates in one or more of transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). The RLC sublayer performs transfer of upper layer PDUs; independent of sequence numbering in PDCP (UM and AM); error correction by ARQ (AM only); segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs; reassembly of SDUs (AM and UM); duplicate detection (AM only); RLC SDU discard (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 more logical channels onto / from transport blocks (TBs) transferred to / from the physical layer; scheduling information reporting; error correction by HARQ (one HARQ entity per cell in case of CA); priority handling between UEs by dynamic scheduling; priority handling between logical channels of one UE by logical channel prioritization; priority handling between overlapping resources of one UE; and / or padding. In some implementations, the DU 731 can host a Backhaul Adaptation Protocol (BAP) layer (see, e.g., 3GPP TS 38.340 v16.5.0 (2021-07-07)) and / or an Fl application protocol (Fl-AP) (see, e.g., 3GPP TS 38.470 v16.5.0 (2021-07-01)), such as when the DU 731 operates as an Integrated Access and Backhaul (IAB) node. One DU 731 supports one or more cells, and one cell is supported by only one DU 731. The DU 731 terminates the Fl interface with the CU 732. Additionally or alternatively, the DU 731 can be connected to one or more RRHs / RUs 730.

[0148] The RU 730 is a physical node that serves as a Transmit / Receive Point (TRP) or other device for handling radio frequency (RF) processing functions. The RU 730 is a network (logical) node carrying lower-layer network functions based on lower-layer functional splits. For example, in 3GPP NG-RAN and / or O-RAN architectures, the RU 730 carries low-PHY layer functions and RF processing for radio interfaces based on lower-layer functional splits. The RU 730 can resemble a 3GPP TRP or RRH, but specifically includes a low-PHY layer. Examples of low-PHY functions include Fast Fourier Transform (FFT), Inverse FFT (IFFT), Physical Random Access Channel (PRACH) extraction, etc.

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

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

[0151] NGFI (also known as "xHaul") is a two-tier fronthaul architecture that divides the traditional RRU 730-to-BBU connection in the C-RAN architecture into two tiers: Tier I and Tier II. Tier I connects the RU 730 to the DU 731 via NGFI-I, and Tier II connects the DU 731 to the CU 732 via NGFI-II, as shown below. Figure 7The NGFI-I and NGFI-II connections can be wired connections or wireless connections, can use any suitable RAT, such as any suitable RAT described in the present disclosure. The goal of the two-level architecture is to distribute RAN node protocol functions between the CU 732 and the DUs 731 (split), thereby reducing latency and providing greater deployment flexibility. Generally, NGFI-I interfaces with lower layers of the functional split, which have strict requirements on latency and data rate. In contrast, NGFI-II interfaces with higher layers of the functional split, thereby relaxing the requirements on the fronthaul link as compared to the layers of NGFI-I. Examples of NGFI fronthaul interfaces and functional split architectures include O-RAN 7.2x fronthaul (e.g., see [O-RAN.WG9.XPSAAS] and [O-RAN-WG4.CUS.0]), C-RAN fronthaul based on enhanced Common Public Radio Interface (CPRI) (e.g., see Common Public Radio Interface: eCPRI Interface Specification, eCPRI Specification v2.0 (2019-05-10), Common Public Radio Interface: Requirements for eCPRI Transport Networks, eCPRI Transport Networks vl.2 (2018-06-25), and [O-RAN-WG4.CUS.0]), C-RAN fronthaul based on Radio over Ethernet (RoE) (e.g., see IEEE Standard for Ethernet Wireless Packaging and Mapping, IEEE Standards Association, IEEE 1914.3-2018) (2018-10-05) (“[IEEE1914.3]”), and / or the like. Other aspects of NGFI are also discussed in [O-RAN.WG9.XPSAAS]; [O-RAN-WG4.CUS.0]; IEEE Standard for Packet-Based Fronthaul Transport Networks, IEEE Standards Association, IEEE 1914.1-2019 (2020-04-21) (“[IEEE1914.1]”); [IEEE1914.3]; and Nasrallah et al., Ultra-Low Latency (ULL) Networks: A Comprehensive Survey Covering IEEE TSN Standards and Related ULL Research, arXiv:1803.07673v1 [cs.NI] (2018-03-20) (“[Nasrallah]”), the entire contents of each of which are hereby incorporated by reference into the present disclosure.

[0152] In one example, the deployment 700a can implement a low-level split (LLS) (also referred to as “low-level functional split 7-2x” or “split option 7-2x”) that operates between an RU 730 (e.g., an O-RU in an O-RAN architecture) and a DU 731 (e.g., an O-DU in an O-RAN architecture) (see, e.g., [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 example implementation, the NGFI-I is the open fronthaul interface described in the O-RAN open fronthaul specification (see, e.g., [O-RAN-WG4.CUS.0]). Other LLS options can be used, such as related interfaces described in other standards or specifications, e.g., 3GPP NG-RAN functional split (see, e.g., [TS 38 401] and 3GPP TR 38.801 v14.0.0 (2017-04-03)), Small Cell Forum for Split Option 6 (see, e.g., 5G Small Cell Architecture and Product Definition: Configuration and Specification for Companies Deploying Small Cells 2020-2025, Small Cell Forum, Document 238.10.01 (July 5, 2020) (“[SCF 238]”), 5G NR FR1 Reference Design: Generic Modular Architecture Case for 5G NR FR1 Small Cell Distributed Radio Units, Small Cell Forum, Document 251.10.01 (December 15, 2021) (“[SCF 251]”), and [O-RAN.WG7.IPC-HRD-Opt6], all of which are incorporated by reference into the present disclosure), and / or O-RAN Whitebox Hardware Split Option 8 (e.g., [O-RAN.WG7.IPC-HRD-Opt8]).

[0153] Additionally or alternatively, the CU 732, the DU 731, and / or the RU 730 can be an IAB node. IAB supports wireless relaying in NG-RAN, where a relaying node (referred to as an “IAB node”) supports both access and backhaul via 3GPP 5G / New Radio (NR) links / interfaces. The terminating node of the network-side NR backhaul is referred to as an “IAB-donating node,” which represents a RAN node (e.g., gNB) with additional functionality to support IAB. Backhauling can be via single-hop or multi-hop. All IAB nodes connected via single-hop or multi-hop to the IAB-donating node form a Directed Acyclic Graph (DAG) topology with the IAB-donating node as the root node. The IAB-donating node performs centralized resource, topology, and routing management for the IAB topology. The architecture of IAB is shown and described in [TS 38300].

[0154] While the NGF deployment 700a shows the CU 732, the DU 731, the RRH 730, and the CN 742 as separate entities, in other implementations, some or all of these network nodes can be bundled, combined, or otherwise integrated into a single device or element, including folding some internal interfaces (e.g., F1-C, F1-U, E1, E2, etc.). At least the following functionalities can be implemented: (i) an integrated CU 732 and DU 731 (e.g., CU-DU) connected to the RRH 730 via NGFI-I; (ii) an integrated DU 731 and RRH 730 (e.g., CU-DU) connected to the CU 732 via NGFI-II; (iii) an integrated RAN controller and CU 732 connected to the DU 731 via NGFI-II; (iv) an integrated CU 732, DU 731, and RU 730 connected to the CN 742 via a backhaul interface; and (v) an integrated network controller (or smart controller), CU 732, DU 731, and RU 730. Any of the above example implementations involving the CU 732 can also include an integrated CU-CP 732 and CP-UP 732,

[0155] Figure 7An example RAN disaggregation deployment 700b (also referred to as “disaggregated RAN 700b”) is also shown, in which a UE 702 is connected to a RRH 730, and the RRH 730 is communicatively coupled with one or more RAN Functions (RANFs) 1-N (where N is a number). The RANFs 1-N are disaggregated and geographically distributed across multiple components and network nodes. In some implementations, each RANF 1-N is a software (SW) element operated by a physical compute node, and the RRH 730 includes radio frequency (RF) circuitry (e.g., RF propagation modules for a particular RAT, and / or the like). In this example, RANF 1 is running on a physical compute node that is co-located with the RRH 730, and the other RANFs are deployed at locations that are farther away from the RRH 730. Also, in this example, the CN 742 is also disaggregated in the same or similar manner as the RANFs 1-N into CNFs 1-x (where x is a number). However, in other implementations, the CN 742 is not disaggregated.

[0156] Network disaggregation (or disaggregated networking) involves separating network equipment into functional components and allowing each component to be deployed separately. This can include separating SW elements (e.g., NFs) from specific hardware elements, and / or using APIs to support software-defined networking (SDN) and / or network function virtualization (NFV). RAN disaggregation involves network disaggregation and virtualization of various RANFs (e.g., RANFs 1-N in Figure 7 Based on use cases, the RANFs 1-N can be placed in different physical sites with different topologies in RAN deployments. This enables distribution and deployment of RANFs in different geographical areas and allows breakout of multiple RANFs to support various use cases (e.g., low latency use cases, etc.) as well as flexible RAN implementation. Disaggregation provides a common or unified RAN platform that can exhibit different characteristics depending on its deployment location. This allows for the use of fewer fixed function equipment and lower total cost of ownership compared to existing RAN architectures. The Telecom Infra Project (TIP) Open vRAN TM , [O-RAN], Open Optical & Packet Transport (OOPT), Reconfigurable Optical Add Drop Multiplexer (ROADM), etc. provide examples of RAN disaggregation frameworks.

[0157] In a first example implementation, the RANFs 1-N disaggregate the hardware and software (SW) of the RAN using commercial off-the-shelf (COTS) hardware (HW) and open interfaces (e.g., NGFI-I and NGFI-II, etc.). In this example implementation, each RANF 1-N can be a virtual BBU or vRAN controller operating on a COTS computing infrastructure that provides HW acceleration for the BBU / vRANF.

[0158] In a second example implementation, the RANFs 1-N disaggregate layers of one or more RAT protocol stacks. As an example of this implementation, RANF 1 is a DU 731 operating on a first COTS computing infrastructure that provides hardware acceleration for the BBU / vRANF, and RANF 2 is a virtual CU 732 operating on a second COTS computing infrastructure.

[0159] In a third example implementation, the RANFs 1-N disaggregate control plane and user plane functions. As an example of this implementation, RANF 1 is a DU 731 operating on a COTS computing infrastructure that provides hardware acceleration for the BBU / vRANF; RANF 2 is a virtual CU-CP 732 operating on a COTS computing infrastructure; and a third RANF (e.g., RANF 3 (not shown in FIG. 7)) is a virtual CU-UP 732 operating on the same or a different COTS computing infrastructure as the virtual CU-CP 732. Additionally or alternatively, in this implementation, one or more CN NFs 1-x can be CN-UP functions, and one or more other CN NFs 1-x can be CN-CP functions. Figure 7

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

[0161] ​In a fifth example implementation, the RANFs 1-N disaggregate different O-RAN RANFs, including E2SM. As an example of this implementation, RANF 1 implements near real-time RIC, RANF 2 implements E2SM-KPM, RANF 3 implements E2SM-CCC, RANF 4 implements E2SM RAN control, RANF 5 implements E2SM-NI, RANF 6 implements a function that provides an AI service, and so on.

[0162] In any of the implementations discussed in this disclosure, lower layers of the RAN protocol stack can feature real-time (RT) functions and relatively complex signal processing algorithms, while higher layers of the RAN protocol stack can feature non-RT functions. In these implementations, the RT functions and signal processing algorithms can be implemented in the DUs 731 and / or RRHs 730 using special-purpose network elements, or in COTS hardware equipped with special-purpose hardware accelerators.

[0163] Figure 7Various functional split options 700c for DL and UL directions are also shown. A traditional RAN is an integrated network architecture based on a distributed RAN (D-RAN) model, where the D-RAN integrates all RAN F into a few network elements. As previously mentioned, disaggregated RAN architectures provide flexible functional split options to overcome various deficiencies of the D-RAN model. A disaggregated RAN disaggregates the integrated network system into multiple functional components that can be individually repositioned as needed without impacting their ability to work together to provide overall network services. Split options 700c primarily split between a CU 732 and a DU 731, but can include splits between the CU 732, the DU 731, and a RU 730. For each option 700c, the protocol entities on the left side of the figure are included in a RAN F implementing the CU 732, and the protocol entities on the right side of the figure are included in a RAN F implementing the DU 731. For example, option 2 functional split includes separating non-RT processing (e.g., RRC and PDCP layers) from RT processing (e.g., RLC, MAC, and PHY layers), where the RAN F implementing the CU 732 performs network functions for the RRC and PDCP layers, and the RAN F implementing the DU 731 performs baseband processing functions for the RLC (including high RLC and low RLC), MAC (including high MAC and low MAC), and PHY layers. In some implementations, the PHY layer is further divided between the DU 731 and the RU 730, where the RAN F implementing the DU 731 performs high-PHY layer functions, and the RU 730 handles low-PHY layer functions. In some implementations, the low PHY entity can be operated by the RU 730 regardless of which functional split option is selected. Under the option 2 split, the RAN F implementing the CU 732 can be connected to multiple DUs 731 (e.g., the CU 732 is centralized), which allows for no RRC and PDCP anchor point change during handover across DUs 731, and allows the centralized CU 732 to pool resources across several DUs 731. In these ways, the option 2 functional split can improve resource efficiency. The specific functional split option used can vary depending on service needs and network deployment scenarios, and can be implementation specific. It should also be noted that in some implementations, all functional split options can be selected, where each protocol stack entity is operated by a respective RAN F (e.g., a first RAN F operates the RRC layer, a second RAN F operates the PDCP layer, a third RAN F operates the high RLC layer, and so on to an eighth RAN F operating the low PHY layer).Other splitting options are possible, such as discussed in [O-RAN.WG7.IPC-HRD-Opt6], [O-RAN.WG7.IPC-HRD-Opt7-2], [O-RAN.WG7.IPC-HRD-Opt8], [O-RAN.WG7.OMAC-HRD], and [O-RAN.WG7.OMC-HRD-Opt7-2].

[0164] For one or more embodiments, at least one of the components outlined in the foregoing one or more figures can be configured to perform one or more operations, techniques, processes, and / or methods described by the present disclosure, including the examples listed in the example section below. For example, baseband circuitry related to one or more of the foregoing figures can be configured to operate in accordance with one or more of the examples described below. For another example, circuitry related to a UE, base station, satellite, network element, etc. as described above in connection with one or more of the foregoing figures can be configured to operate in accordance with one or more of the examples described in the example section below.

[0165] The term “application” can refer to a complete and deployable package or environment that implements a particular functionality in an operating environment. The term “AI / ML application” and like terms can be an application that includes some artificial intelligence (AI) / machine learning (ML) models and application-level descriptions. In some embodiments, the AI / ML application can be used to configure or implement one or more aspects disclosed.

[0166] The term “machine learning” or “ML” refers to the use of computer systems to implement algorithms and / or statistical models to perform specific tasks without the use of explicit instructions, but rather by relying on patterns and reasoning. ML algorithms build or estimate mathematical models (referred to as “ML models” and the like) based on sample data (referred to as “training data,” “model training information,” and the like) to make predictions or decisions without being explicitly programmed to perform such tasks. Generally, a ML algorithm is a computer program that learns from experience with respect to some task and performance metric, while a ML model can be any object or data structure created after training a ML algorithm using one or more training data sets. After training, a ML model can be used to make predictions on new data sets. Although the term “ML algorithm” refers to a concept that is different from the term “ML model,” as discussed in the present disclosure, these terms can be used interchangeably in the present disclosure.

[0167] The terms“machine learning model,”“ML model,” and the like can also refer to ML methods and concepts used by ML-assisted solutions. An“ML-assisted solution” refers to a solution that uses ML algorithms to solve a particular use case in operation. ML models include supervised learning (e.g., linear regression algorithms, K-Nearest Neighbor (KNN) algorithms, decision tree algorithms, support vector machines, Bayesian algorithms, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, Principal Component Analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-armed bandit learning, deep reinforcement learning, etc.), neural networks, and the like. Depending on the implementation, a particular ML model can include multiple sub-models as constituent parts, and the ML model can train on all sub-models together. ML models that are trained separately can also be concatenated in a ML pipeline in inference. An“ML pipeline” is a set of functions, functions, or functional entities specific to an ML-assisted solution; an ML pipeline can include one or more data sources in a data pipeline, a model training pipeline, a model evaluation pipeline, and an actor. An“actor” is an entity that carries out an ML-assisted solution using the output of ML model inference. The term“ML training host” refers to an entity, such as a network function, that hosts model training. An“ML inference host” refers to an entity, such as a network function, that hosts a model during inference mode, which includes model execution and any online learning, as applicable. The ML host notifies an actor of the output of the ML algorithm, and the actor decides on an action to perform (“action” refers to an operation performed by the actor according to the output of the ML-assisted solution). The term“model inference information” refers to information used as input to an ML model to determine inference; the data used to train an ML model and the data used to determine inference can overlap; however,“training data” and“inference data” refer to different concepts.

[0168] The present disclosure defines or otherwise provides UE behaviors and capabilities to support cross-link interference management in cellular systems. The following discussion can apply to any type of UE or base station, such as Figures 1A-10 any UE or base station in a 5G system.

[0169] Mobile communications have evolved from early voice systems to today's highly sophisticated integrated communication platforms. The next generation wireless communication system, 5G, or New Radio (NR), will provide access to information and data, shared anytime and anywhere, for a variety of users and applications. NR is expected to be a unified network / system designed to meet vastly different, and sometimes conflicting, performance dimensions and services. These diverse multi-dimensional requirements are driven by different services and applications. Overall, NR will evolve based on 3GPP LTE-Advanced and introduce more potential new types of Radio Access Technologies (RATs) to enrich people's lives with better, easier, and seamless wireless connectivity solutions. NR will enable wireless connectivity with everything and provide fast, rich content and services.

[0170] Time Division Duplex (TDD) is currently widely used in commercial NR deployments, where time domain resources are split between downlink symbols and uplink symbols. In NR, TDD UL / DL configurations can be semi-statically configured by a gNB via tdd-UL-DLConfigurationCommon or tdd-UL-DL-ConfigurationDedicated. In addition, dynamic TDD is also introduced in NR. In this case, a gNB can dynamically allocate UL and DL resources, thus matching the instantaneous traffic conditions for UL and DL transmissions, respectively, which helps to maximize resource utilization and improve UE throughput.

[0171] However, specific cross-link interference (CLI) can occur in dynamic TDD systems if there is no coordination between gNBs, especially when considering two gNBs from different operators transmitting in the same frequency band.

[0172] Figure 8 A diagram 800 illustrating cross-link interference of a dynamic time division duplex (TDD) system is shown in accordance with some aspects.

[0173] Figure 9 A diagram 900 illustrating subband full duplex (SBFD) operation in a downlink (DL) symbol is shown in accordance with some aspects.

[0174] Figure 8One example of cross-link interference in a dynamic TDD system is shown. In this example, two types of (CLI) can be observed under dynamic TDD operation due to the difference in transmission direction between neighboring gNBs at a given time: UE-to-UE interference and gNB-to-gNB interference. For UE-to-UE interference, CLI occurs when a serving gNB’s DL transmission interferes with a UE’s UL transmission from a neighboring gNB. Also, for gNB-to-gNB interference, CLI occurs when a neighboring gNB’s DL transmission interferes with a UE’s UL transmission from a serving gNB.

[0175] Adjusting DL and UL transmission power in slots or symbols with or without CLI can flexibly manage CLI - by reducing CLI or providing robustness in the presence of CLI.

[0176] The techniques disclosed in this disclosure include DL and UL transmission power control methods for cross-link interference management.

[0177] Downlink (DL) transmit power control for CLI management

[0178] In some aspects, DL transmission power can be reduced by one (“aggressor”) gNB to minimize gNB-to-gNB CLI, thereby reducing the adverse impact on UL reception by one or more neighboring (“victim”) gNBs. Optionally, power for DL transmission to one or more (“victim”) UEs can be increased in order to provide robustness in the event that UL transmission by one or more (“aggressor”) UEs results in UE-to-UE CLI.

[0179] An example method for transmission power control in DL for CLI management is provided below.

[0180] While for most PDCCH and PDSCH transmissions, the gNB can adjust the DL transmit power in a manner transparent to the UE, for link adaptation it is beneficial to have CSI feedback corresponding to channel state information reference signal (CSI-RS) resources that can be transmitted with different DL transmit power levels. In this regard, it is noted that according to Rel-17 3GPP specifications, if the SS / PBCH block is associated with the serving cell PCI, the downlink CSI-RS resource element power (EPRE) can be derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower and a CSI-RS power offset given by the higher layer provided parameter powerControlOffsetSS; or if the SS / PBCH block is associated with an additional PCI different from the serving cell PCI, the downlink CSI-RS resource element power (EPRE) can be derived from ss-PBCH-BlockPower-r17 in SSBMTC-AdditionalPCI-r17 and the higher layer provided powerControlOffsetSS, where the CSI-RS is quasi co-located (QCLed) with the SS / PBCH block. The downlink reference signal transmit power is defined as the linear average of the power contributions (in [W]) of the resource elements that carry the configured CSI-RS within the operating system bandwidth.

[0181] In some aspects, the UE can be indicated a second value of the downlink CSI-RS resource element power (EPRE) that can be derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower and a second CSI-RS power offset given by the higher layer provided parameter powerControlOffsetSS-2, if the SS / PBCH block is associated with the serving cell PCI.

[0182] In some aspects, a second value of downlink CSI-RS resource energy per resource element power (EPRE) can be indicated to the UE if the SS / PBCH block is associated with an additional PCI different from the serving cell PCI, which can be derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower-r17 in SSB-MTC-AdditionalPCI-r17 and a second CSI-RS power offset given by the parameter powerControlOffsetSS-2 provided by higher layers, where the CSI-RS has a quasi co-location (QCLed) relationship with the SS / PBCH block.

[0183] In some aspects, a second value of downlink CSI-RS resource energy per resource element power (EPRE) can be indicated to the UE if the SS / PBCH block is associated with an additional PCI different from the serving cell PCI, which can be derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower-r17 in SSB-MTC-AdditionalPCI-r17 and a second CSI-RS power offset given by the parameter powerControlOffsetSS-2 provided by higher layers, where the CSI-RS has a quasi co-location (QCLed) relationship with the SS / PBCH block.

[0184] In some aspects, a second value of downlink CSI-RS resource energy per resource element power (EPRE) can be indicated to the UE if the SS / PBCH block is associated with an additional PCI different from the serving cell PCI, which can be derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower-r17 in SSB-MTC-AdditionalPCI-r17 and a second CSI-RS power offset given by the parameter powerControlOffsetSS-2 provided by higher layers, where the CSI-RS has a quasi co-location (QCLed) relationship with the SS / PBCH block.

[0185] Uplink (UL) transmit power control for CLI management

[0186] Similar to the case of DL transmission, in certain scenarios, the UL transmission power of the (potential "aggressor") UE can be reduced to minimize inter-UE CLI, or can be increased for certain UL transmissions that are used to be received at the (potential "victim") gNB in the presence of CLI from other DL transmissions (i.e. manifesting as inter-gNB CLI).

[0187] Example techniques of transmit power control in UL for CLI management are provided below.

[0188] In order to be able to apply different UL transmit power levels in time slots / symbols with or without CLI, some methods need to be employed to provide such indication to the UE through higher layer signaling or dynamic signaling or a combination of both. While it is feasible to achieve certain flexibility via closed-loop transmit power control (TPC), it depends on the amount of variation required between the transmit power in time slots / symbols with or without CLI, which can not be sufficient.

[0189] In some aspects, separate UL power control parameters can be provided for a UE to apply to different time slots or symbols. In some aspects, the different time slots or symbols can be identified based on a semi-static UL symbol, and can not be indicated via a cell-specific and / or UE-specific TDD DL-UL configuration.

[0190] In some aspects, the time slots or symbols for applying different UL power control parameters can be identified using a time slot format indication configuration that is different from a semi-static cell-specific or user equipment-specific TDD UL-DL time slot format configuration. In one example, such a configuration can be provided using a similar signaling mechanism as specified in 3GPP Release 15 TDD DL-UL configuration, but limited to two types of symbols. In another example, such a configuration can be provided using a bitmap over multiple symbols spanning a configuration period. Further, the period can be the same or different from the period indicated by the TDD DL-UL configuration.

[0191] In some aspects, the different time slots or symbols can be identified according to whether the time slots or symbols are identified for sub-band full duplex (SBFD) operation, i.e., whether they are identified as SBFD symbols / time slots or non-SBFD symbols / time slots. In another example, the different time slots or symbols can be identified according to a combination of the above criteria.

[0192] In some embodiments, for UL transmission cases spanning different types of symbols / slots associated with different sets of UL power control parameters, the UL power control parameters corresponding to the transmission in the semi-static UL symbols can be applied. In some aspects, this approach can be applied if separate UL power control parameters are applied to symbols / slots identified (or not identified) based on semi-static UL symbols.

[0193] In some aspects, for UL transmission cases spanning different types of symbols / slots associated with different sets of UL power control parameters, the selection of UL power control parameters can be determined based on the relative number of each type of slot / symbol that the transmission spans.

[0194] In some aspects, for UL transmission cases spanning different types of symbols / slots associated with different sets of UL power control parameters, the UL power control parameters that result in a smaller value of transmit power in both can be used. In another variant of this alternative, for UL transmission cases spanning different types of symbols / slots associated with different sets of UL power control parameters, the UL power control parameters that result in a larger value of transmit power in both can be used.

[0195] In some aspects, the criteria for determining the set of UL power control parameters according to one of the above rules can be configured to the UE via higher layers.

[0196] In some aspects, the above rules can apply at least to higher layer configured UL transmissions, which can include Configured Grant PUSCH (CG-PUSCH), periodic or semi-persistent PUCCH transmissions, PRACH transmissions not triggered by dynamic signaling, periodic or semi-persistent SRS, etc.

[0197] In some aspects, the use of a particular set of UL power control parameters for a given transmission can be overridden by an indication in the DCI format that triggers the UL transmission. In one example, such overriding behavior indicated by the scheduling DCI format can be limited to at least dynamically scheduled UL transmissions.

[0198] In some aspects, such overriding behavior indicated by the scheduling DCI format can apply to all UL transmissions occurring within a period of time after the UL transmission scheduled by the scheduling DCI format. Further, the duration of the period of time for which the particular set of UL power control parameters applies can be configured by higher layers.

[0199] In some aspects, the use of a particular UL power control parameter set for UL transmissions and / or symbols occurring over multiple slots can be overridden by an indication of a group common DCI format. Further, the number of slots and / or symbols can be explicitly indicated by the group common DCI format and can be indicated relative to the last symbol of the PDCCH receiving the group common DCI format. The indicated set of OLPC parameters can apply to UL transmissions only for transmissions mapped to a particular symbol type, or to all UL transmissions within the indicated time period. In another example, the periodicity length of a particular UL power control parameter set can be configured by higher layers, with the starting symbol relative to the last symbol of the PDCCH carrying the group common DCI format.

[0200] In some aspects, a UL power control parameter set can include one or more of the following: a “P0” value indicating a target SNR at the receiving gNB, an “alpha” value indicating a fractional pathloss compensation to be used in an UL transmit power control (TPC) equation as specified in 3GPP specifications, a TPC command accumulation behavior (whether to accumulate or not), and a set of TPC command offsets.

[0201] A wireless communication method of a 5G or NR system between a UE and a gNB uses one or more DL and UL transmission power control adjustments in different time instances to effectively manage CLI in a multi-cell system.

[0202] In some aspects, a UE is indicated a second value of downlink CSL-RS resource energy per resource element (EPRE) that is derived from a downlink transmit power of an SS / PBCH block given by a parameter ss-PBCH-BlockPower and a second CSI-RS power offset given by a parameter powerControlOffsetSS-2 provided by higher layers if the SS / PBCH block is associated with the serving cell PCI.

[0203] In some aspects, a second value of downlink CSI-RS resource energy per resource element power (EPRE) is indicated to the UE, if the SS / PBCH block is associated with an additional PCI different from the serving cell PCI, the value is derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower-r17 in SSB-MTC-AdditionalPCI-r17 and a second CSI-RS power offset given by the parameter powerControlOffsetSS-2 provided by higher layers, where the CSI-RS has a quasi co-location (QCLed) relationship with the SS / PBCH block.

[0204] In some aspects, a second value of downlink CSI-RS resource energy per resource element power (EPRE) is indicated to the UE, if the SS / PBCH block is associated with an additional PCI different from the serving cell PCI, the value is derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower-r17 in SSB-MTC-AdditionalPCI-r17 and a second CSI-RS power offset given by the parameter powerControlOffsetSS-2 provided by higher layers, where the CSI-RS has a quasi co-location (QCLed) relationship with the SS / PBCH block.

[0205] In some aspects, a second value of downlink CSI-RS resource energy per resource element power (EPRE) is indicated to the UE, if the SS / PBCH block is associated with an additional PCI different from the serving cell PCI, the value is derived from the SS / PBCH block downlink transmit power given by the parameter ss-PBCH-BlockPower-r17 in SSB-MTC-AdditionalPCI-r17 and a second CSI-RS power offset given by the parameter powerControlOffsetSS-2 provided by higher layers, where the CSI-RS has a quasi co-location (QCLed) relationship with the SS / PBCH block.

[0206] In some aspects, the additional offset can be a positive or negative value in decibels (dB) and can be added to the CSI-RS power offset in dB.

[0207] In some aspects, the UE is provided with separate UL power control parameters to apply in different slots or symbols.

[0208] In some aspects, the different slots or symbols are identified based on semi-static UL symbols or not as indicated via a cell-specific and / or UE-specific TDD DL-UL configuration.

[0209] In some aspects, the different slots or symbols are identified using a slot format indication configuration different from a semi-static cell-specific or UE-specific TDD UL-DL slot format configuration.

[0210] In some aspects, the configuration is provided using a similar signaling mechanism as specified in 3GPP Release 15 TDD DL-UL configuration, but limited to two types of symbols only.

[0211] In some aspects, for UL transmission occasions spanning different types of symbols / slots associated with different sets of UL power control parameters, the UL power control parameters corresponding to the transmission in the semi-static UL symbols are applied.

[0212] In some aspects, for UL transmission occasions spanning different types of symbols / slots associated with different sets of UL power control parameters, the UL power control parameters resulting in smaller transmit power values in both are used.

[0213] In some aspects, for UL transmission occasions spanning different types of symbols / slots associated with different sets of UL power control parameters, the UL power control parameters resulting in smaller transmit power values in both are used.

[0214] In some aspects, for UL transmission occasions spanning different types of symbols / slots associated with different sets of UL power control parameters, the UL power control parameters resulting in larger transmit power values in both are used.

[0215] In some aspects, the use of a particular set of UL power control parameters for a given transmission can be overridden by an indication in the DCI format triggering the UL transmission.

[0216] Figure 10 A block diagram of a communication device, such as an evolved Node B (eNB), a New Generation Node B (gNB) (or another RAN node), an access point (AP), a wireless station (STA), a mobile station (MS), or a user equipment (UE), according to some aspects is shown and performs one or more of the techniques disclosed in this disclosure. In alternative aspects, the communication device 1000 can operate as a standalone device or can be connected (e.g., networked) to other communication devices.

[0217] Circuitry (e.g., processing circuitry) is a collection of circuits implemented in tangible entities that include hardware (e.g., simple circuits, gates, logic, etc.). Circuitry membership can be flexible as circuits are often placed within the circuitry and removed from it. Circuitry includes members that may, alone or in combination, perform specified operations when operating. In one example, hardware of the circuitry can be immutably designed to carry out a specific operation (e.g., hardwired). In one example, the hardware of the circuitry can include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a machine-readable medium physically modified (e.g., magnetically, electrically,

[0218] In connecting the physical components, the base electrical properties of the hardware constituents can be changed, for example, from insulator to conductor or vice versa. The instruction can be embodied in the form of a hardware-embedded instruction set or other mechanisms such as, for example, micro-code. A machine-readable medium other than a propagating signal is used to store instructions embodying the instructions. The instruction set can be

[0219] In some aspects, the device 1000 can operate as a standalone device or can be connected (e.g., networked) to other devices. In a networked deployment, the communication device 1000 can operate in the capacity of a server communication device, a client communication device, or both in a server-client network environment. In an example, the communication device 1000 can act as a peer communication device in a peer-to-peer (P2P) (or other distributed) network environment. The communication device 1000 can be a UE, an eNB, a PC, a tablet PC, an STB, a PDA, a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any communication device that has the ability to execute instructions (sequential or otherwise) that specify actions to be taken by that communication device. Further, while only a single communication device is illustrated, the term "communication device" shall also be taken to include any collection of communication devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations, or the like.

[0220] As described in this disclosure, examples can include, or operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and can be configured or arranged in a certain manner. In an example, circuits can be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors can be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside on a communication device readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

[0221] Accordingly, the term“module” is understood to encompass a tangible entity, be that entity hardware or hardware capable of running software, that is physically constructed to perform certain operations (e.g., a portion of hardware) or is temporarily configured to perform certain operations (e.g., a portion of hardware configured by software) in a specified manner. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured by software, the general-purpose hardware processor can be configured as respective different modules at different times. Software can accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

[0222] The communication device (e.g., UE) 1000 can include a hardware processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware

[0223] The communication device 1000 can further include a display device 1010, an alphanumeric input device 1012 (e.g., a keyboard), and a User Interface (UI) navigation device 1014 (e.g., a mouse). In one example, the display device 1010, input device 1012, and UI navigation device 1014 can be a touch screen display. The communication device 1000 can additionally include a signal generation device 1018 (e.g., a speaker), a network interface device 1020, and one or more sensors 1021, such as a Global Positioning System (GPS) sensor, compass, accelerometer, or another sensor. The communication device 1000 can include an output controller 1028, such as a serial (e.g., Universal Serial Bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

[0224] The storage device 1016 can include a device readable medium 1022 on which is stored one or more sets of data structures or instructions 1024 (e.g., software) embodying any one or more of the techniques or functions described in this disclosure. In some aspects, a hardware processor 1002, the main memory 1004, the static memory 1006, and / or the registers of the storage device 1016 can be or include (in whole or in part) a device readable medium 1022 on which is stored one or more sets of data structures or instructions 1024 embodying any one or more of the techniques or functions described in this disclosure. In one example, the hardware processor 1002, the main memory 1004, the static memory 1006, or the storage device 1016, or any combination thereof, can constitute a device readable medium 1022.

[0225] As used in this disclosure, the term “device readable medium” can be interchangeable with “computer readable medium” or “machine readable medium.” While the communication device readable medium 1022 is illustrated as a single medium, the term “communication device readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store the one or more instructions 1024. The term “communication device readable medium” includes the term “machine readable medium” or “computer readable medium,” and can include any medium that is capable of storing, encoding, or carrying instructions (e.g., the instructions 1024) for execution by the communication device 1000 and that cause the communication device 1000 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by such instructions. Non-limiting communication device readable medium examples can include solid-state memories, and optical and magnetic media. Specific examples of a communication device readable medium can 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 disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, a communication device readable medium can include a non-transitory communication device readable medium. In some examples, a communication device readable medium can include a communication device readable medium that is non-transitory in nature.

[0226] The instructions 1024 can further be transmitted or received using a transmission medium via the network interface device 1020 utilizing any one of a number of transfer protocols. In one example, the network interface device 1020 can include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 1026. In one example, the network interface device 1020 can include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) techniques. In some examples, the network interface device 1020 can wirelessly communicate using multiple-user MIMO techniques.

[0227] The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the instructions for execution by the communication device 1000, and includes digital or analog communications signals or another intangible medium to facilitate communication of such software. In this manner, the transmission medium of the present disclosure is device readable medium.

[0228] The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" mean the same thing and can be used interchangeably in this disclosure. The terms are defined to include both machine storage media and transmission media. Accordingly, the terms include both storage devices / media and carrier waves / modulated data signals.

[0229] Implementations of the described subject matter can include one or more of the following features, alone or in combination.

[0230] Example 1 is an apparatus for a user equipment (UE) configured for operating in a Fifth Generation New Radio (5G NR) network, the apparatus comprising: processing circuitry, wherein, to configure the UE for cross-link interference management in the 5G NR network, the processing circuitry is to: decode first configuration signaling received from a base station, the first configuration signaling indicating a first set of one or more symbols and a second set of one or more symbols associated with a time division duplex (TDD) downlink-uplink (DL-UL) configuration; decode second configuration signaling received from the base station, the second configuration signaling including at least one UL power control parameter associated with the second set of one or more symbols; encode first UL data for transmission of the first UL data to the base station at a first power level during the first set of symbols; and encode second UL data for transmission of the second UL data to the base station at a second power level during the second set of symbols; and a memory coupled to the processing circuitry and configured to store the first configuration signaling and the second configuration signaling.

[0231] In Example 2, the subject matter of Example 1 includes, wherein the first configuration signaling is cell-specific or UE-specific TDD DL-UL configuration signaling.

[0232] In Example 3, the subject matter of Examples 1-2 includes, wherein the first configuration signaling is to configure a different slot format indication than the cell-specific or UE-specific TDD DL-UL configuration signaling.

[0233] In Example 4, the subject matter of Examples 1-3 includes, wherein the first configuration signaling is radio resource control (RRC) signaling to identify the second set of one or more symbols as symbols for sub-band full duplex (SBFD) operation.

[0234] In Example 5, the subject matter of Examples 1-4 includes, wherein the processing circuitry is to decode the first configuration signaling to determine UL transmission cases across different types of symbols or slots, the different types of symbols or slots being associated with different sets of UL power control parameters, and apply, in at least one UL transmission case, at least one UL power control parameter corresponding to transmission of second UL data in a semi-static UL symbol.

[0235] In Example 6, the subject matter of Example 5 includes, selecting the at least one UL transmission case to apply the at least one UL power control parameter based on a relative number of slots or symbols associated with each of the different types.

[0236] In Example 7, the subject matter of Examples 5-6 includes, selecting the at least one UL transmission case to apply the at least one UL power control parameter based on a minimum resulting transmission power associated with the at least one UL transmission case.

[0237] In Example 8, the subject matter of Examples 5-7 includes, selecting the at least one UL transmission case to apply the at least one UL power control parameter based on a highest resulting transmission power associated with the at least one UL transmission case.

[0238] In Example 9, the subject matter of Examples 1-8 includes, wherein the at least one UL power control parameter comprises one or more of: a PO value indicating a target signal-to-noise ratio (SNR) at a base station; an alpha value indicating an alpha value for fractional path loss compensation to be used in a UL transmit power control (TPC) equation; a TPC command accumulation behavior; and a set of TPC command offsets.

[0239] In Example 10, the subject matter of Examples 1-9 includes, a transceiver circuit coupled with the processing circuitry; and two or more antennas coupled to the transceiver circuit.

[0240] Example 11 is a computer-readable storage medium storing instructions for execution by one or more processors of a base station to configure the base station for cross-link interference management in a Fifth Generation New Radio (5G NR) and beyond network, and to cause the base station to perform operations comprising: encoding first configuration signaling for transmission to a user equipment (UE), the first configuration signaling indicating a first set of one or more symbols and a second set of one or more symbols associated with a time division duplex (TDD) downlink-uplink (DL-UL) configuration; encoding second configuration signaling received from the base station, the second configuration signaling including at least one UL power control parameter associated with the second set of one or more symbols; decoding first UL data in a first transmission received from the UE during the first set of symbols; and decoding second UL data in a second transmission received from the UE during the second set of symbols, the second transmission being associated with a power level based on the at least one UL power control parameter.

[0241] In Example 12, the subject matter of Example 11 includes, wherein the first configuration signaling is cell-specific or UE-specific TDD DL-UL configuration signaling.

[0242] Example 13 is a computer-readable storage medium storing instructions for execution by one or more processors of a user equipment (UE) to configure the UE for cross-link interference management in a Fifth Generation New Radio (5G NR) and beyond network, and to cause the UE to perform operations comprising: decoding first configuration signaling received from a base station, the first configuration signaling indicating a first set of one or more symbols and a second set of one or more symbols associated with a time division duplex (TDD) downlink-uplink (DL-UL) configuration; decoding second configuration signaling received from the base station, the second configuration signaling including at least one UL power control parameter associated with the second set of one or more symbols; encoding first UL data for transmission of the first UL data to the base station at a first power level during the first set of symbols; and encoding second UL data for transmission of the second UL signal or channel to the base station at a second power level during the second set of symbols, the second power level being based on the at least one UL power control parameter.

[0243] In Example 14, the subject matter of Example 13 includes, wherein the first configuration signaling is cell-specific or UE-specific TDD DL-UL configuration signaling.

[0244] In Example 15, the subject matter of Examples 13-14 includes, wherein the first configuration signaling is to configure a slot format indication different from cell-specific or UE-specific TDD DL-UL configuration signaling.

[0245] In Example 16, the subject matter of Examples 13-15 includes, wherein the first configuration signaling is radio resource control (RRC) signaling to identify the second set of one or more symbols as symbols for sub-band full duplex (SBFD) operation.

[0246] In Example 17, the subject matter of Examples 13-16 includes, the operations include: decoding the first configuration signaling to determine UL transmission cases across different types of symbols or slots associated with different sets of UL power control parameters; and applying, in at least one UL transmission case, at least one UL power control parameter corresponding to transmission of second UL data in a semi-static UL symbol.

[0247] In Example 18, the subject matter of Example 17 further includes selecting the at least one UL transmission case to apply the at least one UL power control parameter based on a relative number of slots or symbols associated with each of the different types.

[0248] In Example 19, the subject matter of Examples 17-18 further includes selecting the at least one UL transmission case to apply the at least one UL power control parameter based on a minimum resulting transmission power associated with the at least one UL transmission case.

[0249] In Example 20, the subject matter of Examples 17-19 further includes selecting the at least one UL transmission case to apply the at least one UL power control parameter based on a highest resulting transmission power associated with the at least one UL transmission case.

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

[0251] Example 22 is an apparatus comprising means for implementing any of Examples 1-20.

[0252] Example 23 is a system for implementing any of Examples 1-20.

[0253] Example 24 is a method for implementing any of Examples 1-20.

[0254] While one aspect has been described with regard to various example aspects, it will be obvious that various modifications and changes can be made of these aspects without departing from the broader scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. Thus, the detailed description is not to be taken as limiting in any regard and the scope of various aspects is to be accorded the full breadth of the appended claims, and any equivalents thereof.

Claims

1. An apparatus for a user equipment (UE) configured for operating in a Fifth Generation New Radio (5G NR) network, the apparatus comprising: processing circuitry, wherein, to configure the UE for cross-link interference management in the 5G NR network, the processing circuitry is to: decode first configuration signaling received from a base station, the first configuration signaling indicating a first set of one or more symbols and a second set of one or more symbols associated with a time division duplex (TDD) downlink-uplink (DL-UL) configuration; decode second configuration signaling received from the base station, the second configuration signaling including at least one UL power control parameter associated with the first set of one or more symbols; decode third configuration signaling received from the base station, the third configuration signaling including at least one UL power control parameter associated with the second set of one or more symbols; encode a first UL signal or channel for transmission to the base station at a first power level during the first set of symbols, the first power level based on the at least one UL power control parameter associated with the first set of one or more symbols; and encode a second UL signal or channel for transmission to the base station at a second power level during the second set of symbols, the second power level based on the at least one UL power control parameter associated with the second set of one or more symbols; and a memory coupled to the processing circuitry and configured to store the first configuration signaling and the second configuration signaling.

2. The apparatus of claim 1, wherein the first configuration signaling is cell-specific or UE-specific TDD DL-UL configuration signaling.

3. The apparatus of claim 1, wherein the first configuration signaling is to configure a different slot format indication than cell-specific or UE-specific TDD DL-UL configuration signaling.

4. The apparatus of claim 1, wherein the first configuration signaling is radio resource control (RRC) signaling to identify the second set of one or more symbols as symbols for sub-band full duplex (SBFD) operation.

5. The apparatus of claim 1, wherein the processing circuitry is to: decode the first configuration signaling to determine a UL transmission case that spans different types of symbols or slots, the different types of symbols or slots being associated with different sets of UL power control parameters; and transmit a UL signal or channel in the UL transmission case using a separate one of the first or second sets of UL power control parameters.

6. The apparatus of claim 5, wherein the processing circuitry is to: select the set of UL power control parameters based on a relative number of slots or symbols associated with each of the different sets of UL power control parameters.

7. The apparatus of claim 5, wherein the processing circuitry is to: selecting the set of UL power control parameters from different sets of UL power control parameters based on a minimum resulting transmission power associated with the UL transmission case.

8. The apparatus of claim 5, wherein the processing circuitry is to: select the set of UL power control parameters from different sets of UL power control parameters based on a maximum resulting transmission power associated with the UL transmission case.

9. The apparatus of any one of claims 1-8, wherein the at least one UL power control parameter comprises one or more of: a PO value indicating a target signal-to-noise ratio (SNR) at a base station; an alpha value indicating an alpha value for fractional path loss compensation to be used in an UL transmit power control (TPC) equation; a TPC command accumulation behavior; and a set of TPC command offsets.

10. The apparatus of any one of claims 1-9, further comprising: a transceiver circuit coupled with the processing circuitry; and two or more antennas coupled to the transceiver circuit.

11. A computer-readable storage medium storing instructions for execution by one or more processors of a base station, the instructions to configure the base station for cross-link interference management in Fifth Generation New Radio (5G NR) and beyond networks and cause the base station to perform operations comprising: encoding first configuration signaling for transmission to a user equipment (UE), the first configuration signaling indicating a first set of one or more symbols and a second set of one or more symbols associated with a time division duplex (TDD) downlink-uplink (DL-UL) configuration; encoding second configuration signaling for transmission to the UE, the second configuration signaling comprising at least one UL power control parameter associated with the first set of one or more symbols; encoding third configuration signaling for transmission to the UE, the third configuration signaling comprising at least one UL power control parameter associated with the second set of one or more symbols; decoding a first UL signal or channel received from the base station during the first set of symbols at a first power level, the first power level based on the at least one UL power control parameter associated with the first set of one or more symbols; and decoding a second UL signal or channel received from the base station during the second set of symbols at a second power level, the second power level based on the at least one UL power control parameter associated with the second set of one or more symbols.

12. The computer-readable storage medium of claim 11, wherein the first configuration signaling is cell-specific or UE-specific TDD DL-UL configuration signaling. ​ ​ 13. A computer-readable storage medium storing instructions for execution by one or more processors of a user equipment (UE) to configure the UE for cross-link interference management in a Fifth Generation New Radio (5G NR) and beyond network and to cause the UE to perform operations comprising: decoding first configuration signaling received from a base station, the first configuration signaling indicating a first set of one or more symbols and a second set of one or more symbols associated with a time division duplex (TDD) downlink-uplink (DL-UL) configuration; decoding second configuration signaling received from the base station, the second configuration signaling including at least one UL power control parameter associated with the first set of one or more symbols; decoding third configuration signaling received from the base station, the third configuration signaling including at least one UL power control parameter associated with the second set of one or more symbols; encoding a first UL signal or channel for transmission to the base station at a first power level during the first set of symbols, the first power level based on the at least one UL power control parameter associated with the first set of one or more symbols; and encoding a second UL signal or channel for transmission to the base station at a second power level during the second set of symbols, the second power level based on the at least one UL power control parameter associated with the second set of one or more symbols.

14. The computer-readable storage medium of claim 13, wherein the first configuration signaling is cell-specific or UE-specific TDD DL-UL configuration signaling.

15. The computer-readable storage medium of claim 13, wherein the first configuration signaling is for configuring a different slot format indication than cell-specific or UE-specific TDD DL-UL configuration signaling.

16. The computer-readable storage medium of claim 13, wherein the first configuration signaling is radio resource control (RRC) signaling identifying the second set of one or more symbols as symbols for sub-band full duplex (SBFD) operation.

17. The computer-readable storage medium of any one of claims 13-16, the operations comprising: decoding the first configuration signaling to determine a UL transmission case spanning different types of symbols or slots, the different types of symbols or slots being associated with different sets of UL power control parameters; and transmitting a UL signal or channel in the UL transmission case using a separate one of the first or second sets of UL power control parameters.

18. The computer-readable storage medium of claim 17, the operations comprising: selecting the set of UL power control parameters based on a relative number of slots or symbols associated with each of the different sets of UL power control parameters. ​ 19. The computer-readable storage medium of claim 17, the operations comprising: selecting the set of UL power control parameters from different sets of UL power control parameters based on a minimum resulting transmission power associated with the UL transmission scenario.

20. The computer-readable storage medium of claim 17, the operations comprising: selecting the set of UL power control parameters from different sets of UL power control parameters based on a highest resulting transmission power associated with the UL transmission scenario.

Images