Ptrs associated with dmrs for wireless transmission

Abstract

A user equipment (UE) is configured for physical uplink shared channel (PUSCH) transmission in a fifth generation new radio (5G NR) network. The UE includes front-end circuitry coupled to three or more antennas and processing circuitry coupled to the front-end circuitry. The processing circuitry is to receive control information in a downlink control information (DCI) format from a base station. The control information includes an indicator of an association between phase tracking reference signals (PTRS) and demodulation reference signals (DMRS) for scheduling a PUSCH transmission with 3 transmit antenna ports. The processing circuitry is to configure, based on the association: transmission of the DMRS and the PTRS for the PUSCH transmission, a location of the PTRS relative to the DMRS.

Description

[0001] Priority requirements This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 574,708, filed April 4, 2024, entitled “PTRS and DMRS Association for Multi-TRP and Multi-Panel PUSCH Transmission Using 3 Transmit Antennas,” which is incorporated herein by reference in its entirety. Background Technology

[0002] Mobile communications have evolved significantly from early voice systems to today's highly complex integrated communication platforms. The use of 3GPP LTE systems has increased with the growing number of different types of devices communicating with various network devices. The proliferation of mobile devices (User Equipment) in modern society continues to drive demand for a wide range of connected devices in diverse environments. The advent of fifth-generation (5G) wireless systems promises higher speeds, connectivity, and availability. Next-generation 5G networks (or NR networks) and their subsequent evolutions (e.g., 6G networks) are expected to increase throughput, coverage, and robustness, while reducing latency, operating expenses, and capital expenditures. 5G NR (and its subsequent evolutions) networks will be based on 3GPP LTE Advanced and will introduce other potential new radio access technologies (RATs) to enrich people's lives with seamless wireless connectivity solutions, providing fast, rich content and services. Given the current saturation of cellular network frequencies, higher frequencies, such as millimeter wave (mmWave) frequencies, may be beneficial due to their high bandwidth.

[0003] It is anticipated that future versions of 5G and its subsequent evolutionary communication systems will see further enhancements in the operation of LTE and NR systems in both licensed and unlicensed spectrum. Such enhanced operation may include techniques for configuring phase tracking reference signals (PTRS) and demodulation reference signals (DMRS) for multi-TRP and multi-panel PUSCH transmissions using three transmit antennas. Attached Figure Description

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

[0005] Figure 1A The diagram illustrates the network architecture based on several aspects.

[0006] Figure 1B and Figure 1C The diagram illustrates the architecture of a non-roaming 5G system based on several aspects.

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

[0008] Figure 6 The diagram illustrates an example artificial intelligence (AI) assisted communication architecture for communication between the UE and the RAN, based on several aspects.

[0009] Figure 7 The diagram illustrates an example RAN split architecture based on several aspects.

[0010] Figure 8 The diagram illustrates three transmit (Tx) antennas configured at the UE according to several aspects.

[0011] Figure 9 The diagram illustrates a block diagram of a communication device based on various aspects such as an evolved Node B (eNB), a next-generation Node B (gNB) (or another RAN node), an NCR, an access point (AP), a radio station (STA), a mobile station (MS), or a user equipment (UE). Detailed Implementation

[0012] The following description and accompanying drawings fully illustrate aspects that enable those skilled in the art to practice them. Other aspects may include structural, logical, electrical, technological, and other modifications. Parts and features of some aspects may be included in or substitute for parts and features of other aspects. The aspects set forth in the claims cover all available equivalents of these claims.

[0013] Figures 1A to 9 The illustrations depict various systems, devices, and components that can implement aspects of the disclosed embodiments in different communication systems, such as LTE (EUTRA) and 5G-NR (and their evolution) networks. The UEs, base stations (such as gNBs), and / or other nodes (e.g., satellites or other computing nodes) discussed herein can be configured to perform the disclosed technologies.

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

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

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

[0017] The aspects described herein can be used in the context of any spectrum management scheme, including, for example, dedicated licensed spectrum, unlicensed spectrum, and (licensed) shared spectrum (such as licensed shared access (LSA) in frequencies of 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz and above, and spectrum access systems (SAS) in frequencies of 3.55–3.7 GHz and above).

[0018] The aspects described in this article can also be applied to different single-carrier or OFDM styles (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDMA, etc.) by assigning OFDM carrier data bit vectors to corresponding symbol resources, as well as 3GPP NR (New Radio) in particular.

[0019] In some aspects, either UE 101 or UE 102 may include an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications utilizing ephemeral UE connections. In some aspects, either UE 101 or UE 102 may include a narrowband (NB) IoT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). IoT UEs may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) for exchanging data with MTC servers or devices via public terrestrial mobile networks (PLMNs), proximity services (ProSe), or device-to-device (D2D) communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated. IoT networks include interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) utilizing ephemeral connections. IoT UEs may execute background applications (e.g., keep-alive messaging, state updates, etc.) to facilitate connectivity within the IoT network.

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

[0021] UE 101 and UE 102 can be configured to connect to, for example, a radio access network (RAN) 110 for communication coupling. RAN 110 can be, for example, a Universal Mobile Telecommunications System (UMTS), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a Next Generation RAN (NG RAN), or some other type of RAN. UE 101 and UE 102 utilize connections 103 and 104, respectively, where each connection includes a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are illustrated as air interfaces for implementing communication coupling and can conform to cellular communication protocols such as the Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, Cellular Push-to-Talk (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, 5G protocol, New Radio (NR) protocol, etc.

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

[0023] UE 102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as, for example, a connection conforming to any IEEE 802.11 protocol, according to which AP 106 may include a 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).

[0024] 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., ground access points) or satellite stations that provide coverage within a geographical area (e.g., a cell). In some aspects, communication nodes 111 and 112 may be transmit / receive points (TRPs). In the case that communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may operate within the communication cell of the NodeB. RAN 110 may include one or more RAN nodes (e.g., macro RAN nodes) for providing macro cells, and one or more RAN nodes (e.g., low-power (LP) RAN nodes or secondary RAN nodes based on unlicensed spectrum) for providing femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells).

[0025] Either communication node 111 or 112 can terminate the air interface protocol and can be the first point of contact for UE 101 and UE 102. In some respects, 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, 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.

[0026] RAN 110 is shown communicatively coupled to core network (CN) 120 via S1 interface 113. In all respects, CN 120 can be an evolved packet core (EPC) network, a next-generation packet core (NPC) network, or some other type of CN (e.g., such as...). Figures 1B to 1C (As illustrated in the figure). In this respect, the S1 interface 113 is split into two parts: the S1-U interface 114, which carries user service data between communication nodes 111 and 112 and the serving gateway (S-GW) 122; and the S1-Mobility Management Entity (MME) interface 115, which is the signaling interface between communication nodes 111 and 112 and the MME 121.

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

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

[0029] P-GW 123 can terminate the SGi interface toward the PDN. P-GW 123 can route data packets between the EPC network (such as the core network 120) and external networks (such as a network containing application server 184 (alternatively referred to as Application Function (AF)) via Internet Protocol (IP) interface 125. P-GW 123 can also transmit data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Typically, application server 184 can be an element that provides applications using IP bearer resources of the core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). In this respect, P-GW 123 is shown as communicatively coupled to application server 184 via IP interface 125. Application server 184 can also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UE 101 and UE 102 via core network 120.

[0030] 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 CN 120. In non-roaming scenarios, in some aspects, a single PCRF may exist in the Home Public Land Mobile Network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In roaming scenarios with local service offloading, two PCRFs may exist associated with the UE's IP-CAN session: the Home PCRF (H-PCRF) within the HPLMN and the Visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). PCRF 126 can be communicatively coupled to application server 184 via P-GW 123.

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

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

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

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

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

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

[0037] In some aspects, the 5G system architecture 140B includes the 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) (not listed in the original text). Figure 1B (See diagram) or query 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 to act as a contact point within the operator's network for all IMS connections directed 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 170, such as an IMS operated by a different network operator.

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

[0039] 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 the two UPFs, not shown), N10 (between UDM / HSS 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136, not shown), N12 (between AMF 144 and AMF 132). N13 (between AMF 144 and UDM / HSS 146, not shown), N14 (between the two AMFs, not shown), N15 (between PCF 148 and AMF 132 in non-roaming scenarios, or between PCF 148 and the visited network and AMF 132 in roaming scenarios, not shown), N16 (between the two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Figure 1B Other reference points not shown in the diagram may also be used.

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

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

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

[0043] Network architecture 200 includes UE 202, which is any mobile or non-mobile computing device designed to communicate with RAN 204 via an over-the-air connection. UE 202 is communicatively coupled to RAN 204 via a Uu interface, which is applicable to both LTE and NR systems. Examples of UE 202 include, but are not limited to: smartphones, tablet computers, wearable devices (e.g., smartwatches, fitness trackers, smart glasses, smart clothing / fabrics, head-mounted displays, smart shows, and / or similar devices), desktop computers, workstations, laptop computers, in-vehicle infotainment systems, in-vehicle entertainment systems, dashboards, head-up displays (HUDs), in-vehicle diagnostic equipment, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networked home appliances, machine-type communication devices, machine-to-machine (M2M), device-to-device (D2D), machine-type communication (MTC) devices, Internet of Things (IoT) devices, smart appliances, flying drones or unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, electronic signage, single-board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel Edison, etc.), plug-in computers, and / or any type of computing device such as those discussed herein.

[0044] Alternatively or additionally, UE 202 may be a RedCap UE, which is a UE with reduced capabilities as specified in Clause 4.2.21.1 of 3GPP TS38.306 v17.4.0 (2023-03-30) (“[TS38306]”).

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

[0046] In some examples, UE 202 may additionally communicate with AP 206 via an over-the-air (OTA) connection. AP 206 manages the WLAN connection, which can be used to offload some / all network services from RAN 204. The connection between UE 202 and AP 206 can conform to any IEEE 802.11 protocol. Additionally, UE 202, RAN 204, and AP 206 may utilize cellular WLAN aggregation / integration (e.g., LWA / LWIP). Cellular WLAN aggregation may involve UE 202 being configured by RAN 204 to utilize both cellular radio resources and WLAN resources.

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

[0048] One example implementation is a “CU / DU split” architecture, in which the AN 208 is implemented as a gNB central unit (CU) communicatively connected to one or more gNB distributed units (DUs), where each DU may be communicatively coupled to one or more radio units (RUs) (also known as RRHs, RRUs, or the like) (see, for example, [TS38401]). In some implementations, the one or more RUs may be separate RSUs. In some implementations, the CU / DU split may include an ng-eNB-CU and one or more ng-eNB-DUs, replacing or attaching to the gNB-CU and gNB-DU, respectively. The AN 208 used as a CU may be implemented in a discrete device or as one or more software entities running on a server computer, as part of a virtual network including, for example, a virtual baseband unit (BBU) or BBU pool, cloud RAN (CRAN), radio equipment controller (REC), radio cloud center (RCC), centralized RAN (C-RAN), virtualized RAN (vRAN), and / or the like (although these terms may refer to different implementation concepts). Any other type of architecture, arrangement, and / or configuration may be used.

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

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

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

[0052] Additionally or alternatively, each UE 202 provides radio information to one or more AN 208s and / or one or more edge computing nodes (e.g., edge servers / hosts, etc.). The radio information may be in the form of one or more measurement reports and may include, for example, signal strength measurements, signal quality measurements, and / or similar measurements. Each measurement report is tagged with a timestamp and the location of the measurement (e.g., the current location of UE 202). As an example, by UE 202... Measurements collected and / or included in the measurement report may include one or more of the following: bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), number of interruptions, out-of-order delivery of data packets, transmission power, bit error rate, bit error ratio (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) delay, signal-to-noise ratio (SNR), signal-to-interference and noise-to-noise ratio (SINR), signal-plus-noise-plus-distortion to noise-plus-distortion ratio (SINAD), carrier-to-interference-to-noise ratio (CINR), additive white Gaussian noise (AWGN), energy per bit to noise power density ratio (Eb / N0). Energy-to-interference power density ratio per chip (Ec / I0), Energy-to-noise power density ratio per chip (Ec / N0), Peak-to-average power ratio (PAPR), Reference signal received power (RSRP), Reference signal received path power (RSRPP), Reference signal received quality (RSRQ), 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), Including SSB_RP (Bearer NR measured at the boundary of the UE antenna connector or radiating interface). The measurements include: received (linear) average power of SSB signal and channel resource elements; side-link synchronization signal block (S-SSB) measurements; 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 for cell frames used for UE positioning for E-UTRAN or 5G / NR (e.g., timing between AP or RAN node reference time and GNSS-specific reference time for a given GNSS); GNSS code measurements (e.g., the first...). i The GNSS code phase (integer and fractional parts) of the spreading code of the GNSS satellite signal, and GNSS carrier phase measurements (e.g., the 1st measurement since the lock signal). iThe number of carrier phase cycles (integer and fractional parts) of a GNSS satellite signal; also known as cumulative incremental distance (ADR)), channel interference measurement, thermal noise power measurement, received interference power measurement, power histogram measurement, channel load measurement, STA statistics and / or other similar measurements. RSRP, RSSI and / or RSRQ measurements may 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 for 3GPP networks (e.g., LTE or 5G / NR), and RSRP, RSSI, RSRQ, RCPI, RSNI and / or ANPI measurements for various beacons, Fast Initial Link Establishment (FILS) discovery frames or probe response frames for WLAN / WiFi (e.g., [IEEE 80211]) networks. Additionally or alternatively, other measurements may be used, such as those discussed in 3GPP TS 36.214 v17.0.0 (2022-03-31) (“[TS36214]”), 3GPP TS 38.215 v17.3.0 (2023-03-30) (“[TS38215]”), 3GPP TS 38.314 v17.2.0 (2023-01-13) (“[TS38314]”), IEEE Standard for Information Technology – Telecommunications and Information Exchange between Systems – Local Area Networks and Metropolitan Area Networks – Specific Requirements – Part 11: WLAN Media Access Control (MAC) and Physical Layer (PHY) Specification, IEEE Std 802.11-2020, pp. 1-4379 (February 26, 2021) (“[IEEE80211]”), and / or similar standards. Additionally or alternatively, any of the above measurements (or combinations of measurements) may be collected by one or more AN 208 and provided to edge computing nodes.

[0053] Additionally or alternatively, measurements may include one or more of the following: measurements related to data radio bearers (DRBs) (e.g., the number of DRBs attempted to be established, the number of DRBs successfully established, the number of active DRBs released, the in-session activity time for DRBs, the number of DRBs attempted to be resumed, the number of DRBs successfully resumed, etc.); measurements related to radio resource control (RRCs) (e.g., the average number of RRC connections, the maximum number of RRC connections, the average number of stored inactive RRC connections, the maximum number of stored inactive RRC connections, the number of attempted, successful, and / or failed RRC connection establishments, etc.); measurements related to UE context (UECNTX); and measurements related to radio resource utilization (RRUs) (e.g., total DL PRB usage, total UL PRB usage, the distribution of total DL PRB usage, the distribution of total UL PRB usage, DL PRBs used for data services, UL PRBs used for data services). PRB, DL total available PRB, UL total available PRB, etc.); Measurements related to Registration Management (RM); Measurements related to Session Management (SM) (e.g., number of PDU sessions requested to be established; number of PDU sessions successfully established; number of PDU sessions that failed to be established, 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-frequency / inter-frequency handover and / or conditional handover: requested, successful...). The number of successful and / or failed handover preparations; the number of requested, successful and / or failed handover resource allocations; the number of requested, successful and / or failed handover executions; the average and / or maximum time of requested handover executions; the number of successful and / or failed handover executions per beam pair, etc.); measurements related to virtualized resources (VR); measurements related to carrier (CARR); measurements related to Quality of Service (QoS) flows (QF) (e.g., the number of active QoS flows released, the number of QoS flows attempted to be released, the in-session activity time for QoS flows, and the time for UEs). Measurements related to: Session activity time (202), number of QoS flows attempted to be established, number of successfully established QoS flows, number of failed QoS flows, number of initial QoS flows attempted to be established, number of successfully established initial QoS flows, number of failed initial QoS flows, number of QoS flows attempted to be modified, number of successfully modified QoS flows, number of failed modified QoS flows, etc.; Application Triggered (AT) related measurements; Short Message Service (SMS) related measurements; Power, Energy, and Environment (PEE) related measurements; NF Service (NFS) related measurements; Packet Flow Description (PFD) related measurements; Random Access Channel (RACH) related measurements; Measurement Report (MR) related measurements.Measurements related to Layer 1 Measurement (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 Service Impact (TI); measurements related to Connection Establishment (CE); measurements related to Service Parameter Provisioning (SPP); measurements related to Back-End Data Delivery Policy (BDTP); measurements related to Data Management (DM); and / or any other performance measurements, such as those discussed in 3GPP TS 28.552 v17.3.1 (2021-06-24) (“[TS28552]”), 3GPP TS 32.425 v17.1.0 (2021-06-24) (“[TS32425]”) and / or similar documents.

[0054] Radio information may be reported in response to triggering events and / or periodically. Additionally or alternatively, each UE 202 may report radio information with low or high periodicity based on the data transmission to be performed and / or other information about that data transmission. Additionally or alternatively, multiple edge computing nodes may request measurements from AN 208 with low or high periodicity, or AN 208 may provide measurements to multiple edge computing nodes with low or high periodicity. Additionally or alternatively, multiple edge computing nodes may obtain other relevant data, such as key performance indicators (KPIs), from multiple other edge computing nodes, core network functions (NFs), application functions (AFs), and / or other UE 202s, either together with or separately from the measurement reports.

[0055] Additionally or alternatively, in cases where 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 interpolation can be performed to supplement the obtained observation data, such as, for example, replacing with values ​​from previous reports and / or historical data, applying extrapolation filters, and / or similar operations. Additionally or alternatively, acceptable limits for observation data can be predetermined or configured. For example, CQI and MCS measurements can be configured to be performed only within ranges defined by appropriate 3GPP standards. In cases where reported data values ​​are unreasonable (e.g., the value exceeds an acceptable range / limit, etc.), such values ​​can be discarded for the current learning / training segment or round. For example, in packet delivery, delay limits can be defined or configured, and packets received after a packet delivery delay limit can be discarded.

[0056] UE 202 can also perform reference signal (RS) measurement and reporting procedures to provide the network with information about the quality of one or more wireless channels and / or the overall communication medium, and this information can be used to optimize various aspects of the communication system. As an example, the measurement and reporting procedures performed by UE 202 may include 3GPP TS 38.211 v17.4.0 (2023-01-04) (“[TS38211]”), 3GPP TS 38.212 v17.4.0 (2023-01-04) (“[TS38212]”), 3GPP TS38.213 v17.4.0 (2023-01-04) (“[TS38213]”), 3GPP TS 38.214 v17.4.0 (2023-01-04) (“[TS38214]”), [TS38215], and 3GPP TS 38.101-1 v18.0.0 (2023-01-12) (“[TS38.101-1]”), 3GPP TS 38.104 v18.0.0 (2023-01-10) (“[TS38104]”), 3GPP TS 38.133 v18.0.0 (2023-01-12) (“[TS38133]”), [TS38331] and / or those discussed therein. Physical signals and / or RS may 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).

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

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

[0059] W-V2X RATs include, for example, the IEEE Wireless Access Guidelines for Vehicular Environments (WAVE) architecture, the IEEE Standards Association, IEEE 1609.0-2019 (April 10, 2019) (“[IEEE16090]”), the V2X Communication Message Set Dictionary, SAE International (July 23, 2020) (“[J2735_202007]”), 5 GHz band Intelligent Transportation Systems (ITS-G5), [IEEE 80211p] (which is the Layer 1 (L1) and Layer 2 (L2) portion of WAVE, DSRC, and ITS-G5) and / or the IEEE Broadband Wireless Access Systems Air Interface Standard, IEEE Std 802.16-2017, pp. 1-2726 (March 2, 2018) (“[WiMAX]”). The term "DSRC" refers to vehicular communications in the 5.9 GHz band typically used in the United States, while "ITS-G5" refers to vehicular communications in the 5.9 GHz band in Europe. Since any number of different RATs (including the [IEEE 80211p] RAT) are applicable and can be used in any geographic or political region, the terms "DSRC" (used in the United States, among other regions) and "ITS-G5" (used in Europe, among other regions) may 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 referred to as "[EN302663]"), which describes the access layer for the ITS-S reference architecture. The ITS-G5 access layer includes [IEEE 80211] (which now includes [IEEE 80211p]), as well as features for distributed congestion control (DCC) methods discussed in ETSI TS 102 687V1.2.1 (2018-04) (“[TS102687]”). The access layer based on 3GPP LTE-V2X (multiple) interfaces is mainly outlined in ETSI EN 303 613 V1.1.1 (2020-01), 3GPP TS23.285 v16.2.0 (2019-12), and other documents; while 3GPP 5G / NR-V2X is mainly outlined in 3GPP TR23.786 v16.1.0 (2019-06) and 3GPP TS 23.287 v18.0.0 (2023-03-31) (“[TS23287]”) and other documents.

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

[0061] NG-RAN 214 can provide a 5G-NR air interface (also known as a Uu interface) with the following characteristics: variable SCS; CP-OFDM for DL, and CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, monomorphic codes, and Reed-Müller codes for control, and LDPC codes for data. The 5G-NR air interface can rely on CSI-RS, PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface may not use CRS, but can use PBCH DMRS for PBCH demodulation, PTRS for phase tracking against PDSCH, and a tracking reference signal for time tracking. The 5G-NR air interface can operate on the FR1 band, including sub-6 GHz, or the FR2 band, including the 24.25 GHz to 52.6 GHz band. The 5G-NR air interface may include an SSB, which is a region of the DL resource grid that includes PSS / SSS / PBCH.

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

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

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

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

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

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

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

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

[0070] CN 220 can be 5GC 240, which includes AUSF 242, AMF 244, SMF 246, UPF 248, NSSF 250, NEF252, NRF 254, PCF 256, UDM 258, and AF 260. They are coupled to each other through the interfaces shown in the figure. A brief description of each NF in 5GC240 is as follows.

[0071] The AUSF 242 stores data used for UE 202 authentication and handles authentication-related functions. The AUSF 242 can support common authentication frameworks for various access types.

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

[0073] AMF 244 also supports NAS signaling with UE 202 via the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF can be the termination point of the N2 interface between RAN 204 and AMF 244 for the control plane, and can be the termination point of the N3 reference point between RAN 214 and UPF 248 for the user plane. Thus, AMF 244 processes N2 signaling from SMF246 and AMF244 for PDU sessions and QoS, encapsulates / decapsulates packets for IPSec and N3 tunneling, marks N3 user plane packets in the uplink, and implements QoS corresponding to the N3 packet markings, taking into account the QoS requirements associated with such markings received via N2. The N3IWF can also relay UL and DL control plane NAS signaling between UE 202 and AMF 244 via the N1 reference point between UE 202 and AMF 244, and relay uplink and downlink user plane packets between UE 202 and UPF 248. The N3IWF also provides a mechanism for establishing an IPsec tunnel with UE 202. AMF 244 can present a service-based Namf interface and can be the N14 reference point between two AMF 244s and between AMF 244 and 5G-EIR (…). Figure 2 The endpoint of the N17 reference point (not shown).

[0074] SMF 246 is responsible for SM (e.g., session establishment, tunnel management between UPF 248 and AN 208); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring service redirection at UPF 248 to route services to appropriate destinations; termination of interfaces to policy control functions; control of policy enforcement, billing, and quality of service as a part; lawful interception (for SM events and interfaces to the LI system); termination of the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information, which is sent to AN 208 via AMF 244 through N2; and determining the SSC mode of the session. SM refers to the management of PDU sessions, and a PDU session or “session” refers to the PDU connectivity service that provides or enables PDU exchange between UE 202 and DN 236. SMF 246 may also include the following functions to support edge computing enhancements (see, for example, [TS23548]): selecting EASDF 261 and providing its address to the UE as a DNS server for PDU sessions; using EASDF 261 services as defined in [TS23548]; and providing and updating ECS ​​address configuration information to the UE to support the application layer architecture defined in [TS23558]. The discovery and selection process for EASDF 261 is discussed in §6.3.23 of [TS23501].

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

[0076] NSSF 250 selects a set of network slice instances to serve UE 202. If necessary, NSSF 250 also determines the allowed NSSAIs and their mappings to subscribed S-NSSAIs. NSSF 250 also determines, based on appropriate configuration and possibly by querying NRF 254, the set of AMFs or a list of candidate AMFs 244 to be used to serve UE 202. The selection of a set of network slice instances for UE 202 can be triggered by the AMF 244 registered by UE 202 interacting with NSSF 250; this may result in a change of AMF 244. NSSF 250 interacts with AMF 244 via reference point N22 and can communicate with another NSSF in the visited network via reference point N31 (not shown).

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

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

[0079] PCF 256 provides policy rules to control plane functions and enforces these rules, and can also support a unified policy framework to manage network behavior. PCF 256 can also implement a front-end to access subscription information related to policy decisions in the Unified Data Repository (UDR) of UDM 258. In addition to communicating with functions via reference points as shown in the figure, PCF 256 presents a service-based interface for NPCF.

[0080] UDM 258 processes subscription-related information to support network entities in handling communication sessions and stores UE 202's subscription data. For example, subscription data can be transmitted via the N8 reference point between UDM 258 and AMF 244. UDM 258 may include two parts: an application front-end and a UDR. The UDR can store subscription data and policy data for UDM 258 and PCF 256, and / or store structured data for open and application data (including PFDs for application detection and application request information for multiple UEs 202) for NEF 252. The UDR can present a NUDR-based service interface to allow 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. UDM 258 may include UDM-FE, which is responsible for handling credentials, location management, subscription management, etc. Multiple different front-ends can serve the same user in different transactions. UDM-FE accesses subscription information stored in UDR and performs authentication credential processing, user identity processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points, as shown in the figure, UDM 258 can present a Nudm service-based interface.

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

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

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

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

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

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

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

[0088] Edge computing nodes may include or be part of an edge system employing one or more Edge Computing Technologies (ECTs) (also referred to as “edge computing frameworks” or similar terms). Edge computing nodes may also be referred to as “edge hosts” or “edge servers.” An edge system includes a set of edge servers and an edge management system (not shown) necessary to run edge computing applications within a carrier network or a subset of carrier networks. Edge servers are physical computer systems that may include edge platforms and / or virtualization infrastructure and provide computing, storage, and network resources to edge computing applications. Each edge server is located at the edge of the corresponding access network and is positioned relatively adjacent to UE 202 to provide computing resources and / or various services (e.g., computing tasks and / or workload offloading, cloud computing capabilities, IT services, and other similar resources and / or services discussed herein). The VIs of an edge computing node provide a virtualization environment and virtualization resources for the edge hosts, and edge computing applications may run on top of the VIs as VMs and / or application containers.

[0089] In one example implementation, ECT is a MEC framework and / or operates according to the MEC framework, as in ETSI GR MEC 001v3.1.1 (2022-01), ETSI GS MEC 003 v3.1.1 (2022-03), ETSI GS MEC 009 v3.1.1 (2021-06), ETSI GS MEC 010-1 v1.1.1 (2017-10), ETSI GS 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 GSMEC 013 V2.2.1 (2022-01), and ETSI GS MEC 014. v2.1.1 (2021-03), ETSI GS MEC 015v2.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 MEC031 v2.1.1 The contents of each of the above documents discussed herein are incorporated herein by reference in their entirety as discussed in U.S. Provisional Patent Application No. 63 / 003,834 (“[US'834]”), filed April 1, 2020, and International Patent Application No. PCT / US2020 / 066969 (“[PCT'696]”), filed December 23, 2020 (collectively referred to herein as “[MEC]”).This example implementation (and / or any other example implementations discussed herein) may also include NFV and / or other similar virtualization technologies, such as ETSI GR NFV 001 V1.3.1 (2021-03), ETSI GS NFV 002 V1.2.1 (2014-12), ETSI GRNFV 003 V1.6.1 (2021-03), ETSI GS NFV 006 V2.1.1 (2021-01), ETSI GS NFV-INF 001V1.1.1 (2015-01), ETSI GS NFV-INF 003 V1.1.1 (2014-12), ETSI GS NFV-INF 004V1.1.1 (2015-01), and ETSI GS NFV-MAN 001 v1.1.1. The contents of all of the above discussed in (2014-12) and / or in Israel et al., OSM Release FIVE Technical Overview, ETSI Open Source MANO, OSM Whitepaper, 1st Edition (January 2019), https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf (collectively, “[ETSINFV]”), are incorporated herein by reference in their entirety. Other virtualization technologies and / or service orchestration and automation platforms may be used, such as End-to-End Network Slicing Architecture, GSMA, official document NG.127, v1.0 (June 3, 2021), https: / / www.gsma.com / newsroom / wp-content / uploads / / NG.127-v1.0-2.pdf, Open Network Automation Platform (ONAP) documentation, Istanbul version, v9.0.1 (February 17, 2022), https: / / docs.onap.org / en / latest / index.html (“[ONAP]”), and the 3GPP Service-Based Management Architecture (SBMA) discussed in 3GPP TS28.533 v17.1.0 (December 23, 2021) (“[TS28533]”), the contents of which are incorporated herein by reference in their entirety.

[0090] In another example embodiment, ECT is an Open RAN framework and / or operates based on that framework. Typically, front-end and back-end equipment vendors and operators work closely together to ensure compatibility. On the other hand, this working model makes plug-and-play with other equipment quite difficult, which can hinder innovation. To address this issue and promote openness and interoperability at all levels, several key players in the wireless field (e.g., operators, equipment manufacturers, academic institutions, and / or similar organizations) formed the Open RAN Consortium (“O-RAN”) in 2018. The O-RAN network architecture is a building block for designing virtualized RANs on programmable hardware, with radio access control driven by AI / ML. The various aspects of the O-RAN architecture are described in the following documents: O-RAN Architecture Description v07.00, O-RAN Consortium WG1 (October 2022) (“[O-RAN.WG1. O-RAN-Architecture-Description]”); O-RAN Operations and Maintenance Architecture Specification v04.00, O-RAN Consortium WG1 (February 2021) (“[O-RAN.WG1.OAM-Architecture]”); O-RAN Operations and Maintenance Interface Specification v04.00, O-RAN Consortium WG1 (February 2021) (“[O-RAN.WG1.O1-Interface.0]”); O-RAN Information Model and Data Models Specification v01.00, O-RAN Consortium WG1 (February 2021); O-RAN Working Group 1 Slicing Architecture v08.00 (October 2022); O-RAN Working Group 2 (Non-RT) RIC and A1 interface WG) A1 interface: ApplicationProtocol v03.02 (July 2021); O-RAN Working Group 1 Use Cases DetailedSpecification v09.00 (October 2022) (“[O-RAN.WG1.Use-Cases]"); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: General Aspects andPrinciples v03.00 (October 2022) ("[O-RAN.WG2.A1GAP]"); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Type Definitions v04.00 (October 2021); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface:Transport Protocol v02.00 (October 2022); O-RAN Working Group 2 AI / ML workflowdescription and requirements v01.03 O-RAN Alliance WG2 (October 2021) ("[O-RAN.WG2.AIML]"); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) Non-RT RIC Architecture v02.01 (October 2022); O-RAN Working Group 2 Non-RT RIC: Functional Architecture v01.01, O-RAN Consortium WG2 (June 2021); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG): R1 interface: General Aspects and Principles v03.00, O-RAN Consortium WG2 (October 2022); O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles v02.02 (July 2022) (“[O-RAN.WG3.E2GAP]"); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) v02.01 (March 2022) ("[O-RAN.WG3.E2SM]"); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM), Cell Configuration and Control v01.00 (October 2022) ("[O-RAN.WG3.E2SM-CCC]"); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) KPM v02.03 (October 2022) ("[O-RAN.WG3.E2SM-KPM]"); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Function Network Interface (NI) v01.00 (February 2020) ("[O-RAN-WG3.E2SM-NI]"); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Control v01.03 (October 2022) ("[O-RAN.WG3.E2SM-RC]"); O-RAN Working Group 3, Near-Real-time Intelligent Controller, E2 Application Protocol (E2AP) v02.03 (October 2022) ("[O-RAN.WG3.E2AP]"); O-RAN Working Group 3 (Near-Real-time RAN Intelligent Controller and E2 Interface Working Group): Near-RT RIC Architecture v03.00 (October 2022) ("[O-RAN.WG3.RICARCH]"); O-RAN Working Group 4 (Open Fronthaul Interfaces WG) Control, User and Synchronization Plane Specification v09.00 (July 2022) ("[O-RAN-WG4.CUS.0]"); O-RAN Fronthaul Working Group 4 Cooperative Transport Interface Transport Control Plane Specification v02.00, O-RAN Alliance WG4 (June 2021); O-RAN Fronthaul Working Group 4 Cooperative Transport Interface Transport Management Plane Specification v02.00 (June 2021); O-RAN Fronthaul Working Group 4 (Open Fronthaul Interfaces WG): Management Plane Specification v09.00 (July 2022) ("[O-RAN.WG4.MP.0]"); O-RAN Alliance Working Group 5 O1 Interface specification for O-CU-UP and O-CU-CP v04.00 (October 2022); O-RAN Alliance Working Group 5 O1 Interface specification for O-DU v05.00 (October 2022); O-RAN Open F1 / W1 / E1 / X2 / Xn Interfaces Working Group Transport Specification v01.00, O-RAN Alliance WG5 (April 2020); O-RAN Working Group 6 (Cloudification and Orchestration) Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN v04.00 (October 2022) ("[O-RAN.WG6.CADS]"); O-RAN Cloud Platform Reference Designs v02.00, O-RAN Alliance WG6 (February 2021); O-RAN Working Group 6 O2 Interface General Aspects and Principles v02.00 (Oct. 2022); O-RAN Working Group 6 (Cloudification and Orchestration Work Group); O-RAN Acceleration Abstraction Layer General Aspects and Principles v04.00 (October 2022); O-RAN Working Group 6: O-Cloud Notification API Specification for Event Consumers v03.00 ("[O-RAN.WG6.O-Cloud Notification API]"); O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Indoor Pico Cell with Fronthaul Split Option 6 v02.00, O-RAN Alliance WG7 (October 2021) ("[O-RAN.WG7.IPC-HRD-Opt6]"); O-RAN WG7 Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 7-2 v03.00, O-RAN Alliance WG7 (October 2021) ("[O-RAN.WG7.IPC-HRD-Opt7-2]"); O-RAN WG7 Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 8 v03.00 (October 2021) ("[O-RAN.WG7.IPC-HRD-Opt8]"); O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Outdoor Micro Cell with Split Architecture Option 7.2 v03.00, O-RAN Alliance WG7 (October 2022) ("[O-RAN.WG7.OMC-HRD-Opt7-2]"); O-RAN White Box Hardware WorkingGroup Hardware Reference Design Specification for Outdoor Macro Cell with Split Architecture Option 7.2 v03.00, O-RAN Alliance WG7 (July 2022) ("[O-RAN.WG7.OMAC-HRD]"); O-RAN Open X-haul Transport Working Group Managementinterfaces for Transport Network Elements v04.00, O-RAN Alliance WG9 (July 2022); O-RAN Open v02.00, O-RAN Year WG9 (March 2022); O-RAN Open XhaulTransport WG9 WDM-based Fronthaul Transport v2.0, O-RAN Alliance WG9 (March 2022); O-RAN Open Transport Working Group 9 Xhaul Packet Switched Architectures and Solutions v03.00, O-RAN Alliance WG9 (July 2022) (“[O-RAN.WG9.XPSAAS]”); O-RAN Operations and Maintenance Architecture v07.00, O-RAN Alliance WG10 (July 2022) (“[O-RAN.WG10”).[O-RAN-Architecture]”; O-RAN Operations and Maintenance Interface Specification v07.00, O-RAN Consortium WG10 (July 2022); O-RAN Operations and Maintenance Interface Specification v08.00, O-RAN Consortium WG10 (October 2022) (“[O-RAN.WG10.O1-Interface.0]”); O-RAN: Towards an Open and Smart RAN, O-RAN Consortium White Paper (October 2018); and U.S. Patent Application No. 17 / 484,743, filed September 24, 2021 (collectively, “[O-RAN]”), the contents of which are incorporated herein by reference in their entirety.

[0091] In another example implementation, ECT is and / or operates according to the architecture of 3GPP System Aspects Working Group 6 (SA6) to enable edge applications (referred to as "3GPP edge computing"), as discussed in the following documents: 3GPP TS 23.558 v18.1.0 (2022-12-23) ("[TS23558]"), 3GPP TS 23.501 v18.0.0 (2022-12-21) ("[TS23501]"), 3GPP TS 23.548 v17.4.0 (2022-09-22) ("[TS23548]"), 3GPP TR 23.700-98 v18.0.0 (2022-12-23) ("[TR23700-98]"), 3GPP TS 23.222 v18.0.0 (2022-12-23) ("[TS23222]"), TS 33.122 v18.0.0 (2022-12-16) ("[TS33122]") and 3GPP TS 29.222 v17.1.0 (2021-06-25) ("[TS29222]"), 3GPP TS 23.502v18.0.0 (2022-12-21) ("[TS23502]"), 3GPP TS 29.522 v18.0.0 (2022-12-16) ("[TS29522]"), 3GPP TS 29.122 v18.0.0 (2022-12-16) ("[TS29122]"), 3GPP TS 23.682v17.3.0 (2022-06-15) (“[TS23682]”), 3GPP TS 23.434 v18.3.0 (2022-12-23) (“[TS23434]”) and 3GPP TS 23.401 v18.0.0 (2022-12-21) (collectively, “[SA6Edge]”), the entire contents of each of the above are incorporated herein by reference.

[0092] In another example implementation, ECT is and / or operates according to the Intel® Smart Edge Open framework (formerly known as OpenNESS), as discussed in the Intel® Smart Edge Open Developer Guide version 21.09 (September 30, 2021), which is available at https: / / smart-edge-open.github.io / (“[ISEO]”), the contents of which are incorporated herein by reference in their entirety.

[0093] In another example implementation, ECT operates based on the Multi-Access Management Services (MAMS) framework, as discussed in the following: Kanugovi et al., Multi-Access Management Services (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (March 2020) (“[RFC8743]”), Ford et al., TCP Extensions for Multipath Operation with MultipleAddresses, IETF RFC 8684 (March 2020), De Coninck et al., Multipath Extensions for QUIC (MP-QUIC), IETF draft-deconinck-quic-multipath-07, IETA, QUICWorking Group (May 3, 2021), Zhu et al., User-Plane Protocols for MultipleAccess Management Service, IETF draft-zhu-intarea-mams-user-protocol-09, IETA, INTAREA (March 4, 2020), and Generic Multi-Access (GMA) Convergence Encapsulation Protocols, IETF RFC 9188 (February 2022) by Zhu et al. (collectively, “[MAMS]”), the contents of each of which are incorporated herein by reference in their entirety.

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

[0095] The 5GC 240 interface includes reference points and service-based interfaces. Reference points include N1 (between UE 202 and AMF 244), N2 (between RAN 214 and AMF 244), N3 (between RAN 214 and UPF 248), N4 (between SMF 246 and UPF 248), N5 (between PCF 256 and AF 260), N6 (between UPF 248 and DN 236), N7 (between SMF 246 and PCF 256), N8 (between UDM 258 and AMF 244), N9 (between the two UPF 248), N10 (between UDM 258 and SMF 246), N11 (between AMF 244 and SMF 246), N12 (between AUSF 242 and AMF 244), and N13 (between AUSF 242 and UDM 244). N14 (between two AMF 244s; not shown), 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 246s; not shown), and N22 (between AMF 244 and NSSF 250). Figure 2 Other reference points not shown in the diagram may also be used. Figure 2Service-based representations represent NFs within the control plane that enable other authorized NFs to access their services. Service-based interfaces (SBIs) include Namf (SBI presented by AMF 244), Nsmf (SBI presented by SMF 246), Nnef (SBI presented by NEF 252), Npcf (SBI presented by PCF 256), Nudm (SBI presented by UDM 258), Naf (SBI presented by AF 260), Nnrf (SBI presented by NRF 254), Nnssf (SBI presented by NSSF 250), and Nausf (SBI presented by AUSF 242). Figure 2 Other service-based interfaces (e.g., Nudr, N5g-eir, and Nudsf) not shown in the diagram may also be used. In some examples, the NEF 252 may provide an interface to the edge computing node, which can be used to handle wireless connections with the RAN 214.

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

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

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

[0099] UE 302 can be communicatively coupled to AN 304 via connection 306. Connection 306 is illustrated as an air interface for communication coupling and is compliant with cellular communication protocols such as LTE or 5G NR operating at millimeter wave or sub-6 GHz frequencies.

[0100] UE 302 may include a host platform 308 coupled to a modem platform 310. Host platform 308 may include an application processing circuitry system 312, which may be coupled to a protocol processing circuitry system 314 of the modem platform 310. Application processing circuitry system 312 may run various applications for generating / consuming application data for UE 302. Application processing circuitry system 312 may also implement one or more layer operations for sending / receiving application data to / from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

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

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

[0103] The modem platform 310 may also include a transmitting circuit system 318, a receiving circuit system 320, an RF circuit system 322, and an RF front-end (RFFE) 324 that may include or be connected to one or more antenna panels 326. Briefly, the transmitting circuit system 318 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; the receiving circuit system 320 may include an analog-to-digital converter, a mixer, an IF component, etc.; the RF circuit system 322 may include a low-noise amplifier, a power amplifier, a power tracking component, etc.; and the RFFE 324 may include filters (e.g., surface acoustic wave filters / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of the components of the transmitting circuit system 318, the receiving circuit system 320, the RF circuit system 322, the RFFE 324, and one or more antenna panels 326 (collectively referred to as the "transmit / receive components") may be specific to implementation details, such as, for example, whether the communication is TDM or FDM, or whether it is in millimeter wave or sub-6 GHz frequencies. In some embodiments, the transmit / receive components may be arranged in multiple parallel transmit / receive chains, may be located in the same or different chips / modules, and so on.

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

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

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

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

[0108] Figure 4 These are block diagrams based on some example embodiments, illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein. Specifically, Figure 4 The schematic representation of hardware resources 400 includes one or more processors (or processor cores) 410, one or more memory / storage devices 420, and one or more communication resources 430, each of which may be communicatively coupled via bus 440 or other interface circuitry. In embodiments utilizing node virtualization (e.g., NFV), a virtual machine monitor 402 may be executed to provide an execution environment for one or more network slices / subslices to utilize hardware resources 400.

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

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

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

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

[0113] Figure 5 Another example network architecture 500 is shown. Network architecture 500 can operate in accordance with 3GPP technical specifications or technical reports for 6G systems. In some examples, network architecture 500 can operate simultaneously with network architecture 200. For example, in some examples, network architecture 500 can share one or more frequency or bandwidth resources with network architecture 200. As a specific example, a UE (e.g., UE 502) can be configured to operate in both network architecture 500 and network architecture 200. This configuration can be based on the UE including circuitry configured to communicate with the frequency and bandwidth resources of both network architecture 200 and network architecture 500. In general, several elements of network architecture 500 can share one or more characteristics with elements of network architecture 200. For the sake of brevity and clarity, these elements will not be repeated in the description of network architecture 500.

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

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

[0116] UE 502 and RAN 508 can be configured to communicate via an air interface, which may be referred to as a sixth-generation (6G) air interface. The 6G air interface may include one or more features, such as communication in the terahertz (THz) or Asia-Pacific Hertz (APH) bandwidth, or communications-aware integration. As used herein, the term "communications-aware integration" may refer to a system that allows wireless communication via various types of multiplexing methods as well as radar-based sensing. As used herein, the terahertz or APH bandwidth may refer to communication in the frequency range of 80 GHz and above. These frequency ranges may additionally or alternatively be referred to as "millimeter wave" or "mmWave" frequency ranges.

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

[0118] Additionally, RAN 508 may include various additional functions beyond or replacing those of traditional cellular networks (such as 4G or 5G networks). Two such functions may include Compute Control Function (Comp CF) 524 and Compute Service Function (Comp SF) 536. Comp CF 524 and Comp SF 536 may be parts or functions of the Compute Service Plane. Comp CF 524 may be a control plane function that provides functions such as managing Comp SF 536, generating and managing compute task contexts (e.g., creating, reading, modifying, and deleting), and interacting with the underlying compute infrastructure for compute resource management. Comp SF 536 may be a user plane function that acts as a gateway connecting compute service users (such as UE 502) to compute nodes behind the Comp SF instance. Some functions of Comp SF 536 may include: parsing compute service data received from users into compute tasks that can be executed by compute nodes, mounting a service mesh inbound gateway or service API gateway, enforcing service and charging policies, performance monitoring, and telemetry collection. In some examples, a Comp SF 536 instance can be used as a user plane gateway for a cluster of compute nodes. A Comp CF 524 instance can control one or more Comp SF 536 instances.

[0119] Two other such functions may include a communication control function (Comm CF) 528 and a communication service function (CommSF) 538, which may be part of the communication service plane. Comm CF 528 may be a control plane function for managing Comm SF 538, communication session creation / configuration / release, and managing the communication session context. Comm SF 538 may be a user plane function for data transfer. Comm CF 528 and Comm SF 538 can be considered upgrades to SMF 246 and UPF248, which... Figure 2The description is integrated with 5G systems. Upgrades provided by Comm CF 528 and Comm SF 538 can support service-aware transport. For legacy (e.g., 4G or 5G) data transmission, SMF 246 and UPF248 can still be used.

[0120] Two other such functions may include a Data Control Function (Data CF) 522 and a Data Service Function (DataSF) 532, which may be part of the data service plane. Data CF 522 may be a control plane function, providing functions such as Data SF 532 management, data service creation / configuration / release, and data service context management. Data SF 532 may be a user plane function, acting as a gateway between data service users (such as UE 502 and various functions of 6G CN 510) and the data service endpoints behind the gateway. Specific functions may include parsing data service user data and forwarding it to the corresponding data service endpoint, generating billing data, and reporting data service status.

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

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

[0123] Other such capabilities may include the Evolved Services Communication Agent (eSCP) and the Services Infrastructure Control Function (SICF) 526, which provide services communication infrastructure for control plane services and user plane services. The eSCP can be associated with the 5G Services Communication Agent (SCP), with the addition of user plane services communication agent capabilities. Therefore, the eSCP is represented in two parts: eCSP-C 512 and eSCP-U 534, for the control plane services communication agent and user plane services communication agent, respectively. SICF 526 can control and configure eCSP instances in areas such as traffic routing policies, access rules, load balancing configuration, and performance monitoring.

[0124] Another such function is AMF 544. AMF 544 can be similar to 244, but with additional functions. Specifically, AMF 544 can include potential function refactoring, such as moving message forwarding functions from AMF 544 to RAN 508.

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

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

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

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

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

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

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

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

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

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

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

[0136] Model store 635 is responsible for storing and accessing AI / ML models (trained and untrained). Trained / updated models (multiple models) can be stored in model store 635. Models and model parameters can be discovered and requested by other function blocks (e.g., training data selection / filtering function block 620 and / or model training function block 625). In some examples, UE 605 can discover and request AI / ML models from RAN 610's model store 635. Similarly, RAN 610 can discover and / or request AI / ML models from UE 605's model store 635. In some examples, RAN 610 can configure models and / or model parameters in UE 605's model store 635.

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

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

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

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

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

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

[0143] The CU 732 is a central controller capable of serving or otherwise connecting to one or more DU 731s and / or RU 730s. The CU 732 is a higher-layer / upper-layer network (logical) node carrying network protocol function decompositions. For example, in 3GPP NG-RAN and / or O-RAN architectures, the CU 732 carries the Radio Resource Control (RRC) layer, Serving Data Adaptation Protocol (SDAP) layer, and Packet Data Convergence Protocol (PDCP) layer of a next-generation NodeB (gNB), or, when included in an E-UTRA-NRgNB (en-gNB) or operating as an E-UTRA-NR gNB, carries the RRC and PDCP protocol layers. The SDAP sublayer performs the mapping between Quality of Service flows and Data Radio Bearers (DRBs) and marks the Quality of Service Flow ID (QFI) in packets of both DL and UL. The PDCP sublayer performs the transmission 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; performs encryption and decryption; provides integrity protection and integrity verification; provides timer-based SDU dropping; routes for split bearers; performs duplicate and duplicate dropping; performs reordering and in-order delivery; and / or out-of-order delivery. In various implementations, the CU 732 terminates the corresponding F1 interface connected to the corresponding DU 731 (see, for example, [TS38401]).

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

[0145] The DU731 locally controls radio resources, such as time and frequency bands, in real time and allocates resources to one or more UEs. The DU731 is a network (logical) node carrying intermediate and / or lower layers of network protocol function decomposition. For example, in 3GPPNG-RAN and / or O-RAN architectures, the DU731 carries the Radio Link Control (RLC), Media Access Control (MAC), and High Physical (PHY) layers of the gNB or en-gNB, and its operation is at least partially controlled by the CU 732. The RLC sublayer operates in one or more of the following modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC sublayer performs the following: delivery of upper-layer PDUs; sequence numbering independent of sequence numbers in the PDCP (UM and AM); error correction via ARQ (AM only); RLC SDU segmentation (AM and UM) and resegmentation (AM only); SDU reassembly (AM and UM); duplicate detection (AM only); RLC SDU dropping (AM and UM); RLC reconstruction; and / or protocol error detection (AM only). The MAC sublayer performs mapping between logical channels and transport channels; multiplexes MAC SDUs belonging to one or different logical channels into or demultiplexes them from transport blocks (TBs), which are delivered to or received from the physical layer on the transport channel; reports scheduling information; performs error correction via HARQ (one HARQ entity per cell in the case of CA); performs priority processing among UEs via dynamic scheduling; performs priority processing among logical channels of a UE via logical channel priority ordering; performs priority processing among overlapping resources of a UE; and / or padding. In some embodiments, the DU731 may carry the Backhaul Adaptation Protocol (BAP) layer (see, for example, 3GPP TS38.340 v16.5.0 (2021-07-07)) and / or the F1 Application Protocol (F1AP) (see, for example, 3GPP TS 38.470 v16.5.0 (2021-07-01)), such as when the DU731 operates as an Integrated Access and Backhaul (IAB) node. One DU731 supports one or more cells, and a cell is supported by only one DU731. The DU731 terminates the F1 interface connected to the CU 732. Alternatively, the DU731 can be connected to one or more RRH / RU 730s.

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

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

[0148] In some implementations, the fronthaul gateway function (FHGW) can be set between the DU 731 and the RU / RRU 730. Figure 7 (Not shown), where 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, or similar), including those interfaces that do not support open fronthaul (e.g., Option 7-2x). FHGW may be encapsulated in a physical device or apparatus with one or more other functions (e.g., Ethernet switching and / or similar functions). In some implementations, the RAN controller may communicate with CU 732 and / or DU 731.

[0149] NGFI (also known as "xHaul" or similar) is a two-tier fronthaul architecture that separates the traditional RRU730-BB connection in a C-RAN architecture into two tiers: Tier I and Tier II. Tier I connects the RU730 to the DU731 via NGFI-I, and Tier II connects the DU731 to the CU732 via NGFI-II, as follows. Figure 7The deployment is shown in 700a. The connection between NGFI-I and NGFI-II can be wired or wireless, and can utilize any suitable RAT, such as any RAT discussed herein. The purpose of the two-tier architecture is to distribute (split) RAN node protocol functions between the CU732 and DU731, thereby relaxing latency and providing greater deployment flexibility. Generally, NGFI-I interfaces with the lower layer of the function split, which has strict latency and data rate requirements. In contrast, NGFI-II interfaces with the higher layer of the function split relative to the NGFI-I level, thus relaxing the requirements for the fronthaul link. Examples of NGFI fronthaul interfaces and functional split architectures include O-RAN (O-RAN) 7.2x fronthaul (see, for example, [O-RAN.WG9.XPSAAS] and [O-RAN-WG4.CUS.0]), C-RAN fronthaul based on Enhanced Public Radio Interface (eCPRI) (see, for example, Universal Public Radio Interface: eCPRI Interface Specification, eCPRI Specification v2.0 (2019-05-10), Universal Public Radio Interface: eCPRI Transport Network Requirements, eCPRI Transport Network v1.2 (2018-06-25), and [O-RAN-WG4.CUS.0]), C-RAN fronthaul based on Ethernet Radio (RoE) (see, for example, IEEE Radio Ethernet Encapsulation and Mapping Standard, IEEE Standards Association, IEEE 1914.3-2018 (October 5, 2018) (“[IEEE1914.3]”), and / or similar items. Additional aspects of NGFI are also discussed in [O-RAN.WG9.XPSAAS], [O-RAN-WG4.CUS.0], IEEE Packet-Based Fronthaul Transport Network Standard, IEEE Standards Association, IEEE 1914.1-2019 (April 21, 2020) (“[IEEE1914.1]”), [IEEE1914.3], and Nasrallah et al., Ultra-Low Latency (ULL) Networks: A Comprehensive Survey Covering the IEEE TSN Standard and Related ULL Research (arXiv:1803.07673v1 [cs.NI] (March 20, 2018) (“[Nasrallah]”), the contents of each of which are incorporated herein by reference in their entirety.

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

[0151] Alternatively or concurrently, CU 732, DU 731, and / or RU 730 can be IAB nodes. IABs enable wireless relaying in NG-RAN, where relay nodes (referred to as "IAB nodes") support access and backhaul via 3GPP 5G / New Radio (NR) links / interfaces. The terminating node of the NR backhaul on the network side is called the "IAB donor," which represents a RAN node (e.g., a gNB) with additional IAB support. Backhauls can be performed via single hops or multiple hops. All IAB nodes connected to the IAB donor via one or more hops form a directed acyclic graph (DAG) topology rooted at the IAB donor. The IAB donor performs centralized resource, topology, and routing management for the IAB topology. The IAB architecture is shown and described in [TS38300].

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

[0153] Figure 7The illustration also depicts an example RAN disaggregation deployment 700b (also known as “disaggregated RAN 700b”), where UE 702 is connected to RRH 730, and RRH 730 is communication-coupled with one or more RAN functions (RANFs) 1 to N (where N is a number). RANFs 1 to N are decoupled and geographically distributed across several component segments and network nodes. In some implementations, each RANF 1 to N is a software (SW) element operated by a physical compute node, and RRH 730 includes radio frequency (RF) circuitry (e.g., RF propagation modules and / or the like for a specific RAT). In this example, RANF 1 operates on a physical compute node co-located with RRH 730, and the other RANFs are located further away from RRH 730. Additionally, in this example, CN 742 is also decoupled to CN NF 1 to x (where x is a number) in the same or similar manner as RANFs 1 to N. However, in other implementations, CN 742 is not decoupled.

[0154] Network decoupling (or decoupled networking) involves separating network devices into functional components and allowing each component to be deployed independently. This may cover separating SW elements (e.g., NFs) from specific HW elements and / or using APIs to implement Software-Defined Networking (SDN) and / or NF virtualization (NFV). RAN decoupling involves network decoupling as well as individual RANFs (e.g., Figure 7 The RANFs (RANF 1 through N) are virtualized. RANF 1 through N can be placed at different physical sites in various topologies within a RAN deployment based on use cases. This enables the distribution and deployment of RANFs across different geographic regions and allows for the decoupling of RANFs to support a variety of use cases (e.g., low-latency use cases and the like) and flexible RAN implementations. Decoupling provides a common or unified RAN platform capable of presenting different configurations depending on its deployment location. This allows for fewer fixed-function devices and a lower total cost of ownership compared to existing RAN architectures. Example RAN decoupling frameworks are provided by Telecom Infrastructure Project (TIP) OpenRAN™, Cisco® OpenvRAN™, [O-RAN], Open Optical and Packet Transport (OOPT), Reconfigurable Optical Add-Drop Multiplexer (ROADM), and / or the like.

[0155] In the first example implementation, RANFs 1 to N decouple the RAN HW and SW using commercially available off-the-shelf (COTS) HWs and open interfaces (e.g., NGFI-I and NGFI-II). In this example implementation, each RANF 1 to N can be a virtual BBU or vRAN controller, running on a COTS compute infrastructure with HW acceleration for BBU / v RANF.

[0156] In the second example implementation, RANF 1 to N decouple one or more RAT protocol stacks. As an example of this implementation, RANF 1 is a DU731 running on a first COTS computing infrastructure with HW acceleration for BBU / vRANF, and RANF 2 is a virtual CU 732 running on a second COTS computing infrastructure.

[0157] In the third example implementation, RANF 1 through N decouple the control plane functions and the user plane functions. As an example of this implementation, RANF 1 is a DU 731 running on a COTS compute infrastructure with HW acceleration for BBU / vRANFs, RANF 2 is a virtual CU-CP 732 running on the COTS compute infrastructure, and a third RANF (e.g., RANF 3) Figure 7 (Not shown) is a virtual CU-UP732 running on the same or a different COTS computing infrastructure as the virtual CU-CP732. Additionally or alternatively, in this implementation, one or more CN NFs 1 to x may be CN-UP functions, and one or more other CN NFs 1 to x may be CN-CP functions.

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

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

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

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

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

[0163] The term "application" can refer to a complete and deployable software package or environment used to implement specific functions in a runtime environment. The term "AI / ML application" or similar terms can refer to an application that includes some artificial intelligence (AI) / machine learning (ML) models and application-level descriptions. In some embodiments, an AI / ML application can be used to configure or implement one or more of the disclosed aspects.

[0164] The term "machine learning" or "ML" refers to the use of computer systems that implement algorithms and / or statistical models to perform specific tasks(s) without explicit instructions, relying instead on patterns and reasoning. ML algorithms build or estimate mathematical models (referred to as "ML models" or similar terms) based on sample data (referred to as "training data," "model training information," or similar terms) to make predictions or decisions without being explicitly programmed to perform such tasks. Typically, an ML algorithm is a computer program that learns from experience for a specific task and performance metric, and an ML model can be any object or data structure created after the ML algorithm has been trained using one or more training datasets. After training, the ML model can be used to make predictions on new datasets. Although the term "ML algorithm" refers to a different concept than the term "ML model," these terms are used interchangeably in this disclosure as discussed herein.

[0165] The terms "machine learning model," "ML model," or similar terms can also refer to the ML methods and concepts used in ML-assisted solutions. An "ML-assisted solution" is a solution that uses ML algorithms to solve a specific use case during runtime. ML models include supervised learning (e.g., linear regression, k-nearest neighbors (KNN), decision tree algorithms, support vector machines, Bayesian algorithms, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal component analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-armed learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model may have many sub-models as components, and the ML model may train all sub-models together. Separately trained ML models may also be chained together in an ML pipeline during inference. An "ML pipeline" is a set of functions, functional units, or functional entities specific to an ML-assisted solution; an ML pipeline may include one or more data sources in a data pipeline, a model training pipeline, a model evaluation pipeline, and an executor. An "executor" is the entity that carries the output of the ML model inference. The term "ML training host" refers to the entity that carries the model training, such as a network function. The term "ML inference host" refers to the entity that hosts the model during inference mode, such as network functions (which include both model execution and any online learning, if applicable). The ML host informs the executor of the output of the ML algorithm, and the executor determines the action ("action" is performed by the executor as a result of the output of the ML-assisted solution). The term "model inference information" refers to the information used as input to the ML model to determine inference(s); the data used to train the ML model and the data used to determine inference can overlap; however, "training data" and "inference data" refer to different concepts.

[0166] This disclosure defines or otherwise provides SL positioning configurations, such as techniques for configuring the association information between a transmitter ARP ID and a transmitted SL PRS for SL positioning. The following discussion is applicable to any type of UE or base station, such as... Figures 1A to 7 Any UE or base station.

[0167] In NR, PUSCH transmission based on 1-port, 2-port, 4-port, and 8-port networks is supported. However, current commercial mobile UEs are typically equipped with only 1 or 2 Tx antennas. To improve UL performance and anticipate advancements in hardware and design technologies, the emergence of UEs equipped with 3 Tx antennas is a foreseeable development in the near future. Therefore, the disclosed technology can be used to enhance the NR standard to support 3-port PUSCH at up to 3 layers.

[0168] Figure 8 A schematic diagram 800 shows three transmit (Tx) antennas configured at the UE according to some aspects.

[0169] In some respects, the association between the phase tracking reference signal (PTRS) and the demodulation reference signal (DMRS) used for Physical Uplink Shared Channel (PUSCH) transmission is defined to allow the receiver to use the PTRS to estimate the phase noise and use the DMRS to perform channel estimation based on the estimated phase noise.

[0170] Furthermore, in Rel-17, for multi-TRP PUSCH transmissions, when the maximum rank used for PUSCH transmission is equal to 2, DCI formats 0_1 and 0_2 include a 2-bit field, where the first and second bits are used to indicate the PTRS and DMRS associations for PUSCH transmissions to the first and second TRPs, respectively. When the maximum rank used for PUSCH transmission is greater than 2, DCI formats 0_1 and 0_2 have two fields, each with 2 bits, where the first and second fields are used to indicate the PTRS and DMRS associations for PUSCH transmissions to the first and second TRPs, respectively.

[0171] To support mTRP PUSCH transmission using 3 transmit (Tx) antennas, it may be necessary to define certain mechanisms to update the PTRS and DMRS association.

[0172] The disclosed technology provides systems and methods for PTRS and DMRS association for multi-TRP and multi-panel PUSCH transmissions using three transmit antennas. For example, aspects of various embodiments may include PTRS and DMRS association for multi-TRP and multi-panel PUSCH transmissions using three Tx antennas. Additional aspects include coherent joint transmission (CJT) calibration reports for inter-TRP phase offset, inter-TRP frequency offset, and CJT channel state information (CSI).

[0173] The following configuration can be used to associate PTRS with DMRS for multi-TRP and multi-panel PUSCH transmissions using 3 Tx antennas.

[0174] In some respects, when the maximum rank used for multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, a 1-bit second PTRS-DMRS association field may be included in the DCI format 0_1 ​​or DCI format 0_2 used for scheduling PUSCH transmissions to indicate the PTRS and DMRS associations from Table 1, which illustrates the second PTRS-DMRS associations for PUSCH transmissions to the second TRP.

[0175] Table 1. Second PTRS-DMRS Association for UL PTRS Port 0: Option 1 In some respects, when the maximum rank used for multi-TRP PUSCH transmissions is greater than 2, and when one PTRS port is configured, a 2-bit second PTRS-DMRS association field can be included in the DCI formats 0_1 and 0_2 used for scheduling PUSCH transmissions. Furthermore, the last row in the table with a value of 3 can be reserved. Table 2 illustrates an example of the second PTRS-DMRS association for PUSCH transmissions to the second TRP.

[0176] Table 2. Second PTRS-DMRS association for UL PTRS port 0: Option 2 In some respects, when the maximum rank used for multi-TRP PUSCH transmission is greater than 2, and when one PTRS port is configured, a 2-bit second PTRS-DMRS association field can be included in the DCI format 0_1, 0_2 used for scheduling PUSCH transmissions. Additionally, the UE may not expect a DMRS port with an indicated value of 3 or a fourth scheduled DMRS port to be used for PUSCH transmissions using 3 Tx antennas.

[0177] In another option, when the maximum rank used for multi-TRP PUSCH transmissions is greater than 2, and when one PTRS port is configured, a 2-bit PTRS-DMRS association can be defined to indicate the PTRS and DMRS associations for PUSCH transmissions to the first TRP and the second TRP, respectively. In this case, the first 1 bit (or MSB) is used to indicate the PTRS-DMRS association for PUSCH transmissions to the first TRP using 3 Tx antennas, while the second 1 bit (or LSB) is used to indicate the PTRS-DMRS association for PUSCH transmissions to the second TRP using 3 Tx antennas.

[0178] Table 3 illustrates an example of PTRS-DMRS association for an mTRPPUSCH using three Tx antennas when the maximum rank used for multi-TRP PUSCH transmission is greater than 2. In this case, the second PTRS-DMRS association field is absent in DCI formats 0_1 and 0_2.

[0179] Table 3. PTRS-DMRS association for mTRP PUSCH using 3 Tx antennas: Option 1 In some respects, for a PUSCH using 3 transmit antennas based on multi-panel simultaneous transmission (STxMP), when a PTRS port is configured, the STxMP scheme is configured as a spatial division multiplexing (SDM) scheme, and the SRS resource set indicator field exists and is equal to "10" and "11" and maxRank=2, the UE can ignore the 1 LSB used for PTRS and DMRS association.

[0180] In some embodiments, when a PTRS port is configured, the STxMP scheme is configured as an SDM-based scheme, and when the SRS resource set indicator field exists and is equal to "10" or "11" and maxRank=2, the UE expects not to be indicated by the PTRS-DMRS association field LSB with a value of 1.

[0181] In some respects, when a PTRS port is configured, the STxMP scheme is configured as an SDM-based scheme, and the SRS resource set indicator field exists and is equal to “10” and “11” and maxRank=2, the 2-bit PTRS-DMRS association field can be included in DCI formats 0_1 and 0_2 to indicate the PTRS-DMRS association from Table 4.

[0182] Table 4. PTRS-DMRS association for mTRP PUSCH using 3 Tx antennas: Option 2 In some respects, when a PTRS port is configured, the STxMP scheme is configured as an SDM-based scheme, and the SRS resource set indicator field exists and is equal to "10" and "11" and maxRank=2, a 1-bit PTRS-DMRS association field can be included in DCI formats 0_1 and 0_2 to indicate the PTRS and DMRS association from Table 5, which illustrates the PTRS-DMRS association for an STxMP PUSCH using an SDM-based scheme and utilizing 3 Tx antennas.

[0183] Table 5. PTRS-DMRS Correlation for STxMP PUSCH using SDM Scheme and 3 Tx Antennas The above can also be applied to the case where two PTRS ports are configured, the STxMP scheme is configured as an SDM-based scheme, and the SRS resource set indicator field exists and is equal to "10".

[0184] In another embodiment, for an STxMP PUSCH using 3 transmit antennas, when a PTRS port is configured, the STxMP scheme is configured as an SDM-based scheme, and the SRS resource set indicator field exists and is equal to "10", the UE does not expect the DMRS port with an indicator value of 3 or the fourth scheduled DMRS port to be used for PUSCH transmission using 3 Tx antennas.

[0185] In some respects, for an STxMP PUSCH using 3 transmit antennas, when a PTRS port is configured, the STxMP scheme is configured as an SDM-based scheme, and the SRS resource set indicator field is present and equal to "10", a 2-bit PTRS-DMRS association field can be included in DCI formats 0_1 and 0_2 to indicate the PTRS and DMRS association from Table 2.

[0186] In another option, for an STxMP PUSCH using three transmit antennas, when a PTRS port is configured, the STxMP scheme is configured as an SDM-based scheme, and the SRS resource set indicator field is present and equal to "10", a 1-bit PTRS-DMRS association field can be included in the DCI format 0_1, 0_2 used for scheduling PUSCH transmissions. In this case, Table 1 can be used for PTRS-DMRS association for STxMP SDM PUSCH transmissions utilizing a 1-port PTRS (and when the SRS resource set indicator field is present and equal to "10").

[0187] The following configurations can be used for Coherent Joint Transmission (CJT) calibration reports for inter-TRP phase offset, inter-TRP frequency offset, and CJT CSI.

[0188] In some respects, the timestamp can be associated with a CJT calibration report instance used for inter-TRP phase offset, inter-TRP frequency offset, or CJT CSI reporting. The timestamp records the moment or time interval used for the measurement. It can also record the time difference between the measurement of a first inter-TRP measurement and the measurement of a second inter-TRP measurement.

[0189] As an example, a timestamp can record the time between a CJT CSI measurement and a TRP phase offset measurement. As an example, a timestamp can record the time between a CJT CSI measurement and a TRP frequency offset measurement.

[0190] Timestamps may include a System Frame Number (SFN), a slot number or symbol number, a Channel State Information Reference Signal (CSI-RS) or Tracking Reference Signal (TRS) resource set ID, an instance of a CSI-RS or TRS, or a measurement window used for a CSI-RS or TRS. In the case of a CSI-RS resource or TRS resource ID, they are associated with inter-TRP phase offset measurements or inter-TRP frequency offset measurements. The SFN, slot number, and symbol number can be determined based on the subcarrier spacing of the DL bandwidth portion used for transmitting CSI-RS and TRS.

[0191] On one hand, the association between timestamps and CJT calibration reports is demonstrated by reporting the timestamp along with an instance of the calibration report. On the other hand, the association between timestamps and CJT calibration reports is demonstrated by the NW notifying the UE of the measurement time window or moment to be associated with the report instance.

[0192] One alternative to NW notification to the UE is a rule-based association, which is specified when no NW notification is made to the UE. An example of a rule-based association is given by a measurement time window prior to the reporting time.

[0193] In addition, the timestamp can correspond to a CSI reference resource slot. Alternatively, the timestamp can correspond to the most recent CSI-RS time slot no later than the CSI reference resource.

[0194] The above embodiments can be extended to the case of CJT calibration reports for inter-TRP delay offset and / or frequency offset.

[0195] Figure 9 The diagram illustrates a block diagram of a communication device, such as an evolved Node B (eNB), a next-generation Node B (gNB) (or another RAN node, such as a base station), a network control repeater (NCR), an access point (AP), a radio station (STA), a mobile station (MS), or a user equipment (UE), to perform one or more of the technologies disclosed herein. Alternatively, the communication device 900 may operate as a standalone device or may be connected (e.g., networked) to other communication devices.

[0196] A circuit system (e.g., a processing circuit system) is a series of circuits implemented in a tangible entity of device 900, the tangible entity including hardware (e.g., simple circuits, gates, logic, etc.). The composition of the components of a circuit system can change flexibly over time. A circuit system includes components that can perform a specified operation individually or in combination when in operation. For example, the circuit system hardware can be immutably designed to perform a specific operation (e.g., hardwired). For example, the hardware of a circuit system can include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.), the physical components containing machine-readable media that are physically modified (e.g., in a magnetic, electrical, or movable arrangement of particles of fixed mass, etc.) to encode instructions for a specific operation.

[0197] When physical components are connected, the underlying electrical properties of the hardware components are altered, for example, from insulators to conductors or vice versa. Instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create components of a circuit system within the hardware via variable connections to perform specific operations at runtime. Thus, in one example, while the device is running, a machine-readable medium element is part of the circuit system or communicatively coupled to other components of the circuit system. For example, any physical component can be used for more than one component of more than one circuit system. For example, during operation, an execution unit may be used at one point in time for a first circuit of a first circuit system and multiplexed at different times by a second circuit in the first circuit system or a third circuit in the second circuit system. Additional examples of these components of device 900 are as follows.

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

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

[0200] Therefore, the term "module" is understood to encompass tangible entities, whether physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate or perform some or all of the operations described herein in a specified manner. Considering examples where modules are temporarily configured, each module does not need to be instantiated at any given time. For example, in the case where modules include general-purpose hardware processors configured using software, the general-purpose hardware processors can be configured as different modules at different times. The software can accordingly configure the hardware processors, for example, to constitute a particular module at one time and different modules at different times.

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

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

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

[0204] As used herein, the term “device-readable medium” is interchangeable with “computer-readable medium” or “machine-readable medium.” While device-readable medium 922 is illustrated as a single medium, the term “communication device-readable medium” can include a single medium or multiple media configured to store instructions 924 (e.g., a centralized or distributed database and / or associated caches and servers). The term “communication device-readable medium” encompasses the terms “machine-readable medium” or “computer-readable medium” and can include any medium capable of storing, encoding, or carrying instructions (e.g., instructions 924) for execution by communication device 900 and causing communication device 900 to perform any one or more of the technologies disclosed herein, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of communication device-readable media may include solid-state memory, as well as optical and magnetic media. Specific examples of communication device readable media may include non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), 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, the communication device readable medium may include non-transitory communication device readable medium. In some examples, the communication device readable medium may include communication device readable medium that is not a transient propagation signal.

[0205] Instruction 924 can also be transmitted or received on communication network 926 via a transmission medium using any of several transmission protocols through network interface device 920. In one example, network interface device 920 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connection to communication network 926. In one example, network interface device 920 may include multiple antennas for wireless communication using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) technologies. In some examples, network interface device 920 may use multi-user MIMO technology for wireless communication.

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

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

[0208] An implementation of the described subject may include one or more features, individually or in combination, as illustrated below by example.

[0209] Example 1 is an apparatus for a user equipment (UE) configured to operate in a 5G New Radio (5G NR) network. The apparatus includes a processing circuitry system, wherein, in order to configure the UE to perform Physical Uplink Shared Channel (PUSCH) transmissions in the 5G NR network, the processing circuitry system is configured to: decode control information received from a base station in a downlink control information (DCI) format, the control information containing an indicator of an association between a phase tracking reference signal (PTRS) and a demodulation reference signal (DMRS) associated with scheduling PUSCH transmissions; configure the transmission of the DMRS and PTRS for PUSCH transmissions, the position of the PTRS relative to the DMRS based on the association; and a memory coupled to the processing circuitry system and configured to store the control information.

[0210] In Example 2, the subject of Example 1 includes a subject in which the DCI format includes either DCI format 0_1 ​​or DCI format 0_2.

[0211] In Example 3, the topics of Examples 1 to 2 include topics in which PUSCH transmission is either multi-transmitter-receiver point (multi-TRP) PUSCH transmission or multi-panel simultaneous transmission (STxMP) PUSCH transmission.

[0212] In Example 4, the subject of Example 3 includes a subject in which, when the maximum rank used for multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 1-bit second PTRS-DMRS association field contained in the DCI format used to schedule PUSCH transmission.

[0213] In Example 5, the subject matter according to Examples 3 to 4 includes a subject matter in which, when the maximum rank used for multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association field contained in the DCI format used for scheduling PUSCH transmission.

[0214] In Example 6, the subject matter according to Examples 3 to 5 includes a 2-bit second PTRS-DMRS association when the maximum rank for multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association indicating the subject matter of PTRS and DMRS association for PUSCH transmissions to the first TRP and the second TRP.

[0215] In Example 7, the topics of Examples 3 to 6 include the topic that when a PTRS port is configured, when the STxMP PUSCH transmission is configured to be based on a spatial division multiplexing (SDM) scheme, and when the SRS resource set indicator field exists and is equal to "10" or "11" and the maximum rank is equal to 2, the UE does not expect to be indicated with the associated PTRS-DMRS association field having a least significant bit (LSB) value of 1.

[0216] In Example 8, the topics of Examples 3 to 7 include the topic in which, when a PTRS port is configured, when the STxMP PUSCH transmission is configured to be based on a spatial multiplexing (SDM) scheme, and when an SRS resource set indicator field exists and is equal to “10” and “11” and the maximum rank is equal to 2, the UE ignores the topic of a single least significant bit (LSB) in the association.

[0217] In Example 9, the subject matter of Examples 3 through 8 includes the inclusion of a 2-bit PTRS-DMRS association field in the association when a PTRS port is configured, when the STxMP PUSCH transport is configured to be based on a spatial division multiplexing (SDM) scheme, and when the SRS resource set indicator field exists and is equal to “10” and “11” and maxRank is equal to 2.

[0218] In Example 10, the subject matter according to Examples 1 to 9 includes a transceiver circuit system coupled to the processing circuit system, and three or more antennas coupled to the transceiver circuit system.

[0219] Example 11 is a computer-readable storage medium storing instructions for execution by one or more processors of a user equipment (UE), the instructions for configuring the UE to perform Physical Uplink Shared Channel (PUSCH) transmissions in a 5G New Radio (5GNR) network, and for causing the UE to perform operations including: decoding control information received from a base station in a downlink control information (DCI) format, the control information containing an indicator of an association between a phase tracking reference signal (PTRS) and a demodulation reference signal (DMRS) associated with scheduling PUSCH transmissions; and configuring the transmission of the DMRS and PTRS for PUSCH transmissions, the position of the PTRS relative to the DMRS based on the association.

[0220] In Example 12, the subject of Example 11 includes a subject in which the DCI format includes either DCI format 0_1 ​​or DCI format 0_2.

[0221] In Example 13, the topics of Examples 11 to 12 include topics in which PUSCH transmission is a multi-transmitter receiver point (multi-TRP) PUSCH transmission or a multi-panel simultaneous transmission (STxMP) PUSCH transmission.

[0222] Example 14 is a user equipment (UE) configured to perform Physical Uplink Shared Channel (PUSCH) transmission in a 5G New Radio (5G NR) network. The UE includes a front-end circuitry coupled to three or more antennas; a processing circuitry coupled to the front-end circuitry, the processing circuitry being configured to: decode control information received from a base station in a downlink control information (DCI) format, the control information containing an indicator of the association between a phase tracking reference signal (PTRS) and a demodulation reference signal (DMRS) associated with scheduling PUSCH transmission; and configure the transmission of the DMRS and PTRS for PUSCH transmission, the position of the PTRS relative to the DMRS being based on the association.

[0223] In Example 15, the subject matter according to Example 14 includes a subject matter in which the DCI format includes either DCI format 0_1 ​​or DCI format 0_2.

[0224] In Example 16, the topics of Examples 14 to 15 include topics in which PUSCH transmission is a multi-transmitter receiver point (multi-TRP) PUSCH transmission or a multi-panel simultaneous transmission (STxMP) PUSCH transmission.

[0225] In Example 17, the subject of Example 16 includes a second PTRS-DMRS association field, which is included in the DCI format used for scheduling PUSCH transmissions when the maximum rank for multi-TRP PUSCH transmissions is greater than 2 and when a PTRS port is configured.

[0226] In Example 18, the subject matter according to Examples 16 to 17 includes a subject matter in which, when the maximum rank of a multi-TRP PUSCH transmission is greater than 2, and only one PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association field contained in the DCI format used to schedule the PUSCH transmission.

[0227] In Example 19, the subject matter according to Examples 16 to 18 includes a subject matter in which, when the maximum rank for multi-TRP PUSCH transmission is greater than two, and when a PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association, the 2-bit second PTRS-DMRS association indicating the subject matter of the PTRS and DMRS association for PUSCH transmissions to the first TRP and the second TRP.

[0228] In Example 20, the subject matter of Examples 16 to 19 includes the subject matter of when a PTRS port is configured, when the STxMPPUSCH transmission is configured to be based on a spatial multiplexing (SDM) scheme, and when an SRS resource set indicator field exists and is equal to “10” and “11” and maxRank is equal to 2, the UE does not expect to be indicated by the value of the least significant bit (LSB) of the associated PTRS-DMRS association field.

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

[0230] Example 22 is an apparatus that includes components for implementing any of Examples 1 through 20.

[0231] Example 23 is a system for implementing any of the examples in Examples 1 through 20.

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

[0233] Although one aspect has been described in conjunction with specific exemplary aspects, it will be apparent that various modifications and changes can be made to these aspects without departing from the broader scope of this disclosure. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. Therefore, this detailed description should not be construed as limiting, and the scope of each aspect is defined only by the appended claims and the full scope of their equivalents.

Claims

1. An apparatus for a user equipment (UE) configured to operate in a fifth-generation new radio (5G NR) network, the apparatus comprising: A processing circuitry system, wherein, in order to configure the UE for Physical Uplink Shared Channel (PUSCH) transmission in the 5G NR network, the processing circuitry system is configured to: The control information received from the base station in the form of downlink control information (DCI) is decoded. The control information includes an indicator for scheduling the association between the phase tracking reference signal (PTRS) and the demodulation reference signal (DMRS) transmitted using the PUSCH through the three transmit antenna ports. as well as Based on the aforementioned associated configuration: the transmission of the DMRS and the PTRS for the PUSCH transmission, and the position of the PTRS relative to the DMRS; as well as A memory, coupled to the processing circuitry system and configured to store the control information.

2. The apparatus according to claim 1, wherein the DCI format includes DCI format 0_1 ​​or DCI format 0_2.

3. The apparatus according to claim 1, wherein the PUSCH transmission is a multi-transmitter-receiver point (multi-TRP) PUSCH transmission or a multi-panel simultaneous transmission (STxMP) PUSCH transmission.

4. The apparatus of claim 3, wherein when the maximum rank used for the multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 1-bit second PTRS-DMRS association field contained in the DCI format used for scheduling the PUSCH transmission.

5. The apparatus of claim 3, wherein when the maximum rank used for the multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association field contained in the DCI format used for scheduling the PUSCH transmission.

6. The apparatus of claim 3, wherein when the maximum rank used for the multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association, the 2-bit second PTRS-DMRS association indicating the PTRS and DMRS association for the PUSCH transmission to the first TRP and the second TRP.

7. The apparatus of claim 3, wherein when a PTRS port is configured, when the STxMP PUSCH transmission is configured to be based on a spatial division multiplexing (SDM) scheme, and when the SRS resource set indicator field exists and is equal to "10" and "11" and the maximum rank is equal to 2, the UE does not expect to be indicated with the associated PTRS-DMRS association field having a least significant bit (LSB) value of 1.

8. The apparatus of claim 3, wherein when a PTRS port is configured, when the STxMP PUSCH transmission is configured to be based on a spatial division multiplexing (SDM) scheme, and when the SRS resource set indicator field exists and is equal to "10" and "11" and the maximum rank is equal to 2, the UE ignores a single least significant bit (LSB) in the association.

9. The apparatus of claim 3, wherein when a PTRS port is configured, when the STxMP PUSCH transmission is configured to be based on a spatial division multiplexing (SDM) scheme, and when the SRS resource set indicator field exists and is equal to "10" and "11" and the maximum rank is equal to 2, the association includes a 2-bit PTRS-DMRS association field.

10. The apparatus according to claim 1, further comprising: The transceiver circuitry is coupled to the processing circuitry. as well as Three or more antennas are coupled to the transceiver circuit system.

11. A computer-readable storage medium storing instructions executable by one or more processors of a user equipment (UE), the instructions being configured to configure the UE to perform Physical Uplink Shared Channel (PUSCH) transmission in a 5G New Radio (5G NR) network, and to cause the UE to perform operations including: The control information received from the base station in downlink control information (DCI) format is decoded. This control information includes an indicator for scheduling the association between the phase tracking reference signal (PTRS) and demodulation reference signal (DMRS) transmitted via the PUSCH using the three transmit antenna ports; and Based on the associated configuration: the transmission of the DMRS and the PTRS for the PUSCH transmission, and the position of the PTRS relative to the DMRS.

12. The computer-readable storage medium of claim 11, wherein the DCI format includes DCI format 0_1 ​​or DCI format 0_2.

13. The computer-readable storage medium of claim 11, wherein the PUSCH transmission is a multi-transmitter-receiver point (multi-TRP) PUSCH transmission or a multi-panel simultaneous transmission (STxMP) PUSCH transmission.

14. A user equipment (UE) configured to perform Physical Uplink Shared Channel (PUSCH) transmission in a fifth-generation new radio (5G NR) network, the UE comprising: The front-end circuitry is coupled to three or more antennas; A processing circuit system, coupled to the front-end circuit system, is used for: The control information received from the base station in the form of downlink control information (DCI) is decoded. The control information includes an indicator for scheduling the association between the phase tracking reference signal (PTRS) and the demodulation reference signal (DMRS) transmitted using the PUSCH through the three transmit antenna ports. as well as Based on the associated configuration: the transmission of the DMRS and the PTRS for the PUSCH transmission, and the position of the PTRS relative to the DMRS.

15. The UE according to claim 14, wherein the DCI format includes DCI format 0_1 ​​or DCI format 0_2.

16. The UE of claim 14, wherein the PUSCH transmission is a multi-transmitter-receiver point (multi-TRP) PUSCH transmission or a multi-panel simultaneous transmission (STxMP) PUSCH transmission.

17. The UE of claim 16, wherein when the maximum rank used for the multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 1-bit second PTRS-DMRS association field contained in the DCI format used for scheduling the PUSCH transmission.

18. The UE of claim 16, wherein when the maximum rank used for the multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association field contained in the DCI format used for scheduling the PUSCH transmission.

19. The UE of claim 16, wherein when the maximum rank used for the multi-TRP PUSCH transmission is greater than 2, and when a PTRS port is configured, the association includes a 2-bit second PTRS-DMRS association, the 2-bit second PTRS-DMRS association indicating the PTRS and DMRS association for the PUSCH transmission to the first TRP and the second TRP.

20. The UE of claim 16, wherein when a PTRS port is configured, when the STxMP PUSCH transmission is configured to be based on a spatial division multiplexing (SDM) scheme, and when the SRS resource set indicator field exists and is equal to "10" and "11" and the maximum rank is equal to 2, the UE does not expect to be indicated with the associated PTRS-DMRS association field having a least significant bit (LSB) value of 1.

Images