The Cloud Native 5G Core Network

When you look through the 5G core network specification documents of 3GPP such as TS 23.501 and 23.502 the idea I got was that it’s pretty much the same as before. Yes, the interfaces and network components have new names but by and large the 5G core network does the same things as today’s core networks and also pretty much in the same way. One thing that stands out just a little bit, though, is that control plane network components are now referred to as ‘functions’ and that the interfaces between them are now ‘service based’. In practice, that means the interactions are now stateless and use http query/responses and data is encoded in JSON format instead of the stateful connections with protocols for signaling interactions as before. O.k. so fine, I thought, 3GPP has moved to web based technologies. But that’s only the tip of the iceberg according to this interesting paper from 5G Americas on ‘5G and the Cloud’.

All these changes are actually just a means to an end. The reason for going in this direction is because 3GPP has bet their money on the cloud and the core network to become cloud native. Today, the hype in telecommunications is network function virtualization based on virtual machines. The way the 5G core network standards were written, however, opens the door to go beyond the virtual machine approach and enables a 5G core network implementation based on containers running on bare metal servers in combination with container orchestration (e.g. with Kubernetes). Going from bare metal servers to virtual machines for control plane functions was a fundamental shift. Going to containers is even more radical but holds a lot of potential.

Containers Work Out Of The Box During the Development Process

For developers working in a team, containers are great because they can be built and re-built when something changes in the same way everywhere. If it works on the a development machine, it will work on the development machines of all other developers in the same way. And it will also work in the same way on the production system as well.

Microservices in Containers

Cloud native not only means containers but to split the functionality of a huge application into smaller microservices that each run in their own containers. Here’s a practical example: When deploying a blog with WordPress for example, the virtual machine way of doing things is to spin-up a bare Ubuntu in a VM and then install Apache or nginx, a database server such as Maria-DB, and then the WordPress PHP website on top. In a containerized approach, the web server and the database server would have separate containers and communicate over IP with each other. The database with the blog entries itself would not be housed in the containers but in a directory somewhere on the host OS and mapped into the database server container. This way, the containers can be updated independently from each other and from the data they work on. So that’s containers.

How To Make Containers Play Together

Things get tricky again if you have lots and lots of containers. At some point it becomes difficult to manage them and the interaction between them, including which containers are allowed to talk with which other containers. Also, one needs to put some sort of monitoring into place that ensures that if a container dies, it is automatically restarted. And then, you want to have containers running on different bare metal servers at different locations for redundancy and capacity reasons. At this point you need to think about clusters. Managing storage where the containers can put their data is another thing. So for all of that you need orchestration, which is where Kubernetes comes in.

There’s lots more to say about containers and orchestration. For a good start I can recommend Red Hats’s “The Command Line Heroes” podcast episode “The Containers_Derby“.

And here’s the link again to the 5G Americas paper on the 5G and the cloud that got me started in the first place. Lots of good links to other resources in there to dig deeper!