Telcos are complex and therefore need solutions that have the flexibility required to enable them to succeed. Over the years, we have developed specific recommendations on best practices, or heuristics, that can be used on future projects, so that you can be agile and efficient as you move toward the Telco 5G cloud.
System Architecting has sometimes been described as the art of bringing structure to an ill-defined problem. This contrasts with engineering, which could be described as optimizing for project requirements. In our work, we have the privilege to do both for our customers. Here are some of the best practices we have developed in dealing with change in our O-RAN projects to help you navigate this ambiguity.
Remember the objectives and end goals
Take the time to understand all your objectives, which are sometimes explicitly expressed and sometimes not. For example, instead of focusing on how many parallel sessions can be supported by a VNF manager instance or how many replicas of a pod can be deployed to process “N” number of provisioning requests, architects should focus on how many network functions can be deployed in a workday or in a maintenance window. You need to focus on the main outcome that is important for the business. During requirements validation, always ask what the objectives and end goals are.
Have alternative options in mind
New ideas, new constraints, and new requirements will often emerge during the project. Some will be triggered by interactions between VMware and the CSPs, and it is important to be prepared. For important use cases, it is a best practice to present alternate designs and discuss jointly what the benefits and drawbacks are of each option to converge on design recommendations.
When making a recommendation, do not be overly attached to it. Sometimes you must deploy both options. Sometimes requirements change over time, and you must migrate from one option to the other. Other times, you may have different requirements in different locations, use cases, or 3rd party vendors, and need to choose different solutions in different areas. Sometimes, you just have to go with it. We have seen this many times. For instance, when determining the location to deploy the CNF/VNF of an O-RAN solution, the standard allows for multiple split options and placement of CU-UP, CU-CP, or DU. In some cases, all are deployed at the far edge and in some cases the CU-CP may be deployed in a central cloud location. The split option that is best in a rural market may be different than the solution that is optimal in an urban environment, for example, and the same operator may choose both designs and use each in different places in their network.
Keep the doors open as long as you can
A famous System Architect once praised “the agony of decision” when talking about keeping options open for as long as possible in the design and implementation phases. For the task-oriented architect, it is exceedingly difficult not to focus on solving problems related to technology when the concern is first raised. However, getting locked into a solution too early often creates unnecessary complexity.
We commonly see this when looking at innovative technologies where the ecosystem is still evolving. The RAN Intelligent Controller (RIC) of O-RAN is an example. The concept has been discussed in the industry for over five years, but the standards are just emerging now. An operator might have been tempted to choose and deploy a pre-standard RIC early on. For many, this would have been premature, and the benefits of early deployment need to be weighed against the benefits of operating a standard and widely deployed solution. Deciding the best moment to jump in and invest is part of the art. During the period before the decision is made, many other decisions are held off and uncertainty can be draining. Our natural tendency may be to make early commitments, but the rational thing to do is to wait until the ecosystem becomes mature.
Finding the balance: simplicity and flexibility
Customer requirements may have been expressed in a rigid way. However, a flexible solution is key to a successful design. 5G solutions should be built around an eco-system that is flexible enough to accommodate any minor changes during the lifecycle of the project. This may mean choosing components that are open and programmable. It may also mean introducing a new component rather than stretching the capabilities of an older component beyond its natural use case.
One such instance is the VMware Telco Cloud Automation (TCA) product. It was justified by the CSP’s need for an ETSI compliant NFV-Management/Orchestrator (MANO) platform, as they were looking to onboard functions with CSAR files through a SOL005 interface. When the CSP later decided to deploy Container as a Service (K8s) infrastructure, management clusters, workload clusters, node pool etc., were new requirements. We might have been tempted to say that the existing Cloud Platform was obsolete (before being used), and to replace it, but TCA proved extremely useful in facilitating these additional tasks.
Later it became clear that hundreds of clusters would need to be deployed, and user inputs should be collected by some wrappers and posted for cluster provisioning. We were able to leverage TCA North Bound APIs and introduce a CI/CD pipeline and realize the automation.
We only introduced this product because there was a clear need for it. It was also important to implement a platform that was flexible enough to enable multiple additional use cases that had not been initially foreseen.
Anticipating future requirements is important and what may feel like unnecessary complexity early on may prove to be precious flexibility later.
Balance Performance and Flexibility
Faced with a performance goal, the engineer’s natural reaction is to optimize that metric. Best is sometimes the enemy of good and you should instead practice creating a robust design that offers acceptable performance over a wide range of requirements as opposed to creating a high performance but fragile design. The overoptimized design would not be optimal if the strategy changes or if use cases shift over the lifetime of the project.
We recommend taking an alternative approach, where performance of the overall solution fulfils most use cases with adequate performance providing better ROI. In the graph above, requirements change over time. Adapting to all the changes in design and achieving high performance sometimes makes the design more fragile. But a design may not appear fragile until it really reaches a breaking point. The flexibility needs to be built into the design.
Begin the way you plan to finish – successful!
When dealing with change, flexibility is important. The flexibility we had built with vSphere, TCA, the CI/CD platform, and the other VMware tools helped everyone tremendously in handling major requirements changes (such as AWS) with minimal changes to the architecture. Any time we help our Telco customers make a smooth transition to 5G, it’s a journey. But this journey is a fun one; one we look forward to making every time.
Check out the other blogs in this series for information on heuristics while designing 5G core and RAN and evolving a 5G core and RAN design with changing requirements. As always, we are here to help you! Visit Telco Services to learn more.
