Orchestrating private network deployments with AWS Telco Network Builder

Communication Service Providers (CSPs) are evolving into providers of a “network of networks” to enable new revenue streams through industry-specific private network solutions. This plurality of networks needs the adoption of automation to achieve operational excellence. CSPs are seeking opportunities to automate the lifecycle management (LCM) operations of private networks. By using automation, CSPs can streamline processes, improve efficiency, and effectively manage the complexities arising from operating multiple private network offerings tailored to different industry verticals.

Unlike traditional telco network deployments that may rely on complex orchestrators, CSPs can now adopt a streamlined and tailored solution that aligns with the static and replicable nature of private networks. AWS Cloud Development Kit (AWS CDK) provides an infrastructure as code (IaC) approach to interacting with AWS services. When combined with AWS Telco Network Builder (AWS TNB), AWS CDK helps automating the end-to-end deployment of private networks for CSPs and their enterprise customers.

In this post, we provide an example of how a CSP can use IaC and AWS TNB to enable agile, scalable, and efficient network operations to manage use-case driven private networks for their enterprise customers.

Solution overview

The solution described in this post uses AWS TNB and AWS Step Functions by creating workflows using AWS CDK and Cloud Service Archive (CSAR) packages as an input. This approach allows CSPs to use AWS TNB for the LCM of network components, while also providing a streamlined and automated experience for their enterprise customers through custom APIs.

Figure 1. Solution overview

The overall solution architecture includes the following key components:

• AWS TNB allows you to create repeatable templates to automatically provision the private network components (for example UPF, AMF, Enterprise Edge Applications).
• LCM orchestration workflows built using AWS serverless services such as Amazon API Gateway and Step Functions. These workflows expose standard APIs compliant with ETSI NFV SOL001/SOL004 standards, which enable the CSP to automate the instantiation and termination of private networks end-to-end and across multiple AWS Regions.

The rest of the post walks you through the implementation details of these custom orchestration workflows integrated with TNB, which provides a step-by-step guide for CSPs looking to build lightweight orchestrators for their private network offerings.

CSAR package onboarding

CSPs often receive network function software releases from Independent Software Vendors (ISVs) in the form of Cloud Service Archive (CSAR) packages. CSAR packages include network function descriptors and other deployment artifacts such as Helm charts or scripts. CSPs may want to apply their specific security guidelines (for example scanning, signing, publishing) to the deployable artifacts in these packages in an automated method to quickly onboard new security best practices. In addition, CSPs who have enterprise customers needing deployment of private networks in different countries (for example a mining company) need an orchestration workflow that allows them to abstract the deployment across multiple AWS Regions and accounts.

AWS TNB is a regional service, thus the new CSAR files are uploaded to the AWS TNB Network Function (NF) and Network Service (NS) catalogs in one or more AWS Regions for each workload account as described in the following architecture.

Figure 2. Multi-region and mutli-environment CSAR package onboarding

The process of uploading and updating AWS TNB catalogs is also automated by the following CSAR onboarding workflow.

Figure 3. Automated CSAR File Ingestion and Modification

First, a CSAR package is uploaded into an Amazon S3 bucket. This generates a “new objects created” event, which triggers an Amazon EventBridge rule. In this case, the rule triggers the running of a state machine (Figure 5), which performs the customer-desired transformation on the CSAR package.

The CSAR processing state machine extracts the original Helm templates within the CSAR package and modifies them to meet the CSP’s specific requirements. For example, the file processing operations can be implemented using AWS Lambda functions or AWS CodeBuild projects. At the end of the customization process, the state machine packages the Helm templates and stores the new CSAR package in Amazon S3.

Then, the CSAR onboarding state machine uploads the customized CSAR package to AWS TNB in the required Regions for each workload account. In this stage, CSPs can use AWS TNB to create and instantiate network services in the workload accounts.

The CSAR onboarding state machine defines the steps to onboard network service and function descriptors into an AWS TNB environment, which handles the file uploads, package management, and metadata storage.

The following Step Functions workflow outlines the automated CSAR onboarding process:

Figure 4. CSAR package onboarding Step Function workflow

First, the workflow checks the file path of the uploaded object. Depending on whether it’s a Network Service Descriptor (NSD) or a Network Function Descriptor (NFD), the workflow takes the appropriate next steps.

Second, for NSDs, the workflow first calls the createSolNetworkPackage API to create the package entry in AWS TNB. Then, it invokes a Lambda function to upload the actual CSAR file. The metadata associated with the package upload is stored in an Amazon DynamoDB table. Furthermore, the workflow lists existing packages, and updates the referenced NFDs.

Third, the process for NFDs is similar: the workflow creates the package, uploads the file, stores the metadata, and updates the references.

There is also error handling in place to delete packages if the upload fails. When the upload is successful, the workflow stores keys in a DynamoDB table to associate the uploaded objects with their respective packages.

Network service instantiation

When the NSD describing the deployment of a private network is available, CSPs can initiate the instantiation of the network service using Step Functions to orchestrate the AWS TNB APIs and perform custom tasks.

The workflow architecture is as follows:Figure 5. Network service instantiation Step Function workflow

The workflow begins by calling the AWS TNB GetSolNetworkInstance API to retrieve the details of the network instance using the provided instance ID.

Then, it calls the InstantiateSolNetworkInstance API to trigger the instantiation of the network service in AWS TNB.

The workflow monitors the state of the instantiation, waiting for the deployment to complete.

When the instantiation is successful, the workflow can apply more customizations or configurations to the network service using custom pipelines or CodeBuild projects.

By using a state machine workflow instead of directly calling TNB APIs, CSPs can gain several benefits. First, the improved orchestration and visibility over the entire network service instantiation and configuration process allows CSPs to better monitor the progress, identify bottlenecks, and optimize the workflow as needed.

Second, more robust error handling and automatic retries built into state machine workflows make sure of reliable and resilient deployment. This is because the workflow can automatically attempt to recover and retry operations in case of failures.

Network service instance termination

CSPs can use the Termination workflow to quickly and reliably terminate the instantiated network resources when needed. This helps reduce the overhead for customers to manually clean up resources, making sure of a consistent and efficient process for network service LCM.

Figure 6. Network service termination Step Function workflow

The workflow for network service Termination is as follows:

First, the workflow retrieves the details of the network instance using the provided instance ID. Then, it calls the AWS TNB API to terminate the network instance and stores the result.

Finally, the workflow invokes a Lambda function to check the deployment status, retrying on errors, and when the termination is complete, deletes the token record from the DynamoDB table.

This automated approach not only streamlines the termination process as compared to directly calling TNB APIs, but also makes sure of consistency and reliability, which allows CSPs to maintain a closed-loop of network service instantiation and termination. Furthermore, this workflow can be integrated with inventory management systems to update the application state of the deployed network, which provides a comprehensive view of the end-to-end private network lifecycle.

The workflows described earlier are packaged in AWS CDK, which makes them deployable in any AWS account. This allows customers to enjoy the same level of automation and streamlined network service LCM.

Conclusion

AWS provides CSPs that can create custom orchestration flow to deploy enterprise networks at scale. Building on AWS using AWS TNB, Step Functions, and EventBridge helps CSPs:

1. Automate ingestion and customize network function CSAR packages from ISVs.
2. Streamline instantiation of network services across multiple AWS Regions.
3. Deploy and configure event-driven end-to-end networks.
4. Terminate event-driven networks.
5. Package the automation workflows using AWS CDK, which enables consistent deployment and reuse across AWS accounts.
6. To have visibility, and end-to-end LCM of private network solutions and their enterprise customers.

To learn more about how CSPs are using AWS, visit Telecom on AWS.