Scaling of Open Radio Access Network (o-Ran) Applications

This application claims the benefit of Greece Patent Application Serial No. 20240100642 filed on Sep. 20, 2024, the entire content of which is incorporated herein by reference.

The disclosure relates to computer networking and, more specifically, to scaling of Open Radio Access Network (O-RAN) applications of functions and services with a radio intelligent controller.

Computer networks have become ubiquitous, and the number of network applications, network-connected devices, and types of network-connected devices are rapidly expanding. Such devices now include computers, smartphones, Internet-of-Things (IoT) devices, vehicles, medical devices factory equipment, etc. 5G mobile network architectures enhanced the ability to provide communication services using cloud-based network function virtualization (NFV). Specialized networks can be created using the Radio Access Network (RAN) of a mobile network operator combined with functions of a 5G core. For example, networks can be created for a specific service level agreement (SLA), special use cases, or other specific requirements. Examples of such networks include private mobile networks, industrial networks, a dedicated network for connected vehicles, etc.

In general, this disclosure describes techniques for scaling applications, such as xApps and rApps of a mobile network. The mobile network may include one or more RAN Intelligent Controllers (RIC) for a RAN. For example, a network system may include a Service Management and Orchestration (SMO) framework offering various framework functions along with a non-real-time (non-RT) RIC, configured in accordance with Open Radio Access Network (O-RAN) standards (the network system being referred to hereinafter as an “O-RAN architecture”), to manage and/or monitor aspects of a RAN and/or 5G core. The O-RAN architecture may include a non-RT RIC and a near-real-time RIC (near-RT RIC) that each executes different functions and services for RAN functions. For example, the non-RT RIC is an orchestration and automation function configured to provide radio resource management, higher layer procedure optimization, policy optimization, and provide guidance, parameters, policies and AI/ML models to support the operation of near-RT RIC functions in the RAN. The non-RT RIC may onboard one or more applications (e.g., rApps) that provide non-real time (e.g., greater than one second) control of RAN elements and their resources, and the near-RT RIC may onboard one or more applications (e.g., xApps) that provide near-real time control of RAN elements and their resources.

A mobile network may include thousands of base stations and potentially tens or hundreds of thousands of cells that RICs are controlling and/or managing. In addition to cell level control, there may be hundreds or thousands of user equipment (UEs) using each cell that a RIC controls and/or manages. This large number of cells and UEs may easily outpace the performance a single instance of a non-RT RIC or a near-RT RIC.

Because a mobile network may include more base stations and/or UEs than can be managed by a single RIC, the mobile network may be divided into a plurality of clusters. A RIC instance can manage one or more clusters. A cluster may be a geographically contiguous smaller portion of a mobile network. For example, a cluster may include a number of base stations that are geographically proximate to one another, for example. In this manner, a mobile network may be divided into a plurality of clusters in which each cluster covers a particular contiguous geographic area. In managing resources of a cluster, applications and resources of the cluster may exchange cluster messages. A cluster message may include a message between one or more resources of a cluster and an instance of an application.

According to the techniques of this disclosure, a RIC, such as a non-RT RIC or a near-RT RIC may be configured to provide functionality for scaling applications, such as rApps or xApps (which may be alternatively referred to herein collectively as r/xApps). The RIC may determine a plurality of virtual clusters from a cluster of a mobile network to scale an application and may split communications to/from the plurality of virtual clusters between an existing, first instance of the application and a new, second instance of the application. For example, the RIC may configure microservices, such as A1, O1, O2, and/or E2 microservices, to route new cluster messages from a second virtual cluster to the second instance of the application and may continue to route new cluster messages from the first virtual cluster (which is part of the cluster being split) to the first instance of the application, thereby distributing a workload of the cluster across the first instance of the application and the second instance of the application between two virtual clusters.

The techniques described herein may provide one or more technical advantages that realize at least one practical application. For example, the techniques of this disclosure may provide for the scaling of applications prior to the applications becoming overloaded and failing. Failure of an application may negatively affect the functioning of a network and may disrupt and/or diminish the quality of communications over the network and may cause dropped calls and/or data connections. As such, the techniques of this disclosure may improve network operations and connectivity. The techniques may enable the RIC to scale an application that is not natively scalable, i.e., the application is not deployed and/or manufactured in a manner that enables the application itself to manage scaling and load balancing. Rather, as described in detail below, the RIC causes or instantiates new instances of such a “non-scalable” application and, by intelligently routing virtual cluster messages from different virtual clusters, effectively spoofs the application instances into managing different virtual clusters.

In one example, a RIC for a RAN includes processor circuitry; and memory coupled to the processor circuitry, the memory storing instructions that, when executed, cause the processor circuitry to: determine that operation of a first instance of an application satisfies one or more criteria for scaling the application, the first instance of the application processing cluster messages generated by the RAN; in response to determining that the operation of the first instance of the application satisfies the one or more criteria, determine a first virtual cluster and a second virtual cluster of the RAN, wherein the first virtual cluster includes first one or more resources of the RAN and the second virtual cluster includes second one or more resources of the RAN, the first one or more resources of the RAN and the second one or more resources of the RAN being different; instantiate a second instance of the application; and route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application.

In another example, a method includes determining, by a RIC, that operation of a first instance of an application satisfies one or more criteria for scaling the application, the first instance of the application processing cluster messages generated by the RAN; determining, by the RIC and in response to determining that the operation of the first instance of the application satisfies the one or more criteria, a first virtual cluster and a second virtual cluster of the RAN, wherein the first virtual cluster includes first one or more resources of the RAN and the second virtual cluster includes second one or more resources of the RAN, the first one or more resources of the RAN and the second one or more resources of the RAN being different; instantiating, by the RIC, a second instance of the application; and configuring, by the RIC, one or more microservices to route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application.

In another example, non-transitory computer-readable storage media stores instructions that, when executed, cause one or more processors of a RIC to determine that operation of a first instance of an application satisfies one or more criteria for scaling the application, the first instance of the application processing cluster messages generated by the RAN; in response to determining that the operation of the first instance of the application satisfies the one or more criteria, determine a first virtual cluster and a second virtual cluster of the RAN, wherein the first virtual cluster includes first one or more resources of the RAN and the second virtual cluster includes second one or more resources of the RAN, the first one or more resources of the RAN and the second one or more resources of the RAN being different; instantiate a second instance of the application; and route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application.

The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

Like reference characters refer to like elements throughout the text and figures.

1 FIG.A 1 FIG.A 1 FIG.A 100 112 122 124 109 105 104 104 104 140 122 121 is a block diagram illustrating an example network system configured to provide scaling of application services for a RAN, in accordance with one or more techniques of the disclosure. In the example illustrated in, network systemincludes Service and Management Orchestrator (SMO), non-RT RIC, near-RT RIC, one or more radio access networks (RANs), e.g., RAN, and mobile core network (or simply “core”)that provide user equipmentA-N (collectively, “UEs”) with access to one or more applications or services provided by data network. In the example of, non-RT RICincludes application scaling manager.

104 100 109 104 109 109 106 106 106 140 106 106 1 FIG.A 1 FIG.A UEsmay represent smartphones, desktop computers, laptop computers, tablets, smart watches, and/or “Internet-of-Things” (IOT) devices, such as cameras, sensors, televisions, appliances, or the like. As shown in, network systemincludes RANthat provides network access, data transport, and other services to UEs. In some examples, RANmay be an Open Radio Access Network (O-RAN), a 5G mobile network RAN, a 4G LTE mobile network RAN, another type of RAN, or a combination of the above. For example, in a 5G-radio access network, RANcomprises a plurality of cell sites (or simply “cells”) that each include radio equipment, such as base stationsA-M (collectively, “base stations”), which may also be referred to as gNodeBs, to exchange packetized data within a data network to ultimately access one or more applications or services provided by data network. While represented inas towers, each of base stationsis divided into three functional components: radio unit (RU), distributed unit (DU), and central unit (CU), which can be deployed in various configurations. RU manages the radio frequency layer and has antenna arrays of various sizes and shapes. DU performs lower layer protocol processing. CU performs the upper layer protocol processing. Depending on operator and service requirements, base stationscan be deployed monolithically, e.g., RU, DU, and CU reside within a particular geographically located cell site, or these functionalities can be distributed across geographically different cell sites while the CU resides in an edge cloud site controlling a plurality of distributed DUs. O-RAN is, for example, an approach to networking in which disaggregated functions can be used to deploy mobile front-haul and mid-haul networks. The disaggregated functions can be cloud-based functions.

109 105 140 105 140 105 109 105 100 105 104 105 rd Technical Specification Group Services and System Aspects; System architecture for the G System GS Stage Release Radio access networksconnect to coreto exchange packets with data network. Coremay be a 5G core network, and data network (DN)may represent, for example, one or more service provider networks and services, the Internet, third party services, one or more IP-VPNs, an IP-multimedia subsystem, a combination thereof, or other network or combination of networks. In some examples, resources associated with the service provided by a mobile network operator to the tenant may be provided by, or managed by, functions of coreand/or components of RAN. In some examples, coreimplements various discrete control plane and user plane functions for network system. Examples of 5G control plane functions that may be provided by coreinclude Access Mobility Management Function (AMF) that provides access mobility management services, Session Management Function (SMF) that provides session management services, Policy Control Function (PCF) that provides policy control services, User Data Management (UDM) that provides management of network user data, Network Repository Function (NRF) that provides a repository that can be used to register and discover services in a network operator's network, Authentication Server Function (AUSF) that provides authentication services, Network Slice Selection Function (NSSF), Network Slice Management Function (NSMF) that may be used to select an instance of an available network slice for use by any of UE devices, and Network Slice Subnet Management Function (NSSMF) that provides coordination, management, and orchestration of network slice subnet instances (NSSI). Coremay also include User Plane Functions (UPF) that provides packet routing, forwarding and other network data processing functions (e.g., Quality of Service, packet inspection, traffic optimization etc.). Further details on services and functions provided by the 5G core can be found in 3Generation Partnership Project5(5);2 (18), TS 23.501 V18.2.2 (2023 July), the entire contents of which is hereby incorporated by reference. Further details on the O-RAN architecture can be found in O-RAN Alliance, “O-RAN Work Group 1 (Use Cases and Overall Architecture) O-RAN Architecture Description,” O-RAN.WG1.OAD-R003-v12.00, June 2024, the entire contents of which is hereby incorporated by reference.

109 105 112 122 124 112 122 124 112 109 112 122 124 122 124 124 122 124 124 1 FIG.B 1 FIG.C Aspects of RANand/or coremay be managed and/or monitored by SMO, non-RT RIC, and near-RT RIC. In some examples, SMO, non-RT RIC, and near-RT RICmay be operated by the mobile network operator providing 5G services to a tenant. SMOcan orchestrate and control management and automation aspects of RAN(e.g., network slicing, management, and orchestration of O-Cloud, etc.). Further, SMOmay control aspects of non-RT RICand near-RT RIC. Non-RT RICcan provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources such as RUs, DUs, and CUs, workflow management, and policy-based control of applications and features of near-RT RIC. Near-RT RICcan provide near-real-time (e.g., milliseconds) control and optimization of RAN elements and resources via fine-grained data collection and actions. As further described inand, non-RT RICand near-RT RICmay deploy as a highly scalable, microservices based containerized architecture, such as a Kubernetes architecture. In some examples, near-RT RICmay be located within an edge or regional cloud.

122 123 122 123 122 123 124 123 124 124 125 124 125 124 124 123 122 122 122 123 122 124 125 124 Non-RT RICmay onboard one or more applications, e.g., applications, which may include rApps that manage non-real time events within non-RT RIC, such as applications that do not require response times of less than one second. Applicationsmay leverage the functionality exposed via the non-RT RIC framework of non-RT RIC. Applicationsmay be used to control and manage RAN elements and resources, such as near-RT RIC, RAN nodes, and/or resources in the O-RAN cloud. Applicationsmay also utilize network data, performance metrics, and subscriber data to provide recommendations for network optimization and operational guidance (e.g., policies) to one or more applications of near-RT RIC. Near-RT RICmay onboard one or more applications, e.g., applications, which may include xApps, that manage near-real time events within near-RT RIC. Applicationsmay leverage the functionality exposed via the near-RT RIC framework of near-RT RIC. Near-RT RICmay enforce policies received from applicationsof non-RT RICand may provide policy feedback to non-RT RIC. Although illustrated as within non-RT RIC, any one or more of applicationsmay be executed by a third party, separate from non-RT RIC. Likewise, although illustrated as within near-RT RIC, any one or more of applicationsmay be executed by a third party, separate from near-RT RIC.

The O-RAN architecture includes several interfaces, such as A1, O1, O2, and E2 interfaces, that are each used to provide the functions and services by which the SMO and RIC can configure or direct other components of the RAN. For example, the functions and services of non-RT RIC may include policy management services and/or enrichment information services for a near-RT RIC that are provided over an A1 interface (collectively referred to herein as “A1 services” because they provided over the A1 interface); performance management services, configuration management services, and/or Operations, Administration, and Management (OAM) services for O-RAN management elements that are provided over an O1 interface (referred to herein as “O1 services” because they are provided over the O1 interface); configuration management services and performance management services for resources of an O-RAN cloud that are provided over an O2 interface (referred to herein as “O2 services” because they are provided over the O2 interface), and/or other services, such as service management and exposure (SME) services (e.g., registration of a service, update of a service registration), data management and exposure (DME) services, and/or AI/ML services. The functions and services for a near-RT RIC may include control procedures and functionalities to control O-RAN elements, such as radio units (RUS), distributed units (DUs), and central units (CUs), that are provided over an E2 interface and may be referred to as “E2 services” because they are provided over the E2 interface.

122 122 124 122 112 124 122 112 122 As described further below, non-RT RICmay provide services using A1 and O1 interfaces. An A1 interface connects the non-RT RICand near-RT RIC. Non-RT RICmay perform services via the A1 interface, such as policy management services (e.g., creation and update of a policy), ML model management services, and/or enrichment information services. Services performed via the A1 interface are referred to herein as “A1 services.” An O1 interface may include an interface that connects SMOwith O-RAN managed elements, such as near-RT RICand/or RAN nodes (e.g., O-RAN centralized unit (O-CU), O-RAN distributed unit (O-DU)). Non-RT RICmay perform services via the O1 interface, such as configuration management services and performance management services of O-RAN managed elements (e.g., operation and maintenance (OAM) services), fault supervision, file management, heartbeat, trace, physical network function (PNF) discovery, software management, etc.). Services performed via the O1 interface are referred to herein as “O1 services.” An O2 interface may include an interface that connects SMOto resources of the ORAN O-Cloud. The O-Cloud may comprise of one or more physical infrastructure nodes that host O-RAN functions (e.g., virtual network functions), the supporting software components, and the appropriate management and orchestration functions. Non-RT RICmay also perform other functions and services, such as service management and exposure (SME) services (e.g., registration of a service, update of a service registration), data management and exposure (DME) services, AI/ML services, or the like.

124 124 An E2 interface may include an interface that connects near-RT RICto RAN nodes. Near-RT RICmay control and/or manage (e.g., configure) functionalities of the RAN nodes via the E2 interface.

121 123 125 121 123 125 109 Application scaling managermay manage scaling of applications, such as applicationsand/or applications. For example, application scaling managermay monitor operation of applicationsand/orand may determine that operation of a first instance of an application satisfies one or more criteria for scaling the application, the first instance of the application processing cluster messages generate by the RAN. The one or more criteria may include a threshold, such as a compute resource usage threshold, a number of cells or base stations managed by the first instance, a number or rate of messages sent from the RIC and handled by the first instance, a request or query from the first instance, an indication from the first instance of one or more virtual clusters, or other criteria. The criteria may be user configurable. The criteria may be specified in a policy. The criteria may be application specific, e.g., for different r/xApps.

123 125 121 121 121 121 121 109 109 2 FIG. In the following example, the criteria include a compute resource usage of an instance of an application satisfying (e.g., meeting or exceeding) a threshold. In response to determining that the compute resource usage of the first instance of the application (e.g., rAppA or xAppA) exceeds one or more thresholds, application scaling managermay determine a first virtual cluster and a second virtual cluster of the cluster. An example cluster, first virtual cluster, and second virtual cluster are described later herein with respect to. The first virtual cluster includes first one or more resources of the cluster and the second virtual cluster includes second one or more resources of the cluster that are different than each other. For example, the E2 nodes of the two virtual clusters are different (e.g., each E2 node of the first virtual cluster is not part of the second virtual cluster, and each E2 node of the second virtual cluster is not part of the first virtual cluster). Application scaling managermay instantiate a second instance of the application. Application scaling managermay route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. For example, application scaling managermay configure one or more microservices to route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. Such configuring effectively splits the cluster for the purposes of the first instance of the application, which continues to receive cluster messages from, and interacts with, the first virtual cluster, and the second instance of the application, which now receives cluster messages from, and interacts with, the second virtual cluster. In this manner, application scaling managerprevents the first instance of the application from becoming overloaded and thereby prevent or diminish the chances of a network disruption of RANand/or the diminishment of the quality of communications over RAN.

1 FIG.B 1 FIG.A 1 FIG.B 1 FIG.B 122 112 122 142 144 168 169 112 122 124 146 148 150 121 is a block diagram illustrating further example details of the non-RT RICof. In the example illustrated in, SMOmay include non-RT RIC, one or more AI/ML models, one or more functions(e.g., NSSMF, NFMF, and other functions), and open interfaces, such as O1 terminationand O2 termination. SMOmay manage non-RT RIC, near-RT RIC, O-RAN managed elements (e.g., centralized unit (O-CU), O-RAN decentralized unit (O-DU)of one or more base stations), and resources in O-RAN cloud. In the example of, non-RT RIC includes application scaling manager.

122 124 122 122 123 123 123 123 122 123 122 123 Non-RT RICmay provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources such as RUs, DUs, and CUs, workflow management, and policy-based control of applications and features of near-RT RIC. Non-RT RICmay be deployed as a highly scalable, microservices based containerized architecture. In this example, non-RT RICmay onboard, deploy, and/or terminate one or more applications, e.g., rAppA through rAppN (collectively “applications”). Applicationsmay represent applications that leverage the functionality exposed via the framework of non-RT RIC. Applicationsmay provide non-RT RICwith non-real time (e.g., greater than one second) control of RAN elements and their resources. Applicationsmay provide services for radio resource management, higher layer procedure optimization, policy optimization, and providing guidance, parameters, policies, and AI/ML models to support the operation of RAN functions.

123 124 124 124 For example, applicationsmay provide A1 services that provide and facilitate RAN operations and optimization of near-RT RIC, such as providing operational guidance (e.g., policies), enrichment information (e.g., forecasts), and AI/ML services. A1 services may include policy management services such as creating, updating, and/or deleting of A1 policies; receiving policy feedback; querying policy types, identifiers, and status; defining which policy types are supported by near-RT RIC; and registering applications (xApps) of near-RT RICto specific policy types. A1 services may include enrichment information services, such as providing data for model training of AI/ML models, such as forecasts and/or data analytics.

123 124 146 148 122 Applicationsmay provide O1 services that provide configuration management or performance management of O-RAN managed entities, such as near-RT RICand/or RAN nodes, e.g., O-CU, O-DU(also referred to herein as “E2 nodes”). O1 services may provide configuration management services to create, update, and/or delete configurations to O-RAN managed entities. For example, configuration management services may include provisioning operations (e.g., for NSS and NF provisioning) to create a managed object instance (MOI), obtain MOI attributes, modify MOI attributes, and/or delete the MOI. O1 services may also provide performance management services that monitor the status of elements or components in the O-RAN managed entities. For example, non-RT RICmay create, modify, or delete performance management jobs to receive performance metrics, or send heartbeat messages to monitor the status and/or availability of services of RAN nodes or to send trace messages to monitor link failures. O1 services may also provide file management, such as to push files to the RAN nodes (e.g., software updates, beamforming configuration files, ML models, security certificates, etc.).

123 150 150 Applicationsmay provide O2 services that provide infrastructure management and/or network function deployment of resources in O-RAN cloud(also referred to herein as “O-Cloud”). O2 services may provide discovery and administration of O-Cloud resources; Scale-In, Scale-Out of cloud/deployments (e.g., deploying resources with more or less processors); FCAPS of cloud/deployments, software management of cloud platform/deployments; create/delete deployment and associated allocated O-Cloud resources.

123 154 122 123 123 123 123 123 123 Applicationsmay provide service management and exposure (SME) services, data management and exposure (DME) services, and/or other services. SME services may provide services that enable services provided over an internal interface (R1 interface) of non-RT RICand their exposure and extensibility through services including bootstrap, service registration/deregistration or updates to service registration, service discovery or notification, heartbeat, authentication, authorization, etc. Data management and exposure (DME) services may include services that manage data and their exposure between applications. For example, applicationsmay have different functions, such as applicationA configured to collect and analyze data, applicationB configured to generate an ML model based on the results of the analysis, and applicationN configured to make a prediction or inference using the ML model and/or to generate controls for RAN nodes based on the prediction or inference. DME services may manage the data shared between applications, such as the collection of data, the processing of the data, and/or the advertisement of the data.

122 122 158 160 162 163 155 122 123 Non-RT RICmay include one or more managers to process the A1, O1, O2, SME, DME services, and other services. For example, non-RT RICmay include a policy manager, O1 services manager, O2 services manager, service manager, and data manager. Non-RT RICmay include other managers, such as an application manager and an application on-boarder, that are configured to manage the installation and deployment of applications.

158 123 154 154 158 151 158 156 151 124 164 Policy manageris configured to control the deployment of policies (e.g., A1 services). For example, in response to receiving requests for A1 services from applicationsvia R1 interface, R1 interfacesends the requests to policy managervia message bus. Policy managermay process the A1 services and may send the A1 services to A1 terminationvia message bus, which provides the A1 services to near-RT RICvia A1 interface. In some examples, the A1 interface may implement an A1AP application protocol based on the O-RAN specifications.

160 124 146 148 124 123 154 154 160 151 160 168 124 166 O1 services manageris configured to control the deployment of O1 services for monitoring the performance of near-RT RICand/or RAN nodes (e.g., O-CU, O-DU). For example, in response to receiving requests for O1 services for monitoring the performance of near-RT RICfrom applicationsvia R1 interface, R1 interfacesends the requests to O1 services managervia message bus. O1 services managermay process the O1 services and may send the O1 services to O1 termination, which provides the O1 services to near-RT RICvia O1 interface. In some examples, the O1 interface may implement REST/HTTPS APIs and/or NETCONF.

160 124 124 123 154 154 160 160 168 124 166 O1 services manageris additionally, or alternatively, configured to control the deployment of O1 services for the configuration of near-RT RICand/or RAN nodes. For example, in response to receiving requests for O1 services for the configuration of near-RT RICfrom applicationsvia R1 interface, R1 interfacesends the requests to O1 services manager. O1 services managermay process the O1 services and may send the O1 services to O1 termination, which provides the O1 services to near-RT RICvia O1 interface.

162 150 150 150 154 154 162 162 169 150 167 O2 services managermay be configured to control the deployment of O2 services for monitoring the performance of resources of O-RAN Cloud(which may also be referred to herein as “O-Cloud). For example, in response to receiving requests for O2 services for monitoring the performance of resources within O-Cloudvia R1 interface, R1 interfacesends the request to O2 services manager. O2 services managermay process the O2 services and may send the O2 services to O2 termination, which provides the O2 services to resources of O-Cloudvia O2 interface.

162 150 150 123 154 154 162 162 169 150 167 O2 services managermay additionally, or alternatively, be configured to control the deployment of O2 services for the configuration of resources of O-Cloud. For example, in response to receiving requests for O2 services for configuring resources within O-Cloudfrom applicationsvia R1 interface, R1 interfacesends the requests to O2 services manager. O2 services managermay process the O2 services and may send the O2 services to O2 termination, which provides the O2 services to resources of O-Cloudvia O2 interface.

154 123 123 154 154 163 163 152 123 154 123 154 154 155 155 152 123 154 In some examples, R1 interfacealso exposes applicationsto SME services, DME services, and/or other services. For example, in response to receiving requests for SME services from applicationsvia R1 interface, R1 interfacesends the requests to service manager. Service managermay process the SME services (e.g., register/update a service) and may send the SME services to R1 termination, which provides the SME services to applicationsvia R1 interface(e.g., sending response to application regarding service registration, update, or discovery). Similarly, in response to receiving requests for DME services from applicationsvia R1 interface, R1 interfacesends the requests to data manager. Data managermay process the DME services and may send the DME services to R1 termination, which provides the DME services to applicationsvia R1 interface(e.g., sending data from application configured as a data producer to application configured as a data consumer).

154 123 123 R1 interfacemay also expose applicationsto slice subnet management services, such as RAN NSSMF interfaces to retrieve slice service level agreements (SLAs) and slice topologies, and/or slice management, SLA, and slice performance management notifications to applications.

121 123 125 121 123 125 109 Application scaling managermay manage scaling of applications, such as applicationsand/or applications. For example, application scaling managermay monitor operation of applicationsand/orand may determine that operation of a first instance of an application satisfies one or more criteria for scaling the application, the first instance of the application processing cluster messages generate by the RAN. The one or more criteria may include a threshold, such as a compute resource usage threshold, a number of cells or base stations managed by the first instance, a number or rate of messages sent from the RIC and handled by the first instance, a request or query from the first instance, an indication from the first instance of one or more virtual clusters, or other criteria. The criteria may be user configurable. The criteria may be specified in a policy. The criteria may be application specific, e.g., for different r/xApps.

123 125 121 121 121 2 FIG. In the following example, the criteria include a compute resource usage of an instance of an application satisfying (e.g., meeting or exceeding) a threshold. In response to determining that the compute resource usage of the first instance of the application (e.g., rAppA or xAppA) exceeds one or more thresholds, application scaling managermay determine a first virtual cluster and a second virtual cluster of the cluster. An example cluster, first virtual cluster, and second virtual cluster are described later herein with respect to. The first virtual cluster includes first one or more resources of the cluster and the second virtual cluster includes second one or more resources of the cluster that are different than each other. For example, the first one or more resources may not be a part of the second virtual cluster and the second one or more resources may not be a part of the first virtual cluster. Application scaling managermay instantiate a second instance of the application. Application scaling managermay route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application.

121 121 168 169 156 152 168 156 121 168 156 For example, application scaling managermay configure one or more microservices to route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. For example, application scaling managermay configure one or more microservices of O1 services manager, O2 services manager, O1 termination, O2 termination, A1 termination, and/or R1 terminationto route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. For example, O1 messages may include cell information identifying a RAN resource associated with the O1 message. A1 messages may include cell or group of cells information identifying RAN resources associated with the A1 message. By configuring microservices of O1 terminationand/or A1 termination, application scaling managermay affect the routing of cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. For example, microservices of O1 terminationand/or A1 terminationmay route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application based on the information within those cluster messages identifying the second one or more resources.

1 FIG.C 1 FIG.A 1 FIG.C 124 188 189 190 191 192 193 194 195 196 187 197 185 186 198 199 is a block diagram illustrating further example details of the near-RT RIC of. In the example illustrated in, near-RT RICincludes shared data layer, database, one or more AI/ML models, managers, xApp subscription manager, messaging infrastructure, application scaling manager, security, xApp repository, message bus, API enablement, and open interfaces, such as O1 termination, A1 termination, Y1 termination, and E2 termination.

124 146 148 199 124 125 125 125 125 1 FIG.C Near-RT RICcan provide near-real-time (e.g., milliseconds) control and optimization of RAN elements and resources, such as O-CUand/or O-DU, via fine-grained data collection and actions performed via E2 termination. For example, near-RT RICmay onboard one or more applications(e.g., xAppsA-N of, collectively, “xApps”) that provide near-real time control of RAN elements and their resources.

124 124 125 125 124 125 124 124 123 122 122 124 125 124 Near-RT RICmay be deployed as a highly scalable, microservices based containerized architecture. Near-RT RICmay onboard one or more applications, e.g., applications(e.g., xApps) that manage near-real time events within near-RT RIC. Applicationsmay leverage the functionality exposed via the near-RT RIC framework of near-RT RIC. Near-RT RICmay enforce policies received from applicationsof non-RT RICand may provide policy feedback to non-RT RIC. Although illustrated as within near-RT RIC, any one or more of applicationsmay be executed by a third party, separate from near-RT RIC.

188 189 124 189 189 188 189 124 125 188 125 189 188 Shared Data Layerand databaseenable near-RT RICto maintain and expose RAN/UE information and other information required to support specific use cases. In some examples, databasemaintains a list of UEs and associated data, and perform tracking and correlation of the UE identities associated with the connected E2 Nodes. In some examples, databasemaintains configurations and near real-time information relating to connected E2 Nodes and the mappings between them. In some examples, Shared Data Layerand database. Such information may be generated and accessed by near-RT RICor authorized xApps. Shared Data Layerprovides SDL services for xApps, which can be used to subscribe to database notifications and to read, write and modify information stored on database. Use-case specific information may be exposed using the services provided by Shared Data Layer.

191 191 124 191 191 Managersinclude OAM management, which provides fault, configuration, accounting, performance, file, security and other management plane services. Managersof near-RT RICprovide several capabilities to support OAM management services. For example, managersprovide fault management, including Near-RT RIC Fault Supervision MnS over the O1 interface. Further, managersprovide configuration management, including Near-RT RIC Provisioning MnS over the O1 interface.

191 124 In some examples, managersperform logging, tracing, and metrics collection functions. Logging is to capture information needed to operate, troubleshoot and report on the performance of near-RT RICand its constituent components. Log records may be viewed and consumed directly by users and systems, indexed and loaded into a data storage, and used to compute metrics and generate reports. Near-RT RIC components log events according to a common logging format. Different logs can be generated (e.g., audit log, metrics log, error log and debug log). Tracing mechanisms are used to monitor the transactions or a workflow. An example subscription workflow can be broken into two traces namely, a subscription request trace followed by a response trace. Individual traces can be analyzed to understand timing latencies as the workflow traverses a particular Near-RT RIC component. Metrics are collected and reported for performance and fault management specific to each xApp logic and other internal functionalities are collected and published for authorized consumer (e.g., SMO).

124 192 192 124 125 125 192 192 125 192 125 Near-RT RICincludes xApp subscription manager. xApp subscription managerenables near-RT RICto handle subscription requests from different xAppsfor, e.g., E2-related data, and provides unified data distribution to xAppsfor those data. xApp subscription manager, in some examples, manages subscriptions from xApps to E2 nodes. xApp subscription managermay enforce authorization of policies controlling xAppaccess to messages. Further, xApp subscription managerenables merging of identical subscriptions from different xAppsinto a single subscription toward an E2 Node.

193 124 193 193 193 193 193 193 193 193 193 193 199 125 193 193 Messaging infrastructureenables near-RT RICwith low-latency message delivery between Near-RT RIC internal endpoints. Messaging infrastructuresupports registration of endpoints, wherein endpoints register themselves to messaging infrastructure. Messaging infrastructurefurther supports discovery of endpoints, wherein endpoints are discovered by messaging infrastructureinitially and registered to messaging infrastructure. Messaging infrastructurealso supports deletion of endpoints, wherein endpoints are deleted once they are not used anymore. Messaging infrastructuremay provide an API for sending messages to messaging infrastructureand an API for receiving messages from messaging infrastructure. Messaging infrastructuresupports multiple messaging modes, e.g., point-to-point mode (e.g., message exchange among endpoints), publish/subscribe mode (e.g., real-time data dispatching from E2 terminationto multiple subscriber xApps). Messaging infrastructureprovides message routing, namely according to the message routing information, messages can be dispatched to different endpoints. Messaging infrastructuresupports message robustness to avoid data loss during a messaging infrastructure outage/restart or to release resources from the messaging infrastructure once a message is outdated.

124 195 195 125 Near-RT RICincludes security. Securityprevent malicious xAppsfrom abusing radio network information (e.g., exporting to unauthorized external systems) and/or control capabilities over RAN functions.

124 165 124 199 186 185 198 199 199 199 125 199 199 199 125 Near-RT RICmay communicate with E2 nodes via E2 interface. Near-RT RICincludes termination for various interfaces, including E2 termination, A1 termination, O1 termination, and Y1 termination. E2 terminationenables termination of an E2 interface. E2 terminationmay terminate an SCTP connection from each E2 Node. E2 terminationmay also route messages from xAppsthrough the SCTP connection to an E2 Node. E2 terminationmay further decode the payload of an incoming ASN.1 message enough to determine message type. In some examples, E2 terminationhandles incoming E2 messages related to E2 connectivity and receives and responds to an E2 Setup Request from an E2 Node. Furthermore, E2 terminationmay notify xAppsof a list of RAN functions supported by an E2 Node based on information derived from the E2 Setup and RIC Service Update procedures, and may notify the newly connected E2 Node of the list of accepted functions.

186 186 124 122 122 186 122 125 125 196 A1 terminationenables termination of the A1 interface. A1 terminationprovides a generic API by means of which Near-RT RICcan receive and send messages via an A1 interface. These include, e.g., A1 policies and enrichment information received from non-RT RIC, or A1 policy feedback sent towards non-RT RIC. A1 terminationmay further send an A1 policy that is set or updated by non-RT RICto suitable xApp(s)based on a list of candidate xAppsprovided by xApp repository.

185 124 112 166 124 124 112 124 124 124 124 124 O1 terminationenables termination of the O1 interface. Near-RT RICcommunicates with SMOvia O1 interfaceand exposes O1-related management services from near-RT RIC. For O1 management services (MnS), near-RT RICis an MnS producer and SMOis an MnS consumer. Near-RT RICexposes provisioning management services from near-RT RICto an O1 provisioning management service consumer, translates O1 management services to internal APIs of near-RT RIC, exposing FM services to report faults and events from near-RT RICto an O1 FM service consumer, exposes PM services to report bulk and real-time PM data from near-RT RICto an O1 PM service consumer, exposes file management services to download ML files, software files, etc. and upload log/trace files to/from file MnS consumer, and exposes communication surveillance services to the O1 communication surveillance service consumer.

198 198 124 Y1 terminationenables termination of the Y1 interface. Y1 terminationprovides support for exposing RAN analytics information from near-RT RICto Y1 consumers.

124 124 125 Near-RT RICmay include one or more managers to process the O1, A1, Y1, and E2 services, and other services. Near-RT RICmay include other managers, such as an application manager and an application on-boarder, that are configured to manage the installation and deployment of applications.

197 124 124 197 125 125 197 125 API enablementprovide APIs for near-RT RIC. The near-RT RIC APIs can be categorized based on the interaction with near-RT RICand can be related to E2-related services, A1-related services, management related services, and SDL services. This functionality provides support for registration, discovery and consumption of near-RT RIC APIs within the near-RT RIC scope. In particular, API enablementprovides services including repository and registry services for near-RT RIC APIs, services that allow discovery of the registered near-RT RIC APIs, services to authenticate xAppsfor use of the near-RT RIC APIs, services that enable generic subscription and event notification, and functionality to avoid compatibility clashes between xAppsand the services they access. In some examples, API enablementprovides API enablement services that are accessed by xAppsvia one or more enablement APIs.

190 124 125 125 190 125 190 125 AI/ML modelsenables near-RT RICwith data pipelining, model management, training and inference, which constitute complete AI/ML workflow support for xAppsto implement AI/ML algorithms. xAppsmay use none, part, or all of this functionality, depending on its design. In some examples, AI/ML modelsinclude data pipelining, which performs data ingestion and preparation for xApps. AI/ML modelsmay provide generic and use case-independent capabilities to AI/ML-based xAppsthat may be useful to multiple use cases. The input data for training may come from an xApp-specific space (e.g., dedicated space in database).

196 186 125 196 124 125 196 xApp repositorymaintaining a list of candidate xApp(s) to A1 terminationfor sending A1 policy or policy update to suitable xApp(s)based on policy type and operator policies. In addition, xApp repositorymaintains the policy types supported in near-RT RIC. The supported policy types are based on policy types supported by the registered xAppsand operator policies. Further, xApp repositoryperforms xApp access control to requested A1-EI type based on operator policies.

194 123 125 194 123 125 109 1 1 FIGS.A-B Application scaling managermay manage scaling of applications, such as applications() and/or applications. For example, application scaling managermay monitor operation of applicationsand/orand may determine that operation of a first instance of an application satisfies one or more criteria for scaling the application, the first instance of the application processing cluster messages generate by the RAN. The one or more criteria may include a threshold, such as a compute resource usage threshold, a number of cells or base stations managed by the first instance, a number or rate of messages sent from the RIC and handled by the first instance, a request or query from the first instance, an indication from the first instance of one or more virtual clusters, or other criteria. The criteria may be user configurable. The criteria may be specified in a policy. The criteria may be application specific, e.g., for different r/xApps.

123 125 194 194 194 2 FIG. In the following example, the criteria include a compute resource usage of an instance of an application satisfying (e.g., meeting or exceeding) a threshold. In response to determining that the compute resource usage of the first instance of the application (e.g., rAppA or xAppA) exceeds one or more thresholds, application scaling managermay determine a first virtual cluster and a second virtual cluster of the cluster. An example cluster, first virtual cluster, and second virtual cluster are described later herein with respect to. The first virtual cluster includes first one or more resources of the cluster and the second virtual cluster includes second one or more resources of the cluster that are different than each other. For example, the E2 nodes of the two virtual clusters are different. Application scaling managermay instantiate a second instance of the application. Application scaling managermay route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application.

194 194 185 186 199 199 185 186 199 194 185 186 199 For example, application scaling managermay configure one or more microservices to route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. For example, application scaling managermay configure one or more microservices of O1 termination, A1 termination, and/or E2 terminationto route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. For example, O1 messages may include cell information identifying a RAN resource associated with the O1 message. A1 messages may include cell or group of cells information identifying RAN resources associated with the A1 message. E2 terminationmay include a table that maps each cell or RAN resource to a particular instance of an application, for example, through the use of a Stream Control Transmission Protocol (SCTP) port. By configuring microservices of O1 termination, A1 termination, and/or E2 termination, application scaling managermay affect the routing of cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application. For example, microservices of O1 terminationand/or A1 terminationmay route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application based on the information within those cluster messages identifying the second one or more resources. For example, microservices of E2 terminationmay alter the table to map the second one or more resources of the second virtual cluster to the second instance of the application.

2 FIG. 1 FIGS.A 200 122 124 109 109 200 200 220 220 122 124 220 230 230 230 230 123 125 is a conceptual diagram illustrating an example cluster and two virtual clusters according to one or more aspects of this disclosure. Clustermay be a cluster of network elements managed or controlled by non-RT RICand/or near-RT RIC. For example, RANmay be divided into a plurality of clusters for management purposes as the number of elements and UEs in RANmay be greater than a single non-RT RIC and/or near-RT RIC may be able to manage. Clustermay be an example of one of the plurality of clusters. Clustermay send and/or receive cluster messages to/from RIC. RICmay be an example of non-RT RICand/or near-RT RICof-IC. RICmay route cluster messages to/from first instanceA and/or second instanceB. First instanceA and second instanceB may represent example instances of any of applicationsand/or.

200 210 210 212 212 214 214 216 216 For example, clustermay include geographically neighboring elements, such as cell towersA-K, RUA-RUB, CUA-CUB, and/or DUA-DUB.

220 200 230 230 200 200 220 200 2 FIG. It should be noted that a cluster may include any number of elements of any type. In some examples, RICmay determine to split clusterinto a plurality (e.g., two) of virtual clusters for a particular application (e.g., an application of which first instanceA and second instanceB are instances), such as an rApp or an xApp, when one or more criteria for scaling the application are satisfied. While two virtual clustersA andB are shown in the example of, it should be understood that RICmay split clusterinto two virtual clusters or more than two virtual clusters.

220 220 220 220 220 220 220 220 230 220 230 230 In an example, a criteria for scaling the application may be satisfied when the compute usage of the rApp or xApp becomes too great. For example, RICmay monitor the compute usage of the application over time. The compute usage may include CPU utilization (such as MIPS or percentage of CPU utilization by the application), memory utilization (such as gigabits or terabits used or a percentage of system memory used), network utilization (such as bandwidth or percentage of available bandwidth used), and/or the like. RICmay compare the compute utilization of the application to one or more thresholds. Based on the compute utilization of the application meeting or exceeding one or more of the one or more thresholds, RICmay determine that the application is a candidate for a new instance. In some examples, there may be a threshold for each modality of compute usage monitored by RIC. For example, there may be a first threshold for CPU utilization, a second threshold for memory utilization, and a third threshold for network utilization. In one example, RICmay determine the application is a candidate for a new instance based on determining that one of the thresholds is exceeded (or met or exceeded). In another example, RICmay determine the application is a candidate for a new instance based on more than on threshold being exceeded (or met or exceeded). In some examples, the one or more thresholds are programmable. If RICdoes determine that an application is a candidate for a new instance, RICmay instantiate a new instance of the application. For example, prior to instantiating second instanceB, RICmay determine that operation of first instanceA satisfies one or more criteria for scaling an application and, in response to this determination, instantiate second instanceB.

230 200 230 220 200 200 200 220 200 200 200 200 200 200 While instantiating a new instance of an application (e.g., second instanceB) for clustermay be beneficial and avoid overloading an existing instance of the application (e.g., first instanceA), doing so and dividing the tasks between the existing instance and the new instance may result in inefficiencies if performed, for example, in real-time. As such, RICmay determine to split clusterinto first virtual clusterA and second virtual clusterB for the application. While RICmay split clusterinto first virtual clusterA and second virtual clusterB for the application, clustermay remain as a single cluster or not be split into first virtual clusterA and second virtual clusterB for other applications.

123 125 220 200 200 200 If in the future, another application, such as a second application of applicationsor application, exceeds one or more of the one or more compute usage thresholds, RICmay determine to split clusterinto a plurality of virtual clusters for that application. In some examples, the split may be the same as for the first application (e.g., virtual clusterA and virtual clusterB). In other examples, the split may be different for the second application than for the first application.

230 230 220 200 200 200 240 200 240 200 200 240 200 240 200 240 200 200 200 200 For the first application (e.g., represented by first instanceA and second instanceB), RICmay determine to split clusterinto virtual clusterA and virtual clusterB along geographic boundary, such that elements of clusterthat are west of geographic boundaryare part of virtual clusterA and elements of clusterthat are cast of geographic boundaryare part of virtual clusterB. Geographic boundaryis merely an example and may be any geographic boundary or boundaries that splits clusterinto a plurality of virtual clusters. RIC determines geographic boundarysuch that elements within virtual clusterA are geographically contiguous and elements within virtual clusterB are geographically contiguous. In other words, virtual clusterA includes a neighborhood of geographically neighboring elements and virtual clusterB includes a separate neighborhood of geographically neighboring elements. It should be noted that geographically contiguous as used herein does not require the elements themselves to physically be in contact with each other, rather it is intended to mean that there are not geographically intervening elements of a different virtual cluster between geographically neighboring elements.

3 FIG. 3 FIG. 1 FIG. 2 FIG. 1 1 FIGS.A andB 1 FIG.C 300 122 124 220 332 230 332 230 310 121 194 is a diagram illustrating an example computing system in accordance with techniques of this disclosure. In the example of, computing systemmay implement non-RT RIC, near-RT RICof, and/or RICof. First instanceA may be an example of first instanceA, second instanceB may be an example of second instanceB, and application scaling managermay be an example of application scaling managerofand/or of application scaling managerof.

300 320 322 323 319 321 300 300 Computing systemincludes one or more processors, one or more input devices, one or more output devices, one or more communication units, and one or more storage devices. In some examples, computing systemis a cloud computing system, server farm, and/or server cluster (or portion thereof) that provides services to client devices and other devices or systems. In other examples, computing systemmay be implemented through one or more virtualized compute instances (e.g., virtual machines, containers) of a data center, cloud computing system, server farm, and/or server cluster.

300 One or more of the devices, modules, storage areas, or other components of computing systemmay be interconnected to enable inter-component communications (physically, communicatively, and/or operatively). In some examples, such connectivity may be provided by communication channels, a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data.

320 300 320 320 300 320 300 123 125 One or more processorsof computing systemmay implement functionality and/or execute instructions associated with application scaling as described herein. One or more processorsmay be, may be part of, and/or may include processing circuitry that performs operations in accordance with one or more aspects of the present disclosure. Examples of processorsinclude microprocessors, application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configured to function as a processor, a processing unit, or a processing device. Computing systemmay use one or more processorsto perform operations in accordance with one or more aspects of the present disclosure using software, hardware, firmware, or a mixture of hard ware, software, and firmware residing in and/or executing at computing system. In some examples, any one or more of applications/may be hosted by a cloud provider or other third-party.

319 300 300 319 319 319 300 319 319 One or more communication unitsof computing systemmay communicate with devices external to computing systemby transmitting and/or receiving data, and may operate, in some respects, as both an input device and an output device. In some examples, communication unitsmay communicate with other devices over a network. In other examples, communication unitsmay send and/or receive radio signals on a radio network such as a cellular radio network. In other examples, communication unitsof computing systemmay transmit and/or receive satellite signals on a satellite network such as a Global Positioning System (GPS) network. Examples of communication unitsinclude a network interface card (e.g., an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and/or receive information. Other examples of communication unitsmay include devices capable of communicating over Bluetooth®, GPS, NFC, ZigBee, and cellular networks (e.g., 3G, 4G, 5G), and Wi-Fi® radios found in mobile devices as well as Universal Serial Bus (USB) controllers and the like. Such communications may adhere to, implement, or abide by appropriate protocols, including Transmission Control Protocol/Internet Protocol (TCP/IP), Ethernet, Bluetooth, NFC, or other technologies or protocols.

322 300 322 322 One or more input devicesmay represent any input devices of computing systemnot otherwise separately described herein. One or more input devicesmay generate, receive, and/or process input from any type of device capable of detecting input from a human or machine. For example, one or more input devicesmay generate, receive, and/or process input in the form of electrical, physical, audio, image, and/or visual input (e.g., peripheral device, keyboard, microphone, camera).

323 300 323 323 One or more output devicesmay represent any output devices of computing systemnot otherwise separately described herein. One or more output devicesmay generate, receive, and/or process input from any type of device capable of detecting input from a human or machine. For example, one or more output devicesmay generate, receive, and/or process output in the form of electrical and/or physical output (e.g., peripheral device, actuator).

321 300 300 321 320 321 320 321 320 321 320 321 300 300 One or more storage deviceswithin computing systemmay store information for processing during operation of computing system. Storage devicesmay store program instructions and/or data associated with one or more of the modules described in accordance with one or more aspects of this disclosure. One or more processorsand one or more storage devicesmay provide an operating environment or platform for such modules, which may be implemented as software, but may in some examples include any combination of hardware, firmware, and software. One or more processorsmay execute instructions and one or more storage devicesmay store instructions and/or data of one or more modules. The combination of processorsand storage devicesmay retrieve, store, and/or execute the instructions and/or data of one or more applications, modules, or software. Processorsand/or storage devicesmay also be operably coupled to one or more other software and/or hardware components, including, but not limited to, one or more of the components of computing systemand/or one or more devices or systems illustrated as being connected to computing system.

321 321 300 321 321 321 In some examples, one or more storage devicesare temporary memories, meaning that a primary purpose of the one or more storage devices is not long-term storage. Storage devicesof computing systemmay be configured for short-term storage of information as volatile memory and therefore not retain stored contents if deactivated. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art. Storage devices, in some examples, also include one or more computer-readable storage media. Storage devicesmay be configured to store larger amounts of information than volatile memory. Storage devicesmay further be configured for long-term storage of information as non-volatile memory space and retain information after activate/off cycles. Examples of non-volatile memories include magnetic hard disks, optical discs, Flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

300 123 125 122 124 1 FIGS.A Computing systemmay include one or more modules or units configured to perform one or more services or functions of applications/or any of the functions of non-RT RICor near-RT RIC, as described above and shown with respect to-IC.

300 310 310 300 310 123 125 332 300 122 300 310 123 300 124 300 310 125 300 310 332 334 1 1 FIGS.A andB 1 1 FIGS.A andC Computing systemmay include application scaling manager. Application scaling managermay be configured to perform the application scaling techniques described herein. For example, computing systemmay provide scaling management via application scaling managerfor the applications/, such as r/xApp, which in some examples represents an rApp, and in other examples represents an xApp. For example, when computing systemrepresents non-RT RIC, computing systemvia application scaling managermay provide scaling management for rApps such as applicationsof. In the example when computing systemrepresents near-RT RIC, computing systemvia application scaling managermay provide scaling management for xApps such as applicationsof. Although shown as executing on the same computing systemas application scaling manager, r/xApps,may execute on different computing systems.

310 312 310 312 310 312 310 314 316 314 314 310 300 1 1 FIGS.A-C Application scaling managermay include one or more scaling criteriawith which application scaling managermay determine whether or not to scale a given application or the instance of the application. For example, when one or more scaling criteriainclude compute resource threshold(s), application scaling managermay compare compute resource usage of an instance of an application to the compute resource threshold(s) of one or more scaling criteriato determine whether or not to scale the given application or the instance of the application. Application scaling managermay also implement microservicesfor routing cluster messagesto an appropriate virtual cluster or cluster when scaling an instance of an application or an application. In some examples, microservicesmay include A1, O1, O2, and/or E2 microservices, such as those described above with respect to. It should be noted that in some examples, microservicesmay be implemented outside of application scaling manager, such as in one or more other modules or units of computing system. In addition, although referred to being performed by microservices, the techniques are applicable to other deployable computing units, such as virtual machines, bare metal processes, or other modules or services.

310 300 109 300 109 109 200 300 321 In some examples, application scaling managermay determine or characterize the compute resource usage of an instance of an application as more cells are added to and/or deleted from a cluster or a virtual cluster. Computing systemmay keep track of a network inventory of network elements, such as the elements of RAN, using, for example, optional information like dynamic neighbor discovery (via automatic neighbor relation (ANR)) and base station GPS coordinates from provisioning data. As such, computing systemmay have the information regarding the geographic layout of the elements of RAN, and may thus split RANinto clusters or split clusters (like cluster) into virtual clusters in a manner that maintains geographic continuity for the clusters or virtual clusters. Computing systemmay store this network inventory in memory, such as storage device(s).

310 310 142 190 1 FIG.B 1 FIG.C As application scaling managerdetermines to scale up a particular application, application scaling managermay split the network into virtual clusters, using the information from the network inventory, for example, to keep the virtual clusters geographically contiguous (e.g., the resources or elements of a given virtual cluster neighboring). In some examples, the information used to determine the split may be learned via an artificial intelligence model or machine learning model (e.g., of AI/ML modelsofand/or AI/ML modelsof) over time or may be entered manually by an operator to align such splitting with the operator's network planning.

310 310 310 For example, to scale up an application, application scaling managermay automatically instantiate a new instance of the application. Any operation to cause a new instance of the application is considered instantiating the new instance of the application. For example, application scaling managermay load and execute a new instance on a compute node, request that an existing instance of the application scale up to create a new instance of the application, receive a request to scale from an existing instance of the application, and/or perform another operation to instantiate the new instance of the application. Application scaling managermay assign a particular virtual cluster to that new instance of the application. The RIC platform may then start routing incoming and outgoing A1/O1/O2/E2 messages from elements or resources (e.g., the set of cells) in that virtual cluster to the newly launched application instance.

310 310 310 For example, if a particular cluster includes 200 cells, application scaling managermay add an instance of the application and split the cluster into a first virtual cluster of 100 cells and a second virtual cluster of 100 cells for that application. Thus, when a new instance of an application is instantiated, application scaling manageradjusts the other instance to reduce the usage of that instance by routing incoming and outgoing A1/O1/O2/E2 messages associated with a second virtual cluster to the new instance of the application. Application scaling managercontinues to route a remainder of the incoming and outgoing A1/O1/O2/E2 messages associated with the first virtual cluster to the existing instance of the application. Each of the first virtual cluster and the second virtual cluster may be geographically contiguous. In other words, the resources or elements of the first virtual cluster form a first neighborhood and the resources or elements of the second virtual cluster form a second neighborhood where there are no geographically intervening resources of one cluster in the neighborhood of another cluster.

310 332 312 332 332 109 332 312 310 200 200 109 200 200 310 332 310 316 300 316 200 200 310 200 332 200 332 332 332 332 According to the techniques of this disclosure, application scaling managermay determine that operation of a first instance (e.g., r/xAppA) of an application satisfies one or more scaling criteriafor scaling application. First instance (e.g., r/xAppA) of the application may process cluster messages generated by RAN. In response to determining that the operation of first instance (e.g., r/xAppA) of the application satisfies the one or more scaling criteria, application scaling managermay determine a first virtual cluster (e.g., first virtual clusterA) and a second virtual cluster (e.g., second virtual clusterB) of RAN. The first virtual cluster (e.g., first virtual clusterA) includes first one or more resources of the cluster and the second virtual cluster (e.g., second virtual clusterB) includes second one or more resources of the cluster that are different than each other. For example, the E2 nodes of the two virtual clusters are different. Application scaling managermay instantiate a second instance (e.g., r/xAppB) of the application. Application scaling managermay route cluster messages (e.g., cluster messages) from the second one or more resources of the second virtual cluster to the second instance of the application. For example, computing systemmay receive cluster messagesfrom both first virtual clusterA and second virtual clusterB in parallel. Application scaling managermay route cluster messages from virtual clusterA to first instanceA, and cluster messages from virtual clusterB to second instanceB. It should be noted that first instanceA and second instanceB may be executing in parallel (e.g., both are executing at a same time after the instantiation of second instanceB).

310 310 332 310 332 It should be understood that application scaling managermay continue to monitor the compute usage of both the first instance of the application and the second instance of the application. If the compute usage of either instance of the application later exceeds the one or more thresholds, application scaling managermay repeat this process, determining further virtual clusters from the first or second virtual cluster, and may instantiate a new instance (e.g., r/xAppN) of the application to handle messages from, and interact with, the new virtual cluster. Application scaling managermay continue thereafter, determining new virtual clusters and instantiating new instances of r/xAppas needed to handle messages from, and interact with, any further new virtual clusters.

310 310 332 310 332 310 Application scaling managermay also monitor operation of instances of applications to determine if the application satisfies one or more criteria for scaling the application downward, such as terminating one or more instance of an application. For example, application scaling managermay compare compute usage for instances of applicationto determine if compute usage falls below (or below or equal to) one or more second thresholds. If compute usage falls below (or below or equal to) one or more second thresholds, application scaling managermay determine to scale down the application by terminating an instance of application, tearing down the virtual cluster associated with that instance of the application, and routing messages from that virtual cluster to another instance of the application. In some examples, application scaling managermay take into account compute usage of the other instance of the application prior to taking such actions.

310 Some r/Apps and/or x/Apps may not be designed with inherent scaling features. Such applications may be referred to herein as non-scalable applications. While such applications may be scalable with external management, such applications may not be capable of determining that there may be a desire or need to scale the application. Other r/Apps and/or x/Apps may be designed with inherent scaling features. Such applications may be referred to herein as scalable applications. Such applications may be capable of determining that there may be a desire or need to scale the application. This disclosure describes techniques that applications scaling managermay employ when managing scaling of non-scalable applications and scalable applications.

4 FIG. 400 122 124 300 402 123 125 400 310 is a flow diagram of example application scaling techniques for non-scalable applications according to one or more aspects of this disclosure. RICmay be an example of non-RT RIC, near-RT RIC, and/or computing system. r/xAppmay be an example of any of applicationsand/or applications. The actions of RICmay be performed by any of, or any combination of, the modules or units described herein, including application scaling manager.

400 410 400 400 400 400 109 400 RICmay keep track of node and cell inventory and neighborhoods (). For example, RICmay monitor nodes and cells that may be managed by RICand may store mappings of nodes and cells into clusters. RICmay store geographic positioning data associated with cells and/or base stations. Such data may be used by RICto determine neighborhoods or geographically continuous clusters (or virtual versions thereof) of cells and/or base stations within the portion or cluster of RANmanaged by RIC.

400 420 400 RICmay monitor the operation of instances of applications (). For example, RICmay monitor operational parameters of each instance of each application to determine when it may be desirable to scale a particular application. Such operational parameters may be indicative of a desire or need to scale an application. In some examples, operational parameters may include CPU usage, memory usage, and/or the like.

400 422 400 312 312 400 402 400 RICmay characterize the operation of the instances of the applications (). For example, RICmay determine whether operation of an instance of an application satisfies one or more scaling criteriafor scaling the application. In an example where one or more scaling criteriaincludes a compute utilization threshold, RICmay compare the compute utilization of each instance of an application, or the application as a whole (e.g., r/xApp), to one or more thresholds to determine whether a new instance of an application should be instantiated. In such an example, the one or more thresholds may be variable, based on the overall usage of the compute resources of the platform and/or based on available remaining resources (e.g., currently unused or currently unassigned resources) of the platform (e.g., RIC).

400 424 400 400 200 200 200 RICmay determine one or more clusters to which to perform offloading operations (). For example, RICmay determine two (or more) virtual clusters based on an existing cluster. For example, RICmay split clusterinto two (or more) virtual clusters, assigning a first plurality of neighboring cells and/or base station(s) to first virtual clusterA and a second plurality of neighboring cells and/or base station(s) to second virtual clusterB.

400 426 400 402 402 402 402 200 402 200 200 RICmay instantiate a new instance of the application (). For example, RICmay instantiate a new instance of r/xAppto reduce resource utilization by an existing instance of r/xApp. For example, existing instance of r/xAppmay be responsible for handling the cluster that is being split. The new instance of r/xAppmay be instantiated to handle second virtual clusterB and the existing instance of r/xAppmay be relieved of handling second virtual clusterB and may, at least for the near term, be responsible for only handling first virtual clusterA.

402 400 428 402 402 400 400 The new instance of r/xAppmay begin a startup process and may register with RIC(). In the example where r/xApprepresents an rApp, r/xAppmay attempt to obtain a list of cells (and/or other resources) from RICthat the new instance of the rApp is to manage. In such cases, in some examples, RICmay provide such information to the new instance of the application.

400 316 402 430 200 RICmay configure A1/O1/O2/E2 RIC microservices to route new cluster messages (e.g., of cluster messages) for the first virtual cluster to new instance of r/xApp(). In this manner, any new messages for second virtual clusterB will be routed to/from the new application instance rather than the existing application instance, thus reducing the burden on, and compute resource usage of, the existing application instance.

400 402 432 402 In some examples, RICmay notify the new instance of r/xAppof the cluster topology of the second virtual cluster (). This may be desirable when r/xAppis an rApp and attempts to acquire a list of cells for which the new instance is handling.

In some examples, an application may be configured with scalability capabilities (e.g., a scalable application). In such cases, the application may still require certain notifications and information from the RIC platform in order to determine when to scale. For example, the application may use notifications from the RIC platform that there may be an overload (or underload) condition with the application and the application needs to scale up (or down). As such, there may be a need for APIs for applications to query the RIC to determine which virtual cluster a new instance of the application should operate on. There may be a need for APIs for applications to notify and/or register with the RIC platform which virtual cluster the new instance of the application will operate on. There may be a need for APIs for applications to trigger instantiation of a new instance of itself with a particular virtual cluster. This may be needed because in many instances, an application will not have permissions necessary to self-instantiate a new instance within the O-RAN network. For example, APIs may be needed for an application to request or query permission to instantiate a new instance and for the application to receive notifications from the RIC platform of permission to instantiate a new instance of the application.

5 FIG. 500 122 12 300 502 123 125 500 310 is a flow diagram of example application scaling techniques for scalable applications according to one or more aspects of this disclosure. RICmay be an example of non-RT RIC, near-RT RIC, and/or computing system. r/xAppmay be an example of any of applicationsand/or applications. The actions of RICmay be performed by any of, or any combination of, the modules or units described herein, including application scaling manager.

500 510 500 500 500 500 109 500 RICmay keep track of node and cell inventory and neighborhoods (). For example, RICmay monitor nodes and cells that may be managed by RICand may store mappings of nodes and cells into clusters. RICmay store geographic positioning data associated with cells and/or base stations. Such data may be used by RICto determine neighborhoods or geographically contiguous clusters (or virtual versions thereof) of cells and/or base stations within the portion or cluster of RANmanaged by RIC.

500 520 500 RICmay monitor the operation of instances of applications (). For example, RICmay monitor operational parameters of each instance of each application to determine when it may be desirable to scale a particular application. Such operational parameters may be indicative of a desire or need to scale an application. In some examples, operational parameters may include CPU usage, memory usage, and/or the like.

500 522 500 312 312 500 502 500 RICmay characterize the operation of the instances of the applications (). For example, RICmay determine whether operation of an instance of an application satisfies one or more scaling criteriafor scaling the application. In an example where one or more scaling criteriaincludes a compute utilization threshold, RICmay compare the compute utilization of each instance of an application, or the application as a whole (e.g., r/xApp), to one or more thresholds to determine whether a new instance of an application should be instantiated. In such an example, the one or more thresholds may be variable, based on the overall usage of the compute resources of the platform and/or based on available remaining resources (e.g., currently unused or currently unassigned resources) of the platform (e.g., RIC).

500 502 500 502 530 500 502 502 500 502 500 502 500 502 500 502 500 502 RICmay determine to instantiate a new instance of r/xApp. In such a case, RICmay send a notification to r/xApp, such as an application overload notification (). For example, RICmay inform r/xAppthat a new instance of r/xAppis to be instantiated. In some examples, RICmay inform r/xAppwhether RICwill determine the virtual clusters or whether r/xAppwill determine the virtual clusters. In some examples, RICand r/xAppmay negotiate whether RICwill generate the virtual clusters or whether r/xAppwill generate the virtual clusters. In some examples, whether RICwill generate the virtual clusters or whether r/xAppwill generate the virtual clusters is predetermined.

500 502 502 502 502 502 502 500 502 500 502 In some examples, rather than RICdetermining to instantiate a new instance of r/xApp, r/xAppitself may determine to instantiate a new instantiate a new instance of r/xApp. For example, r/xAppmay determine that one or more existing instance of r/xAppare overloaded. In such a case, r/xAppmay send a notification to RIC, such as an application overload notification. For example, r/xAppmay inform RICto that a new instance of r/xAppis to be instantiated.

500 500 502 540 544 550 552 502 500 502 550 52 540 544 5 FIG. 5 FIG. In the event that RICgenerates the virtual clusters, RICand r/xAppmay perform steps-set forth inand bypass steps-. In the event that r/xAppgenerates the virtual clusters, RICand r/xAppmay perform steps-set forth inand bypass steps-.

500 502 502 540 502 500 200 200 502 502 500 502 530 502 For example, if RICgenerates the virtual clusters the following may occur. r/xAppmay query regarding the potential virtual clusters for r/xApp(). For example, r/xAppmay request from RICan identification of potential virtual clusters, such as first virtual clusterA and/or second virtual clusterB. In the example where r/xApprepresents an rApp, r/xAppmay attempt to obtain a list of cells (and/or other resources) from RICthat the new instance of the rApp is to manage. In some examples where r/xAppsends the notification in step, that notification may be combined with or part of the query regarding potential virtual clusters for r/xApp.

500 502 542 500 200 500 200 200 200 RICmay determine virtual clusters for r/xApp(). For example, RICmay determine two (or more) virtual clusters based on an existing cluster (e.g., cluster). For example, RICmay split an existing cluster (e.g., cluster) into two (or more) virtual clusters, assigning a first plurality of neighboring cells and/or base station(s) to a first virtual cluster (e.g., virtual clusterA) and a second plurality of neighboring cells and/or base station(s) to a second virtual cluster (e.g., virtual clusterB).

500 502 544 500 502 200 200 RICmay notify r/xAppof the potential virtual clusters (). For example, RICmay send a message to r/xAppidentifying first virtual clusterA and/or second virtual clusterB. Such an identification may include identifiers of specific assets, such as cells and/or base stations as being associated with one or more particular virtual clusters and/or geographical identifiers associated with one or more particular virtual clusters.

502 502 500 550 502 502 200 502 500 200 200 502 530 If r/xAppgenerates the virtual clusters, the following may occur. r/xAppmay send a notification to RICof the virtual clusters for the application (). For example, r/xAppmay determine virtual clusters based on information available to r/xApp, such as a geographic location information of resources of a cluster (e.g., cluster) being split into virtual clusters. For example, r/xAppmay send a message to RICidentifying first virtual clusterA and/or second virtual clusterB. Such an identification may include identifiers of specific assets, such as cells and/or base stations as being associated with one or more particular virtual clusters and/or geographical identifiers associated with one or more particular virtual clusters. In some examples where r/xAppsends the notification in step, that notification may be combined with or part of the notification of the virtual clusters for the application.

500 502 552 550 500 502 500 542 544 RICmay send an acknowledgement (ACK) or negative acknowledgement (NACK) to r/xApp() in response to the notification. In the case that RICsends a NACK, r/xAppmay repeat the generation of the virtual clusters so as to generate different virtual clusters than before, or, alternatively, RICmay generate the virtual clusters to be used (see steps-).

500 502 500 560 500 502 502 502 200 502 200 502 200 200 The following may be performed regardless of whether RICor r/xAppgenerates the virtual clusters. RICmay instantiate a new instance of the application (). For example, RICmay instantiate a new instance of r/xAppto reduce resource utilization by an existing instance of r/xApp. For example, existing instance of r/xAppmay be responsible for handling clusterthat is being split. The new instance of r/xAppmay be instantiated to handle second virtual clusterB and the existing instance of r/xAppmay be relieved of handling second virtual clusterB and may, at least for the near term, be responsible for handling only first virtual clusterA.

502 500 662 500 316 502 664 500 168 169 156 152 1 FIG.B The new instance of r/xAppmay begin a startup process and may register with RIC(). RICmay configure A1/O1/O2/E2 RIC microservices to route new cluster messages (e.g., of cluster messages) for the second virtual cluster to new instance of r/xApp(). For example, RICmay configure one or more microservices of O1 services manager, O2 services manager, O1 termination, O2 termination, A1 termination, and/or R1 termination(of) to route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application.

200 In this manner, any new messages for second virtual clusterB will be routed to/from the new application instance rather than the existing application instance, thus reducing the burden on, and compute resource usage of, the existing application instance.

500 502 666 500 502 568 In some examples, RICmay notify the existing instance of r/xAppof the cluster topology of the first virtual cluster (). In some examples, RICmay notify the new instance of r/xAppof the cluster topology of the second virtual cluster ().

6 FIG. 6 FIG. 300 is a flow diagram illustrating example scaling techniques for applications according to one or more aspects of this disclosure. The techniques ofare described with respect to computing system, but may be performed by any computing system capable of performing such techniques.

300 600 300 332 332 332 312 332 300 332 332 332 332 200 300 332 332 Computing systemmay determine that operation of a first instance of an application satisfies one or more criteria for scaling the application (). The first instance of the application may process cluster messages generated by the RAN. For example, computing systemmay monitor the operation of first instanceA of applicationto determine that first instanceA satisfies one or more scaling criteriafor scaling application. In the example where the one or more criteria include a compute usage threshold, computing systemmay monitor a compute resource usage of first instanceA of applicationand compare compute resource usage to one or more thresholds. First instanceA of applicationmay be associated with cluster. Based on the comparison of the compute resource usage to the one or more thresholds, computing systemmay determine that the compute resource usage of first instanceA of applicationexceeds the one or more thresholds.

300 602 300 200 200 200 200 200 200 200 In response to determining that the operation of the first instance of the application satisfies the one or more criteria, computing systemmay determine a first virtual cluster and a second virtual cluster of the RAN (). For example, computing systemmay determine first virtual clusterA and second virtual clusterB of cluster. First virtual clusterA includes first one or more resources of clusterand second virtual clusterB includes second one or more resources of cluster, and the first one or more resources and the second one or more resources are different.

300 604 300 332 332 Computing systemmay instantiate a second instance of the application (). For example, computing systemmay instantiate second instanceB of application.

300 606 300 314 316 200 332 332 Computing systemmay route cluster messages from the second one or more resources of the second virtual cluster to the second instance of the application (). For example, computing systemmay configure one or more microservices of microservice(s)to route cluster messagesfrom the resources of second virtual clusterB to second instanceB of application.

300 332 332 332 332 In some examples, computing systemmay monitor compute resource usage of first instanceA of application, and wherein the compute resource usage of first instanceA of applicationincludes at least one of microprocessor usage, memory usage, or network usage. In such examples, the one or more criteria may include a compute resource usage threshold met or exceeded by the compute resource usage of the first instance of the application.

300 321 200 In some examples, memory of computing system(e.g., storage device(s)) stores information indicative of geographic location information of resources of the RAN (e.g., of clusterof the RAN). In some examples, the first one or more resources are geographically contiguous and the second one or more resources are geographically contiguous. For example, the first one or more resources are neighboring each other in a first geographic neighborhood and the second one or more resources are neighboring each other in a second geographic neighborhood.

300 332 332 200 332 332 300 332 300 332 332 200 200 200 332 332 332 300 332 332 332 332 In some examples, computing systemmay receive a registration notification from second instanceB of application. In some examples, to route the cluster messages from the second one or more resources of second virtual clusterB to second instanceB of application, computing systemmay route the cluster messages to second instanceB based on the registration notification. In some examples, computing systemmay send a message to second instanceB of applicationindicative of second virtual clusterB. For example, the message may be indicative of the identity of the second one or more resources of second virtual clusterB and/or geographic location information of the second one or more resources of second virtual clusterB. Such information may be of use to second instanceB when determining future virtual clusters if second instanceB is an instance of a scalable application and second instanceB later satisfies the one or more criteria for scaling. In some examples, computing systemmay send a notification to first instanceA of applicationindicative of the resource usage of first instanceA of applicationsatisfying the one or more criteria.

300 332 332 332 300 200 200 200 300 332 332 In some examples, computing systemmay receive, from first instanceA of application, a query for virtual clusters for application, wherein the one or more criteria comprises the query. Computing systemmay split, in response to the query, clusterof the RAN into a plurality of virtual clusters, the plurality of virtual clusters including first virtual clusterA and second virtual clusterB. Computing systemmay send, to first instanceA of application, an indication of the plurality of virtual clusters.

300 332 332 200 200 300 332 332 300 200 200 316 In some examples, computing systemmay receive, from first instanceA of application, an indication of at least one of first virtual clusterA or second virtual clusterB, wherein the one or more criteria comprises the indication. Computing systemmay send, to first instanceA of application, an acknowledgement of the indication. In some examples, computing systemmay determine first virtual clusterA and second virtual clusterB based on the indication. In some examples, cluster messagesconform to at least one of an O1 interface, an O2 interface, an A1 interface, or an E2 interface.

200 200 200 In some examples, first virtual clusterA and second virtual clusterB are virtual clusters of a first cluster (e.g., cluster) of a plurality of clusters of the RAN. In some examples, the first cluster includes the first one or more resources and the second one or more resources.

The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more programmable processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure.

Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components or integrated within common or separate hardware or software components.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a compact disc read only memory (CD-ROM), a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. The term “computer-readable storage media” refers to physical storage media, and not signals, carrier waves, or other transient media.