DATA HANDLING FOR A WIRELESS ACCESS NETWORK CONTROLLER

Abstract

A network processing device is connected to a host processor and receives radio access network (RAN) data that describes the RAN's attributes. The network processing device also includes a classification engine to determine a priority level for the RAN data and to identify a memory block on the host processor for the RAN data associated with that priority level. The classification engine creates a cache row in the network processing device's cache to store the RAN data, with the cache row being mapped to the memory block. The network processing device then flushes the cache row containing the RAN data to the memory block based on the priority level.

Description

CROSS-REFERENCE TO A RELATED REGISTRATION

[0001] This application claims the priority benefit pursuant to 35 USC § 119(e) over International Patent Cooperation Treaty (PCT) application no. PCT / CN2023 / 101922, filed on June 21, 2023, which is incorporated herein by reference in its entirety. SPECIALIZATION

[0002] The present disclosure relates generally to the field of distributed data processing systems, and in particular to data transmissions within a data processing platform. BACKGROUND

[0003] Wireless communication systems, both cellular and non-cellular, have evolved significantly in recent years. With the introduction of fifth-generation (5G) wireless cellular networks, considered the mobile communication standard, to enable emerging vertical applications such as the Industrial Internet of Things (IIoT), Extended Reality (XR), and autonomous systems, these systems place stringent communication and computing demands on the infrastructure that enables them to deliver seamless, real-time experiences to users. Traditionally, macro base stations provide cellular wireless connectivity to devices. This approach suffers from issues such as coverage gaps, dropped calls, jitter, high latency, and video buffering delays.

[0004] Link management is a widely used networking solution to achieve optimal load balancing within wireless communication systems based on expected goals. Traditionally, user equipment (UE) triggers a handover request based on quality measurements of wireless channels. The handover request is then processed by the central processing unit (CU). This process can be inefficient and slow. Furthermore, existing link management techniques employ a UE-centric approach rather than a context-aware, global approach at the network layer. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a simplified block diagram illustrating an example network architecture. Fig. Figure 2 is a simplified block diagram illustrating an example network topology. Fig.Figure 3 is a simplified block diagram illustrating an exemplary O-RAN-RIC architecture. Fig. Figure 4 is a simplified block diagram of an example protocol circuit for implementing a Compute Express Link (CXL)-based protocol. Fig. Figure 5 is a simplified block diagram illustrating an exemplary data center cluster architecture. Fig. Figure 6 is a simplified block diagram illustrating an example wireless access network architecture. Fig. Figure 7 is a simplified block diagram illustrating an example network processing device. Fig. Figure 8 is a simplified block diagram illustrating an example system that includes a network processing device. Fig.Figure 9 is a simplified block diagram illustrating a data flow within an example system that includes a network processing device. Fig. Figure 10 is a simplified flowchart illustrating an exemplary technique for using a network processing device. Fig. Figure 11 illustrates a block diagram of an exemplary processor device according to certain embodiments.

[0005] Identical reference symbols and designations in the different drawings indicate identical elements. DETAILED DESCRIPTION

[0006] Connection management and network management are used by many wireless networks to ensure a consistent and well-balanced traffic load across the network. Traditional connection management methods (such as user allocation) employ suboptimal and demanding mechanisms, such as assigning each user a connection to a base station with maximum receive power.

[0007] Cloud computing (as opposed to local computing on a device) can be used to support the large computing demands of the aforementioned emerging vertical applications. However, communication latency to the cloud service can be significant, leading to negative user experiences. Multi-access edge computing (MEC) addresses this issue by bringing computing resources closer to end users to avoid the typical high latency mentioned above. To address the problem holistically, however, the radio access network (RAN) that supports the connection between user devices and an edge server must be reliable, offer high throughput (data rate), and have low latency. The network should be extended in parallel or concurrently with edge computing frameworks to meet the demands of emerging applications.

[0008] In some implementations, connection management can be implemented using machine learning (ML) and / or artificial intelligence (AI)-based algorithms to perform load-aware connection management and / or handoff management to optimize user allocation / connections and load balancing to meet QoS requirements. For example, a graph neural network (GNN) model can be used to model or otherwise represent a network, including heterogeneous RAN with multiple types of network elements / nodes, such as UEs, central units (CUs), distributed units (DUs), and / or radio units (RUs), and / or multiple RAT types, such as one or more WLAN access points, one or more cellular RAN nodes, and the like.These network elements / nodes can interact with each other using standardized and / or predefined interfaces. Each network element / node in the network is represented as a node in the graph or GNN, and each interface is represented as an edge in the graph / GNN. Representing such a network as a graph allows relevant features to be extracted from logical network entities using GNN tools, such as a convolutional neural network (CNN), a spatiotemporal neural network, and / or similar tools. These tools can learn hidden spatial and temporal features of the network and apply these insights, among other exemplary implementations, for load balancing and handoff decisions within the network.

[0009] The implementations discussed herein are scalable and possible on various RAN platforms. Connection management can be implemented using a suitable edge computing framework, such as the O-RAN network architecture. Additionally or alternatively, connection management algorithms can be implemented or defined, among other examples, in the logic of an xApp in O-RAN-RIC, 3GPP standards (e.g., SA6Edge), ETSI standards (e.g., MEC), O-RAN standards (e.g., O-RAN), Intel® Smart Edge Open (formerly OpenNESS) standards (e.g., ISEO), IETF standards or RFCs (e.g., MAMS RFC8743), and / or WiFi standards (e.g., IEEE80211, WiMAX, IEEE16090, etc.).Additionally or alternatively, the embodiments discussed herein may be implemented as software elements that can be made available to any of the aforementioned platforms and / or any other suitable platform as discussed herein.

[0010] Fig. Figure 1 shows an exemplary network architecture 100, where the protocol stack is divided between centralized units (CU) 132 and distributed units (DU) 131. The network architecture 100 includes edge intelligence 135. The edge intelligence 135 includes a connection management function (CMF) 136 and a number of CUs 132. The network architecture 100 also includes a number of DUs 131 and a number of radio units (RUs) 130. Each DU 131 is paired for communication with one CU 132 and one or more UEs 121. The UEs 121 can be the same or similar as those shown below with reference to Fig.The 10 discussed nodes may be 1020 and / or 1010. Additionally or alternatively, a DU 131 may be coupled to the CMF 136. In general, the edge network 100 includes a CMF 136, which is arranged together with one or more CU 132, DU 131, RU 130, and UE 121. The CU 132 and some DU 131 have wired and / or wireless return links 103 to the CMF 136 and support wireless access 105 to the UE 121.

[0011] In some implementations, the CU 132s are central controllers that can operate or otherwise connect multiple DU 131s and multiple RU 130s. The CU 132s are network (logic) nodes that host higher / upper layers of a network protocol function split. For example, in 3GPP-NG-RAN and / or O-RAN architectures, a CU 132 hosts the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) of a next-generation NodeB (gNB), or hosts the RRC and PDCP protocols if they are contained in or operated as an E-UTRA-NR-gNB (en-gNB). The gNB CU 132 terminates the F1 interface connected to the gNB DU 131. Additionally or alternatively, each CU 132 can be connected to one or more DU 131s.

[0012] Each DU 131 controls radio resources, such as time and frequency bands, locally in real time and allocates resources to one or more UE 121s. The DU 131s are network (logic) nodes that host middle and / or lower layers of the network protocol function distribution. In 3GPP-NG-RAN and / or O-RAN architectures, for example, a DU 131 hosts the Radio Link Control (RLC), Medium Access Control (MAC), and High-Physical (PHY) layers of the gNB or en-gNB, and its operation is at least partially controlled by the gNB-CU 132. A gNB-DU 131 supports one or more cells, and a cell is supported by only one gNB-DU 131. A gNB-DU 131 terminates the F1 interface connected to a gNB-CU 132. Additionally or alternatively, each DU 131 can be connected to one or more RU 130s.

[0013] The RU 130s are Transmission / Reception Points (TRPs) or Remote Radio Heads (RRHs) that handle radio frequency (RF) processing functions. The RU 130s are network (logic) nodes that host lower layers based on a functional partitioning of the lower layer. In 3GPP-NG-RAN and / or O-RAN architectures, for example, an RU 130 hosts the low-PHY layer (e.g., Fast Fourier Transform (FFT), Inverse FFT (iFFT), Physical Random Access Channel (PRACH) extraction, etc.). Each of the CU 132, DU 131, and RU 130 is connected by respective links, which can be any suitable wireless or wired (e.g., fiber, copper, etc.) connections.

[0014] In some implementations, the network architecture (or edge intelligence) is implemented using the MEC framework. In these implementations, the CMF is implemented in a MEC host / server, part of a MEC platform, or is a MEC application run by a MEC host or platform. In other implementations, the CMF may be a Multi-Access Management Services (MAMS) server or client, or run by one. In these implementations, an edge compute node and / or one or more cloud compute nodes / clusters may be the MAMS servers, and the CMF is implemented as a Network Connection Manager (NCM) for downstream / DL traffic or a Client Connection Manager (CCM) for upstream / UL traffic.An NCM is a functional entity that handles MAMS control messages from clients (for example, UE 121), configures the distribution of data packets over available access paths 105 and (core) network paths 103, and manages user-level handling (for example, tunneling, encryption, etc.) of traffic flows. The CCM is the peer functional element in a client (for example, UE 121) that handles MAMS control-level procedures, exchanges MAMS signaling messages with the NCM, and configures the network paths 105 / 103 on the client for the transport of user data (for example, network packets, etc.). In other implementations, the CMF 136 can be part of a 3GPP edge data processing architecture. In these implementations, the CMF 136 is implemented as an Edge Application Server (EAS), an Edge Enabler Server (EES) and / or an Edge Configuration Server (ECS) in an Edge Data Network (EDN).These implementations and architectures can, in some cases, be extended by using enhanced network processing devices, such as an Infrastructure Processing Unit (IPU), an intelligent Network Interface Controller (NIC), or other devices. The network processing device possesses logic to support connection management and offload tasks from a host or other system implementing other parts of control management (for example, CMF). A CXL connection can be used to couple the network processing device to the host, as discussed in more detail below.

[0015] As an additional example, the CMF 136 can be part of the O-RAN framework. In these implementations, the CMF 136 can be part of an Intelligent RAN Controller (RIC), such as a Non-Real Time (RT) RIC or a Near-RT RIC. Additionally or alternatively, the CMF 136 can be implemented using one or more applications, microservices, or software tools (for example, xApp) operated by a RIC. In some implementations, a RIC may employ AI / ML techniques to perform connection management. Additionally or alternatively, in O-RAN implementations, the CU 132 is the O-RAN CU (also referred to as "O-CU 132"), the DU 131 is the O-RAN DU (also referred to as "O-DU 131"), and the RU 130 is the O-RAN RU (also referred to as "O-RU 130"). In O-RAN implementations, network management can be hierarchical, with a mix of centralized and distributed controls, each located at a CU 132, DU 131, or DU 131 respectively.RU 130 is located. In other implementations, the CMF 136 can be part of a mobile network, such as a 3GPP 5th generation (5G) core network (5GC). In these implementations, the CMF 136 can be part of an existing network function (NF) or application function (AF) that is located in or connected to other NFs within the core network. Alternatively, in other examples, the CMF 136 can be implemented as a new NF within the core network.

[0016] In addition to or as an alternative to the various examples mentioned above, the techniques and technologies of CMF 136 can be applied to other types of networks of different communication nodes. In some examples, a network may comprise a set of autonomous or semi-autonomous nodes (for example, autonomous vehicles (AVs), robots, drones, unmanned aerial vehicles (UAVs), Internet of Things (IoT) devices, autonomous sensors, etc.), with the (semi-)autonomous nodes organizing communication among themselves. In these examples, one of the autonomous nodes, a gateway device, a network apparatus, or another similar element may be used to assume (or operate) the role of CMF 136.In these examples, the connections or links between the autonomous nodes can be cellular connections (for example, 5G / NR, LTE, WiMAX, and / or any others discussed herein), WLAN connections (for example, WiFi and / or any others discussed herein), Vehicle-to-Everything (V2X) links / connections (for example, cellular V2X, ITS-G5, DSRC, etc.), short-range and / or Wireless Personal Area Network (WPAN) technologies (for example, Bluetooth / BLE, ZigBee, WiFi Direct, and / or any others discussed herein), and / or any other suitable access technology. In another example, a network can comprise a set of servers, hardware accelerators, and a switch fabric in one or more data centers or other similar facilities, which may be distributed across one or more geographic locations.In these examples, a switch fabric, one or more of the servers (or a virtual machine operated by a server), or another similar element assumes the role of (or operates) the CMF 136. In these examples, the connections or links can be a suitable switching or connection technology. Additionally or alternatively, the connection management techniques and technologies can also be applied to other types of networks and / or RATs, such as those where the CU 132, DU 131, and / or RU 130 are WiMAX base stations, WiFi access points, gateway devices, network appliances (e.g., switches, routers, hubs, firewalls, etc.), application servers, data aggregators, and / or the like.

[0017] When a UE 121 attempts to connect to a network (or network access node - NAN), a network entity has the functionality to provide initial access by connecting the UE 121 to a cell. Similarly, when a UE 121 moves, it must maintain its connection to the network for smooth operation, which is facilitated by link management. In addition to managing initial access and mobility, link management solutions can also be programmed to achieve optimal load balancing. Traditionally, a UE 121 triggers a handover (HO) request based on signal / quality measurements of the wireless channel. The HO request is then processed by the CU 132.Link management solutions can traditionally be implemented using a UE-centric approach rather than a context-aware, global approach at the network level. A common UE-centric technique involves using a received signal reference power (RSRP)-based cell-UE linking. As a UE moves away from a serving cell, the RSRP from the serving cell will degrade over time, while its RSRP to a target cell will increase as it gets closer. Therefore, a simple UE-centric maximum RSRP selection approach involves switching to a new cell when the measured RSRP from a target cell is greater than a threshold or greater than the measured RSRP of the current serving cell.While this sophisticated approach is simple and effective, it does not consider the local and global network state and, among other exemplary shortcomings, lacks adequate load balancing. Other implementations can employ machine learning or artificial intelligence techniques to assist and optimize UE handoff, such as predicting obstacles to assigning UE 121 to new cells. Other algorithms can implement load-aware link management, taking into account, among other exemplary techniques, the structure of wireless networks (for example, as modeled in a neural network (NN) model, such as a graph neural network (GNN)).

[0018] Fig.Figure 2 shows a representation of an example network deployment (or network) 200. The network 200 can contain multiple cells 230, with each cell 230 having a cell boundary 210 around a network access node (NAN) 231 that serves or otherwise provides network connectivity to the cell 230. Unit 221 within a cell boundary 210 is provided with network connectivity by the corresponding NAN 231. In other examples, one or more NANs 231 can serve or otherwise provide network connectivity to multiple cells 230, such as in implementations of carrier aggregation (CA) and / or dual connectivity (DC). Individual NANs 231 correspond to one or more distribution units (DUs) and / or one or more distribution units (RUs).In this example, the Network 200 includes a number of NAN 231 or cells (the terms “NAN”, “RU”, “DU” and “cell” may be used interchangeably throughout this disclosure, although these terms refer to different concepts), and a number of UE 221 (for example, with the NAN 231 / cells and UE 221 together referred to as “network equipment”, “network nodes”, “communication equipment”, “communication nodes” or the like).

[0019] As previously mentioned, the CMF 136 can be implemented using the O-RAN framework (see, for example, O-RAN), where the CMF 136 can be implemented as an xApp operated by a RIC. In O-RAN, xApps are applications designed to run on the Near-RT-RIC to provide one or more microservices. The microservices receive input data through interfaces between the RIC and RAN functionality and provide additional functionality as output data to a RAN. In various embodiments, an exemplary CMF can be implemented as one or more xApps that provide connection management for network deployments.For example, components or functions of a RIC (e.g., xApps) can be used for "connection events" (sometimes referred to as "measurement events" or "mobility events"), where mobile users in a network request new connections that may include, for example, connection setup, connection re-establishment, connection reconfiguration, connection release (e.g., to redirect the UE 221 to a different frequency or carrier frequency), connection suspension, connection re-establishment, handovers, cell selection or cell re-selection, measurement report triggering, radio link failure / re-establishment, WiFi association messages, WiFi re-association messages, WiFi disassociation messages, WiFi measurement requests and / or measurement reports, WiFi channel changes, and / or other mobility and state transitions.In one example, a UE 221 continuously performs signal / cell measurements or in response to a configured trigger condition and reports the measurements to the RAN / RAN node when certain conditions are met. For signal / cell measurements, the network can configure one or more types of measurements (for example, RSRP, RSRQ, SINR, RSCP, EcN0, etc.) as the trigger. The collection of measurements at a UE 221 and / or the receipt of a measurement report from a UE 221 can be considered a "measurement event" or "link event."When the CMF 136 detects a connection event (for example, receiving a measurement report, an HO request for an intra-RAT-HO and / or inter-RAT-HO, a cell selection message, a cell re-selection message, radio link failure detection and recovery message(s), beam failure detection and recovery message(s), WiFi association messages, WiFi re-association messages, WiFi disassociation messages, WiFi measurement requests and / or measurement reports, WiFi channel changes, and the like), the CMF 136 can use a connection management algorithm (for example, a GNN-RL model or another ML model) to make new connection decisions to optimize the network 100, such as by balancing the load across the network 100.

[0020] For example, a NAN 231 can send a measurement configuration to a UE 221 to request a measurement report from the UE 221 when one or more specific configured events are triggered, and the UE 221 performs signal quality and / or cell performance measurements for channels / links of one or more cells 230 and / or one or more beams. The UE 221 can perform measurements for cell selection and cell re-selection, as well as for HO operations. When a UE 221 is in a cell provided by a NAN 231, the UE 221 can regularly or periodically search for a better cell or beam according to cell or beam (re) selection criteria. For cell (re) selection, if a better cell is found, that cell or beam can be selected, and the UE 221 can be tuned to one or more control channels of that cell 230.For beam (new) selection, if a better beam is found, the UE 221 can be tuned to one or more of the beam's anchor channels. By using the new beam or cell, the UE 221 can receive system information, registration area information (for example, tracking area information - TAI), other access stratum (AS) and / or non-AS (NAS) information, and / or paging and notification messages (if registered), and transfer them to connected mode (if registered). Additionally or alternatively, some configured events based on the measurement results can trigger the UE 221 to send a measurement report to the serving (source) NAN 231 (for example, if the signal strength or quality of an adjacent cell or beam is stronger than the signal strength or quality of a serving cell or beam).The servicing (source) NAN 231 can choose to transfer the UE 221 to a target NAN 231 by initiating a HO operation. To initiate the HO operation, the source NAN 231 transmits an HO request message to the target NAN 231, and in response, the source NAN 231 receives an HO request acknowledgment (ACK) from the target NAN 231. Once the HO request ACK is received, the source NAN 231 sends an HO command to the UE 221 to begin a binding process with the target NAN 231.

[0021] For the purposes of this disclosure, a measurement report and / or a request for a new cell connection is referred to as a "connection event." Connection events are provided to the CMF 136 by one or more CU 132s or otherwise indicated. When the CMF 136 receives a connection event, the CMF can make new connection decisions for one or more UE 221s to balance the load across the network (or a segment of a network). An O-RAN RIC deployment is expected to include hundreds of cells (for example, 230) and thousands of UEs (for example, 221s).

[0022] Fig.Figure 3 is a simplified block diagram 300, which illustrates the O-RAN Near-RT-RIC architecture 300. RIC 302 can run one or more xApps or other applications or software-based tools configured to run on the Near-RT-RIC 302 to implement the intelligence or logic of the RIC and its implementation functionality. For example, xApps can include multiple microservices that receive input data through interfaces between the Near-RT-RIC 302 and the RAN functionality and provide additional functionality as outputs to the RAN (for example, including one or more NAN 231, CU 132, DU 131, and / or RU 130). Here, the logical functions of the xApp run, which optimize the functions and resources of the CU 132, DU 131 and RU 130, with near real-time control loops (for example, from 10 milliseconds (ms) to 1 second (s)).Near-RT-RIC 301 enables reading and writing of RAN and / or UE information, message transmission infrastructure, and interfaces to Service Management and Orchestration (SMO) 302 and E2 nodes 303. The E2 nodes 303 include one or more CU 132 and one or more cells 230 (for example, DU 131 and / or RU 130). The connection management function of an example RIC can be implemented as a CMF xApp 350, which uses the O1, A1, and E2 interfaces in the Near-RT RIC 301 and can operate in conjunction with other xApps of the RIC 302.

[0023] The Near-RT-RIC 301 can be connected (at the A1 termination) to the Non-RT-RIC 320 in the SMO 302 via the A1 interface / reference point. The Non-RT-RIC 320 supports intelligent RAN optimization by providing policy-based guidance, machine learning model management, and enrichment information to the Near-RT-RIC 301, enabling the RAN to optimize various aspects, such as radio resource management (RRM), under certain conditions. The Non-RT-RIC 320 can also perform intelligent RRM functionalities at non-real-time intervals (e.g., greater than 1 second). In some implementations, the non-RT-RIC 320 can use data analytics and AI / ML training / inference to determine the RAN optimization actions for which it can use SMO 302 services, such as O-RAN node data collection and delivery services.

[0024] The Near-RT-RIC 301 is a logic function that enables near-real-time control and optimization of E2 nodes 303, functions, and resources via fine-grained data collection and actions through an E2 interface with control loops on the order of 10 ms to 1 s. E2 nodes (for example, 303) can include various devices or components, such as one or more NAN 231s, CU 132s, DU 131s, and / or RU 130s. The Near-RT-RIC 301 hosts one or more xApps (for example, 3##) that use an E2 interface to collect near-real-time information (for example, based on a UE 221 and / or a cell / NAN 231) and provide value-added services. The near-real-time information can include one or more measurements / metrics, such as those discussed herein.The control of the Near-RT-RIC 301 via the E2 nodes 303 is guided by the policies and enrichment data provided by the Non-RT-RIC 320 via the A1 interface. In embodiments, the Near-RT-RIC 301 collects cell / NAN characteristics, link characteristics, and UE characteristics from the E2 nodes via the E2 interface 340. The cell / NAN characteristics may include, for example, the aggregation rate of a NAN 231, resource usage (e.g., used / unused resource blocks (RB), physical RB (PRB), etc.) of the NAN 231, and / or other RAN / NAN metrics / measurements. The link characteristics may include, for example, channel / signal quality measurements, such as spectral efficiency (SE), UE measurement report data, and / or other similar link-related measurements / metrics. The UE characteristics can include, for example, UE rate (e.g., data rate, bit rate, etc.), UE resource usage (e.g., resource blocks (RB), physical RB (PRB), etc.).), including UE condition / status (for example, RRC protocol states or the like) and / or other similar UE-related measurements / metrics. The above-mentioned characteristics can be collected based on means and / or other statistical descriptions and the like.

[0025] An example Near-RT-RIC 301 entity can host or otherwise provide the following functions: database functionality (for example, by using Database 305), which enables reading and writing of RAN / UE information; conflict resolution 311, which resolves potentially overlapping or competing requests from multiple xApps (for example, the conflict resolution entity 311 is responsible for resolving conflicts between two or more xApps); xApp subscription management (Verw) 312, which aggregates subscriptions from different xApps and provides unified data distribution to xApps;Administrative services 313 including xApp lifecycle management and fault, configuration, accounting, performance, security (FCAPS) management of Near-RT-RIC 301, as well as logging, tracking, and metric collection, which capture, monitor, and collect the status of Near-RT-RIC internals and can be transmitted to an external system for further evaluation; security 314, which provides the security scheme for the xApps; administrative services, including, for example, fault management, configuration management, and performance management as a service generator for SMO;and message transmission infrastructure 315, which enables message interaction between internal Near-RT-RIC functions. The xApp subscription management 312 manages subscriptions from the xApps to the E2 nodes 303 and enforces authorization of policies that control xApp access to messages. Additionally or alternatively, the xApp subscription management 312 allows, among other examples, the merging of identical subscriptions from different xApps into a single subscription to the E2 node 303.

[0026] Conventional RICs can also host or otherwise provide an interface termination, including an E2 termination that terminates the E2 interface from an E2 node 303; an A1 termination that terminates the A1 interface from the non-RT-RIC 320; and an O1 termination that terminates the O1 interface from the SMO 302. Near-RT-RIC 301 also hosts or otherwise provides various xApp-hosted functions, enabling services to run at Near-RT-RIC 301 and the results to be sent to E2 node 303 via the E2 interface. In various embodiments, the xApp functionality hosted by Near-RT-RIC 301 includes CMF 136, implemented as CMF-xApp 400. One or more xApps can provide UE-related information to be stored in a UE Network Information Base (UE-NIB) (see, for example, UE-NIB 405 from Fig.4) The UE-NIB 405 maintains a list of UE 221 and associated data. The UE-NIB 405 maintains the tracking and correlation of the UE identities associated with the connected E2 nodes 303. One or more xApps can provide radio access network-related information to be stored in a radio network information base (R-NIB). The R-NIB stores the configurations and near-real-time information regarding the connected E2 nodes 303 and the mappings between them. The UE-NIB and the R-NIB can be stored in the database 305. Among other examples, various aspects of the O-RAN architecture are discussed, including aspects of the non-RT-RIC 320 and the near-RT-RIC 301. In some implementations, such as the one discussed herein, a RIC (for example, 301) can be implemented using a host processor device.In some cases, the functionality of a traditional RIC can be distributed between the host processor devices and another device, such as a network processing unit (for example, an IPU), which can manage communication from the E2 nodes 303 and reduce the load on the host processor device by handling parts of the message delivery infrastructure (for example, 315), possibly among other functions and functionalities of the RIC, as discussed in the examples below. Furthermore, link protocols, such as CXL, can be used to facilitate communication and coordination between the network processing unit and the host processor device, which implements the RIC functionality, among other exemplary functions, as detailed below.

[0027] Fig.Figure 4 is a simplified Block Diagram 400 illustrating exemplary protocol logic implemented in hardware and / or software to implement a Compute Express Link (CXL) protocol. It should be acknowledged that while much of the discussion focuses on features provided by a CXL protocol and CXL-compliant communication channels, other substitute protocols with similar, comparable features can replace CXL in the embodiments discussed below. The CXL link protocol was designed to provide enhanced, high-speed CPU-to-device and CPU-to-memory connectivity, accelerating the performance of next-generation data centers, among other applications.CXL maintains memory coherence between the CPU's memory space and the memory on connected devices, which, among other exemplary benefits, enables resource sharing to achieve higher performance, reduced software stack complexity, and lower overall system costs. CXL enables communication between host processors (e.g., CPUs) and a range of workload accelerators (e.g., graphics processing units (GPUs), field-programmable gate arrays (FPGAs), tensor and vector processors, machine learning accelerators, network accelerators, and purpose-built accelerator solutions).CXL was designed to provide a standard interface for high-speed communications, as accelerators are increasingly used to complement CPUs in order to support emerging data processing applications, such as artificial intelligence, machine learning, and other applications.

[0028] A CXL connection can be a discrete or in-packet, low-latency, high-bandwidth connection that supports dynamic protocol multiplexing of coherence, memory access, and input / output (I / O) protocols. Among other applications, a CXL connection can allow an accelerator to access system memory, for example, as a caching agent and / or host system memory. CXL is a dynamic multi-protocol technology designed to support a wide range of accelerators. CXL provides an extensive set of subprotocols, including I / O semantics similar to PCIe (CXL.io), caching protocol semantics (CXL.cache), and memory access semantics (CXL.mem), over a discrete or in-packet connection. Depending on the specific accelerator usage model, all CXL protocols or only a subset of the protocols can be enabled.In some implementations, CXL can build upon the established, widely used PCIe infrastructure (for example, PCIe 5.0), utilizing the physical and electrical PCIe interface to provide an extended protocol in areas such as I / O, memory protocol (for example, enabling a host processor to share memory with an accelerator device), and coherence interface.

[0029] Fig.Figure 4 shows an example protocol stack and the associated logic (implemented in hardware and / or software) used to implement CXL connections. For example, the protocol logic may be organized into multiple layers to implement the multiple protocols supported by the port. A port may, for example, include transaction layer logic (e.g., 470), link layer logic (e.g., 472), and physical layer logic (e.g., 474) (e.g., fully or partially implemented in circuitry). For example, a transaction (or protocol) layer (e.g., 470) may be subdivided into transaction layer logic 475, which implements PCIe transaction layer 476, and CXL transaction layer extensions 478 (for CXL.io) of a basic PCIe transaction layer 476, and logic 480 for implementing cache (e.g., CXL.cache) and memory (e.g., CXL.mem) protocols for a CXL connection. Similarly, link layer logic 472 can be provided to implement PCIe data link layer 482 and a CXL link layer (for CXL.io), which is an extended version of PCIe data link layer 484. A CXL link layer 472 can also include cache and memory link layer extension logic 485 (for example, for CXL.cache and CXL.mem).

[0030] Continuing with the example of Fig.4. A CXL link layer logic 472 can be connected to CXL arbitration / multiplexing (ARB / MUX) logic 455, which, among other exemplary implementations, combines the data traffic from the two logic streams (for example, PCIe / CXL.io and CXL.cache / CXL.mem). During link training, the transaction and link layers are configured to operate in either PCIe or CXL mode. In some cases, a host CPU may support the implementation of either PCIe or CXL mode, while other devices, such as accelerators, may only support CXL mode. In some implementations, the port (for example, a Flex Bus port) may use physical layer 474, which is based on a PCIe physical layer (for example, an electrical PCIe PHY 486).For example, a physical flex bus layer can be implemented as a convergent logic physical layer 488 that can operate in either PCIe mode or CXL mode, based on the results of the alternative mode negotiation during the link training process. In some implementations, the physical layer can support multiple signal rates (e.g., 8 GT / s, 16 GT / s, 32 GT / s, etc.) and multiple link widths (e.g., x16, x8, x4, x2, x1, etc.). In PCIe mode, links implemented through the port can be fully compliant with native PCIe features (e.g., as defined in the PCIe specification), while in CXL mode, all features defined for CXL are supported.Accordingly, a Flex Bus port can provide a point-to-point connection capable of transmitting native PCIe protocol data or dynamic multi-protocol CXL data to provide I / O, coherence, and memory protocols over PCIe electricals, among other examples.

[0031] The CXL I / O protocol, CXL.io, provides a non-coherent load / memory interface for I / O devices. Transaction types, transaction packet formatting, credit-based flow control, virtual channel management, and transaction ordering rules in CXL.io can follow the entire PCIe definition or a section thereof. The CXL cache coherence protocol, CXL.cache, defines the interactions between the device and the host as a series of requests, each with at least one associated response message and sometimes a data transfer. The interface consists of three channels in each direction: request, response, and data.

[0032] The CXL memory protocol, CXL.mem, is a transactional interface between the processor and memory, utilizing the physical and interconnect layers of CXL for cross-chip communication. CXL.mem can be used for several different memory connection options, including, but not limited to, situations where the memory controller resides in the host CPU, in an accelerator device, or on a memory buffer chip. CXL.mem can be applied to transactions involving different memory types (e.g., volatile, persistent, etc.) and configurations (e.g., flat, hierarchical, etc.). In some implementations, a coherence engine on the host processor can be connected to memory using CXL.mem requests and responses.In this configuration, the CPU coherence engine is considered the CXL.mem master, and the storage device is considered the CXL.mem subordinate. The CXL.mem master is the agent responsible for obtaining CXL.mem requests (for example, read, write, etc.), and a CXL.mem subordinate is the agent responsible for responding to CXL.mem requests (for example, data, closures, etc.). If the subordinate is an accelerator, the CXL.mem protocol assumes the presence of a Device Coherency Engine (DCOH). This agent is assumed to be responsible for implementing coherence-related functions, such as snooping device caches based on CXL.mem instructions and updating metadata fields.In implementations where metadata is supported by device-bound storage, it can be used by the host to implement, among other exemplary uses, a coarse snoop filter for CPU sockets.

[0033] In some implementations, an interface can be provided for coupling circuits or other logic (for example, an Intellectual Property (IP) block or other hardware element) that implement a link layer (for example, 472) with circuits or other logic (for example, an IP block or other hardware element) that implement at least one section of a physical layer (for example, 474) of a protocol.For example, an interface based on a Logical PHY Interface (LPIF) specification to define a common interface between a link layer controller, module, or other logic and a module implementing a logical physical layer (“logical PHY” or “logPHY”) to enable interoperability, design and validation reuse between one or more link layers and a physical layer for an interface to a physical link, as in the example in . Fig. 4. To enable this. Additionally, as in the example in Fig.4, an interface with logic (for example, 481, 485) can be implemented to implement and support multiple protocols simultaneously. Furthermore, in such implementations, an arbitration and multiplexer layer (for example, 455) can be provided between the link layer (for example, 472) and the physical layer (for example, 474). In some implementations, each block (for example, 455, 474, 481, 485) in the multi-protocol implementation can be connected to the other blocks via an independent interface (for example, 492, 494, 496). In cases where branching is supported, each branched port can have its own independent interface, among other examples.

[0034] CXL is a dynamic, multi-protocol technology designed to support accelerators and storage devices. CXL provides a comprehensive set of protocols. CXL.io is used for discovery and enumeration, error reporting, peer-to-peer (P2P) access to CXL storage, and host physical address (HPA) lookup. The CXL.cache and CXL.mem protocols can be implemented through various usage models for accelerators or storage devices. A key advantage of CXL is that it provides a low-latency, high-bandwidth path for an accelerator to access the system and for the system to access the storage connected to the CXL device. The CXL 2.0 specification enabled additional usage models, including managed hot-plugging, security enhancements, persistent storage support, storage error reporting, and telemetry.The CXL 2.0 specification also enables support for single-level switching for fan-out, as well as the ability to bundle devices across multiple virtual hierarchies, including multi-domain support for storage devices. The CXL 2.0 specification also allows these resources (storage or accelerators) to be switched offline from one domain to another, enabling resources to be transferred simultaneously across different virtual hierarchies depending on their resource requirements. Additionally, the CXL 3.0 specification doubled the bandwidth while enabling even more usage models beyond those introduced in CXL 2.0. For example, CXL 3.0...The CXL 3.0 specification provides PAM-4 signaling, utilizing the PCIe base specification PHY along with CRC and FEC to double bandwidth, with an optional flit configuration for low latency. Multi-level switching is enabled with the CXL 3.0 specification, which supports up to 4K ports, allowing CXL to evolve as a fabric extending to the rack and pod levels, including non-tree topologies. The CXL 3.0 specification enables devices to perform direct peer-to-peer access to host-managed device memory (HDM) using unordered I / O (UIO) (in addition to memory-mapped I / O - MMIO) to deliver scalable performance. Snoop filter support can be implemented in Type 2 and Type 3 devices to enable direct peer-to-peer access by using the features in CXL.To enable the back-invalidate channels introduced in memory. Support for shared memory is supported, among other exemplary features for collaborative processing across multiple virtual hierarchies.

[0035] CXL is suitable for maintaining memory coherence between the CPU's memory space and the memory on connected devices, allowing each CPU core or any other I / O device configured to support CXL to use this connected memory and cache data locally. Furthermore, CXL enables resource sharing for increased performance. Systems, such as those implementing a RIC, can leverage the combined capabilities of CXL and intelligent network processing units (such as IPUs) to achieve this efficiency with minimal network data movement and improved near-memory processing. Such enhanced clusters can deliver benefits such as lower latency, better resource utilization, and reduced power consumption, among others. Fig.Figure 5 is a simplified block diagram (500) illustrating a logical view of such a section of such an enhanced cluster. As presented above, a service mesh can be composed of one or more clusters (for example, 505, 510). Host devices (for example, 515a, 515b, 520a, 520b, etc.) can each host different programs, services, or applications (for example, 525a-h) that run on the respective host and can share and operate various data on the service mesh. All data (530) moved within the cluster can be processed using the network processing device of the respective cluster (for example, 535, 540), with the network processing device further handling communications between clusters and the internal connections between hosts and the network processing device within the cluster.The network processing device's attached storage can be used to implement a storage pool for the cluster. Accordingly, data used in transactions within the cluster can be stored in the storage pool on the network processing device. Consequently, when the host device accesses the data within a transaction, it can use CXL memory accesses (for example, 550, 555) to read or write data directly from the CXL cache, as if it were local storage.

[0036] Fig.Figure 6 is a simplified block diagram 600 illustrating an example of the data flow of a conventional implementation of a Near-RT-RIC (for example, 301) that runs and is fully implemented on the Host Processor Platform 605. Network Interface Controllers (NICs) (for example, 610, 615) can be used to couple the Host Platform 605 with various E2 nodes 303, 623 (for example, DU devices, CU devices, etc.). Connection Management (CM) is a critical feature in 5G wireless networks.In modern mobile networks, connection management can be challenging, for example, in scenarios where user equipment (US) moves rapidly, such as in onboard data processing systems (e.g., self-driving or autonomous driving assistance systems like autopilot), in environments with a large number of USs (e.g., football fans in a stadium), and in other examples. In some implementations, achieving "smooth and balanced operation in 5G" based on "US greedy max RSRP-based handover" can be difficult. In such situations, global connectivity management for USs and cells can be used to avoid unbalanced results (e.g., an excessive number of USes connected to a single cell, such as missing adjacent cells).

[0037] In one example, a RIC (for example, 301) in an O-RAN deployment can be used to perform global connection management (for example, by using one or more xApps or other software tools running in or in conjunction with the RIC). For instance, one or more xApps of the RIC can be configured to perform connection management tasks using different algorithms (for example, a GNN-based algorithm). E2 interfaces can be used to communicate data to the RIC, such as data received by nodes (for example, E2 nodes), such as baseband units (BBUs) or distributed units (DUs) and central units (CUs) within a radio access network (625) (for example, a 5G cellular network). The E2 nodes can collect radio access network (RAN) data (for example, according to 3GPP TS28.552) and report the data to the E2 termination (630).In this example, the E2 termination 630 can be deployed on the host platform 605 itself and can be connected on the platform to host storage 635 and the near-RT RIC 301, which can run a number of software tools, including xApps, one of which can be a GNN-based connection management application 640. The E2 termination 630 on the host platform 605 is used to receive and transmit (and decode and encode) data on an E2 interface. For example, RAN data can be received from the RAN 625 via the network interface controller (NIC) 610. In some cases, the NIC 610 notifies the host platform 605 of incoming data using interrupt requests (IRQs) and sends the data to the E2 termination logic 630 via an E2 interface.The E2 termination 630 decodes the data in parallel with the numerous host tasks running on the platform 605 (for example, by a host processor (e.g., CPU)) and stores the decoded data in the platform's memory 635. The RAN data is retrieved from memory by the platform 605's CPU and placed in the local cache (e.g., Last Level Cache (LLC)) to be retrieved and used by CM-xApps 645, for example, in an inference-based algorithm to determine global handoff decisions and other aspects of connection management. The RIC 301 sends the corresponding commands via the E2 termination 630, the NIC 610, and E2 nodes (e.g., 303) to the RAN to effect the UE handoff.

[0038] However, a challenge for this arrangement arises in implementations such as scenarios with rapidly fading wireless channels, where the received signal measurements of the UE (which may be contained, for example, in the RAN data received and consumed by the RIC 301, or otherwise influenced, such as received reference signal power (RSRP), received reference signal quality (RSRQ), signal interference + noise ratio (SINR), received signal strength indicator (RSSI), and others) vary rapidly. xApps, in conjunction with the tasks they perform, including connection management, may access and use different types of RAN data and may access this data at different time windows.The processing resources of one or more platform processors can thus be tasked not only with decoding large amounts of data (for example, during E2 termination) but also with executing xApps (for example, 645) on the RIC 301 in conjunction with delivering services to the RAN 625. This can, among other exemplary problems, impair the ability of the system and the 605 platform to provide and process the necessary data in a timely and accurate manner on the RIC 301's xApps in order to effectively deliver the resulting decisions and commands for connection management.

[0039] In some implementations, the delivery of data to a RIC 301 and the execution of connection management and other activities for a RAN 625 can be improved by using an enhanced network processing device (AED) along with a processing platform. A portion of the logic and associated functionality of a traditional processing platform can be offloaded to the enhanced RIC, allowing the processing platform's resources to be more comprehensively dedicated to implementing the RIC and running xApps. For example, the E2 closure logic can be implemented in the enhanced network processing device, along with the logic to classify data for consumption by the RIC and to prioritize the delivery of data to the processing platform (and the RIC).

[0040] With reference to FIG. 7, simplified block diagram 700 is shown, illustrating an exemplary implementation of network processing device 705, such as an enhanced intelligent NIC, an infrastructure processing unit (IPU), or other device. The network processing device 705 may have network port 710 to connect to a network (for example, via an Ethernet connection) and, in some implementations, may include NIC circuitry to allow the network processing device 705 to implement features of a NIC or to replace a NIC in the architecture. The network processing device 705 may additionally include E2 termination circuitry 715 to allow the E2 termination logic and E2 interface decoding / encoding to be implemented on the network processing device 705 (for example, instead of a host processing device).The Network Processing Device 705 may also include port 720 to implement a low-latency, high-bandwidth, multi-protocol path that allows the Network Processing Device 705 to access the memory of an attached host processor. In some implementations, port 720 may be compliant with a CXL-based protocol to implement a CXL connection for coupling the Network Processing Device 705 to a host processor, through which the data processed by the Network Processing Device 705 is provided to a Resource Information Center (RIC) hosted on the host processing system, among other examples. In some implementations, the port 720 logic may include circuitry for implementing cache-coherent transactions, such as via a Device Coherency Agent (DCOH) and Snoop Filter (SF), as well as CXL Cache 722 for use by port 720, among other examples.

[0041] Continuing with the example of Fig. The Network Processing Device 705 can include the Classification Engine 725, implemented in hardware circuitry and / or firmware, to classify RAN data received and decoded by the E2 Termination Circuit 715 from E2 nodes in a network. The E2 Termination Circuit 715 can also be used to encode and deliver the data output from xApps in a RIC to E2 nodes in a network (for example, via appropriate E2 interfaces based on 5G-O-RAN specifications). This allows resources of a host processing device coupled with the Network Processing Device 705 to be reserved for other, higher-value workloads than managing the E2 termination, among other exemplary benefits.

[0042] In the example of Fig.The Network Processing Device 705 can be used not only to offload E2 termination but also to process RAN data before forwarding it to the RIC, to prioritize RAN data, or to sequence RAN data based on priority. The way in which RAN data is to be prioritized by the Network Processing Device 705 can be defined by using a set of registers (for example, 730, 735) located on the Network Processing Device 705.For example, one or more control registers 730 (implemented, for instance, as control or configuration registers compatible with a CXL or PCIe-based protocol) can be provided through which the host processing device (and associated xApps to run on the RIC hosted on the host processing device) can configure the other registers in the set, such as the bound memory table 735, to determine how the classification engine 725 should sequence data for delivery to the host processor. The bound memory table 735 can contain a number of possible entries that define areas of bound memory within the host and assign priority levels to those specific areas of bound memory.The Network Processing Device 705 can use the Classification Engine 725 to identify received RAN data and determine which priority level should be applied to it. Based on this classification, the Network Processing Device 705 can cause the data to be moved to the appropriate area of ​​bound memory in the Host Processing Device or flushed for consumption by the xApps (for example, a connection management xApp) running on the Host Processing Device.

[0043] Table 1 illustrates an example of a control register 730. The host processing device can write to control register 730 to instruct the network processing device 705 on how to configure the bound memory table 735. For example, a set of control registers 730 can be deployed in the standard PCIe / CXL memory-mapped configuration space. After the host processing device (for example, based on one or more xApps, NR-RIC, or other logic running on the host processing device) sets control register 730, the network processing device 705 can locate corresponding entries in the bound memory table 735 whose "Table Identity" field matches the "Target Table" field, with the remaining attributes (for example, priority, address, memory size, etc.) matching the table's name.), accordingly, based on the matching entry in the bound memory table. TABLE 1: Example tax register Area type Value Description Target table Unsigned INT For example, 0x00000002 Target table entry number (for example, the identifier "2" indicates that attribute values ​​should be set to an entry in a bound memory table with a matching table value) priority Unsigned INT For example, 0x00000001 A higher value indicates a higher priority when the CXL cache is flushed into bound memory. address Unsigned long int For example, address: 0x21000000000 System address of the corresponding memory area in the host memory block. Storage size Unsigned long int Memory area size: for example, 64K Size of a memory block in the host system or in the CXL memory.

[0044] Table 2 presents an example implementation of a bound memory table 735. A bound memory table can contain CXL cache memory attributes, with entries in the table specifying a corresponding block of system memory bound to CXL cache rows. The bound memory table 735 can specify a "priority" or priority level to be associated with the described memory block, with priority values ​​being used to flush cache rows in a preferred order. Higher priority values ​​can, for example, indicate that corresponding cache rows (for example, in CXL cache 722) should be flushed first via CXL connection 750 (for example, using the CXL protocol).The cache contains values ​​with lower priority, which can indicate that a corresponding cache row should be cleared after higher-priority data has been cleared, among other examples (for instance, when lower-priority values ​​in the bound memory table indicate a higher priority level, etc.). The host processor can cause values ​​in a bound memory table (for example, priority values) to be dynamically adjusted (for instance, by writing to a corresponding control register 730). TABLE 2: Example register for bound memory Area type Value Description Table Identity Unsigned e Int For example, 0x00000002 Identity of the definitive table entry, value 2 indicates a second table provided by this IPU device. priority Unsigned e Int For example, 0x00000001 A high value indicates a high priority when the CXL cache is flushed back into bound memory in the host. address Unsigned long int For example, address: 0x21000000000. Default setting: 0xffffffffffffffff. System address of the memory area via memory block; the default value 0xffffffffffffffff indicates that the table is not specified with the correct value. Storage size Unsigned long int Memory area size: For example, 64K Size of a memory block in the host system. Default value: 0, indicates that the table is not defined.

[0045] The Classification Engine 725 can analyze and classify data (for example, RAN data) received and decoded by the E2 termination circuit to determine a priority level to assign to the data. For example, RAN data can be classified based on fields or metadata and a definition provided by one or more, or in accordance with, one or more xApps of a connected host processing device. Table 3 shows example classification definitions as they can be provided or set according to one or more xApps. For example, SINR measurement data can be identified by the Classification Engine 725 and classified as priority level "2" data, among other examples.From this classification, the 725 classification engine can consult one or more bound memory tables to identify a memory block (for example, an address) assigned to priority level 2. Accordingly, the 725 classification engine can identify the corresponding target memory area and data for the 722 CXL cache to create corresponding CXL cache rows. The cache row corresponding to the data can be flushed into the appropriate memory block on the host processing device based on the priority level (for example, by applying the CL port's DOCH / SF logic to maintain coherence according to the CXL protocol). The xApps and / or the RIC on the host processing device can then access and consume the flushed data (for example, in conjunction with connection management operations). TABLE 3: Example priority assignments for different data sets. data set priority Description of the data set Sentence 1 2 SS-RSRP distribution per SSB. SS-RSRP distribution per SSB of neighboring NR cell. SINR measurement. Sentence 2 1 SS-RSRP distribution per SSB. SS-RSRP distribution per SSB of neighboring NR cell. Sentence 3 3 Average number of RRC connections. Maximum number of RRC connections. Minimum number of RRC connections. Sentence 4 4 DL-PRB was used for data traffic. Average DL-UE throughput in gNB. Total number of DL-TB.

[0046] With regard to Fig.Figure 8 shows the following: a simplified block diagram 800 depicting an extended network processing device 705 coupled to an E2 node 303 and an example host processing platform 805 via a CXL connection 750. An example flow for configuring the network processing device 705 is shown to properly prioritize rows in the CXL cache 722 and route (or bind) them to memory blocks (for example, 810) in the platform 805 so that they can be used by one or more xApps 640 in a Near-RT-RIC 301.The Host Processing Platform 805 can prepare memory 815, 850 to designate various blocks (for example, 810) for use by the RIC 301, for example, using the memory blocks as a database for storing RAN data consumed by a particular application (for example, a GNN-based connection management xApp 645) that has been pushed, flushed, or otherwise delivered to the Host Processing Platform 805 by the Network Processing Device 705.The xApp (for example, 640, 645) or an associated driver can be used to communicate and specify these memory block allocations within the network processing device, 855, for example, by writing to control register 730 and specifying several different priority levels for passing data directly from the network processing device's cache (for example, 722) to the designated memory blocks (for example, 815) via the connection (for example, CXL connection 750). The network processing device's register management logic 705 can specify the bound memory tables 735 based on the information specified in the control registers 730, 860. For example, the "Target Table" attribute can be used to locate a bound memory table with a matching "Table Identity" entry value.The register management logic can move attributes from the control register to the corresponding bound memory table, including priority, address, memory size, etc. In some implementations, a corresponding bound memory table can be provided for each of the memory blocks designated on the host processing platform for use by xApps or other RIC tools. In some implementations, host processing platform tools (for example, xApps) can also specify which records or record characteristics should be considered by the classification engine when determining the priority levels to be assigned to incoming RAN data in the network processing unit.In some implementations, for example, priority-level data mappings from xApps can be communicated to the 725 classification engine via the E2 termination circuit and an E2 interface. For instance, the xApp uses certain datasets as prerequisite inputs to make UE transfer decisions, and such datasets can be assigned a correspondingly high priority level.

[0047] With regard to FIG. 9, after the bound memory tables 735 and the classification engine 725 are configured (for example, by using a procedure such as in the example in Fig. 8 shown), the 705 network processing device can be used to improve the handling of RAN data for consumption by an exemplary xApp. Fig.Figure 9 shows an exemplary flow of specific RAN data being pushed (e.g., emptied or cleared) from an extended network processing device 705 into the memory 815 of a host processing device 805 for consumption by a RIC 301 (e.g., a near-RT-RIC). RAN data can be received at the E2 node 303 from a wireless network 625 (e.g., a 5G data network), 905. The RAN data can be received at the network processing device 705 via an E2 interface from the E2 node 303, 910, and the E2 termination circuit 715 can decode the data and provide the (sometimes large amounts of) data to the classification engine 725, 915.The classification engine 725 takes into account the data record priority level mapping information, mapping, rules or other information (provided, for example, by xApps (for example, 640, 645) of the host processing platform 805) to determine respective priority levels for the RAN data decoded by the E2 termination circuit 715.

[0048] Continuing with the example of Fig.Classification engine 725 can be used to populate cache rows in cache 722 based on the determined priority level for a received RAN record. The classification engine can efficiently package the received data (for example, removing data from fields not used by the consuming xApp). Classification engine 725 can identify and read a bound memory table corresponding to the priority level assigned to the record, and 920 can determine the address of the system memory block to map to the local cache row used to store the record (for example, the RAN record). This mapping is used to direct the flushing (for example, 925) of the record to the appropriate system memory block (for example, 810).Accordingly, the classification engine 725 generates the cache row based on information retrieved from the corresponding bound memory table 735 (according to the specified priority level), including address, memory size, etc. For example, the cache row can be generated based on a CXL-based protocol (for example, CXL.cache), 930, and can assign an appropriate cache state label to the cache row (for example, "modified" in a CXL-Modified-Exclusive-Shared-Invalid (MESI) protocol model). Other cache-coherent protocols can be used to perform such purges or clearings in other implementations with different cache coherence state models.

[0049] In some implementations, the Network Processing Unit 705 can use the semantics of a cache-coherent link protocol to push, flush, or clear a row from its local cache containing RAN data (as decoded by the E2 termination circuit 715) into the memory or cache of the host processor device, effectively transferring the RAN data to one or more xApps running in a RIC on the host processor device. For example, the protocol circuit of the port (for instance, 720) can be used to send a read request from the Network Processing Unit 705 to the host processor device 805 via link 750, where the read request includes a write back to memory (for example, a CXL.cache RdOwn request).In such a case, reading can allow the network processing device 705 to secure ownership of the memory block (for example, for receiving RAN data associated with a specific priority level) and to write or clear the RAN data directly into the memory block (for example, 810) by using the network processing device's and host processor's protocol circuitry to implement connection 750, without software involvement. In some implementations, an xApp (for example, a GNN-CM xApp 645) can actively use local cache 950.The xApp can identify (for example, from a cache error) that incoming RAN data should be used by the network processing unit and initiate a fetch operation via connection 750 (for example, in conjunction with a CXL bias flip) to, among other exemplary implementations, retrieve cache lines from the cache 722 of the network processing unit 705 directly into the fast cache 950, 935 used on the host processor device.Where cache rows of RAN data are available to be removed or retrieved by the network processing unit 705, but the cache rows have been determined (by the classification engine) to have two different priority levels, the classification engine 725, in conjunction with the port protocol logic, can cause the higher priority cache row to be delivered to the RIC 301 on the host processing unit 805 for use before the lower priority cache row.

[0050] With reference to FIG. 10, simplified flowchart 1000 is shown, illustrating an exemplary technique for using a network processing device, such as an IPU, intelligent NIC, Edge Processing Unit (EPU) (for example, to perform edge orchestration and management tasks), intelligent RIC, or DPU, to improve the forwarding of data to a RAN controller in a host processing platform. In one example, RAN data can be received from a RAN (for example, from a RAN node (for example, an E2 node)) at a first interface of the network processing device, 1005.The network processing device may include interface termination circuits to decode the data, 1010, and further analyze the decoded data to determine attributes of the RAN data, thereby determining one of several different priority levels, 1015, which are applied to the RAN data based on those attributes. Multiple memory blocks of the host processor device may be allocated to the several different priority levels (for example, based on a bound memory table or other register of the network processing device) that can be configured toward the host processor device (for example, based on a Near-RT-RIC or an xApp running on the host processor device).The network processing device can identify a specific memory block associated with the priority level, 1020, and create a cache row in the network processing device's cache associated with that specific memory block, 1025 (for example, as a copy of the specific memory block), and store the RAN data in the cache row. The network processing device can cause the cache row to be flushed or cleared back to the specific memory block, 1030, by using a flush, writeback, or other operation defined in a cache-coherent protocol, such as CXL, used on a connection that couples the network processing device to the host processor device.The timing for clearing the cache line to the host processor device can be based on the priority level associated with the RAN data, the cache line, and a specific memory block, with higher priority levels taking precedence over lower priority levels. This allows higher-priority data to be served and consumed by the host processor device before lower-priority data. The host processor device can generate result data based on the consumption of the served RAN data (for example, by using a RIC or xApp) and can return the result data (at 1035) to the network processing device, enabling the network processing device to route the result data (at 1040) back to RAN entities to perform connection management or other services on the RAN, among other exemplary features and implementations.

[0051] It should be noted that the devices, methods, and systems described above can be implemented in any electronic device or system. As a specific illustration, the following is provided... Fig.11 provides an exemplary implementation of a processing device, such as one that may be included in a network processing device. It should be noted that other processor architectures may be provided to implement the functionality and request processing of an exemplary network processing device, including the implementation of the exemplary network processing device components and functionalities discussed above. Furthermore, it should be noted that while the examples discussed above focus on the use of CXL and CXL-based resource pooling, the reference to CXL is merely illustrative. In fact, the more generalized concepts disclosed herein can be applied equally and advantageously to other connections and connection protocols that, among other examples, enable similar resource pooling.

[0052] Referring to Fig.Figure 11 shows block diagram 1100 of an exemplary data processing device (for example, a central processing unit (CPU)) 1112, which is coupled with various other components of a platform according to certain embodiments. Although the CPU 1112 represents a specific configuration, the cores and other components of the CPU 1112 can be arranged in any suitable manner. The CPU 1112 can include any processor or processing device, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, an application processor, a coprocessor, a system-on-a-chip (SoC), or any other code-executing device. In the embodiment shown, the CPU 1112 includes four processing elements (cores 1102 in the embodiment shown), which can include asymmetric or symmetric processing elements.However, the CPU 1112 can include any number of processing elements, which can be symmetrical or asymmetrical.

[0053] In one embodiment, a processing element refers to hardware or logic to support a software thread. Examples of hardware processing elements include: a thread unit, a thread slot, a thread, a processing unit, a context, a context unit, a logical processor, a hardware thread, a core, and / or any other element capable of maintaining state for a processor, such as an execution state or architectural state. In other words, in one embodiment, a processing element refers to any hardware capable of being independently associated with code, such as a software thread, an operating system, an application, or other code.A physical processor (or processor socket) typically refers to an integrated circuit that potentially includes any number of other processing elements, such as cores or hardware threads.

[0054] A kernel can refer to logic placed on an integrated circuit capable of maintaining independent architectural states, each independently maintained architectural state associated with at least some fixed execution resources. A hardware thread can refer to any logic placed on an integrated circuit capable of maintaining independent architectural states, where the independently maintained architectural states share access to execution resources. As can be seen, the boundary between the nomenclature of a hardware thread and a kernel overlaps when certain resources are shared and others are fixed to a specific architectural state.Nevertheless, an operating system often treats a core and a hardware thread as individual logic processors, with the operating system being able to schedule operations on each logic processor individually.

[0055] The physical CPU 1112, as in Fig.Figure 11 illustrates this with four cores—cores 1102A, 1102B, 1102C, and 1102D—although a CPU can contain any suitable number of cores. Here, cores 1102 can be considered symmetric cores. In another embodiment, cores can contain one or more out-of-order processor cores or one or more in-order processor cores. However, cores 1102 can be individually selected from any type of core, such as a native core, a software-managed core, a core adapted to run a native instruction set architecture (ISA), a core adapted to run a translated ISA, a co-developed core, or any other known core. In a heterogeneous core environment (for example, asymmetric cores), some form of translation, such as binary translation, can be used to schedule or execute code on one or both cores.

[0056] An 1102 core can include a decoding module coupled to a retrieval unit to decode retrieved elements. In one embodiment, the retrieval logic includes individual sequencers, each connected to thread slots of the 1102 cores. Typically, an 1102 core is associated with a first ISA that defines / specifies instructions executable on the 1102 core. Often, machine code instructions that are part of the first ISA include a section of the instruction (called an opcode) that references / specifies an instruction or operation to be executed. The decoding logic can include circuitry that recognizes these instructions from their opcodes and passes the decoded instructions into the pipeline for processing as defined by the first ISA.For example, in one embodiment, decoders may include logic designed or adapted to recognize specific instructions, such as transaction instructions. As a result of recognition by the decoders, the Core 1102 architecture performs specific, predefined actions to execute tasks associated with the appropriate instruction. It is important to note that any of the tasks, blocks, operations, and procedures described herein may be executed in response to one or more instructions; some of these may be new or existing instructions. In one embodiment, Core 1102 decoders recognize the same ISA (or a subset thereof). Alternatively, in a heterogeneous core environment, a decoder from one or more cores (for example, Core 1102B) may recognize a second ISA (either a subset of the first ISA or a specific ISA).

[0057] In various embodiments, the 1102 cores may also include one or more arithmetic logic units (ALUs), floating point units (FPUs), caches, instruction pipelines, interrupt handling hardware, registers, or other suitable hardware to enable the operation of the 1102 cores.

[0058] Bus 1108 can represent any suitable connection coupled to CPU 1112. For example, bus 1108 can couple CPU 1112 to another CPU of the platform logic (for example, via UPI). I / O blocks 1104 represent the interface logic to couple I / O devices 1110 and 1115 to cores of CPU 1112. In various embodiments, an I / O block 1104 can include I / O control integrated on the same package as the cores 1102, or it can simply include interface logic to couple to I / O control located off-chip. For example, I / O blocks 1104 can include PCIe interface logic. Similarly, memory controller 1106 provides interface logic to couple memory 1114 with cores of CPU 1112. In various embodiments, memory controller 1106 is integrated on the same package as cores 1102.In alternative embodiments, a memory controller could be placed outside the chip.

[0059] As various examples, in the illustrated embodiment, core 1102A can have relatively high bandwidth and low latency for devices connected to bus 1108 (for example, another CPU 1112) and NIC 1110, but relatively low bandwidth and higher latency for memory 1114 or core 1102D. Core 1102B can have relatively high bandwidth and low latency for both NIC 1110 and PCIe solid-state drive (SSD) 1115, and moderate bandwidth and latency for devices connected to bus 1108 and core 1102D. Core 1102C would have relatively high bandwidth and low latency for memory 1114 and core 1102D. Finally, the 1102D core would have relatively high bandwidth and low latency compared to the 1102C core, but relatively low bandwidth and high latency compared to the NIC 1110, the 1102A core and devices coupled to the 1108 bus.

[0060] "Logic" (as found, for example, in memory controllers, power managers, latency managers, etc., and other references to logic in this application) can refer to hardware circuits, firmware, software, and / or combinations thereof to perform one or more functions. In various embodiments, the logic may include a microprocessor or other processing element capable of executing software instructions, specialized logic such as an application-specific integrated circuit (ASIC), a programmed logic device such as a field-programmable gate array (FPGA), a storage device containing instructions, combinations of logic devices (such as those found on a printed circuit board), or other suitable hardware and / or software. The logic may include one or more gates or other circuit components.In some embodiments, the logic can also be entirely embodied as software.

[0061] A design can go through various phases, from generation and simulation to manufacturing. Data representing a design can represent it in several ways. First, the hardware, as is useful in simulations, can be represented using a hardware description language (HDL) or another functional description language. Additionally, at some stages of the design process, a circuit-level model with logic and / or transistor gates can be produced. Furthermore, most designs eventually reach a data level that represents the physical placement of various devices within the hardware model.In cases where conventional semiconductor manufacturing techniques are used, the data representing the hardware model can be data specifying the presence or absence of various features on different mask layers for masks used to fabricate the integrated circuit. In some implementations, such data can be stored in a database file format, such as the Graphic Data System II (GDS II), the Open Artwork System Interchange (OASIS) standard, or a similar format.

[0062] In some implementations, software-based hardware models and HDL and other functional description language objects may include, among other examples, Register Transfer Language (RTL) files. Such objects may be machine-analyzable, allowing a design tool to accept the HDL object (or model), analyze it for attributes of the described hardware, and determine a physical circuit and / or on-chip layout from the object. The output of the design tool can then be used to manufacture the physical device. For example, a design tool may determine configurations of various hardware and / or firmware elements from the HDL object, such as, among other attributes, bus widths, registers (including sizes and types), memory blocks, physical connection paths, and fabric topologies that would be implemented to realize the system modeled in the HDL object.Design tools can include tools for determining the topology and fabric configurations of a system-on-a-chip (SoC) and other hardware devices. In some cases, the HDL object can serve as the basis for developing models and design files that can be used by manufacturing equipment to produce the described hardware. In fact, an HDL object itself can be provided as an input for the manufacturing system software to create the described hardware.

[0063] A module as used herein refers to any combination of hardware, software, and / or firmware. For example, a module includes hardware, such as a microcontroller, connected to a non-volatile medium to store code adapted for execution by the microcontroller. Therefore, in one embodiment, a reference to a module refers to the hardware specifically designed to detect and / or execute the code to be held on a non-volatile medium. Furthermore, in another embodiment, the use of a module refers to the non-volatile medium containing the code specifically adapted for execution by the microcontroller to perform predetermined operations.And, as can be inferred, the term module (in this example) can, in a further embodiment, refer to the combination of the microcontroller and the non-volatile medium. Often, module boundaries, which are depicted as separate, typically vary and may overlap. For example, a first and a second module may share hardware, software, firmware, or a combination thereof, while possibly maintaining independent hardware, software, or firmware. In one embodiment, the use of the term logic includes hardware, such as transistors, registers, or other hardware, such as programmable logic devices.

[0064] The use of the phrase "suitable for," "functional for," or "configured for" in an embodiment refers to arranging, assembling, manufacturing, offering for sale, importing, and / or designing a device, hardware, logic, or element to perform a designated or specific task. In this example, a device or element thereof that is not in operation is nevertheless "configured for" to perform an assigned task if it is designed, coupled, and / or connected to perform the designated task. As a purely illustrative example, a logic gate can provide a 0 or a 1 during operation. However, a logic gate that is "configured for" to provide an enable signal to a clock does not include every potential logic gate that can provide a 1 or a 0.Instead, the logic gate is one that is coupled in such a way that, during operation, the 1 or 0 output is intended to activate the clock. It should be noted again that the use of the term "configured to do so" does not require operation, but instead refers to the latent state of a device, hardware, and / or element, whereby the device, hardware, and / or element in the latent state is designed to perform a specific task when the device, hardware, and / or element is operational.

[0065] A value, as used herein, includes any known representation of a number, a state, a logical state, or a binary logical state. Often, the use of logic levels, logic values, or logical values ​​is also referred to as 1 and 0, which simply represent binary logic states. For example, 1 refers to a high logic level, and 0 refers to a low logic level. In one embodiment, a storage cell, such as a transistor or flash cell, may be suitable for holding a single logical value or multiple logical values. However, other representations of values ​​have also been used in computer systems. For example, the decimal number ten can also be represented as a binary value of 418A0 and as a hexadecimal letter A. Therefore, a value includes any representation of information that can be held in a computer system.

[0066] The embodiments of methods, hardware, software, firmware, or code described above can be implemented by means of instructions or code stored on a machine-accessible, machine-readable, computer-accessible, or computer-readable medium that can be executed by a processing element. A non-volatile, machine-accessible / machine-readable medium includes any mechanism that provides (that is, stores and / or transmits) information in a form readable by a machine, such as a computer or electronic system.A non-volatile, machine-accessible medium includes, for example, random access memory (RAM), such as static RAM (SRAM) or dynamic RAM (DRAM); a ROM; a magnetic or optical storage medium; flash memory devices; electrical storage devices; optical storage devices; acoustic storage devices; other forms of storage devices for holding information received from volatile (propagated) signals (for example, carrier waves, infrared signals, digital signals), etc., which must be distinguished from the non-volatile media that can receive information from them.

[0067] The following examples relate to embodiments according to this specification.Example 1 is a device comprising: a network processing device comprising: a cache; a first interface for coupling to a network, wherein data at the first interface is received from user equipment in a wireless access network, and the data describes attributes of the wireless access network; a termination circuit for decoding the data to generate RAN data; a classification engine to: determine a priority level for the RAN data; determine a memory block in a processing device for the RAN data based on the priority level; and generate a cache row in the cache to store the RAN data, the cache row being associated with the memory block; and a second interface for coupling to the processing device, wherein the cache row is to be flushed into the memory block containing the RAN data based on the priority level.

[0068] Example 2 includes the subject of Example 1, wherein the second interface is to implement a connection based on a cache-coherent connection protocol, and the cache row is cleared based on the cache-coherent connection protocol.

[0069] Example 3 includes the subject of one of Examples 1-2, where the connection protocol includes several subprotocols.

[0070] Example 4 includes the subject of Example 3, wherein the multiple protocols include an I / O subprotocol, a storage subprotocol, and a cache-coherent subprotocol.

[0071] Example 5 includes the subject of Example 4, where the link protocol is a Compute Express Link (CXL)-based protocol.

[0072] Example 6 includes the subject of one of Examples 1-5, using RAN data to perform connection management for the wireless access network.

[0073] Example 7 includes the subject of Example 6, with the connection management based on an O-RAN architecture.

[0074] Example 8 includes the subject of Example 7, wherein the data is received from an E2 node via an E2 interface, and the termination circuit includes an E2 termination circuit.

[0075] Example 9 includes the subject of one of Examples 1-8, wherein the priority level is determined based on a priority level definition associated with a RAN intelligent control (RIC) to be executed on the processor device.

[0076] Example 10 includes the subject matter of one of Examples 1-9, which further includes a bound memory register to: identify multiple memory blocks in the processor; and assign each of the multiple memory blocks to a corresponding one from several different priority levels, the classification engine using the bound memory register to determine that the memory block corresponds to the priority level.

[0077] Example 11 includes the subject of one of Examples 1-10, where the RAN includes a 5G wireless network.

[0078] Example 12 is a device comprising: a memory; a processor; a Compute Express Link (CXL)-based port for connecting to a network processing device via a CXL-based link, wherein radio access network (RAN) data is moved from the network processing device's cache to memory via the CXL-based link; RAN control performed by the processor to: access the RAN data from an address in the memory; use the RAN data to perform a task associated with user equipment connection management in a given RAN; generate connection management result data based on the task's performance; and send the connection management result data to the network processing device for transmission to a radio access network associated with the RAN data.

[0079] Example 13 includes the subject of Example 12, wherein the RAN control is to define priority levels for RAN data passed to storage by the network processing device, and wherein the RAN data is cleared based on one of the priority levels identified by the network processing device for the RAN data.

[0080] Example 14 includes the subject of Example 13, wherein the RAN control is further to write to a control register of the network processing device in order to define a mapping of memory blocks in the memory to the priority levels.

[0081] Example 15 includes the subject of one of Examples 12-14, wherein the RAN controller executes a set of one or more xApps, wherein the one or more xApps are to consume the RAN data to produce an output for use in connection management.

[0082] Example 16 includes the subject of one of Examples 12-15, wherein the RAN control includes an intelligent O-RAN Near-Real-Time (RT) RAN control (RIC).

[0083] Example 17 includes the subject of one of Examples 12-16, wherein the RAN data is cleared from the cache by a writeback associated with a read request from the network processing device based on a CXL-based protocol.

[0084] Example 18 includes the subject of one of Examples 12-17, wherein the RAN includes a 5G wireless network.

[0085] Example 19 is a procedure that includes: receiving data from a wireless access network (RAN) unit, the data describing attributes of a RAN; analyzing the data to determine which of several priority levels should be applied to the data; determining a specific memory area of ​​a host processor associated with the respective priority level; creating a cache line on a network processing device corresponding to the memory block area, the cache line containing the data; and clearing the cache line into the specified memory area using Compute Express Link (CXL)-based semantics.

[0086] Example 20 includes the subject of Example 19, wherein the E2 termination associated with receiving data from the RAN unit is performed on the network processing device instead of the host processor, the RAN unit including an E2 node.

[0087] Example 21 includes the subject of one of Examples 19-20, where cache rows associated with higher priority levels must be cleared before cache rows associated with lower priority levels.

[0088] Example 22 includes the subject of one of Examples 19-20, which further includes: receiving result data from the host processor device based on the data; and sending the result data to the RAN unit for use in connection management within the RAN.

[0089] Example 23 includes the subject of one of Examples 19-22, using RAN data to perform connection management for the wireless access network.

[0090] Example 24 includes the subject of Example 23, with connection management based on an O-RAN architecture.

[0091] Example 25 includes the subject of Example 24, wherein the data is received from an E2 node via an E2 interface, and the termination circuit includes an E2 termination circuit.

[0092] Example 26 includes the subject of one of Examples 19-25, wherein the priority level is determined based on a priority level assigned to a RAN intelligent control (RIC) to be executed on the processor device.

[0093] Example 27 includes the subject matter of one of Examples 19-26, which further includes a bound memory register to: identify multiple memory blocks in the processor; and map each of the multiple memory blocks to a corresponding memory block from several different priority levels, the classification engine using the bound memory register to determine that the memory block corresponds to the priority level.

[0094] Example 28 includes the subject of one of Examples 19-27, wherein the RAN includes a 5G wireless network.

[0095] Example 29 is a system that includes means for carrying out the procedure of one of Examples 19-28.

[0096] Example 30 is a non-volatile, machine-readable storage medium containing instructions, wherein the instructions are executable to cause a machine to: receive radio access network (RAN) data dumped from the cache of a network processing device into the memory of a host processor over a cache-coherent link; use the RAN data to perform a user equipment connection management task in a given RAN; generate connection management result data based on the performance of the task; and send the connection management result data to the network processing device over the link for delivery to a radio access network associated with the RAN data.

[0097] Example 31 includes the subject of Example 30, wherein the instructions are further executable to cause the machine to configure a network processing device bound memory table to associate the cache with a specific block of memory in the host processor's memory.

[0098] Example 32 includes the subject of Example 31, wherein the specified memory block is associated with one of several priority levels to be assigned to the RAN data by the network processing device.

[0099] Example 33 includes the subject matter of Example 32, wherein the instructions are further executable to cause the machine to define the allocation of the multiple priority levels by the network processing device.

[0100] Example 34 is a system comprising: a host processing device including a processor and memory; and a network processing device comprising: a cache; a first interface for coupling to a network, wherein radio access network (RAN) data is received at the first interface from user equipment in a radio access network, and the data describes attributes of the radio access network; a classification engine to: determine a priority level for the RAN data; determine a memory block of the host processing device for the RAN data based on the priority level; and generate a cache row in the cache to store the RAN data, the cache row being associated with the memory block; and a second interface for coupling to the host processing device, wherein the cache row is to be flushed into the memory block containing the RAN data based on the priority level.

[0101] Example 35 includes the subject of Example 34, except that an interface termination for RAN data is provided at the network processing device instead of the host processor device.

[0102] Example 36 includes the subject of Example 35, which further includes an E2 node, wherein the network processing device receives the RAN data from the E2 node and is to decode the RAN data using the E2 termination circuit.

[0103] Example 37 includes the subject of one of Examples 34-36, wherein the host processor device further includes an intelligent RAN controller (RIC) to perform connection management for the wireless access network based on the RAN data.

[0104] Example 38 includes the subject of Example 37, with the RIC being based on an O-RAN architecture.

[0105] Example 39 includes the subject of Example 38, where the RIC is to run one or more xApps to perform connection management tasks based on the RAN data.

[0106] Example 40 includes the subject of one of Examples 37-39, where the priority level is one of several priority levels defined based on the RIC.

[0107] The foregoing specification provides a detailed description with reference to specific exemplary embodiments. However, it is obvious that various modifications and changes can be made to it without departing from the broader spirit and scope of the disclosure as set forth in the appended claims. Accordingly, the specification and the drawings should be regarded in an illustrative rather than a limiting sense. Furthermore, the foregoing use of embodiment and other exemplary language does not necessarily refer to the same embodiment or example, but may refer to different and specific embodiments as well as potentially to the same embodiment. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] CN 2023 / 101922

[0001]

Claims

[1] Device comprising: a network processing device comprising: a cache; a first interface for coupling to a network, wherein data is received at the first interface from user equipment in a radio access network, and the data describes attributes of the radio access network; a termination circuit for decoding the data to generate RAN data; a classification engine to: to determine a priority level for the RAN data; determine a memory block in a processor device for the RAN data based on the priority level; and create a cache line in the cache to store the RAN data, the cache line being associated with the memory block; and a second interface for coupling with the host processing device, wherein the cache line is to be flushed into the memory block containing the RAN data based on the priority level. [2] The apparatus of claim 1, wherein the second interface is to implement a connection based on a cache-coherent connection protocol, and the cache line is flushed based on the cache-coherent connection protocol. [3] Apparatus according to any one of claims 1-2, wherein the connection protocol comprises a plurality of sub-protocols. [4] The apparatus of claim 3, wherein the plurality of protocols comprises an I / O sub-protocol, a memory sub-protocol, and a cache-coherent sub-protocol. [5] The apparatus of claim 4, wherein the connection protocol comprises a Compute Express Link (CXL) based protocol. [6] Apparatus according to any one of claims 1-5, wherein RAN data is used to perform connection management for the radio access network. [7] The apparatus of claim 6, wherein the connection management is based on an O-RAN architecture. [8] The apparatus of claim 7, wherein the data is received from an E2 node via an E2 interface, and the termination circuit comprises an E2 termination circuit. [9] The apparatus of any of claims 1-8, wherein the priority level is determined based on a priority level definition associated with an intelligent RAN controller (RIC) to be executed on the processor device. [10] The apparatus of any of claims 1-9, further comprising a bound memory register for: to identify multiple memory blocks in the processor; Assign memory blocks in the plurality of memory blocks corresponding to one of several different priority levels, wherein the classification engine uses the bound memory register to determine that the memory block corresponds to the priority level. [11] Device comprising: a memory; a processor; a Compute Express Link (CXL)-based port for connecting to a network processing device over a CXL-based connection, wherein radio access network (RAN) data is flushed from the cache of the network processing device to memory over the CXL-based connection; a RAN control executed by the processor to: access the RAN data from an address in the memory; to use the RAN data to perform a task associated with connection management for user equipment in a specific RAN, generate the connection management result data based on the performance of the task; and send the connection management result data to the network processing device for delivery to a radio access network associated with the RAN data. [12] The apparatus of claim 11, wherein the RAN controller is to define priority levels for RAN data passed by the network processing device to the memory, wherein the RAN data is evicted based on one of the priority levels identified by the network processing device for the RAN data. [13] The apparatus of claim 12, wherein the RAN controller is further to write to a control register of the network processing device to define a mapping of memory blocks in the memory to the priority levels. [14] The apparatus of any of claims 11-13, wherein the RAN controller executes a set of one or more xApps, the one or more xApps to consume the RAN data to generate an output for use in connection management. [15] The apparatus of any of claims 11-14, wherein the RAN controller includes an intelligent O-RAN Near-Real-Time (RT) RAN controller (RIC). [16] The apparatus of any of claims 11-15, wherein the RAN data is evicted from the cache by a writeback associated with a read request from the network processing device based on a CXL-based protocol. [17] Procedure comprising: Receiving data from a radio access network (RAN) entity, the data describing attributes of a RAN; Analyzing the data to determine that one of several priority levels should be applied to the data; Determining a specific memory area of ​​a host processor associated with the respective priority level; generating a cache line on a network processing device corresponding to the area of ​​the memory block, the cache line comprising the data; and Ejecting the cache line into the specific memory region using Compute Express Link (CXL)-based semantics. [18] The method of claim 17, wherein the E2 termination associated with receiving the data from the RAN unit is performed on the network processing device instead of the host processor, the RAN unit including an E2 node. [19] A method according to any one of claims 17-18, wherein cache lines associated with higher priority levels must be evicted before cache lines associated with lower priority levels. [20] A method according to any one of claims 17-19, further comprising: Receiving result data from the host processor device based on the data; and Sending the result data to the RAN entity for use in connection management within the RAN. [21] A system comprising means for carrying out the method according to any one of claims 17-20. [22] System comprising: a host processing device comprising a processor and a memory; and a network processing device comprising: a cache; a first interface for coupling to a network, wherein radio access network (RAN) data is received at the first interface from user equipment in a radio access network, and the data describes attributes of the radio access network; a classification engine to: to determine a priority level for the RAN data; determine a memory block of the host processor device for the RAN data based on the priority level; and create a cache line in the cache to store the RAN data, the cache line being associated with the memory block; and a second interface for coupling with the host processor device, wherein the cache line is to be flushed into the memory block containing the RAN data based on the priority level. [23] The system of claim 22, wherein an interface termination for RAN data is provided at the network processing device rather than at the host processor device. [24] The system of claim 23, further comprising an E2 node, wherein the network processing device receives the RAN data from the E2 node and is to decode the RAN data with the E2 termination circuit. [25] The system of any of claims 22-24, wherein the host processor device further comprises an intelligent RAN controller (RIC) to perform connection management for the radio access network based on the RAN data, wherein the RIC is to execute one or more xApps to perform connection management tasks based on the RAN data.

Images