Many posts in this blog have discussed DevOps in depth. With the cloud nativificaton ot telco, service providers will begin adopting CI/CD pipelines and GitOps models as a way of deploying, updating and configuring network functions in the cloud or in a hybrid environment. This post describes a model for the same, albeit one for AWS. It is to be noted that a 5G deployment will need the support of NEP (Network Equipment Provider) ISVs such as Nokia, Ericsson, Samsung et al. Fortunately all of these leading vendors provide functions that support some variant of the below model.
5G Core and RAN Network Functions – DevOps
When the overall 5G network is deployed, it consists of multiple instances of Container Native Functions (CNFs) designed as microservices. Depending on the vendor who supplied them, they undergo regular updates into the environment. The CI/CD pipeline described in the below illustration includes a series of stages from source, build, test, staging and production. It is not much different conceptually from the model we discussed here for Edge deployments – https://www.vamsitalkstech.com/5g/edge-devops-transformation-via-ci-cd-on-aws/
Deploying Network Functions via CI/CD pipelines
The deployment and configuration functionality covers the following four areas:
- Network setup
- Infrastructure deployment
- Cloud-native network function (CNF) deployment
- CNF continuous delivery, post-deployment
It is to be noted that the above architecture model is highly flexible in that it can support various tiers or locations of 5G deployments – such as a CORD or Central office or distributed data centers. We use AWS Outposts instances to host user plane functions such as the UPF (user-plane function). It can also be used to deploy Radio Access Network (RAN)’s central unit (CU) component, and any Multi-Access Edge Computing (MEC) component as well.
Typically most CNFs include Helm charts which are implemented as part of the code pipeline. These can be instrumented to perform pre and post-deployment checks and run as a sequence as per the application needs. ISVs provide wrapper scripts that can be invoked via the pipeline. From a monitoring standpoint, open-source projects such as Prometheus and Fluentd can be deployed in addition to the cloud infrastructure monitoring solution (Amazon CloudWatch in the case of AWS), which logs and monitors the cloud infrastructure of the application.
Conclusion
The Telco movement to cloud-native network functions has never been clearer. Leading ISVs are either rewriting their applications to run in containers or creating new functions from scratch. This solves the biggest problems with 4G deployments – the ability to deploy new application code in a matter of minutes and to use zero-touch provisioning to deploy networks across core, edge and RAN. We have covered most of our bases in terms of 5G concepts, deployments and multi-tenancy. The next blog will focus on the first and smallest deployment architecture for 5G deployments.