In our previous blog, we discussed how to stay focused when requirements are changing as you design your 5G core and RAN environment. In this blog, we will discuss how Telcos can build flexibility into the architecture and design.
Solutions are aligned to requirements
Common sense tells us a solution should not be more complex than necessary. To minimize that complexity, we need to get the requirements right. The theory tells us to spend time on requirement gathering, then to confirm those requirements with relevant stakeholders. This process is crucial for Telcos when designing and building complex systems such as an O-RAN networks.
Telco projects are inherently complex. For instance, a 5G core may involve ten different types of network functions (UPF, AMF, SMF, NRF, etc.). In addition, very few projects are greenfield, and operators need to add additional complexity to deal with legacy 2G/3G/4G functions, their data centers, and their applications. When the technology is new and unfamiliar, things get more complex. On top of that, a third level of complexity is added by introducing cloud native architectures. With such a complex environment, it is imperative for large projects like a 5G core or a 5G RAN to come with a predetermined set of requirements from Telcos, Operators and Communication Services Providers (CSPs).
The architectures that VMware recommends involve not only new products, but also concepts that are new to CSPs, like Software Defined Data Centers, Software Defined Networking, Software Defined Storage, Network Slicing, Network Functions Management, Orchestration, etc. To manage this complexity, Telcos need to maintain a clear alignment between the feature or components of the solution and the requirement that justifies it. For every element that we introduce in the solution, we need to be able to point to the business outcomes, use cases, and/or requirements that make that element a necessity. However, we are not saying that for every requirement a new element should be introduced in the solution. Our goal is to make these transitions as painless and simple as possible.
Going beyond the known requirements
We believe elements introduced in the solution should be justified by a specific requirement or business need but retain flexibility to be able to be used for future (though still unknown) requirements. Open APIs and programmable platforms may be used to address new requirements in modern networks. New components that are flexible, adaptable, or programmable may have been first justified by a specific requirement, they also have the built-in power to prepare the future. When the requirements change again, you want to have more options to be able to make a decision that is best for your current environment. And you want to make this decision by leveraging the ability to use the existing platforms to handle the new requirements, or to add another component in the design.
When facing a new requirement, it is up to CSPs supported by VMware’s designers and architects to make judgement calls on whether to make the solution more complex, but more flexible (e.g., introducing a new component) or if it’s possible to utilize the flexibility that has already been built-in (e.g., writing a script for an existing component).
Choosing the right approach to solve complex problems
In our last blog, we described a project that included a Continuous Integration/Continuous Deployment (CI/CD) platform for an O-RAN deployment. This automation tool was seen as essential for the customer to deploy CaaS infrastructure and onboard CNFs such as Distributed Units (DU) on that infrastructure in hundreds of sites. The CI/CD pipeline was composed of VMware’s automation tools, based on industry standards, and included many open-source components and open APIs. It was built with components that are programable and assembled in a way that enabled that flexibility. It allowed for additional scripts to be added and enabled components to be swapped for another if needed. This is the beauty of enabled interworking through open interfaces and its ability to help plan for the future.
The platform was flexible enough that it could be reused by programming CI/CD pipelines not just for initial deployment, but also for every lifecycle operation.
vSphere, TCA (Telco Cloud Automation), and CI/CD might have seemed like unnecessary complexity until, in a major shift of strategy, the customer made an unprecedented move and entered into a major agreement with a public cloud. This business decision trickled down and suddenly directives were given to move as many workloads as possible to the AWS public cloud.
Each public cloud has their own proprietary implementation solution and AWS is no exception. Moving workloads to any of the hyperscalers might have called for a substantial redesign of the automation framework and rewrite of automation scripts, but vSphere and TCA had enhanced our solution’s flexibility. Thanks to their flexibility, the migration to AWS could be done with VMware Cloud on AWS. It was much easier to take the existing implementation and move it to the cloud, and it also allowed for the company’s investments into the CI/CD platform to be re-used. A major change in distribution of components was possible, with minimal changes to the design.
This CI/CD model has since been used as the basis for similar projects with other CSPs. Its architecture was not just flexible enough to resist to changes in one operator’s network, it could also be adapted to other operators.
Of course, flexibility might come at a cost. A balance must be found between complexity, flexibility, and other characteristics of the architecture. VMware Professional Services is here to help our customers attain this balance. In our next installment, we will give more specific recommendations of best practices that we have learned.
Can’t wait for more? Check out this eBook on modernization!
