Distributed execution of ML for a ran

Abstract

Systems, methods, and computer-readable media for performing applications for radio interface controller (RIC) management are disclosed. The system includes a far-edge data center configured to perform radio access network (RAN) functions and real-time RICs, a near-edge data center configured to perform near real-time RICs or non-real-time RICs and core network functions, and a central controller. The central controller is configured to receive inputs of application requirements, hardware constraints, and capacities of first computing resources and second computing resources at the far-edge data center and the near-edge data center, enumerate a plurality of feasible combinations of application locations and configurations that satisfy the application requirements and the hardware constraints, incrementally allocate quantitatively the first computing resources or the second computing resources to the feasible combinations that will yield the most utility based on a utility function from the quantification, and deploy each of the plurality of applications.

Description

Cross-references to related applications

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 608,609, entitled “Distributed Execution of ML for RAN,” filed December 11, 2023, which has been assigned to its assignee and is hereby expressly incorporated herein by reference. Background Technology

[0002] A Radio Access Network (RAN) provides radio access to a network to multiple user equipments (UEs). UEs can wirelessly communicate with base stations, which then forward the communication to the core network. Typically, base stations in the RAN are implemented using dedicated processing hardware (e.g., embedded systems) located near the radio unit, including antennas. Base stations can perform lower-layer processing, including physical (PHY) and media access control (MAC) layer processing for one or more cells. There can be associated costs with deploying dedicated processing hardware for each base station in the RAN, especially for RANs comprising small cells with relatively small coverage areas. Furthermore, dedicated processing hardware can be a single point of failure for a given cell.

[0003] Virtualized radio access networks (RANs) can leverage edge data centers with general-purpose computing resources to perform RAN processing for one or more cells. That is, instead of performing PHY and MAC layer processing locally on dedicated hardware, a RAN can forward radio signals from radio units to the edge data center for processing, and similarly forward signals from the edge data center to radio units for wireless transmission. In a specific example, a cloud computing environment can be used to provide mobile edge computing (MEC), where certain functions of the mobile network can be provided as workloads on nodes within the cloud computing environment. In the MEC, centralized units (CUs) can be implemented in back-end nodes, one or more distributed units (DUs) can be implemented in intermediate nodes, and various remote units (RUs) that can at least provide the PHY and / or MAC layers of the mobile network's base stations or other RAN nodes can be deployed at edge servers. RUs can communicate with CUs via one or more DUs. In the example, DUs can provide higher network layer functions for the RAN, such as Radio Link Control (RLC) or Packet Data Convergence Protocol (PDCP) layer functions. RUs can facilitate access to CUs for various downstream devices, such as User Equipment (UE), Internet of Things (IoT) devices, etc.

[0004] Because edge data centers utilize general-purpose computing resources, virtualized RAN can provide scalability and fault tolerance for base station processing. For example, an edge data center can assign a variable number of computing resources (e.g., servers) based on workload to perform PHY layer processing for radio units associated with the edge data center. Furthermore, virtualized RAN can implement multi-layer RAN processing at the data center, enabling the collection of multiple data feeds. Summary of the Invention

[0005] The following is a simplified overview of one or more aspects to provide a basic understanding of them. This overview is not a comprehensive summary of all anticipated aspects, nor is it intended to identify key or important elements of all aspects, nor to depict the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed descriptions that follow.

[0006] In some aspects, the technology described herein relates to a system for performing applications for Radio Interface Controller (RIC) management, comprising: one or more far-edge data centers, each far-edge data center including a first computing resource configured to perform real-time RIC and Radio Access Network (RAN) functions; one or more near-edge data centers, each near-edge data center including a second computing resource configured to perform at least one of near-real-time RIC or non-real-time RIC and core network functions; and a central controller configured to receive inputs of application requirements, hardware constraints, and the capacity of the first and second computing resources for multiple applications. The multiple applications will be executed in one or more processing pipelines on one or more far-edge data centers or one or more near-edge data centers; multiple feasible combinations of application locations and configurations that meet application requirements and hardware constraints are enumerated; computing resources from a first computing resource or a second computing resource are allocated to a feasible combination, which will generate a deployment with maximum utility based on a utility function applied to the quantification of computing resources or to the conflict of computing resources among the multiple applications predicted by a Bayesian optimizer; and based on the deployment, each application in the multiple applications is deployed to a real-time RIC, a near-real-time RIC, or a non-real-time RIC.

[0007] In some respects, the techniques described in this paper relate to a system in which multiple feasible combinations satisfy application requirements and hardware constraints.

[0008] In some respects, the technology described herein relates to a system in which, in order to allocate computing resources, a central controller is configured to: quantitatively and incrementally allocate either a first computing resource or a second computing resource to feasible combinations that will produce maximum utility based on a utility function from previous allocations, until all the first and second computing resources have been allocated.

[0009] In some respects, the techniques described herein relate to a system in which quantification is part of resource usage that targets the dominant demand at each application location for a feasible combination of first and second computing resources that maximizes resource usage.

[0010] In some respects, the technology described herein relates to a system in which a central controller is configured to sort feasible combinations in ascending order of dominant demand in order to select resources for allocation.

[0011] In some respects, the techniques described in this paper relate to a system in which a utility function measures the accuracy of multiple applications and the efficiency of communication between the multiple applications.

[0012] In some respects, the technique described herein relates to a system in which, in order to allocate computing resources, a central controller is configured to: use a Bayesian optimizer to predict the next conflict among computing resources among multiple applications; and select an optimization utility function for the allocation of conflicting resources.

[0013] In some respects, the techniques described herein relate to a system in which a Bayesian optimizer is configured with an objective function that indicates the aggregate utility of the application.

[0014] In some aspects, the technology described herein relates to a system in which, in order to allocate computing resources from a first computing resource or a second computing resource to a feasible combination that will produce a deployment, a central controller is configured to: quantitatively and incrementally allocate the first computing resource or the second computing resource to a feasible combination that will produce the first proposed deployment with the greatest utility, based on a utility function derived from previous allocations of the first proposed deployment, until all the first computing resources and the second computing resources have been allocated; predict the next conflict among computing resources among multiple applications using a Bayesian optimizer; select the allocation of conflicting resources for a second deployment that optimizes the utility function; and select the first proposed deployment or the second proposed deployment based on an aggregate utility function.

[0015] In some aspects, the technology described herein relates to a method for executing applications for Radio Interface Controller (RIC) management, comprising: receiving inputs of application requirements and hardware constraints for a plurality of applications to be executed in one or more processing pipelines on one or more far-edge data centers or one or more near-edge data centers, the far-edge data centers having first computing resources configured to perform real-time RIC and Radio Access Network (RAN) functions, and the near-edge data centers having second computing resources configured to perform at least one of near-real-time RIC or non-real-time RIC and core network functions; enumerating a plurality of feasible combinations of application locations and configurations that satisfy the application requirements and hardware constraints; quantitatively and incrementally allocating the first or second computing resources to feasible combinations of the first proposed deployment that will produce the maximum utility based on a utility function, given a previous allocation of the first proposed deployment, until all the first and second computing resources have been allocated; and deploying each of the plurality of applications to a real-time RIC, near-real-time RIC, or non-real-time RIC, at least in part based on the first proposed deployment.

[0016] In some respects, the techniques described in this paper involve a method in which feasible combinations satisfy application requirements and hardware constraints.

[0017] In some respects, the techniques described herein relate to a method in which quantification is part of resource usage that targets the dominant demand at each application location for the feasible combination of the first and second computing resources that has the maximum resource usage.

[0018] In some respects, the techniques described herein relate to a method that also includes sorting feasible combinations in ascending order of dominant demand to select resources for allocation.

[0019] In some respects, the techniques described in this paper involve a method in which a utility function measures the accuracy of multiple applications and the communication efficiency between the multiple applications.

[0020] In some respects, the techniques described herein relate to a method that also includes: using a Bayesian optimizer to predict the next conflict in computational resources among multiple applications; and selecting the allocation of conflicting resources for a second deployment to optimize the utility function.

[0021] In some respects, the techniques described herein relate to a method in which each application in a plurality of applications is deployed to a real-time RIC, a near-real-time RIC, or a non-real-time RIC based at least in part on a first proposed deployment, comprising: selecting a first proposed deployment or a second proposed deployment based on an aggregate utility function; and deploying each application in the plurality of applications to a real-time RIC, a near-real-time RIC, or a non-real-time RIC based on the selected deployment.

[0022] In some respects, the techniques described herein relate to a method in which a Bayesian optimizer is configured with an objective function that indicates the aggregate utility of the application.

[0023] In some aspects, the techniques described herein relate to a non-transitory computer-readable medium storing computer-executable instructions for Radio Interface Controller (RIC) management. The non-transitory computer-readable medium includes instructions that, when executed by a processor of a central controller of a network, cause the central controller to: receive inputs of application requirements and hardware constraints for multiple applications to be executed in one or more processing pipelines on one or more far-edge data centers or one or more near-edge data centers, the far-edge data centers having first computing resources configured to perform real-time RIC and Radio Access Network (RAN) functions, and the near-edge data centers having second computing resources configured to perform at least one of near-real-time RIC or non-real-time RIC and core network functions; enumerate multiple feasible combinations of application locations and configurations that satisfy the application requirements and hardware constraints; predict the next conflict among resources among the multiple applications using a Bayesian optimizer; select the allocation of conflicting resources for a first deployment optimization utility function; and deploy each of the multiple applications to a real-time RIC, near-real-time RIC, or non-real-time RIC, at least in part based on the resource allocation.

[0024] In some respects, the techniques described herein relate to a non-transitory computer-readable medium in which a Bayesian optimizer is configured with an objective function that indicates the aggregation utility of an application.

[0025] In some aspects, the techniques described herein relate to a non-transitory computer-readable medium, further comprising instructions for: quantitatively and incrementally allocating a first or second computing resource to a feasible combination of second proposed deployments that will produce maximum utility based on a utility function, given a previous allocation of a second proposed deployment, until all the first and second computing resources have been allocated; selecting a first or second proposed deployment based on an aggregate utility function; and deploying each of the multiple applications to a real-time RIC, a near-real-time RIC, or a non-real-time RIC based on the selected deployment.

[0026] To achieve the foregoing and related objectives, one or more aspects include the features fully described below and specifically pointed out in the claims. The following description and drawings set forth certain illustrative features of one or more aspects in detail. However, these features indicate only a few of the various ways in which the principles of each aspect can be employed, and this description is intended to include all such aspects and their equivalents. Attached Figure Description

[0027] Figure 1This is a diagram of an example virtualized radio access network (vRAN) that provides connectivity to user equipment (UE).

[0028] Figure 2 This is a diagram showing the resources available at various data centers to support network functions and Radio Intelligent Controllers (RICs).

[0029] Figure 3A , Figure 3B and Figure 3C The diagram illustrates a processing pipeline for various applications that perform machine learning analysis on network data.

[0030] Figure 4A , Figure 4B and Figure 4C It is shown that it is used for Figure 3C A diagram showing possible deployments of the processing pipeline application.

[0031] Figure 5 This is a diagram illustrating an example of resource allocation for applications in a distributed wireless access network.

[0032] Figure 6 This is a flowchart illustrating an example of a method used for RIC management.

[0033] Figure 7 This is a flowchart of the first example of a method for application deployment.

[0034] Figure 8 This is a flowchart of a second example of a method for application deployment.

[0035] Figure 9 It shows including, for example Figure 2 An example of a device showing additional optional component details. Detailed Implementation

[0036] The specific embodiments described below with reference to the accompanying drawings are intended as a description of various configurations and are not intended to represent the only configuration in which the concepts described herein can be practiced. Specific details are included in the specific embodiments for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some cases, well-known components are shown in block diagram form to avoid obscuring these concepts.

[0037] This disclosure describes various examples related to frameworks for machine learning (ML)-based analytics and optimization for radio access networks (RAN). A key transformation of RAN in 5G is the migration to an open RAN architecture, i.e., a 5G RAN that is virtualized and decomposed across multiple open interfaces. For example, the 3rd Generation Partnership Project (3GPP) has released technical specifications defining 5G networks. An open RAN architecture can be a non-proprietary version of such a network. This approach fosters innovation by allowing multiple vendors to propose unique solutions for different components at a faster pace. Furthermore, a new component introduced in the open RAN architecture, called the Radio Intelligent Controller (RIC), allows third parties to build new, vendor-agnostic monitoring and optimization use cases on interfaces standardized by the O-RAN.

[0038] Despite this compelling vision, opportunities for innovation remain largely untapped due to two main challenges. The first challenge relates to the flexible data collection required for monitoring and telemetry applications. RAN functions can generate massive amounts of telemetry data at high frequencies (e.g., gigabytes per second). Collecting, transmitting, and processing this data can strain computational and network capacity. The conventional approach, standardized by the 3GPP (3rd Generation Partnership Project), defines a small set of aggregated cell key performance indicators (KPIs) collected every few seconds or minutes. O-RAN RIC extends this idea by providing new KPIs with finer temporal granularity. O-RAN RIC can be categorized as near-real-time RIC. Each KPI is defined through a service model (a form of API), most of which are standardized by O-RAN. However, this approach evolves slowly and cannot scale well due to the limited number of initial use cases and the need to standardize new proposals. The second challenge stems from the real-time nature of many RAN control and data plane operations. To support new service models, any new functionality added to these operations must be completed within a timeframe typically ranging from microseconds (μs) to milliseconds (ms). Breach of deadlines can lead to performance degradation or even vRAN crashes. Any changes to these critical paths can present substantial design challenges and make RAN vendors reluctant to add new features.

[0039] Virtual RAN (vRAN) deployments offer flexibility in terms of which resources to use to implement various functions. Typically, wide area networks (WANs) have different types of data centers in different locations. For example, a large-scale data center can include hundreds or thousands of servers or server racks, including various types of memory and processors (e.g., central processing units (CPUs) and graphics processing units (GPUs)). Such a large-scale data center can be called a cloud data center and can provide economies of scale for geographically agnostic operations. However, for vRAN, geography becomes important. For example, to provide physical layer vRAN functionality, a data center must have a direct connection to a radio unit (RU) to meet latency requirements. Such a data center with a connection to an RU can be called a far-edge data center. However, the resources of a far-edge data center may be limited. For example, a far-edge data center may be located in an urban area where real estate is expensive but resources (such as electricity and water for cooling) are limited. Therefore, a far-edge data center may have fewer and more limited computing resources, and operating such resources may be more expensive. In terms of location, resources, and cost, near-edge data centers can fall between cloud data centers and far-edge data centers. For example, a near-edge data center may not have a direct connection to an RU but can have more processors (including GPUs) than a far-edge data center. Near-edge data centers can still offer advantages over cloud data centers in terms of latency.

[0040] vRAN can include one or more Radio Intelligent Controllers (RICs) configured to provide additional analysis and control for vRAN. In some implementations, basic or standardized RAN functions can be implemented as vRAN functions. RICs can enhance, extend, or customize vRAN functions. For example, RICs can leverage artificial intelligence (AI) or machine learning (ML) models to improve vRAN cost and performance by predicting, classifying, and resolving computationally intractable problems in RAN management. RICs can collect information from various vRAN functions to provide analysis and control. In one aspect, RICs can be categorized based on latency, which in turn depends on their geographical proximity to the RU. For example, RICs can include real-time RICs co-located with vRAN functions at far-edge data centers, near-real-time RICs located at near-edge data centers, and non-real-time RICs that can be located at near-edge or cloud data centers.

[0041] The needs and resources of vRAN and RIC can change over time. For example, when a particular cell in vRAN has a large number of users (e.g., mobile devices), the far-edge data center performing vRAN functions can dedicate more resources (processors and memory) to vRAN functions and have less capacity for RIC operations. Furthermore, changes in vRAN load can also affect the types of useful RIC operations. For example, when cells are busy, an enhanced scheduler using ML can provide greater advantages. Therefore, a static design for RIC can be difficult to operate due to resource constraints that vary based on vRAN load. Thus, a flexible RIC design is needed to improve resource utilization while meeting latency requirements in vRAN.

[0042] In one aspect, this disclosure describes a computing system for hosting two vRAN functions and executing applications for RIC management. In an example implementation, the computing system is a wide area network comprising multiple data centers categorized as far-edge data centers, near-edge data centers, and cloud data centers. Typically, lower-layer vRAN functions are executed on far-edge data centers, and core network functions are executed on near-edge data centers. Far-edge data centers also execute real-time RICs, and near-edge data centers also execute near-real-time RICs. Cloud data centers may execute non-real-time RICs, which may also be executed at near-edge data centers. Each RIC is configured to execute one or more applications. Applications are isolated from vRAN functions and / or core network functions using virtual machines (VMs), containers, web assembly code, or extended Berkeley Packet Filter (eBPF) code. Some applications are configured to apply network data to machine learning models. The computing system also includes a central controller configured to manage applications on different RICs. For example, the central controller receives inputs of application requirements, hardware constraints, and computing resource capacity at each data center. The central controller selects locations at one or more data centers to execute each application to form a pipeline.

[0043] On one hand, the central controller implements policies for efficiently utilizing network resources to execute applications. Applications can execute at different locations with different configurations utilizing different levels of resources. Applications can compete for resources at these locations. There may be trade-offs between application accuracy and latency, resource constraints at locations, and the cost of moving application data between locations for utility to the RAN. Furthermore, the performance of one application may affect the performance of other applications in the pipeline. The central controller can select the location and configuration for applications based on a utility function. For example, the central controller can use a greedy algorithm or a Bayesian optimizer to efficiently allocate resources to applications. The central controller deploys each application to the RIC at the selected location. Thus, the RIC can execute different applications to form a processing pipeline for performing various aspects of vRAN management.

[0044] Turn now Figures 1 to 6 The examples are depicted with reference to one or more components and one or more methods that can perform the actions or operations described herein, wherein the components and / or actions / operations shown in the dashed lines are optional. Although below... Figure 5 The operations described herein are presented in a specific order and / or performed by example components, but in some examples, the order of actions and the components performing the actions may vary depending on the implementation. Furthermore, in some examples, one or more of the actions, functions, and / or described components may be performed by a specially programmed processor, a processor executing specially programmed software or computer-readable media, or any other combination of hardware and software components capable of performing the described actions or functions.

[0045] Figure 1 This is a diagram of an example vRAN 100 providing a connection to User Equipment (UE) 110. vRAN 100 may include a radio unit 120 that transmits and receives radio signals with UE 110. vRAN 100 may include a virtual distributed unit (vDU) 130, which performs processing, for example, at the physical (PHY) layer, media access control (MAC) layer, and radio link control (RLC) layer. vRAN 100 may include a virtual central unit (vCU) 140 that performs processing at higher layers of the radio protocol stack.

[0046] The functional partitioning between vDU 130 and vCU 140 can depend on the functional split architecture. vCU 140 can be divided into a Central Unit Control Plane (CU-CP) and a Central Unit User Plane (CU-UP). CU-UP may include the Packet Data Convergence Protocol (PDCP) layer, the Service Data Adaptation (SDAP) layer, and the Radio Resource Control (RRC) layer. Different components or layers may have different latency and throughput requirements. For example, the PHY layer may have a latency requirement between 125 μs and 1 ms and a throughput requirement greater than 1 Gbps, the MAC layer and RLC layer may have a latency requirement between 125 μs and 1 ms and a throughput requirement greater than 100 Mbps, and higher layers at the vCU may have a latency requirement greater than 125 μs and a throughput requirement greater than 100 Mbps.

[0047] Higher-level network functions may be referred to as core network functions 150. For example, core network functions may include one or more Access and Mobility Management Functions (AMF), Session Management Functions (SMF), and User Plane Functions (UPF). These network functions provide management of the UE 110's connectivity. For example, a UPF may provide processing of user traffic to and from the Internet. For instance, a UPF may receive user traffic packets and forward them to a server via one or more routers using Internet Protocol (IP).

[0048] vRAN 100 includes a RAN Intelligent Controller (RIC) that performs autonomous configuration and optimization of vRAN 100. The RIC is implemented at multiple locations as at least a real-time RIC 162 and a near-real-time RIC 172 or a non-real-time RIC 182. For example, the real-time RIC 162 is implemented at a far-edge data center 160, which also performs vRAN functions such as vDU 130 or vCU 140. The near-real-time RIC 172 is implemented at a near-edge data center 170. The non-real-time RIC 182 can be implemented at either the near-edge data center 170 or a cloud data center 180. In one aspect, each data center is associated with a set of computing resources. For example, the computing resources at the far-edge data center 160 constitute a first set of computing resources, and the computing resources at the near-edge data center 170 constitute a second set of computing resources.

[0049] Programmability in vRAN functions (e.g., Open RAN components) can be facilitated through RICs. Network operators can install applications (application 152, e.g., xApp in Open RAN) on top of any of the real-time RIC 162, near-real-time RIC 172, or non-real-time RIC 182. Each RIC can collect network data and can utilize this data to optimize network performance or report problems on time frames based on location. For example, a real-time RIC can operate with a delay of less than 10 milliseconds (ms); a near-real-time RIC 172 can operate with a delay of more than 10 ms to several seconds; and a non-real-time RIC 182 can operate with a delay of more than 10 seconds.

[0050] RICs can obtain network data from various sources. For example, data collection and control of vRAN components can be facilitated by service models embedded by vendors within vRAN functions. Service models can explicitly define the type and frequency of data reports for each application, as well as a list of control policies that the RIC can use to modify RAN behavior. Such service models can collect data at relatively low rates (…). ms Significant network events occurring within 100 seconds (up to the second) are suitable for near real-time RIC 172 and non-real-time RIC 182. For faster data collection, network functions can be configured with codelets to export data from the network function to the local real-time RIC 162. For example, codelets may include eBPF codelets (e.g., user-space eBPF (uBPF) bytecode) or operating system eBPF probes executed in kernel space. Vendors can support such codelets by configuring hooks within the virtual network function to execute eBPF codelets or provide function call information for operating system eBPF probes. The use of codelets can deliver network data at a faster rate (e.g., less than 1 ms) and can collect larger amounts of network data. Furthermore, real-time RIC 162 and / or near real-time RIC 172 can export network data to other RICs. However, mobile network data consumes network bandwidth and introduces some latency.

[0051] In one aspect, this disclosure provides a central controller 190 for managing RICs. Specifically, the central controller 190 can manage the execution of applications 152 on different RICs to form a processing pipeline for complex network analysis and control. For example, complex network analysis may utilize network data from two or more network functions, or network data may be applied to two or more machine learning models. In the processing pipeline, the output from one application 152 is used as the input to another application 152. The processing pipeline can be considered as a directed acyclic graph. An application repository 184 can store a base version of each application 152. In some implementations, applications 152 can be further trained or customized to execute on a specific RIC. The central controller 190 can consider the application requirements of each application 152 as well as the hardware constraints and capacity of the computing resources available to each RIC at each data center.

[0052] In one implementation, the central controller 190 includes an input component 192 configured to receive inputs of application requirements, hardware constraints, and the capacity of first computing resources in one or more far-edge data centers 160 and second computing resources in one or more near-edge data centers 170. The central controller 190 includes a policy component 194 configured to select a location in one or more far-edge data centers 160 or one or more near-edge data centers 170 based on a policy applied to the input, for executing each of the multiple applications 152 to form a pipeline. In some implementations, the policy component 194 is configured with a greedy algorithm 195 configured to incrementally allocate resources in quantities to combinations of locations and configurations that will produce the greatest utility for the application. In some implementations, the policy component 194 includes a Bayesian optimizer 196 configured to identify resource conflicts between applications. The central controller 190 includes a deployment component 198, which is configured to deploy each of the multiple applications 152 to a real-time RIC 162, a near-real-time RIC 172, or a non-real-time RIC 182 based on a selected location.

[0053] Figure 2 Figure 200 illustrates the resources used to support network functions and RICs at various data centers. A far-edge data center 160 (e.g., far-edge data centers 160a and 160b) may have first resources including CPU 212 and memory 214. A near-edge data center 170 may have second resources including CPU 222, memory 224, and GPU 226. A cloud data center 180 has third resources including CPU 232, memory 234, and GPU 236. In some implementations, far-edge data center 160, near-edge data center 170, and cloud data center 180 include multi-core systems.

[0054] Multi-core systems can utilize the multi-threaded parallel processing capabilities of multiple processor cores. For example, a multi-core system may include CPUs 212, 222, 232, such as server-class x86 processors. A multi-core system may have one or more physical chips providing multiple virtual CPUs (vCPUs). Each vCPU is capable of processing execution threads in parallel with other vCPUs. In general-purpose multi-core systems, the operating system can use context switching to allocate different execution threads to vCPUs as needed. In some implementations, a multi-core system can lock one or more vCPUs to certain execution threads for a virtual function. For example, in one implementation, a pull-mode driver that always occupies a processor core can be used to lock multiple processor cores (e.g., vCPUs) to virtual function execution threads. Locking execution threads to processor cores reduces the overhead of context switching between threads and improves the performance of virtual functions. For example, virtual functions (e.g., vDU 130 or vCU 140) can execute on their respective processor cores without interruption. In one implementation, the capacity of data center 160 can be measured across multiple available processor cores.

[0055] On one hand, the second resource of the near-edge data center 170 is greater than the first resource of one of the far-edge data centers 160, and the third resource of the cloud data center 180 is greater than the second resource. Conversely, latency is lowest at the far-edge data center 160, then at the near-edge data center 170, and finally at the cloud data center 180. Therefore, due to relatively limited resources, there is often a trade-off between executing application 152 at the far-edge data center 160 to achieve lower latency and cost or constraints. For example, the far-edge data center 160 may not have GPUs (or available GPUs) for executing large machine learning models. Similarly, even though the near-edge data center 170 or the cloud data center 180 has greater resources, the increased latency of moving network data to a remote data center may result in the inability to meet the latency requirements of a particular application 152 or network function. Therefore, the central controller 190 is configured to deploy application 152 to the selected data centers based on strategies applied to application requirements, hardware constraints, and resource capacity.

[0056] On one hand, application 152 can be customized or trained for a specific deployment. For example, some ML models used to predict behavior may depend on a specific cell supported by RU 120. For example, a cell covering office buildings may experience greater usage during business hours compared to a cell covering apartment buildings that may experience different usage patterns. Therefore, application 152 for predicting traffic can be trained for a specific RU in training operation 240. Training operation 240 can be similar to application 152 because it utilizes computing resources at the data center and may need to move training data between data centers. Central controller 190 can be configured to select the location for dynamically retraining application 152, including the machine learning model, based on training requirements and the capacity of the first and second computing resources, based on recent data from network functions. Training requirements can be the frequency of retraining or the size of the training set. Capacity can be the number of available processor cores. For example, when the training set is large or the retraining frequency is high, the central controller 190 can select the far edge data center 160 for training operation 240, but when the far edge data center 160 has low capacity or the GPU 226 will accelerate training operation 240, the central controller 190 can select the near edge data center 170 for training operation 240.

[0057] On the other hand, the requirements of application 152 can be adjusted. For example, the model can be executed with different sample sizes or rates corresponding to different resource utilization or latency. If the requirements of application 152 cannot be met in the most desirable location, the central controller 190 can adjust the parameters of application 152 to adjust the requirements, rather than deploying application 152 to different locations.

[0058] On the other hand, application 152 can be migrated between locations. For example, after application 152 is deployed to far-edge data center 160, the capacity of far-edge data center 160 can change. For example, additional users connected to a cell supported on far-edge data center 160 may increase their demand for vDU 130, which can be allocated additional resources. Therefore, the capacity of far-edge data center 160 may no longer support application 152. Central controller 190 can monitor capacity changes and migrate application 152 from far-edge data center 160 to near-edge data center 170. For example, when capacity increases at far-edge data center 160, central controller 190 can migrate application 152 from near-edge data center 170 to far-edge data center 160. Additionally, central controller 190 may migrate application 152 due to a failure at its current location (e.g., to another near-edge data center 170) or due to connectivity issues between data centers.

[0059] Figure 3A , Figure 3B and Figure 3C Processing pipelines for various applications 152 for performing machine learning analysis of network data are illustrated. Although several examples are provided, it should be understood that the framework described herein offers the flexibility to create processing pipelines using the applications described herein or any custom applications, such as those programmed for the specific needs of a network operator.

[0060] The following are example use cases for artificial intelligence (AI) or machine learning (ML) models to improve the cost and performance of vRAN. In particular, AI or ML models can be used to solve computationally difficult problems in RAN management, such as prediction and classification.

[0061] The first example use case is predicting available radio bandwidth for Quality of Experience (QoE) optimization. Radio bandwidth availability can depend on many factors, including the number of User Equipments (UEs), channel conditions for each UE, timing requirements of the data stream, and so on. Many of these factors may change over time. An example processing pipeline for predicting available bandwidth may include separate predictors for one or more factors and another model for combining the various predictions.

[0062] The second example use case is cellular traffic prediction for server utilization. For example, each far-edge data center 160 can implement multiple vRAN functions to handle processing loads that vary based on the amount of cellular traffic. For instance, the PHY layer processing volume at vDU 130 can be based on the amount of data transmitted between RU 120 and UE 110. Far-edge data center 160 can dynamically allocate CPU 212 to vDU 130 for processing load. The processing pipeline for cellular traffic prediction for server utilization can obtain measurements of the data rate for each UE 110 and the CPU utilization of vDU 130. The data rate for each UE 110 can be combined with higher-level events such as session and flow management to predict future data rates, which can be used to predict the CPU required by vDU 130.

[0063] The third example use case is traffic redirection through predicting UE-cell performance. For instance, UE performance can vary based on UE movement within a cell. Some UEs may be located within the coverage area of ​​multiple cells. Typically, when various conditions are met to initiate a handover, the UE measures signal quality and sends a report to the network. Machine learning can be used to improve handover by predicting how UE-cell performance might change. The network can then switch UEs based on these predictions, rather than waiting for the current cell's performance to degrade.

[0064] For example, such as Figure 3AAs shown, the processing pipeline 310 for traffic redirection can operate on UE measurement report information 312. For example, UE measurement report information 312 may include Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), and / or Channel Quality Indicator (CQI). UE measurement report information 312 can be obtained from the PHY layer of vDU 130 at the far edge data center 160. A first application 314 can classify UE measurement report information 312 as an RF fingerprint. For example, an RF fingerprint could be a pattern of UE measurement report information 312 with similar performance. A second application 316 can be a performance predictor configured to predict UE performance based on the RF fingerprint. For example, the performance predictor can combine the RF fingerprint with higher-layer information. A third application 318 can perform traffic allocation. For example, the third application 318 can hand over the UE to a cell based on the predicted performance.

[0065] The fourth example use case is MAC scheduling of resource blocks using predicted quality. Buffer status report 322 can be obtained from the PHY layer of vDU 130 at the far edge data center 160. Similarly, UE motion sensor information 324 can be obtained from the PHY layer of vDU 130 at the far edge data center 160. First application 326 can perform channel quality prediction based on buffer status report 322. Second application 328 can perform motion prediction based on UE motion sensor information 324. Third application 330 can schedule the transmission of resource blocks based on predicted channel quality and predicted motion. For example, third application 330 can select the modulation and coding scheme (MCS) and beam for transmitting one or more resource blocks.

[0066] The fifth example use case is interference detection and classification. In shared bandwidth, multiple networks may attempt to use the same radio resources (e.g., frequencies), which can interfere with other devices. Although most wireless standards include mechanisms for shared bandwidth and / or interference mitigation, channel leakage and rogue devices are possible. Typically, the UE or network functions can measure signals indicating interference, but may not be able to identify the source.

[0067] A processing pipeline 340 for interference detection and classification can begin using IQ samples from the PHY layer of vDU 130. A first application 344 can be an energy sampler and converter that samples (or subsamples) the IQ samples 342 and converts them into detected energy levels. A second application 346 can be an interference detector that determines whether the detected energy level indicates interference. For example, the second application 346 can compare the energy level to a predicted energy level of an expected transmission. A third application 348 can be a wireless spectrum classifier that classifies detected interference into the type of radio network. For example, the third application 348 can determine whether the pattern of detected interference corresponds to 5G, 4G-LTE, Wi-Fi, or other networks such as 6G.

[0068] Figure 4A , Figure 4B and Figure 4C This diagram illustrates possible deployments 410, 420, and 430 for applications 344, 346, and 348 in processing pipeline 340. In the first deployment 410, the collection of IQ samples 342 occurs at the far-edge data center 160. Furthermore, each of applications 344, 346, and 348 can be executed at the far-edge data center 160, and no application is executed at the near-edge data center 170. In the second deployment 420, the collection of IQ samples 342 occurs at the far-edge data center 160. Furthermore, the first application 344 and the second application 346 are executed at the far-edge data center 160, and the third application 348 is executed at the near-edge data center 170. In the third deployment 430, the collection of IQ samples 342 occurs at the far-edge data center 160. Furthermore, the first application 344 is executed at the far-edge data center 160, and the second application 346 and the third application 348 are executed at the near-edge data center 170.

[0069] On one hand, the collection of IQ samples 342 always occurs at vDU 130, which is executed on the far-edge data center 160 (e.g., via small code on vDU 130). Because IQ samples can be quite large (e.g., approximately 5 Gbps per cell for 100 MHz 4×4 MIMO), the first application 344 used to sample the IQ samples and convert them to energy levels can be deployed at the real-time RIC 162. For example, the policy of the central controller 190 can always assign applications with input data streams exceeding a threshold size to the real-time RIC 162.

[0070] The second application 346 and the third application 348 may have latency requirements depending on the RU 120 or the corresponding coverage area of ​​the RU 120. For example, a high-priority RU 120 or coverage area (e.g., a secure area of ​​a building) may have lower latency requirements to detect interference, while a lower-priority RU 120 or coverage area (e.g., public access) may have more lenient latency requirements. Furthermore, the policy may depend on hardware constraints at the far-edge data center 160. For example, if the third application 348 utilizes a large ML model that can only be executed within the latency requirements using GPUs 226 and 236, the policy may require the third application 348 to be deployed to the near-edge data center 170. The policy may also depend on the capacity of the first computing resources at the far-edge data center 160 and the second computing resources at the near-edge data center 170. For example, if the number of UEs is relatively high, the far-edge data center 160 may allocate limited CPUs 212 and memory 214 to vDU 130. Therefore, the far-edge data center 160 may not have the capacity for the second application 346 or the third application 348, which can then be migrated to the near-edge data center 170.

[0071] Figure 5 Figure 500 illustrates an example of resource allocation for applications in a distributed radio access network. As described above, applications can execute at a far-edge data center 160, a near-edge data center 170, or a cloud data center 180. Each data center can have a set of resources for executing the application, such as CPU, memory, and / or GPU. The resources at the far-edge data center 160 can be referred to as first resources 510; the resources at the near-edge data center 170 can be referred to as second resources 520; and the resources at the cloud data center 180 can be referred to as third resources 530.

[0072] Applications that leverage machine learning or artificial intelligence to improve RAN operations can be instantiated at different locations and / or with different configurations. Typically, the resources used to operate the RAN and ML or AI applications are fixed. Network functions can utilize most of the resources, while the remaining resources can be allocated among the ML or AI applications. Trade-offs may exist regarding resources, latency, and network bandwidth for applications executed closer to user equipment (e.g., at a remote edge data center 160).

[0073] On one hand, the utility of application deployment can represent the benefits to RAN operations. In some implementations, the utility of an application can be based on its accuracy and efficiency. The utilities of multiple applications can be aggregated to determine a utility function representing the utility of the deployment.

[0074] An example strategy for allocating resources among applications could utilize a greedy algorithm to allocate a quantity 512 of resources corresponding to dominant demand. Quantity 512 refers to a portion of resources at a location such as a remote edge data center 160. In some implementations, the quantity is based on the dominant demand at that location. For example, an application at remote edge data center 160 might seek to utilize the majority of CPU time, while memory usage could be a smaller fraction; therefore, CPU time could be considered the dominant demand. By allocating resources based on dominant demand, the scarcest resources can be allocated efficiently.

[0075] In the example, resources can be allocated between a combination of location and configuration for the application. Location refers to which data center hosts the application. Configuration can be application-specific. In the example shown, the configuration can be described as low, medium, or high in terms of resource usage. For example, a low resource usage configuration might utilize a relatively small data time window, fewer iteration cycles, or fewer model parameters. Conversely, a high resource usage configuration might utilize relatively more data, more iteration cycles, or more model parameters and / or tiers.

[0076] In some implementations, feasible combinations can refer to combinations that satisfy application requirements and hardware constraints. For example, the energy sampler and converter application 344 may have latency requirements that only allow execution on the far-edge data center 160, making any combination with different locations infeasible. As another example, a low-resource-usage configuration might be feasible at the near-edge data center 170 using GPU resources, but an intermediate-resource-usage configuration might be feasible at the far-edge data center 160 without GPU resources. In the example shown, feasible combinations 540 include four combinations for the first application 542 and two combinations for the second application 544.

[0077] On one hand, the greedy algorithm 195 can incrementally allocate quantities 512 of the first resource 510 and the second resource 520. The greedy algorithm 195 can select feasible combinations 540 from the quantities that will produce the maximum utility based on a utility function. After the first quantity 512 is allocated, the incremental utility can be based on the previous allocation. For example, if the first quantity is allocated to the first application 542 at the far-edge data center 160 to generate energy samples, the decision for the second quantity can be based on the availability of energy samples from the quantity. For example, the second quantity can be used to improve the accuracy of the energy samples or to add an interference detection application 346. The greedy algorithm 195 can allocate all of the first resource 510 and the second resource 520 without reallocating previously allocated quantities. In some implementations, the greedy algorithm 195 can also allocate a third resource 530 if feasible combinations with locations at the cloud data center 180 exist.

[0078] In another example, Bayesian optimizer 196 can be used to predict resource conflicts between multiple applications. Bayesian optimizer 196 can be configured with an objective function representing the aggregate utility of the applications. Conflicts in resources can be considered the next query point for Bayesian optimizer 196. The utility function of the conflicting applications can be used to select resource allocations that optimize the utility between the conflicting applications.

[0079] In some implementations, each of the greedy algorithm and the Bayesian optimizer 196 can be used to generate proposed deployments for the same set of applications. The policy component 194 can, for example, select one of the proposed deployments based on an aggregate utility function. Therefore, the policy component 194 can select the deployment with the maximum utility.

[0080] Figure 6 This is a flowchart illustrating an example of method 600 for RIC management. For example, method 600 may be executed by a data center including one or more memories and one or more processors configured to execute a central controller 190. For example, the central controller 190 may be instantiated on a cloud data center 180 or a near-edge data center 170.

[0081] At box 610, method 600 includes receiving inputs of application requirements, hardware constraints, and the capacity of a first computing resource and a second computing resource. In the example, cloud data center 180 (e.g., incorporating one or more CPUs 232 or memory 234) may execute a central controller 190 and / or input component 192 to receive inputs of application requirements, hardware constraints, and the capacity of a first computing resource (e.g., CPU 212 and memory 214 at a far-edge data center 160) and a second computing resource (e.g., CPU 222, memory 224, and GPU 226 at a near-edge data center 170). For example, input component 192 may receive application requirements from application repository 184. Input component 192 may receive hardware constraints and capacity of the first computing resource from far-edge data center 160. Input component 192 may receive hardware constraints and capacity of the second computing resource from near-edge data center 170. In some implementations, application requirements may include latency requirements, bandwidth requirements, or accuracy requirements. Application requirements, hardware constraints, and capacity can be tailored to applications that are executed in one or more far-edge data centers 160 or one or more near-edge data centers 170 within one or more processing pipelines.

[0082] At box 620, method 600 may optionally include changing parameters of one or more applications to adapt to application requirements for those applications. In the example, cloud data center 180 (e.g., in conjunction with one or more CPUs 232 or memory 234) may execute central controller 190 and / or policy component 194 to change parameters of one or more applications to adapt to application requirements for those applications. For example, policy component 194 may change the input size to produce results within latency requirements, bandwidth requirements, or accuracy requirements. A lower input size (e.g., a lower sampling rate) may reduce latency and bandwidth, but also reduce accuracy.

[0083] At box 630, method 600 includes: selecting a location at one or more far-edge data centers or one or more near-edge data centers based on a policy applied to the input, for executing each application in a plurality of applications to form a pipeline. In the example, cloud data center 180 (e.g., in conjunction with one or more CPUs 232 or memory 234) may execute central controller 190 and / or policy component 194 to select a location at one or more far-edge data centers 160 or one or more near-edge data centers 170 based on a policy applied to the input, for executing each application in a plurality of applications 152 to form pipelines 310, 320, 340. In one aspect, box 630 may include the following regarding... Figure 7 Method 700 described below, regarding Figure 8 The described method is 800, or both 700 and 800. In one aspect, block 630 may include, at sub-block 632, allocating computing resources from a first or second computing resource to a feasible combination that will produce a deployment with maximum utility based on a utility function applied to either the quantification of computing resources or to conflicts of computing resources among multiple applications predicted by a Bayesian optimizer. That is, policy component 194 may execute a greedy algorithm 195 to allocate resources according to method 700, or execute a Bayesian optimizer 196 to predict conflicts in computing resources according to method 800.

[0084] At box 640, method 600 may optionally include selecting a location for dynamically retraining one of the machine learning models based on recent data from the network function, training requirements, and the capacity of a first and a second computing resource. In the example, cloud data center 180 (e.g., incorporating one or more CPUs 232 or memory 234) may execute central controller 190 and / or policy component 194 to select a location (e.g., one of far-edge data center 160, near-edge data center 170, or cloud data center 180) for dynamically retraining (application 152) one of the machine learning models based on recent data from the network function (e.g., vDU 130 or vCU 140), training requirements, and the capacity of the first and second computing resources. For example, policy component 194 may select a location with the lowest available cost resources that can meet the training requirements.

[0085] At box 650, method 600 includes deploying each of multiple applications to a real-time RIC, near-real-time RIC, or non-real-time RIC based on a selected location. In the example, cloud data center 180, for example, in conjunction with one or more CPUs 232 or memory 234, may execute a central controller 190 and / or deployment component 198 to deploy each of multiple applications 152 (e.g., applications 344, 346, 348) to a real-time RIC 162, near-real-time RIC 172, or non-real-time RIC 182 based on a selected location. In some implementations, one or more of the multiple applications are implemented as containers, web assembly code, or eBPF code and configured to apply network data to machine learning models. In some implementations, at sub-box 652, box 650 may optionally include instructing the RIC at the selected location to obtain an image of the application for installation. For example, deployment component 198 may provide an identifier for the application within application repository 184. In some implementations, at sub-box 654, box 650 may optionally include receiving the address of the installed application. For example, the address could be the IP address and port number of the application installed at the selected RIC. In some implementations, at sub-box 656, box 650 may optionally include setting the output destination address of the installed application based on pipeline settings. For example, deployment component 198 may indicate the address of second application 346 to first application 344 as the destination address of the installed first application.

[0086] At box 660, method 600 may optionally include migrating an application between a real-time RIC, a near-real-time RIC, and a non-real-time RIC. In the example, cloud data center 180, for example, combined with one or more CPUs 232 or memory 234, may execute a central controller 190 and / or policy component 194 to migrate an application (e.g., application 346) between real-time RIC 162, near-real-time RIC 172, and non-real-time RIC 182. For example, policy component 194 may migrate application 346 from a real-time RIC 162 on a far-edge data center 160 in deployment 420 to a near-real-time RIC 172 on a near-edge data center 170 in deployment 430. The migration may be in response to current capacity at the current location of the application, a failure at the current location of the application, or connectivity issues between one or more far-edge data centers and one or more near-edge data centers.

[0087] At box 670, method 600 may optionally include updating the output destination address of a previous application in the pipeline to the new location of the application. In the example, cloud data center 180, for example, in conjunction with one or more CPUs 232 or memory 234, may execute central controller 190 and / or deployment component 198 to update the output destination address of a previous application (e.g., application 344) in pipeline 340 to the new location of application 346 (e.g., near-edge data center 170).

[0088] Figure 7 This is a flowchart illustrating an example of method 700 for application deployment. For example, method 700 may be executed by a data center including one or more memories and one or more processors configured to execute a central controller 190. For example, central controller 190 may be instantiated on a cloud data center 180 or a near-edge data center 170. In some implementations, method 700 may also define actions associated with block 630 of method 600. Method 700 may be combined with method 600 and may include any optional blocks of method 600. In some implementations, method 700 may be combined with method 800.

[0089] At block 710, method 700 includes receiving inputs of application requirements, hardware constraints, and the capacity of a first computing resource and a second computing resource for a plurality of applications to be executed in one or more processing pipelines on one or more far-edge data centers or one or more near-edge data centers. In an example, cloud data center 180 (e.g., incorporating one or more CPUs 232 or memory 234) may execute a central controller 190 and / or input component 192 to receive inputs of application requirements, hardware constraints, and the capacity of a first computing resource (e.g., CPU 212 and memory 214 at far-edge data center 160) and a second computing resource (e.g., CPU 222, memory 224, and GPU 226 at near-edge data center 170). For example, input component 192 may receive application requirements from application repository 184. Input component 192 may receive hardware constraints and the capacity of the first computing resource from far-edge data center 160. Input component 192 may receive hardware constraints and the capacity of the second computing resource from near-edge data center 170. In some implementations, application requirements include latency requirements, bandwidth requirements, or accuracy requirements.

[0090] At box 720, method 700 includes enumerating multiple feasible combinations of application locations and configurations that satisfy application requirements and hardware constraints. In the example, cloud data center 180, for example, may combine one or more CPUs 232 or memory 234 to execute central controller 190 and / or policy component 194 to enumerate multiple feasible combinations 540 of application locations and configurations that satisfy application requirements and hardware constraints. For example, policy component 194 can generate different combinations by changing parameters such as input size, sampling rate, number of iterations, or number of model layers.

[0091] At box 730, method 700 may optionally include sorting feasible combinations in ascending order of dominant demand to select resources for allocation. In the example, cloud data center 180, for example, in conjunction with one or more CPUs 232 or memory 234, may execute central controller 190 and / or policy component 194 to sort feasible combinations in ascending order of dominant demand to select resources for allocation. For example, policy component 194 may determine a portion of each resource (e.g., CPU time, memory, etc.) that feasible combination 540 will consume at a location. Policy component 194 may identify the dominant demand at each location as the resource with the largest total usage. Total usage may be greater than 100%, indicating the need for resource allocation among applications.

[0092] At block 740, method 700 includes: incrementally allocating a quantitative amount of either a first computing resource or a second computing resource to a feasible combination of the first proposed deployments that will produce the maximum utility based on a utility function, given a previous allocation of the first proposed deployment, until all the first and second computing resources have been allocated. In the example, cloud data center 180 (e.g., in combination with one or more CPUs 232 or memory 234) may execute central controller 190 and / or policy component 194 to incrementally allocate a quantitative amount 512 of either the first computing resource 510 or the second computing resource 520 to a feasible combination 540 of the first proposed deployments that will produce the maximum utility based on a utility function, given a previous allocation, until all the first and second computing resources have been allocated.

[0093] At box 750, method 700 may optionally include selecting a first proposed deployment or a second proposed deployment based on an aggregate utility function. In the example, cloud data center 180 (e.g., in combination with one or more CPUs 232 or memory 234) may execute central controller 190 and / or deployment component 198 to select a first proposed deployment or a second proposed deployment based on an aggregate utility function (e.g., from method 800).

[0094] At box 760, method 700 includes deploying each of the multiple applications to a real-time RIC, near-real-time RIC, or non-real-time RIC based on a selected deployment. In the example, cloud data center 180, for example, may combine one or more CPUs 232 or memory 234 to execute a central controller 190 and / or deployment component 198 to deploy each of the multiple applications 152 (e.g., applications 344, 346, 348) to a real-time RIC 162, near-real-time RIC 172, or non-real-time RIC 182 based on a selected deployment. In some implementations, one or more of the multiple applications are implemented as containers, web assembly code, or eBPF code and configured to apply network data to a machine learning model.

[0095] Figure 8 This is a flowchart illustrating an example of method 800 for application deployment. For example, method 800 may be executed by a data center including one or more memories and one or more processors configured to execute a central controller 190. For example, central controller 190 may be instantiated on a cloud data center 180 or a near-edge data center 170. In some implementations, method 800 may also define actions associated with block 630 of method 600. Method 800 may be combined with method 600 and may include optional blocks of method 600.

[0096] At block 810, method 800 includes receiving inputs of application requirements, hardware constraints, and the capacity of a first computing resource and a second computing resource for multiple applications that will be executed in one or more processing pipelines on one or more far-edge data centers or one or more near-edge data centers. In an example, cloud data center 180 (e.g., incorporating one or more CPUs 232 or memory 234) may execute a central controller 190 and / or input component 192 to receive inputs of application requirements, hardware constraints, and the capacity of a first computing resource (e.g., CPU 212 and memory 214 at far-edge data center 160) and a second computing resource (e.g., CPU 222, memory 224, and GPU 226 at near-edge data center 170). For example, input component 192 may receive application requirements from application repository 184. Input component 192 may receive hardware constraints and the capacity of the first computing resource from far-edge data center 160. Input component 192 may receive hardware constraints and the capacity of the second computing resource from near-edge data center 170. In some implementations, application requirements include latency requirements, bandwidth requirements, or accuracy requirements.

[0097] At box 820, method 800 includes generating all feasible placement combinations of multiple applications. In the example, cloud data center 180, for example, combined with one or more CPUs 232 or memory 234, may execute central controller 190 and / or policy component 194 to generate all feasible placement combinations of multiple applications. For example, policy component 194 may generate different combinations of applications at different locations.

[0098] At box 830, method 800 includes: using a Bayesian optimizer to predict the next resource conflict between multiple applications. In the example, cloud data center 180, for example, may combine one or more CPUs 232 or memory 234 to execute central controller 190 and / or policy component 194 to use a Bayesian optimizer to predict the next resource conflict between multiple applications.

[0099] At box 840, method 800 includes: selecting an allocation of conflicting resources with an optimized utility function. In the example, cloud data center 180 (e.g., in combination with one or more CPUs 232 or memory 234) may execute central controller 190 and / or policy component 194 to select an allocation of conflicting resources (e.g., quantification 512) with an optimized utility function for the proposed deployment. For example, depending on whether method 700 is executed, the proposed deployment may be a first proposed deployment or a second proposed deployment.

[0100] At box 850, method 800 may optionally include selecting a first proposed deployment or a second proposed deployment based on an aggregate utility function. In the example, cloud data center 180, for example, in conjunction with one or more CPUs 232 or memory 234, may execute central controller 190 and / or deployment component 198 to select a first proposed deployment or a second proposed deployment based on an aggregate utility function.

[0101] At box 860, method 800 includes deploying each of the multiple applications to a real-time RIC, near-real-time RIC, or non-real-time RIC based on a selected deployment. In the example, cloud data center 180, for example, may combine one or more CPUs 232 or memory 234 to execute a central controller 190 and / or deployment component 198 to deploy each of the multiple applications 152 (e.g., applications 344, 346, 348) to a real-time RIC 162, near-real-time RIC 172, or non-real-time RIC 182 based on a selected deployment. In some implementations, one or more of the multiple applications are implemented as containers, web assembly code, or eBPF code and configured to apply network data to machine learning models.

[0102] Figure 9 It shows including, for example Figure 2 Examples of device 900 with additional optional component details are shown. In one aspect, device 900 may include one or more processors 902, which may be similar to CPU 232 for performing processing functions associated with one or more components and functions described herein. Processor 902 may include a single or multiple sets of processors or a multi-core processor. Furthermore, processor 902 may be implemented as an integrated processing system and / or a distributed processing system.

[0103] Device 900 may also include one or more memories 904, which may be similar to memory 234, such as for storing a local version of an operating system (or components thereof) and / or applications executed by processor 902 (such as central controller 190). One or more memories 904 may include a type of memory that can be used by a computer, such as random access memory (RAM), read-only memory (ROM), magnetic tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof.

[0104] Furthermore, device 900 may include communication component 906, which provides the means to establish and maintain communication with one or more other devices, parties, entities, etc., using the hardware, software, and services described herein. Communication component 906 may carry communication between components on device 900 and between device 900 and external devices, such as devices located on a communication network and / or devices serially or locally connected to device 900. For example, communication component 906 may include one or more buses and may also include transmit chain components and receive chain components, respectively associated with a wireless or wired transmitter and receiver operable for interfacing with external devices.

[0105] Additionally, device 900 may include data storage 908, which may be any suitable combination of hardware and / or software, providing large-capacity storage for information, databases, and programs employed in conjunction with the aspects described herein. For example, data storage 908 may be, or may include, a repository of data not currently executed by processor 902, such as an operating system (or components thereof), applications, related parameters, etc. Furthermore, data storage 908 may be a repository for one or more other components of non-real-time RIC 182, application repository 184, central controller 190, and / or device 900.

[0106] Device 900 may optionally include a user interface component 910 operable to receive input from a user of device 900 and also operable to generate output for presentation to the user. User interface component 910 may include one or more input devices, including but not limited to a keyboard, numeric keypad, mouse, touch-sensitive display, navigation keys, function keys, microphone, voice recognition component, gesture recognition component, depth sensor, gaze tracking sensor, switch / button, any other mechanism capable of receiving input from the user, or any combination thereof. Furthermore, user interface component 910 may include one or more output devices, including but not limited to a display, speaker, haptic feedback mechanism, printer, any other mechanism capable of presenting output to the user, or any combination thereof.

[0107] The device 900 may additionally include a central controller 190, which includes an input component 192, a policy component 194, and a deployment component 198 as described herein.

[0108] The following numbered clauses provide an overview of the various aspects of this disclosure: Clause 1. A system for executing applications for Radio Interface Controller (RIC) management, comprising: one or more far-edge data centers, each far-edge data center including a first computing resource configured to perform real-time RIC and Radio Access Network (RAN) functions; one or more near-edge data centers, each near-edge data center including a second computing resource configured to perform at least one of near-real-time RIC or non-real-time RIC and core network functions; and a central controller configured to: receive inputs of application requirements, hardware constraints, and the capacities of the first and second computing resources for a plurality of applications, the plurality of applications being processed in one or more processing pipelines. Execute on one or more far-edge data centers or one or more near-edge data centers; enumerate multiple feasible combinations of application locations and configurations that satisfy the application requirements and the hardware constraints; allocate computing resources from the first computing resource or the second computing resource to a feasible combination, the feasible combination generating a deployment with maximum utility based on a utility function applied to the quantification of the computing resources or to the conflict of computing resources between the multiple applications predicted by a Bayesian optimizer; and based on the deployment, deploy each of the multiple applications to the real-time RIC, the near-real-time RIC, or the non-real-time RIC.

[0109] Clause 2. The system according to Clause 1, wherein the plurality of feasible combinations satisfy the application requirements and the hardware constraints.

[0110] Clause 3. The system according to Clause 1 or 2, wherein, in order to allocate the computing resources, the central controller is configured to: incrementally allocate a quantitative amount of the first computing resources or the second computing resources to the feasible combination that will produce the maximum utility based on the utility function of the previous allocation, until all the first computing resources and the second computing resources have been allocated.

[0111] Clause 4. The system according to Clause 3, wherein the quantification is part of resource usage, the quantification being directed to the dominant demand at each application location for the feasible combination of maximum resource usage in the first computing resource and the second computing resource.

[0112] Clause 5. The system according to Clause 4, wherein the central controller is configured to sort the feasible combinations in ascending order of the dominant demand to select resources for allocation.

[0113] Clause 6. The system according to any one of Clauses 1 to 5, wherein the utility function measures the accuracy of the plurality of applications and the communication efficiency between the plurality of applications.

[0114] Clause 7. The system according to any one of Clauses 1 to 6, wherein, in order to allocate the computing resources, the central controller is configured to: use the Bayesian optimizer to predict the next conflict among the computing resources among the plurality of applications; and select the allocation of the conflicting resources to optimize the utility function.

[0115] Clause 8. The system according to Clause 7, wherein the Bayesian optimizer is configured with an objective function that indicates the aggregate utility of the application.

[0116] Clause 9. A system according to any one of Clauses 1 to 8, wherein, in order to allocate computing resources from the first computing resource or the second computing resource to a feasible combination that will produce a deployment, the central controller is configured to: quantitatively and incrementally allocate the first computing resource or the second computing resource to a feasible combination of the first proposed deployments that will produce the first proposed deployments with the greatest utility based on a utility function from previous allocations of the first proposed deployments, until all the first computing resources and the second computing resources have been allocated; predict the next conflict among the computing resources among the plurality of applications using a Bayesian optimizer; select the allocation of the conflicting resources for a second deployment that optimizes the utility function; and select the first proposed deployment or the second proposed deployment based on an aggregate utility function.

[0117] Clause 10. A method for executing applications for Radio Interface Controller (RIC) management, comprising: receiving inputs of application requirements and hardware constraints for a plurality of applications to be executed in one or more processing pipelines on one or more far-edge data centers or one or more near-edge data centers, the far-edge data centers having first computing resources configured to perform real-time RIC and Radio Access Network (RAN) functions, the near-edge data centers having second computing resources configured to perform at least one of near-real-time RIC or non-real-time RIC and core network functions; enumerating a plurality of feasible combinations of application locations and configurations that satisfy the application requirements and the hardware constraints; quantitatively and incrementally allocating the first computing resources or the second computing resources to feasible combinations of the first proposed deployments that will produce the maximum utility based on a utility function of a previous allocation of the first proposed deployment, until all the first computing resources and the second computing resources have been allocated; and deploying each of the plurality of applications to the real-time RIC, the near-real-time RIC, or the non-real-time RIC, at least in part based on the first proposed deployment.

[0118] Clause 11. The method according to Clause 10 or 11, wherein the feasible combination satisfies the application requirements and the hardware constraints.

[0119] Clause 12. The method according to Clause 10, wherein the quantification is part of resource usage, the quantification being directed to the dominant demand at each application location for the feasible combination of maximum resource usage in the first computing resource and the second computing resource.

[0120] Clause 13. The method according to Clause 12 further includes sorting the feasible combinations in ascending order of the dominant demand to select resources for allocation.

[0121] Clause 14. The method according to any one of Clauses 10 to 13, wherein the utility function measures the accuracy of the plurality of applications and the communication efficiency between the plurality of applications.

[0122] Clause 15. The method according to any one of Clauses 10 to 14 further includes: using a Bayesian optimizer to predict the next conflict among the computing resources among the plurality of applications; and selecting an allocation of the conflicting resources to optimize the utility function for a second deployment.

[0123] Clause 16. The method according to Clause 15, wherein deploying each application of the plurality of applications to the real-time RIC, the near-real-time RIC, or the non-real-time RIC based at least in part on the first proposed deployment comprises: selecting the first proposed deployment or the second proposed deployment based on an aggregate utility function; and deploying each application of the plurality of applications to the real-time RIC, the near-real-time RIC, or the non-real-time RIC based on the selected deployment.

[0124] Clause 17. The method according to Clause 15 or 16, wherein the Bayesian optimizer is configured with an objective function indicating the aggregation utility of the application.

[0125] Clause 18. A non-transitory computer-readable medium storing computer-executable instructions for radio interface controller (RIC) management, the non-transitory computer-readable medium including instructions that, when executed by a processor of a central controller of a network, cause the central controller to: receive inputs of application requirements and hardware constraints for a plurality of applications to be executed in one or more processing pipelines on one or more far-edge data centers or one or more near-edge data centers, the far-edge data centers having first computing resources configured to perform real-time RIC and radio access network (RAN) functions, the near-edge data centers having second computing resources configured to perform at least one of near-real-time RIC or non-real-time RIC and core network functions; enumerate a plurality of feasible combinations of application locations and configurations that satisfy the application requirements and the hardware constraints; predict the next conflict among resources among the plurality of applications using a Bayesian optimizer; select an allocation of the conflicting resources for a first deployment optimization utility function; and deploy each of the plurality of applications to the real-time RIC, the near-real-time RIC, or the non-real-time RIC, at least in part based on the allocation of the resources.

[0126] Clause 19. The non-transitory computer-readable medium as described in Clause 18, wherein the Bayesian optimizer is configured with an objective function indicating the aggregation utility of the application.

[0127] Clause 20. The non-transitory computer-readable medium pursuant to Clause 18 or 19 further includes instructions for: quantitatively and incrementally allocating the first or second computing resources to a feasible combination of the second proposed deployments that, given the previous allocation of the second proposed deployment based on a utility function, the quantitative allocation will produce the second proposed deployment with the greatest utility, until all the first and second computing resources have been allocated; selecting the first or second proposed deployment based on an aggregate utility function; and deploying each of the plurality of applications to the real-time RIC, the near-real-time RIC, or the non-real-time RIC based on the selected deployment.

[0128] As an example, an element, or any part thereof, or any combination thereof, may be implemented using a “processing system” comprising one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuitry, and other suitable hardware configured to perform the various functions described throughout this disclosure. One or more processors in the processing system may execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or other terms, software should be interpreted broadly as meaning instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc.

[0129] Therefore, in one or more aspects, the one or more functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the function can be stored on a computer-readable medium or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media can be any available medium accessible to a computer. By way of example and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store the required program code in the form of instructions or data structures and is accessible to a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), and floppy disks, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media. Non-transitory computer-readable media specifically exclude transient signals.

[0130] The foregoing description is provided to enable those skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but rather to conform to the full scope consistent with the language of the claims. Unless specifically stated otherwise, reference to an element in the singular is not intended to mean “one and only one,” but rather “one or more.” Unless specifically stated otherwise, the term “some” means one or more. Furthermore, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise stated or clear from the context, the phrase “X employs A or B” is intended to mean any natural inclusive enumeration. That is, the phrase “X employs A or B” is satisfied by any of the following: X employs A; X employs B; or X employs both A and B. Furthermore, the articles “a” and “an” used in this application and the appended claims should generally be interpreted as meaning “one or more,” unless otherwise stated or clearly pointed to from the context in the singular form. Moreover, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is expressly stated in the claims. No claim element should be construed as a functional component unless the element is explicitly stated using the phrase "component for..."

Claims

1. A system for performing applications for wireless interface controller (RIC) management, comprising: One or more remote edge data centers (160), each remote edge data center (160) including a first computing resource configured to perform real-time RIC (162) and radio access network (RAN) functions; One or more near-edge data centers, each near-edge data center including a second computing resource configured to perform at least one of near real-time RIC (172) or non-real-time RIC (182) and core network functions; and The central controller (190) is configured as follows: The system receives inputs of application requirements, hardware constraints, and the capacity of the first and second computing resources for multiple applications that will be executed in one or more processing pipelines (310) on one or more far-edge data centers (160) or one or more near-edge data centers. Enumerate multiple feasible combinations of application locations and configurations that satisfy the application requirements and the hardware constraints (540). The computing resources from the first computing resource (510) or the second computing resource (520) are allocated to a feasible combination (540), which will produce a deployment with maximum utility based on a utility function applied to the quantification (512) of the computing resources or to the conflict of the computing resources between the plurality of applications predicted by the Bayesian optimizer (196). as well as Based on the deployment, each of the multiple applications is deployed to the real-time RIC (162), the near-real-time RIC (172), or the non-real-time RIC (182).

2. The system of claim 1, wherein the plurality of feasible combinations satisfy the application requirements and the hardware constraints.

3. The system of claim 1, wherein, in order to allocate the computing resources, the central controller (190) is configured to: incrementally allocate a quantity (512) of the first computing resources or the second computing resources to the feasible combination (540) that, given the previous allocation based on a utility function, would produce the maximum utility by the quantity (512), until all the first computing resources and the second computing resources have been allocated.

4. The system of claim 3, wherein the quantification (512) is part of resource usage, the quantification being directed to the dominant demand at each application location for a feasible combination (540) of maximum resource usage in the first computing resource and the second computing resource.

5. The system of claim 4, wherein the central controller (190) is configured to sort the feasible combinations in ascending order of the dominant demand to select resources for allocation.

6. The system of claim 1, wherein the utility function measures the accuracy of the plurality of applications and the communication efficiency between the plurality of applications.

7. The system of claim 1, wherein, in order to allocate the computing resources, the central controller (190) is configured to: The Bayesian optimizer is used to predict the next conflict in the computing resources among the multiple applications; and Choose to optimize the allocation of conflicting resources according to the utility function.

8. The system of claim 7, wherein the Bayesian optimizer is configured with an objective function indicating the aggregation utility of the application.

9. The system of claim 1, wherein, in order to allocate computing resources from the first computing resource or the second computing resource to a feasible combination (540) that will produce a deployment, the central controller (190) is configured to: The quantitative (512) allocation of the first computing resources or the second computing resources is incrementally allocated to feasible combinations (540) of the first proposed deployment, based on the utility function, whereby the quantitative (512) will produce the first proposed deployment with the greatest utility, until all the first computing resources and the second computing resources have been allocated. Use a Bayesian optimizer to predict the next conflict in the computing resources among the multiple applications; Choose to optimize the allocation of conflicting resources for the utility function of the second deployment; as well as The first or second proposed deployment is selected based on the aggregation utility function.

10. A method (700) for performing an application for wireless interface controller (RIC) management, comprising: The system receives inputs of application requirements and hardware constraints for multiple applications that will be executed in one or more processing pipelines on one or more far-edge data centers (160) or one or more near-edge data centers. The far-edge data centers (160) have first computing resources configured to perform real-time RIC (162) and radio access network (RAN) functions, and the near-edge data centers have second computing resources configured to perform at least one of near real-time RIC (172) or non-real-time RIC (182) and core network functions. Enumerate multiple feasible combinations of application locations and configurations that satisfy the application requirements and the hardware constraints (540). The quantitative (512) allocation of the first computing resources or the second computing resources is incrementally allocated to feasible combinations (540) of the first proposed deployment, based on the utility function, whereby the quantitative (512) will produce the first proposed deployment with the greatest utility, until all the first computing resources and the second computing resources have been allocated. as well as Each of the plurality of applications is deployed to the real-time RIC (162), the near-real-time RIC (172), or the non-real-time RIC (182), at least in part based on the first proposal.

11. The method of claim 10, wherein the feasible combination satisfies the application requirements and the hardware constraints.

12. The method of claim 10, wherein the quantification (512) is part of resource usage, the quantification being directed to the dominant demand at each application location for a feasible combination (540) of maximum resource usage in the first computing resource and the second computing resource.

13. The method of claim 12, further comprising sorting the feasible combinations in ascending order of the dominant demand to select resources for allocation.

14. The method of claim 10, wherein the utility function measures the accuracy of the plurality of applications and the communication efficiency between the plurality of applications.

15. The method of claim 10, further comprising: Use a Bayesian optimizer to predict the next conflict in the computing resources among the multiple applications; as well as Choose to optimize the allocation of conflicting resources for the utility function of the second deployment.

16. The method of claim 15, wherein deploying each of the plurality of applications to the real-time RIC (162), the near-real-time RIC (172), or the non-real-time RIC (182) based at least in part on the first proposed deployment comprises: The first or second proposed deployment is selected based on the aggregation utility function. as well as Based on the selected deployment, each of the multiple applications is deployed to the real-time RIC (162), the near-real-time RIC (172), or the non-real-time RIC (182).

17. A non-transitory computer-readable medium storing computer-executable instructions for management of a wireless interface controller (RIC), the non-transitory computer-readable medium including instructions that, when executed by a processor of a central controller (190) of a network, cause the central controller (190) to: The system receives inputs of application requirements and hardware constraints for multiple applications that will be executed in one or more processing pipelines on one or more far-edge data centers (160) or one or more near-edge data centers. The far-edge data centers (160) have first computing resources configured to perform real-time RIC (162) and radio access network (RAN) functions, and the near-edge data centers have second computing resources configured to perform at least one of near real-time RIC (172) or non-real-time RIC (182) and core network functions. Enumerate multiple feasible combinations of application locations and configurations that satisfy the application requirements and the hardware constraints (540). Use the Bayesian optimizer (196) to predict the next conflict in resources among the multiple applications; Select the allocation of conflicting resources for the first deployment to optimize the utility function; as well as Based at least in part on the allocation of the resources, each of the plurality of applications is deployed to the real-time RIC (162), the near-real-time RIC (172), or the non-real-time RIC (182).

18. The non-transitory computer-readable medium of claim 17, wherein the Bayesian optimizer is configured with an objective function indicating the aggregation utility of the application.

19. The non-transitory computer-readable medium of claim 17, further comprising instructions for: The quantitative (512) allocation of the first or second computing resources is incrementally allocated to feasible combinations (540) of the second proposed deployment, based on the utility function, whereby the quantitative (512) will produce the second proposed deployment with the greatest utility, until all the first and second computing resources have been allocated. The first or second proposed deployment is selected based on the aggregation utility function. as well as Based on the selected deployment, each of the multiple applications is deployed to the real-time RIC (162), the near-real-time RIC (162) (172), or the non-real-time RIC (162) (182).

20. The non-transitory computer-readable medium of claim 17, wherein the RAN function is a 5G network function.

Images