An analysis of vEPCs in collaboration with GS Lab — a contributor to open-source projects in the telecom domain 

Open-source projects gravitate to some common problems in the industry. The use of open-source projects accelerates product/solution development and cuts down the costs. Open-source projects for embedded systems to the cloud are commonplace.

Until a few years ago, telecom technologies had not leveraged the power of the open-source. This blog aims to cover the open-source movement in telecom, focused on the telecom core. We will cover the capabilities, strengths, and limitations of several open-source telecom cores. The comparisons are made based on the needs of telecom operators (MNOs and MVNOs) and enterprises who need to deploy private LTE networks.

Need for Open-Source in Telecom

The established players who provide proprietary hardware and software have dominated the telecom industry for a long time. Two primary drivers are changing the status quo.

  1. The scale-up of operations meant the costly purchase of hardware and software as a package. This is cost-prohibitive for large-scale deployments such as private LTE and edge services where an order of magnitude user equipment or IoT devices are expected to be connected. 
  2. The evolution of Software Defined Network (SDN) and Network Function Virtualization (NFV) separates the hardware and software layers. This allows cost optimization by the use of non-proprietary hardware. The use of open-source software can cut down costs further.

In line with these two primary drivers, several efforts have been made to bring open-source technologies for telecom in the last few years. 

Open-source virtual Evolved Packet Core (vEPC)  

EPC is a very critical element in the telecom infrastructure. After a few years of effort, today, we have several vEPC/5GC open-source implementations available. 

Some of the more mature options:

  • Open Mobile Evolved Core (OMEC) from Open Networking Foundation (ONF) is a 3GPP Rel 15 compliant mobile core solution, consisting of EPC and charging components designed to handle the enormous load and lightweight deployments. Individual components from the entire suite can be deployed as all the components are 3GPP specifications compliant.
  • Magma Core initially started by Facebook Connectivity and TIP, aims to provide connectivity where it’s missing. Magma core brings abstraction to hinder traditional mobile network complexity, and best practices from IT industry into telecom space.
  • Free5GC is a 5G mobile core network to implement the 5GC defined in 3GPP Release 15 (R15) and beyond.
  • Open5Gcore, such as the Fraunhofer FOKUS Open5GCore toolkit, practically implements the 3GPP 5G core network. It prototypes 3GPP Release 15 and 16 core network functionalities in a form suitable for R&D activities. Open5GCore is interoperable with 5G NR base stations and user equipment.

Architecture and Components

Magma consists of:

Access Gateway, including EPC and AAA

Orchestrator, like the centralized controller to manage the entire core network

Federation Gateway that provides standard 3GPP interfaces to interact with MNO core network

OMEC consists of:

Gateways, like the CUPS implementation of SGW/PGW/SAEGW

MME implementation

HSS, PCRF, PCEF, CTF, CDF, and components to securely process CDRs

Free5GC

An implementation of 5GC SBA, consisting of almost all the components of 5GC like AMF, SMF, UPF, AUSF, N3IWF, NRF, NSSF, PCF, UDM, and UDR.

Open5Gcore, which includes:

Fundamental 5G core network functionality (AMF, SMF, AUSF, UDM, NRF, UPF)

Implementation of Service Based Architecture [HTTP/2 OpenAPI, REST]

Integration with standard 5G NR and UEs [N1, N2, N3]

Data path diversity support with local offload and backhaul control (PFCP [N4])

Advanced session management with traffic influence and basic QoS

Network slice support

  • Non-3GPP access support
  • Maintaining the 4G core for LTE and 5G NSA access

Comparison of vEPCs

Features OMEC Magma Free5GC
Interfaces supported S1-MME, s6a, s6d, S11, Sx, Gx, S1u, SGi, S5S8-C, S5S8-C, Rf, Gz SGs, S6a, Gx, Gy, S1u, SGi, S1-MME SBI N1, N2, N3, N6, N10, N11, N12, N13
Userplane architecture Userplane (SGW-U/PGW-U/SAEGW-U) – DPDK based, P4 based, BESS based Linux Kernel packet processing Linux Kernel packet processing
Charging support Offline charging on the Gz interface Online charging on the Gy interface
Handover procedures S1-based, X2-based handover S1-based handover
Miscellaneous Features Dynamic role switching between SAEGW<–>PGW based on user context and handover case
(useful when SAEGW is deployed and SGW relocation cases)

User Level Packet Copying functionality where control and data packets can be forwarded to debug systems to trace/debug user activity

Discovery of Control Plane (SGW-C/PGW-C/SAEGW-C) and User Plane components (SGW-U/PGW-U/SAEGW-U) using DNS

AWS Stack – An automation allowing to deploy magma components and integrate them with AWS infrastructure
Performance and Stability (recent numbers managed to achieve during PoC/customer deployment for both the projects) No of UE- 50000 Control plane signalling: Calls per second/ – 200 CPS User plane throughput- 100000 Mpps No of UE- 30000 Control plane signalling: Calls per second/ – 50 CPS User Plane throughput- 100000 Mpps

Scaling and HA

Horizontal scaling. Horizontal scaling  HA deployments R&D oriented project  Does not offer HA

Interoperability and Pilots

Several field trials are done with Magma Core and OMEC.

Linux Foundation, TIP and FreedomFi (US) / TechBross (EU), and other community members are building solutions with the help of Magma. 

OMEC has been used by ONF, Intel, T-Mobile, GS Lab, and other community members to support various use cases. 

Deployment Options

OMEC and Magma support various deployment options and can be deployed on bare metal, VM, or K8s clusters. Deployment scripts are available for both OMEC and Magma, which heavily reduces the pain of installation.

There is also ongoing work of introducing Juju Charms, which will make deployment even easier, and provide a secure way of handling day 1 and day 2 operations.

Conclusion

Community efforts have led to the availability of lightweight, cost-effective open source vEPC solutions. If you are an MNO/MVNO with telecom knowledge, OMEC is a good option. You can choose to deploy the entire suite or individual component of vEPC. Magma Core is a good option if you are not a telecom expert and want to deploy a private network with little effort. Free5GC’s ecosystem is building up and can emerge as a prime open-source 5G core.

Canonical is committed to supporting all above open-source EPC efforts. Together with our partners, we are creating a repeatable way of deploying and managing it through model-driven operations with Juju charms and providing infrastructure components like MAAS, LXD, and MicroK8s.

Owing to its open-source vEPC and deployment experience, GS Lab has a deep understanding of vEPC components development, customization, testing, communication standards/protocols, and MEC. It has developed its assets to experiment and test EPCs. GS Lab is committed to helping MNO, MVNOs, telecom startups, and enterprises develop or implement products and solutions leveraging vEPC and MEC.

Author

Himanshu Purohit, Architect @ GS Lab

GS Lab: https://www.gslab.com/telecom/

In cooperation with Telco PM in Canonical – Maciej Mazur

Similar Posts