The last post covered a layered architecture for Network Slicing on a 5G network – https://www.vamsitalkstech.com/5g/network-slicing-layered-software-architecture/. Whether it is network slicing or plain 5G workloads, they bring telecom into the cloud-native world. This post and the next one discuss the next generation of tools for telco service update, we first cover IaC (Infrastructure as code) tools to deploy end-to-end networks. The next post will cover DevOps based on the best practices for service updates.
5G Core and RAN – Infrastructure setup
Given that the vast majority of 5G Core and some of 5G RAN workloads will be cloud-based, we propose cloud-based CD (Continuous Deployment) pipelines for Operators to roll out new services. Whether the service is a CNF (a cloud-native telco function running as dockerized containers) or a plain old VNF (legacy virtual network function running inside a VM), a CD pipeline can be instrumented as shown in the below diagram. This saves (many) days of lead time as the deployment is done using the software as opposed to manual provisioning of old. As AWS is the cloud we will use in all of our blogs, we will go with it.
Automating 5G RAN and Core deployments (Source: Dr. Jung Young AWS)
This example is taken from https://aws.amazon.com/blogs/opensource/open-source-mobile-core-network-implementation-on-amazon-elastic-kubernetes-service/ , we use CloudFormation to create an Amazon Virtual Private Cloud (VPC), an Amazon EKS cluster, and two worker node groups (one for the 3GPP control plane, the other for the 3GPP user plane).
Importantly, when we deploy these types of open source EPC/5GC on EKS because they are mostly using multiple network interfaces to serve all different protocols at each interface with having network separation, we have to leverage the Multus CNI Plugin. As guided in AWS GitHub, we can (again) automate this process through the AWS Lambda function and Amazon CloudWatch Event Rule. The bottom line is that two AWS CloudFormation templates create the following resources:
- Infrastructure creation template
- EpcVpc: A VPC that will be used for the deployment.
- PublicSubnet1/2: These subnets will host the bastion host for kubectl command run with having public internet access. Also, this will host the NAT-GW to provide internet access for the private subnets.
- PrivateSubnetAz1/2: Subnets for the EKS control-plane in AZ1 and AZ2.
- MultusSubnet1Az1: The first subnet that Multus will use to create secondary interfaces in the EPC control plane pods.
- MultusSubnet2Az1: The second subnet that Multus will use to create secondary interfaces in the EPC user plane pods.
- EksCluster: EKS cluster that will host network functions.
- DocumentDBCluster: For the profile store of subscribers, Open5gs originally used MongoDB for HSS and PCRF. In this implementation, Amazon DocumentDB is facilitated because DocumentDB has full compatibility with MongoDB.
- Route53 Private Hosted Zones: For the discovery of service interfaces, such as S6a, Gx, S11, S5-c/u IP addresses, Amazon Route 53 is facilitated as one central DNS.
- EKS worker node group creation template
- Worker node group for control plane network functions, such as MME, SGW-c, SMF, etc., with additional control plane subnet network.
- Worker node group for user plane network functions, such as SGW-u and UPF, with additional control plane subnet and user plane subnet networks.
- Lambda function for attaching additional Multus subnet networks to worker node groups.
- CloudWatch Event Rule for monitoring instance scaling up and down to trigger Lambda hook to attach additional Multus networks to worker node groups.
So What is the Big Deal Here?
Whatever be the collection of IaC tools chosen, which will depend based on the cloud provider of choice, this approach solves most of the deployment pain points of Operators. Carrier-grade requirements imposed on 5G SA and NSA networks mean that high availability and scalability are very important in addition to meeting QoS(quality of service) guarantees. This means that everything in the network needs to be Software-Defined. A lot of the elements covered in these blog posts all now apply to telcos – https://www.vamsitalkstech.com/?s=software+defined . By making the network programmable, telcos can meet faster time-to-market requirements.
Conclusion
The next blog post will continue the theme by discussing DevOps and CI/CD pipelines as best practices ways of automating service updates.
Feature image source: Ricardo Gomez Angel