Fully automated CI/CD pipelines for deploying and managing Magma on AWS

Introduction

Magma is an open-source, flexible, and extendable mobile core network solution. It is designed to be 3GPP generation and access network agnostic. Magma supports many radio technologies, such as LTE, 5G, and WiFi, and it enables use cases like mobile private networks, fixed wireless access, or mobile edge computing. It is governed by the Linux Foundation, and it is being developed and supported by an open-source software community.

We explained in a previous the process of deploying Magma on AWS manually. This post shows how to fully automate the deployment and lifecycle management of Magma on the AWS Cloud.

Magma on AWS deployment models

As illustrated in Figure 1, There are three key components in the Magma architecture:

• Access Gateway (AGW), which provides network services and policy enforcement.
• Orchestrator, which provides a simple, secure, and consistent way to configure and monitor the wireless network.
• Federation Gateway, which uses standard 3GPP interfaces to integrate with the existing mobile network operator’s core network. It acts as a proxy between the Magma AGW and the operator’s network and facilitates core functions such as authentication, data plans, policy enforcement, and charging.

Figure 1: Magma Architecture based on 3GPP EPC

This blog post’s focus is on the automated deployment of the AGW and the Orchestrator components. Depending on the use case requirements, there are three possible deployment models for Magma on AWS:

• AGW on AWS Region + Orchestrator on AWS Region: recommended for testing stages and for applications that do not have strict requirements in terms of latency or network bandwidth
• AGW on Outpost + Orchestrator on AWS Region: suitable for applications that are sensitive to traffic latency and are high throughput, such as online gaming and financial trading.
• AGW on Snow family devices + Orchestrator on AWS Region: suitable for applications that are sensitive to traffic latency and less demand on network bandwidth. Examples are robotics and IoT local data processing.

In the following sections, we detail how we can streamline the deployment of Magma on the AWS Region using AWS developer tools. However, the same principles can be applied for the rest of the deployment models mentioned above.

Magma AGW and Orchestrator on AWS Region

First, let’s have a look at the infrastructure that is needed for running Magma AGW and the Orchestrator in AWS Region, which is shown in Figure 2.

Magma Orchestrator is deployed using Helm on an (Amazon EKS) cluster. Amazon Application Load Balancers serve as an entry point to the ingress services exposed by the Magma Orchestrator. An Amazon RDS for PostgreSQL database instance keeps the states of the Orchestrator and the network management system (NMS).

Magma AGW is provisioned as an EC2 instance with ENIs in two private subnets (S1U/N3 and SGi/N6) within its dedicated VPC. A NAT gateway provides the Magma AGW access to the internet or the service provider’s network. The UEs or mobile clients connect to the Magma AGW via the 3GPP S1U/N3 interface. For the sake of simplicity, we assume that the connectivity from the radio access network (RAN) to the Magma AGW has already been set up, for example, using AWS Direct Connect. A hosted zone in Amazon Route 53 defines the DNS records needed to access the Magma Orchestrator web administration portal.

Figure 2. Magma AGW and Orchestrator on AWS Region

Automation pipelines

In a previous we describe in detail how AWS tools and services can be used to fully automate the deployment and upgrades of mobile network functions. The deployment and lifecycle operations of Magma have been fully automated using a collection of AWS developer tools, such as AWS CodeCommit, AWS CodePipeline, and AWS CodeBuild. Following a GitOps approach, the infrastructure is defined as code (IaC) alongside application code, versioned in a git repository, and then provisioned following the same merge request process as the application software code. GitOps combines infrastructure as code (IaC) with git version control and automated continuous integration and continuous deployment (CI/CD).

The separation between infrastructure and Magma automation pipelines is intentional and allows for having separate DevOps teams that focus on a given domain within an organization. There are a total of four independent pipelines, divided into two categories: infrastructure resources and Magma resources. The automation pipelines follow a reusable pattern with the following stages:

1. Source: Get the CDK application or infrastructure code from the relevant source code repository
2. Deploy: synthesize the CDK code and push the resulting templates to the AWS CloudFormation service. From there, the AWS CloudFormation service will create cloud resources in the target AWS account.
3. Test: execute relevant test cases to verify the correct deployment of application or infrastructure resources.

The source code repository is built on AWS CodeCommit. AWS CloudWatch generates events that trigger the execution of automation pipelines whenever there is a change in the specified branch of the source code repository associated to that pipeline. This process and the above-mentioned automation pipelines are depicted in Figure 3.

Figure 3. Magma automation pipelines

In order to successfully deploy Magma infrastructure and its services for the first time, the automation pipelines must be executed in the proper sequence. For instance: VPC and subnets need to be created before the EKS cluster. The sequence of tasks to deploy Magma on AWS is defined as a state machine that AWS Step Functions orchestrates. By doing so, the service lifecycle management operations, such as the initial deployment of Magma and the underlying infrastructure, can be fully automated and triggered by a single API call. Figure 4 illustrates the different steps (states) used within AWS Step Functions to orchestrate the entire process of deploying Magma.

Figure 4. AWS Step Functions state machine that orchestrates the deployment of Magma on AWS

AWS Step Functions state machines can be parameterized to allow for customizing individual Magma service instances to fit various customer’s needs.

After a successful deployment of Magma on AWS using AWS Step Functions, the Magma orchestrator is ready to be configured using the Magma administration web portal, as shown in Figure 5. The Magma administration web portal provides a view of several network operation metrics as well as a list of the deployed Magma AGWs.

Figure 5. Magma orchestrator administration web portal

Updating the deployment

Because we are using a GitOps approach with CI/CD pipelines to deploy the different components of the Magma service and its underlying infrastructure, we can deploy updates to the existing resources just by merging the desired change to the git repository that contains the CDK template to be updated. The change in the CodeCommit repository generates a CloudWatch event, which at the same time will automatically trigger the execution of the CI/CD pipeline that is associated to the repository.

Magma service deletion

The Magma service deployment on AWS can be torn down by destroying the underlying infrastructure resources as well as all the CI/CD pipelines. This can be done via a single API call and it has been implemented using AWS Step Functions, where in the execution input you have the option to specify whether the existing EKS cluster and network resources should also be deleted. If you set the deletion of EKS and network resources to true, the state machine will delete all the resources associated to Magma.

Figure 6 depicts the end-to-end Magma deletion process defined as a state machine in AWS Step Functions.

Figure 6. AWS Step Functions state machine that orchestrates the termination and deletion of Magma related resources on AWS

Conclusion

Magma provides operators and vendors an open, flexible, and extendable mobile core network solution. Its simplicity and lower cost structure empower innovators to build/experiment with mobile networks as was never before.

By using AWS managed services and AWS developer tools, we were able to automate the lifecycle management of Magma on AWS. With a single API call, you can now deploy Magma Orchestrator, Magma Access Gateways and the required underlying infrastructure without any manual intervention. Moreover, you can also continuously deploy any changes and updates to the Magma services and infrastructure in a fully automated manner.

In order to learn more about how operators are reinventing communications together with AWS, please refer to Telecommunications on AWS.