5G Lab – Running a Fully Containerized 5G Core with Open5GS

A report published by the Global Mobile Suppliers Association in July 2023 shows that there has been significant progress in the development of 5G Standalone (5G SA) networks globally. According to the report, 115 operators in 52 countries and territories have invested in 5G SA networks through trials, deployments, or planned deployments.

With increasing expansion, 5G networks require the ability to scale horizontally to handle the increased load and demand for services. Kubernetes will play a significant part in that process. The article you are about to read explores how Software Mind runs a 5G Standalone Lab on Kubernetes using Open5GS.

Black box vs. virtualization vs. containerization

Let’s start by briefly describing how the deployment of a telecommunications network has changed over the years.

A: The early days, when network elements were tied to physical hardware

The “black box” model is what some of our colleagues call the classic Telco vendor model of commercializing software and hardware as a single piece. It acted as a standard in the early days of the Telco world.

Hardware and software acted as a “monolith” and an operator had a limited view of what was inside. If a carrier wanted to add more capacity, this would often require buying more hardware, which in some cases, could become underutilized.

B: Virtualization: when vendors “broke” the “black box”

Not so long ago, Telco vendors became more eager to open themselves to distribute their software decoupled from any hardware. This was (and still is) commonly called “Network Functions Virtualization” (NFV). 

 Nowadays, telecommunication operators are expected to install network elements in commercial off-the-shelf (COTS) hardware or virtual machines already owned or purchased. There is no need for special hardware anymore.

Read also: The Important Role of Open5GS in Private 5G Network Development

C: An introduction to today’s model: containerization

While virtualization is beneficial and omnipresent in almost all information and communication technology (ICT) infrastructure, the hype for virtualization is over. The need to run software without virtualizing entire operating systems has become apparent to the industry.

Previously, this article mentioned how vendors broke the “black box” by switching to virtualization? Now, it’s the time to ” break the virtual machine “.

Software containerization means packing software in a carefully designed way so it can be distributed, upgraded and managed conveniently and in a standard way.

Companies use containerized software every day. Mobile apps on systems like Android or iOS are good early examples of containerized software. They come in a package managed by an external system (in this particular example, the OS itself), and are isolated from a system so they can’t cause conflict or damage anything, nor read or write data to other apps. The procedures to install, remove and update are always the same, and because of that, they have very little probability of failure.

Why are containerized software solutions the new standard?

Containerization has become the standard in back-end infrastructures because you don’t need an entire virtual machine to run many different pieces of software and containerization makes it possible to provide a machine with as many pieces of software as you want without breaking anything.

When it comes to systems where you can run containers, Docker was one of the pioneering solutions for a long time (and still is for many applications such as building and testing new containers).

Why did Software Mind choose Kubernetes for 5G containerization?

Solutions like Kubernetes enable great flexibility when it comes to running containers. You can create a mesh of containers (also called Kubernetes Service) that are interconnected automatically. Kubernetes is so practical because it:

• Provides automatic scaling based on resource utilization, which ensures networks can adapt to changing conditions and efficiently allocate resources. 
• Delivers built-in service discovery and load balancing features essential for managing the dynamic nature of 5G networks – an important solution for Service Based Infrastructure (SBI). 
• Supports rolling updates and continuous deployment strategies, that facilitate seamless updates and changes to the 5G network without any downtime. 
• Creates a transparent and resilient mesh of containers across nodes, making it possible to have a server farm with any type of redundancy, even geographically, while still managing a cluster of elements as if they were all in one machine. 

The challenges linked to 5G containerization

How does Kubernetes help in practice?

By doing containerization of a 5G core with Kubernetes, you can smoothly ease operations on a network when performing operations like:

• Integrating network elements and changes: Adding a new network element or features can easily be performed. When you test a new implementation, you can clone the environment in production and make any changes in an isolated way.
• Adding network capacity and improving load balancing: Kubernetes allows for automatic scaling, depending on resource demand, making use of DNS to automatically allow new network elements to be recognized by others. Without the need to order hardware and set up a new virtual machine on the network, the staff at network operations or an automated system in the Operations Support System (OSS) domain can easily make more resources available by spinning up more containers that will start communicating with each other automatically.

How Software Mind moved our 5G Lab into Kubernetes

Let’s focus on the advantages and challenges our team faced when porting our first prototype 5G Lab to its new place on a Kubernetes platform.

Preparing the form

We knew this was going to be a significant project and we wanted to apply the Continuous Integration and Continuous Delivery (CI/CD) approach from the beginning, so we first set up a Git Repository (Gitlab) to keep our code, store documentation and created a container registry – this is where container images are saved and pulled by container platforms like Docker or Kubernetes when we want to spin up a container.

Thanks to GitOps and Infrastructure as Code (IaS) the deployment of the 5G Core infrastructure is fully automated.

(Our internal Gitlab containing some of our 5G-related projects)

Introducing the basic makings of a container

First, we need a container image, which is a snapshot of all the files, binaries and libraries necessary for the application to work. This required our team to develop a script that would install only the necessary packages and dependencies into the operating system. The container platform would take care to gather all the changes made in the system and nicely package everything into an isolated filesystem called “container image.”

Once our images were ready, we would push them into our repository. Container images are typically read-only, so any of us could download and run a 5G network element by just using that image (as well as a runtime configuration and optional storage, explained below).

A runtime configuration:

Before running an image, it is necessary to specify which network you want to connect to when you run the image, the ports that should be available for connection, environment variables that should be passed onto the system, etc.

The idea was to have a straightforward configuration for anyone to run, so the container configuration only needed to specify which ports to open.

Below you will find an example of running the Access and Mobility Management Function (AMF). The AMF in 5G is a key element that keeps control of the mobile user’s registration and mobility status:

amf: 

    sbi: 

     - dev: eth0 

      advertise: open5gs-amf 

      port: 7777  

Our team made it so Open5GS elements communicate with each other over the Kubernetes network (or more precisely, through service names). The deployment was named open5gs-amf, other elements, instead of using the IP address (which changes with each deployment restart), use a reference to the DNS name, which resolves to Cluster IP.

Read also: How 5G is Changing Steering of Roaming

Open5GS is also helpful in this matter, as it supports DNS names and enables you to use the ‘advertise’ flag to broadcast the DNS name of an element.

A storage volume:

Containers are ephemeral. If the application needs to save data, you’d typically designate one or more specific paths for storing data. When the container is torn down, all the rest of the data generated that you don’t want to keep is erased. It helps keep things tidy, as only desired data is saved.

Keeping logs and the Open5GS configuration files were helpful, so we did just that. Additionally, we chose an external path to keep subscriber data. 

You can have a basic container up and running once you join these three things together. 

Here is an output of what a simple ready environment looks like:

sysadmin@observability-1:~$ kubectl -n 5g get pods 

NAME                                     READY   STATUS   

mongodb-6b874774b8-psplp                 2/2     Running  

default-logging-simple-fluentbit-vg4f5   2/2     Running  

default-logging-simple-fluentd-0         0/3     Init:0/1 

default-logging-simple-fluentbit-ddk9g   2/2     Running  

open5gs-bsf-67ddb699fc-4x5tv             2/2     Running  

open5gs-ausf-849bb8f855-btpqh            2/2     Running  

open5gs-scp-6f4f9bcb66-gskkm             2/2     Running  

open5gs-udm-677d7bdb88-cbsc7             2/2     Running  

open5gs-nrf-79df7fd95f-l78rv             2/2     Running  

open5gs-amf-7f4469fbdd-rn6vg             2/2     Running  

open5gs-webui-844688995c-pvnqm           2/2     Running  

open5gs-pcf-764c687d5f-8qwtz             2/2     Running  

open5gs-nssf-5dffb4b797-25r2r            2/2     Running  

open5gs-udr-b4d55b7c6-m8dhh              2/2     Running  

open5gs-smf-5c87b94d89-xmblk             2/2     Running  

ueransim-gnodeb-85b48c545-26xdx          2/2     Running  

ueransim-ue-55ff855c7d-m26qg             2/2     Running  

Bonus: Running a testing application on Kubernetes

Our team ran several tests to ensure the proper interworking of the network elements and, at some point, wondered if it wouldn’t be easier to have a 5G mobile device simulator to allow our teams to work without having to be tied to their individual radio equipment.

And yes, such a solution exists! UERANSIM is a client terminal simulator, which connects to our Kubernetes 5G Lab. Communication between Open5GS components takes place via the Kubernetes service.

Maxing out a container’s possibilities

You just saw how easy it is to have a container ready to go. But you know what’s even better? You can “tie” them up together in a Kubernetes Service to create an extensive network that offers as much capacity as you’d like.

As mentioned, Kubernetes handles most of the communication between containers using DNS to have them talk together. Once you get two containers to talk together, you most likely can expand this into three, four… and to infinity.

If you want to learn more about how these elements interact together, you can read 5G Lab – Building and Connecting to Our Own 5G Network.

What comes after containerization?

This article only focuses on the 5G core. But with a fully virtualized and containerized telecommunications core becoming the standard, OpenRAN is coming to standardize and decouple the elements inside the radio infrastructure (RAN) as well.

One of the projects Software Mind is working on is the containerization of the RAN backhaul and midhaul. That’s correct. RAN is also going through a revolution, moving from local base station sites into data centers thanks to virtualization and containerization working together.

Next in the 5G Lab series… observability

Thanks to the fact that the 5G core has more open interfaces and uses more common protocols for network elements to communicate, such as HTTP, we went a step further and made the integration of monitoring tools for gathering metrics and analyzing traffic, all based on widely available software. The results are interesting, and the entire team can’t wait to publish the next article of our 5G Lab series.

If you can’t wait, you can right now request access to watch our private Telco Days 2023 sessions. Together with our partners RedHat, AWS and Casa Systems, among others, we show how beautifully 5G, the cloud and containerization come together.

Deploying Open5GS on Kubernetes for a 5G network can improve scalability and resource efficiency, increase flexibility and portability for deployments in different environments and significantly automate network operations. If you want to enhance the management of your 5G network, please use the form below to contact one of our experts.