Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments of the invention provide a method for cloning a set of one or more applications implemented by a first set of machines connected through a first logical network that defines a virtual private cloud in a set of one or more datacenters. The method instantiates a cloned, second set of machines that is a replicated copy of the first set of machines. The method identifies a set of network configuration data that configures a set of logical forwarding elements (LFEs) of the first logical network. The method uses the identified set of network configuration data to define a cloned, second logical network to connect the cloned, second set of machines.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments of the invention provide a method for cloning a set of one or more applications implemented by a first set of machines connected through a first logical network that defines a virtual private cloud in a set of one or more datacenters. The method instantiates a cloned, second set of machines that is a replicated copy of the first set of machines. The method identifies a set of network configuration data that configures a set of logical forwarding elements (LFEs) of the first logical network. The method uses the identified set of network configuration data to define a cloned, second logical network to connect the cloned, second set of machines.

Abstract: Some embodiments of the invention provide a method for cloning a set of one or more applications implemented by a first set of machines connected through a first logical network that defines a virtual private cloud (VPC) in a set of one or more datacenters. The method detects that the first logical network does not have sufficient resources to process a set of network traffic destined for the set of one or more applications implemented by the first set of machines. Based on said detecting, the method uses a set of network configuration data that configures a set of logical forwarding elements (LFEs) of the first logical network to define a cloned, second logical network for connecting a cloned, second set of machines that implement a second set of one or more applications. The method uses the cloned, second logical network to process at least a subset of the network traffic destined to the set of applications.

Abstract: Some embodiments of the invention provide a method for cloning a set of one or more applications implemented by a first set of machines connected through a first logical network that defines a virtual private cloud (VPC) in a set of one or more datacenters. The method detects that the first logical network does not have sufficient resources to process a set of network traffic destined for the set of one or more applications implemented by the first set of machines. Based on said detecting, the method uses a set of network configuration data that configures a set of logical forwarding elements (LFEs) of the first logical network to define a cloned, second logical network for connecting a cloned, second set of machines that implement a second set of one or more applications. The method uses the cloned, second logical network to process at least a subset of the network traffic destined to the set of applications.

Abstract: Some embodiments of the invention provide a method for cloning a set of one or more applications implemented by a first set of machines connected through a first logical network that defines a virtual private cloud in a set of one or more datacenters. The method instantiates a cloned, second set of machines that is a replicated copy of the first set of machines. The method identifies a set of network configuration data that configures a set of logical forwarding elements (LFEs) of the first logical network. The method uses the identified set of network configuration data to define a cloned, second logical network to connect the cloned, second set of machines.

Abstract: Some embodiments use CRDs (custom resource definitions) to define resources in an O-RAN system. These resources include applications (xApps, rApps, etc.), components of these applications, deployment constructs, cloud constructs, AI/ML models and RTE constructs. Using these CRD descriptors, app developers can develop and distribute their applications in a platform independent manner. The CRDs of some embodiments are used to on board applications into an O-RAN system. In some embodiments, the SMO (Service, Management and Orchestration) framework of the O-RAN system has a service for processing CRDs. In some of these embodiments, this SMO service has one controller to process the new application CRD. In some embodiments, the SMO identifies clouds for placements of the deployed applications and directs Kubernetes managers of the identified clouds to deploy the applications.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments provide a method of performing control plane operations in a radio access network (RAN). The method deploys several machines on a host computer. On each machine, the method deploys a control plane application to perform a control plane operation. The method also configures on each machine a RAN intelligent controller (RIC) SDK to serve as an interface between the control plane application on the same machine and a set of one or more elements of the RAN. In some embodiments, the RIC SDK on each machine includes a set of network connectivity processes that establish network connections to the set of RAN elements for the control plane application. These RIC SDK processes allow the control plane application on their machine to forego having the set of network connectivity processes.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: Some embodiments provide a method of performing control plane operations in a radio access network (RAN). The method deploys several machines on a host computer. On each machine, the method deploys a control plane application to perform a control plane operation. The method also configures on each machine a RAN intelligent controller (RIC) SDK to serve as an interface between the control plane application on the same machine and a set of one or more elements of the RAN. In some embodiments, the RIC SDK on each machine includes a set of network connectivity processes that establish network connections to the set of RAN elements for the control plane application. These RIC SDK processes allow the control plane application on their machine to forego having the set of network connectivity processes.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

Abstract: To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.