Behind the scenes – how we became leaders within 5G Core

How the dual-mode 5G Core journey started  

Even though 5G is still the latest commercial mobile infrastructure, a lot of historically interesting technological developments have happened during the past years. We, being the authors of this blog post, have 10-25 years of experience each in designing and deploying core networks to service providers globally. We will be sharing glimpses of what happened behind the scenes when getting 5G standalone networks to market. What were the bold decisions, challenges, achievements and what are the next steps to bring the true value of 5G standalone for global scaling? Join us on a technology history journey on how our 5G Core networks became world-leading! 

Compared to previous mobile system generations, the system design and development of standardization specifications for 5G Core was initiated with a more visionary set of requirements and expectations. This included enabling a set of new business opportunities and use cases, while also aiming to reduce the complexity and time for creating new services in the network. In addition, the architecture was targeted to be future-proof and capable of supporting different types of accesses, for example, fixed access. The vision was hence to enable true multi-access capability also for future access technologies. Together, this set of requirements and expectations called for challenging some of the existing core network concepts, and 5G Core was therefore decided to be designed to be non-backward compatible to the 4G Evolved Packet Core network architecture while allowing for seamless interworking between 4G and 5G.  

In the 3rd Generation Partnership Project (3GPP), formal work on specifying 5G Core started in late 2016.  It was preceded by several years of research and early discussions between key industry players where we at Ericsson took a very active role. Along the way, a key decision during the standardization process was the May 2017 decision to base the architecture on the service-based concept. This relies on network functions interacting with each other through exposing and consuming services using APIs and relying on hypertext transfer protocol (HTTP) and transport layer security (TLS) protocols for flexible and secure interconnection. This was a disruption compared to the EPC architecture. The first set of 5G Core specifications were finalized and approved to be released as part of 3GPP release-15 in September 2019. 

In parallel with research on 5G Core as preparation for upcoming standardization, we started in 2015 to explore how to design a cloud-native EPC, and later, as standardization of 5G progressed, the obvious next step was to also look into the service-based architecture (SBA) for 5G Core. At the time, the use of open source in the IT industry had witnessed an unprecedented growth through among other the Linux foundation. The Cloud Native Computing Foundation (CNCF) centered around container technologies was recently born and had taken off with a bang. As reluctance towards ETSI’s NFV initiative (only a few years old by then) began to permeate the industry, it became evident that the real telco convergence with the IT industry was bound to occur in the cloud-native space. Technologically, there was nothing wrong with NFV, but its ecosystem would forever remain small and confined to telco, and synergies with the IT industry would be limited. Moreover, its management and orchestration architecture (MANO) was considered to move too slow as it was governed by standards, a model also being foreign to open source.  

Our conviction was confirmed by the large number of 5G Core requests for quotation from communication service providers (CSPs), with detailed questions on the use of cloud-native technologies and principles in Ericsson’s 5G Core portfolio realization. Also, while not mandating a cloud-native portfolio realization, the 3GPP decision to baseline 5GC on the service-based architecture was done with an implicit intent to facilitate such cloud-native technologies going forward. 

Fig 1: The steps taken in the early journey towards building core networks for 5G.

In order to get the 5G Core networks ready, a lot of other activities also took place, together with the broader eco-system and different technical trials and multi-vendor interoperability testing. Moreover, several initiatives supported our customers in how to best monetize the new capabilities of 5G Core such as end-to-end network slicing, quality of service enhancements, providing a platform for innovation and allowing for example enhanced enterprise service offerings. It was crucial to get feedback from early activities driven by certification organizations and customers. Ericsson was the first vendor to be 100% compliant to the early certification test for 5G Core. 

After the initial 5G Core launches, testing with vertical industries and the device eco-system has accelerated within different industry verticals and to explore new areas of usage.  

The bold decisions behind the scenes 

During the early work with 5G, Ericsson realized that service providers would need to manage a quite complex network setup in the years to come. We expected a mix of radio coverage using different technologies, and a heterogenous fleet of devices where some would be 5G-capable, and some would not. Both the 5G coverage as well as the device fleet would also constantly be changing over time, and we wanted service providers to be able to efficiently manage this constantly changing environment as we could see that standalone (SA) and LTE/non-standalone (NSA) would co-exist for quite a long time. 

So, instead of creating a 5G Core network and hooking that up to the existing EPC network, we took a novel approach. The new dual-mode 5G Core network was designed to contain a control-plane part, a user-plane part, and a data layer, which all would support 4G as well as 5G. The control-plane part of dual-mode 5G Core was designed to contain mobility management entity (MME), signaling gateway controller (SGW-C), and packet gateway controller (PGW-C) to support 4G users and networks, and contain access management function (AMF), and session management function (SMF) to support 5G users and networks. In the same way, the user plane part of dual-mode 5G Core was designed to include serving gateway user plane (SGW-U), PDN gateway user plane (PGW-U), and user plane function (UPF) for 4G and 5G respectively. The dual-mode 5G Core solution was also designed to contain network functions for subscription management, resource control, policy control, signaling control, and exposure. These functions were designed on a common cloud-native framework which allowed a uniform way of managing the network, as well as an efficient resource and capacity sharing across 4G and 5G. This was to make the transition from 4G to 5G very smooth for the service providers, by allowing capacity to dynamically and automatically be re-allocated between 4G and 5G as the 5G coverage and number of devices was expected to grow over time. A major re-architecture work started with the aim to establish a cloud-native EPC portfolio realization (with micro-service decomposition, externalized state et c) to provide feature parity with Ericsson's legacy EPC portfolio. 

Fig 2: The decisions taken to develop the commercial dual-mode 5G Core offering.

As a result of this, we took several bold decisions during the first years of designing the new 5G Core solution: 

Decision 1, 2016: Develop a cloud-native core network.  

Decision 2, 2017: Develop a dual-mode 5G Core solution and maintain complete Ericsson Packet Core feature set and re-architect for cloud-native. We were finding our ways and exploring. Our aim was to provide an as smooth migration path for our customers as possible, by securing feature parity with our legacy portfolio, and also parity in non-functional areas, such as robustness, signaling latency, and other characteristics. We were innovating, which resulted in us being first on the market to develop a highly coherent cloud-native core solution for both EPC and 5G Core. This would bring benefits to service providers such as enabling them to easily move traffic from 4G to 5G with just software upgrades, and having one system is around 20% more cost effective than having to run two separate systems. In October 2017, we started the development of clean-slate dual-mode 5G Core for packet core controller. 

Decision 3, June 2018: But after some initial work we decided to not go for clean slate, to be able to bring along all hardening and the large feature portfolio that had been successfully deployed in customer networks and hardened for many years. Existing core features in access and mobility management functions (AMF) and session management functions (SMF) were also re-used. We also created an alignment of the offering, which would cost-efficiently support our customers in the transition from 4G to 5G. 

Fig 3: Ericsson’s dual-mode 5G Core supports network functions for EPC and 5G Core.

Letting service providers play with the 5G Core trial systems  

We early built a 5G Core trial system to let our customers try the new 5G technology themselves to feel confident. Already in 2019 more than 50 trial systems had been deployed, and it continued to grow to over more than 150 systems. 

The end-to-end customer trial system included 5G Core, RAN and devices. These trial systems were provided to build strong cooperation with leading and advanced service providers. The objectives were to show technology leadership, early hands-on experience with 5G technology and cloud-native, and to collect feedback regarding functionality and roadmaps. The first trial systems were delivered already in 2016 and evolved over time starting from non-standalone to standalone and continued with more advanced functionality such as network slicing and exposure services.  

In 2016, we had a handful of trial systems deployed, the interest was great, and it grew rapidly, and a few years later we had more than 150 trial systems delivered globally. In the beginning, the focus was mainly to implement and demonstrate basic 3GPP functionality to show that the new architecture and concepts were working, for example establishing a connection. There were many challenges to get the basics in place, especially from an end-to-end perspective with chipsets/devices, RAN, and the new 5G Core. Devices (UE) and RAN simulators were developed to support advanced testing and were key to enable global scaling of trials.

Fig 4: Overview of the early Ericsson 5G Core trial system.

We also did a lot of exploration with new use cases together with customers, partners, universities, enterprises, and research institutes. In Europe, numerous activities were undertaken involving communication service providers, automotive enterprises, factories, governments, utility companies, and more. The trial system was a great vehicle to engage with customers and played a vital role in gaining trust and confidence for the new 5G technology.  

Fig 5: Snapshots of early 5G use case exploration, proof-of-concept and demonstrations in Europe 2018.

Challenges along the journey 

The use of cloud-native technologies and ways of working has been a success in the IT industry, various benchmarks on cost-efficiency and roll-out speed of new services speak for themselves. However, it is used for software-as-a-service delivery, while in the telco industry, product-based deliveries of complex software are prevalent (though, there are also early initiatives to SaaS deliveries of core networks). The seamless cooperation between Dev and Ops that is key to the efficiency in a SaaS setting, breaks in a telco “as-a-product-delivery” setting and makes the IT model hard to scale.  For example, the distance between Dev and Ops, the handovers, and the multitude and variation in deployment environments, not only from a technical point of view (CaaS layers, mandated infrastructure services and policies, fault models et c), but also non-technical aspects such as acceptable upgrade cadence that varies widely among CSPs. More conservative CSPs prefer not to touch what works, while some ask for fully continuous deliveries. In a sense there is nothing new here, this was true also for physical network functions (PNFs) and virtual network functions (VNFs), but for cloud-native network functions (CNFs) with many small, moving parts (also known as micro-services), the complexity of integration and the frequency by which integration points are touched grows rapidly, and managing that complexity poses a challenge. 

Fig 6: The relation between Development and Operations in an as-a-Service vs an as-a-Product delivery model.

A product delivery model will remain prevalent for many years in the telco industry and poses a need for managing the growing number of smaller, quickly moving parts brought by the cloud-native transition. Ericsson is devoted to finding efficient ways to address this need by smart packaging and automation. By delivering pre-verified bundles we considerably reduced the complexity. The bundles include both business logic and generic services from cloud-native computing foundation (CNCF), where the latter are channeled within Ericsson via the internal application development platform (ADP) marketplace, also securing a high level of alignment of generic services and management functionality across all of Ericsson’s cloud-native portfolio. Adding in-service software upgrade, and devising means to secure a sufficient level of backwards and forwards compatibility to adjacent services such as K8s, the complexity and cost of integration is further reduced. That said, the integration efforts required to bring cloud-native technologies into our current business context have been more challenging and complex than expected. When you are the first to market, you are the first to experience different new technical challenges and solve any problems along the way. 

Fig 7: Anders Lundström, who is 189 cm tall: “It was challenging to deliver all the new features, this is a product requirement list from one market area in 2020. Today everything is green and ready to launch in any market that wants to launch standalone, both with eMBB/FWA services but also for the new value-added functionality as part of the second market wave.” (photo by Martin Björck)

Another challenge we have been facing is that of the “telco gap”; cloud-native services typically rely on the existence of a robust transport infrastructure, while 5GC is part of that infrastructure. This means there are gaps both in characteristics (for example signaling latency and 5 9s service availability) and functionality (for example networking) between what is required from a society critical 5G network vs what is required from a typical IT service, and hence what can be expected to be supported by the cloud-native technology baseline. 

The flexibility provided by the standards is highly beneficial as it allows CSPs to customize their deployment of this architecture. However, this flexibility also introduces challenges, as there are multiple areas that leading to significant multivendor integration and research & development (R&D) efforts to implement several options. This level of complexity is something that only a handful of vendors and service providers can handle. 

By carefully devising a range of innovative solutions in the Ericsson 5GC portfolio implementation, including caching mechanisms, networking beyond what K8s provides , fault detection, advanced support for overload protection et c, we’ve managed to bridge that gap in critical areas and are continuously working on accommodating telco needs, e.g. 3GPP protocols that do not tolerate network address translation (NAT), 5G requirements on extremely low signaling latency, and quick recovery from failures in a way that do not impact end-users. 

Fig 8: Ericsson’s dual-mode 5G Core bridges the gap between what cloud-native technologies provide and what typical IT services need from the transport layer, e.g. in terms of high availability and other characteristics.

The current bundling of Ericsson’s software was an initial step to getting the first networks ready for launch, and we are now investigating ways that support a larger variability of product packages while keeping complexity low and quality assurance high. This will allow for more flexible combinations of 5GC network functions to be offered to our customers and can be managed as a single element. We expect this to keep our customer’s OPEX down as 3GPP continues to add new network functions to the service-based architecture. 

Scaling the solution for global deployments 

In July 2019, we launched the world’s first live cloud-native container-based EPC for 4G and 5G in the US. Later that same year, in December a second network went live in Australia. After all the initial trials and first commercial deployments were done, the next phase to harden the solution and to make it scale for mass-market commercial deployments became part of the next steps of the journey. Ericsson’s service delivery and customer training units were trained and engaged in a massive effort where we scaled the service delivery organization with cloud-native competence. 

Fig 9: The world’s first live cloud-native container-based EPC for 4G and 5G was launched in 2019.

From an R&D point of view a lot of effort was spent on tuning both infrastructure and applications for large-scale deployments while maintaining excellent network KPIs. The new service-based architecture also faced all the different real-life challenges that can happen. Also, since service availability provided by a network function (CNF) needs to be higher than the service availability of the infrastructure of which it is running, the applications had to be adopted to maintain 5x9’s service availability on a 3x9’s infrastructure. Some examples of unexpected events were: How to operate when connectivity to network repository functions is lost? How to redirect users from 5GC to LTE in a controlled way? How to deal with all types of link failures and fast failovers in case of such events? 

One big concern we had was to scale core network multivendor interoperability with all the new specifications, but by now all interfaces except N4 have been commercially deployed in operator R15 and R16 based networks without major challenges once the interworking (direct mode, service communication proxy option C, NF set or not) model is agreed.  

The new technology also enables software usage in new types of products, which was very difficult with legacy technology. We released the Local Packet Gateway to support breaking out edge solutions and network slicing and released Ericsson Private 5G with a complete core in a single server, leveraging the small footprint of cloud-native dual-mode 5G Core. 

We are now in the middle of transforming mobile networks from 4G to 5G, for millions of users around the world with efficient cloud-native dual-mode 5G Core, which can deliver new value creating services for enterprises, industries, governments, and consumers. 

What is needed to benefit fully from the values of cloud-native and 5G standalone? 

This is a journey, cloud-native is not the goal, but it is an enabler to bring efficiency benefits and reaping all the cloud benefits will require more work from us, the CSPs, and the overall industry over time. As the industry matures, we expect to see a higher level of infrastructure convergence adapted to telco characteristics, a higher level of acceptance among CSPs for continuous deliveries, and the possibility for Dev and Ops to work in closer proximity enabling the benefits of true DevOps, while maintaining the integrity and specific needs of the telco industry. Though it won’t happen overnight, such a transformation will remedy many of the challenges we currently see, and Ericsson is continuously launching new initiatives to drive the industry in that direction. 

The end goal is to enable new end-user services with new 5G network technologies. Once operators have built good radio coverage and launched the fundamental services of mobile broadband and fixed wireless access (FWA) on the new core leveraging 5G Standalone, the next wave can start. We already see leading service providers experimenting with new capabilities such as network slicing, edge compute, and APIs.  

We have demonstrated during Mobile World Congress in February in Barcelona how we can offer differentiated connectivity, and how this is realized through four performance classes where developers have transitioned from solely using transmission control protocol/user datagram protocol (TCP/UDP) to four combinations of fixed or adaptive content classes, which require immediate or buffered delivery. The demonstrations showed how to realize the four performance classes with four network slices and how to set this up. We also explained the importance of all the key network entities like 5G Core, OSS/BSS, API exposure, and user equipment routing selection policy (URSP) which is now being made available on devices. A frontrunner here is Telia who showed at the congress how they have started to work with this concept to help enterprises with their connectivity needs in a project called NorthStar. A significant number of enterprises have already shown interest.  

From the discussions with CSPs, we see a bigger interest in embracing 5G standalone and differentiated connectivity as a way to monetize 5G and offer new services. Service providers are now preparing their core networks for future services and exploring and launching new commercial 5G services, some recent examples from end of 2023 and 2024 include: 

• Chunghwa Telecom and Ericsson enable 5G connected ambulances 
• TPG Telecom and Ericsson complete Cloud Native Core network 
• Ericsson and Telefónica showcase on-demand network slicing 
• Ericsson advances 5G standalone network in Canada 

• Singtel pioneers world’s first app-based network slicing 
• Ericsson and Turkcell successfully trial 5G Core automation 
• TPG automates software, security updates with Ericsson 
• MSB strengthens Sweden’s national critical network 
• Case study: Telefónica Germany’s path to 5G SA - Ericsson 
• MTN Group appoints Ericsson to modernise core network 
• Ericsson and TIM Brazil enable seamless software upgrades 
• Turkcell and Ericsson demonstrate 5G network slicing success 
• Elisa launches first 5G SA subscriptions with Ericsson 

Celebrating over 40 live cloud-native dual-mode 5G Core networks 

We have now migrated several large CSP networks with all of their millions of mobile broadband subscribers to Ericsson’s dual-mode 5G Core. They can now deliver solid user experience for 5G smartphones and fixed wireless access. They are also starting to reap benefits from dual-mode 5G Core with total cost of ownership (TCO) efficiency gains and faster launches of new end-user services. The first commercial global deployments of our dual-mode 5G Core, now with over 40 live networks globally at the closing of 2023, was the first step in this transformation journey, so service providers will get additional benefits going forward with new capabilities on top of this core network.  

What we have deployed so far is the foundation for the second wave of service provider monetization with differentiated 5G services. We continue working with our customers to innovate on top of 5G standalone networks with service exposure and network APIs, differentiated connectivity, and other new 5G capabilities.   

We are proud of what we have achieved so far – but not satisfied yet, the work continues to further improve the core networks for differentiated 5G services and future network capabilities. 

Read more:  

Watch the celebration video with Anders Lundström and Elena Nistal and hear their story about the journey to reach over 40 live cloud-native dual-mode 5G Core networks around the world: 5G Core (5GC) network: Get to the core of 5G - Ericsson

Learn more about the values for service providers with Ericsson’s dual-mode 5G Core in this blog post: Six reasons to select Ericsson’s 5G Core for your network