Home > Communication Service Provider Solutions > Converged Core > Guides > Dell Technologies 5G Core Validated Design with Oracle and VMware Reference Architecture Guide > NF deployment on the cloud infrastructure
The 5G NFs are cloud-native functions (CNFs) composed of multiple microservices that are deployed as pods in a Kubernetes cluster. Some microservices are common to many NFs:
Other microservices are specific to the business logic of each NF—for example, the NRF architecture includes dedicated microservices that manage procedures for registration, discovery, or subscriptions/notifications according to 3GPP standards. Similarly, the PCF architecture includes dedicated microservices that run the procedures for AM or SM Policy, connections to CHF or UDR, and so on.
The following figure shows the NF architecture with different microservices:
Figure 26. Generic NF architecture with different microservices
Each NF uses a dedicated namespace. Kubernetes pods implementing the different microservices of the NF are deployed in replica sets. The deployment settings for each NF can be customized in a dedicated YAML file, custom_value.yaml, which lets you enable or disable specific features, set resources such as the minimum and maximum number of replicas in each set, and allocate cloud resources for execution (request and limit CPU and memory), ServiceType (clusterIP, LoadBalancer), and many others. API gateways and configuration management microservices get an external IP so that they can be accessed from other NFs or from management clients.
All NFs are stateless and store various types of persistent data on a common data management layer, the cnDBTier, which is deployed as a separated cloud-native function. The cnDBTier is built on MySQL Cluster Carrier Grade Edition and provides a reliable and scalable data layer which can replicate data locally and across different geographical sites.
The MySQL cluster includes a cluster manager that exposes management services for the database management API (deployment, registration, and so on), life cycle (creation, schemas, keys, and so on), and operations (provisioning, export, audit, and so on). MySQL Server is the API node that processes database transactions from the NFs. Data is stored in node groups of one to four data nodes with equivalent characteristics (compute, memory, storage) and is synchronously replicated across the data nodes in each node group. Replication nodes replicate updates to the node groups, regardless of the source.
The following figure shows the cnDBTier architecture:
Figure 27. cnDBTier architecture
The cnDBTier is independent of the NFs using it. Each NF has a schema and a set of tables in the data tier. The cnDBTier is deployed first, so that other NFs can use it.
The following figure shows the general process for NF deployment:
Figure 28. NF life cycle management
The software packages that are provided for each NF include software images, Helm charts, and YAML files. Before the deployment, at the preparation stage, some YAML files are customized for the specific environment. Preinstallation scripts are provided to perform several tasks, such as creating a dedicated namespace for each NF and creating database tables and secrets (the prerequisites stage). Then, NF microservices are deployed on the Kubernetes cluster using Helm. When the cluster is available, it can be configured using REST API and tested.
As shown in Figure 28, automation tools can be used to automate some of the LCM steps.