Automated Deployment of 5G RAN and Core Networks using AWS Telco Network Builder

Communication Service Providers (CSPs) are embarking on a digital transformation journey of their network operations to deliver new innovative connectivity services to their customers and to expand their traditional customers’ base. To achieve this transformation, CSPs are looking for ways to unify their operating model, and to adopt automation across their operating stack. CSPs want to use the same automation stack for their Core, Radio Access Networks (RAN), IP Multimedia Subsystem (IMS), Enterprise, and Operational Support Systems (OSS) deployments. They want to have ubiquity of their operating model across public and private networks, and they want to deploy throughout the edge continuum (AWS Regions, AWS Local Zones, AWS Outposts) in one unified manner.

Details provided in this post help address CSP’s operating and automation objectives. A network deployment on AWS Cloud leveraging AWS Telco Network Builder (AWS TNB), an AWS service that automates the deployment and management of your Telco networks on AWS, enables CSPs to do the following:

• Easily deploy network functions (NFs)
• Accelerate deployment of NFs
• Reduce operating duplication
• Reduce network operations complexity
• Reduce total cost of ownership (TCO) through operating ubiquity

More specifically, in this post we demonstrate how Fujitsu cloud-native NFs are easily deployed using AWS TNB. We also show how CSPs can deploy end-to-end 5G networks in minutes.

The following acronyms are used in this post:

• AUSF: Authentication Server Function
• CNI: Container Network Interface
• C-RAN: Centralized-RAN
• CU: Central Unit
• CU-CP: CU Control Plane
• CU-UP: CU User Plane
• DevOps: Development & Operations
• D-RAN: Distributed-RAN
• DU: Distributed Unit
• EC2: Elastic Compute Cloud
• ENI: Elastic Network Interface
• MEC: Mobile Edge Computing
• NRF: Network Repository Function
• NSSF: Network Slice Selection Function
• OAM: Operations, Administration, and Management
• PCF: Policy Control Function
• RAN: Radio Access Network
• REST: Representational State Transfer
• SBI: Southbound Interface
• SDK: Software Development kit
• SMF: Session Management Function
• UDM: Unified Data Management
• UPF: User Plane Function
• VPC: Virtual Private Cloud

Solution overview

Fujitsu

Fujitsu, an AWS Partner, is a leading provider of network digital transformation solutions for customers globally. By adopting cloud-native best practices, Fujitsu supports deployment models running on AWS Regions, Local Zones, and Outposts to meet customers’ demands and requirements, as shown in the following figure.

Figure 1: Fujitsu on AWS

Fujitsu adopted the NFV Industry Specification Group (ISG) recommendation that 5G virtual network functions (VNFs) should go a step further and follow “cloud-native” design principles that have been adopted in enterprise IT and following AWS WAF best practices. Among these cloud-native principles, 5G VNFs:

• Can be decomposed into many lightweight components and common platform services,
• Are designed following component-based software design, or micro services, and
• Are built for quick restoration from failures

Cloud-native design maximizes the efficient use of resources through finer grain infrastructure use (micro services) and also makes sure of the use of advanced cloud orchestration techniques as they are developed. Running CU on AWS provides CSPs with scalability, security, and performance required to unlock 5G services. With Fujitsu on AWS, customers can place CU-UP and UPF based on the application requirements. For example, customers can deploy UPFs on Outposts to enable a latency sensitive video analysis application.

Figure 2: Fujitsu CU Architecture on AWS

The preceding figure describes how Fujitsu cloud native software is deployed on AWS. First, the CU is split into two components: CU-CP and CU-UP. The first is responsible for processing the control plane, while the latter is responsible for handling traffic. Fujitsu CU uses the scalability of AWS Cloud Services. The CU-CP and CU-UP use Amazon Elastic Kubernetes Service (Amazon EKS) to deploy flexible Kubernetes (k8s) applications. Separation of the CU-CP and CU-UP allows independent scaling and placement of each component depending on use case requirements, and they can be deployed in AWS Regions, Local Zones, or Outposts as needed.

Figure 3: Fujitsu 5G Core Architecture on AWS

The 5G Core follows a 3GPP-compliant Service-Based Architecture, designed to be lightweight for private network usage, as shown in the preceding figure. The UPF is the traffic processing component within the 5G Core. Like the CU, the separation of the UPF allows separate scaling and placement of the control plane and user plane functions. The UPF can be deployed from the network core to the edge and provides a repeatable deployment strategy to support our customers in delivering private networks and edge applications to their enterprise customers.

AWS TNB

AWS TNB is an AWS service focusing on helping CSPs to accelerate the deployment of cloud-based NFs’ compute/network resources and services. This is achieved by automating the life-cycle management of the compute and network resources, the container management, and NFs. It provides CSPs with the ability to perform operations (e.g., instantiation, updating, termination) in an automated and repeatable manner. AWS TNB provides customers with a ubiquitous deployment model across AWS Regions, Local Zones, and Outposts. For example, customers can deploy UPFs in Local Zones, CUs on Outpost, and PCF in AWS Regions using the same deployment methodology to reduce their operating complexity.

As illustrated in the following figure, AWS TNB has two main components: a networks function catalog (functions packages) and a network services catalog (networks packages). First, CSPs can ingest their NFs packages (e.g., vCU, vUPF, vIMS) into the function catalogs. A function package is a zip file in a Cloud Service Archive (CSAR) file that contains a descriptor file, helm charts, and optionally custom scripts. Then CSPs ingest a network package (Network Service Descriptor – NSD) that describes the compute and networking resources, as well as the NFs to deploy. A network package is a zip file that contains an NSD file, and optionally customer scripts. This provides CSPs with the ability to unify RAN, Core, IMS, and Enterprise (e.g., private network with video analytics application) operating models by using a common deployment model. AWS TNB supports the templatization of the ingested packages, allowing customers to use one recipe multiple times. For example, for every x customer, a CSP may want to deploy y UPFs and z CUs. AWS TNB lets them create a new deployment using the one unique network package, and to modify the networking or compute resources for that new deployment unit.

Figure 4: AWS TNB

By providing a single service to manage the lifecycle of NFs, AWS TNB provides CSPs with a unified view of their network deployments. Customers can see the number of NFs available for deployment and their versions, the Network Services defined, the status of their deployments, and a view of the resources being consumed.

AWS TNB gives customers the ability to achieve lifecycle operations using the AWS Management Console, AWS SDKs, and AWS Endpoints (REST APIs). AWS TNB exposes ETSI SOL003/SOL005 APIs to enable CSPs to leverage their existing ETSI-based Service Orchestrator. Through repeatable deployment units and programmatic methods, CSPs gain the ability to accelerate the adoption of IT best practices of continuous integration/continuous deployment (CI/CD) and automation of their network operations. For example, as illustrated in Figure 4, CSPs can leverage AWS DevOps services to automatically ingest and augment the software releases provided by their ISVs, and then ingest these augmented artifacts into AWS TNB.

Architecture

Although in this post we demonstrate the Console approach, customers can ingest CSAR packages programmatically, thereby leveraging their existing CI/CD to augment software artifacts received from their software vendors. Once the NF packages (e.g., CU, AMF, UPF) are ingested into AWS TNB function catalog, we ingest the description of our 5G deployment.

Figure 5: Fujitsu 5G Network Deployment using AWS TNB

First, we define the compute and network resources, and the NFs to deploy. Then, customers can create multiple deployments out of one recipe to support multiple copies of private network solutions, or deploy NFs to support scaling across multiple cities and areas where their customers reside. Once ready, customers initiate the deployment. First, AWS TNBs creates VPCs, Subnets, ENIs, Amazon EKS Clusters, and Amazon Elastic Compute Cloud (Amazon EC2) instances to support CU and Core instantiation. Then, AWS TNB performs the installation of NFs automatically and reports the deployment status to the customers.

Design

First, CSAR packages for each NF that we want to deploy must be created. The NF descriptor is created (vnfd.yaml) and Helm charts with desired deployment values are created. Then, these are compressed into a zip file that can be ingested to the AWS TNB functions catalog. Software images referenced in the package are kept in Amazon Elastic Container Registry (Amazon ECR). The following figure illustrates the VNFD descriptors for the Fujitsu CU:

Figure 6: Fujitsu CU network function descriptor

Second, we create an NSD that describes the required compute and network resources as illustrated in Figure 5. The ingestion in AWS TNB is achieved through the Create Function Package and Create Network Package actions. The following figure shows the ingestion of a network package deploying a CU-CP, CU-UP, UPF, and 5G Core.

Figure 7: RAN & Core Network Package Ingestion using AWS TNB

Deployment

As illustrated by the preceding figure, customers can now create one or more network instance (NI) using the previously ingested network service. Each NI is independent from one another, leveraging one unique template. Upon NI creation, customers can instantiate their networks once they desire that network to start carrying traffic. This enables them to only run resources when needed, providing additional cost optimization. As illustrated by the following figure, this is achieved by

Figure 8: Instantiation of our 5G Network

running the Instantiate action on the created NI. For more details on how a network package or service is constructed, and for descriptive step-by-step instruction on AWS TNB actions, the reader is invited to review AWS Telco Network Builder – Deploy and Manage Telco Networks.

Figure 9: Automated 5G Network Deployment Status

The preceding figure shows a successful completion of the deployment tasks. In InfrastructureInstantiation, AWS TNB creates the underlying compute and network resources (e.g., VPC, EKS Cluster) required for this CU-Core deployment. In AppInstallation, AWS TNB configure Multus-CNI automatically, and finally the FunctionInstantiation covers for the instantiation of vCU, AMF, UPF, and SMF. At this point, the network can start carrying traffic.

Conclusion

AWS TNB provides CSPs with the ability to manage the life-cycle management operations of their networks. AWS TNB enables CSPs to:

• Accelerate the deployment of cloud-based NFs’ compute/network resources, and services
• A single service to manage the lifecycle of their NFs
• A unified view of network deployments
• Unify RAN, Core, IMS, and Enterprise-service operating models
• Ubiquitous deployment model across AWS Regions, Local Zones, and Outposts
• Leverage their existing ETSI-based Service Orchestrator
• Accelerate the adoption IT best practices of CI/CD and automation to their network operations

To learn more about AWS TNB, see the AWS TNB User Guide and AWS TNB API Reference Guide.

AWS Telco Network Builder User Guide provides you with the descriptions of AWS TNB capabilities, concepts as well as detailed instructions to deploy and manage your networks using the Console and AWS Command Line Interface (AWS CLI). The AWS TNB API Reference Guide describes all the AWS TNB API actions to deploy and manage your network through programmatic (REST, SDKs) way.

To learn more about how telecommunications companies are leveraging AWS services, visit Telecom on AWS.