How Do CSPs Start Their 5G Automation Journey?

With the disaggregation of a closed construct, value begins to emerge. Examples of disaggregation abound, but white boxes, 5G Core Service-Based Architecture (SBA) and Open Radio-Access Network (RAN) are notable cases. Value chain disaggregation introduces inherent complexities and operational challenges. For example, in Open RAN environments, orchestration and automation of disaggregated radio access is a cumbersome task. Lifecycle management of Distributed Units (DUs) and Centralized Units (CUs) is not an easy endeavor as Open RAN adds more interfaces, network functions, and software components. Though there is more flexibility provided, there is an element of risk that Communications Service Providers (CSPs) need to understand. With ecosystem disaggregation and best of breed deployments, operational costs are expected to explode. Ericsson’s claim, for example, that a lack of automation can potentially increase network operations cost by 100–130% further drives that point home.

When looking at disaggregated value chain there are typically two approaches to avoid risk in business for CSPs. The first approach, as discussed in ABI Research’s insight A changing Telco Landscape from Core to Edge Networks, is to create pre-validated blueprints that aim to certify components from different vendors. Alternatively, CSPs can build automation into the design stages. The industry already has a rich history of automation. But with the right automation pillars, it can go much further to reap the benefits of 5G networks and manage them with the right resilience and Quality of Service (QoS). Further, RAN is the largest area in terms of operational costs for CSPs. Therefore, anything that brings automation platforms into RAN domain is important to achieve synergies and drive down cost to operate these networks.

There are two key strands to consider for intelligent automated operations in 5G: process digitization and process automation, in that order. Often these two terms are used interchangeably but digitization ought to be the first step. It is not possible to automate specialized and hardwired processes unless they can be read by machines. Further, there are typically four layers for automation: infrastructure layer, network layer, applications, and service layer. Each of these layers is a significant standalone domain for automation. For example, it starts from lifecycle management of radio elements, then leads to automating the compute infrastructure and capacity, and finally to managing the capabilities they will deliver and services that run on top.

Replacing manual processes and scripting with automation capabilities across these four layers in one fell swoop is not an easy endeavor. The path to the summit gets even steeper when considering that each suppliers’ automation solution is characterized by proprietary, and therefore different, naming conventions, data formats and interfaces. There are three technical constructs that can alleviate the challenge of bringing a broad set of players into some sustainable commercial relationship. They stand to better facilitate a fruitful discussion in an increasingly diverse supplier ecosystem anchored in a trio of suppliers: network equipment vendors (e.g., Ericsson, Huawei, Nokia, ZTE); hyperscalers (e.g., Amazon, Google, and Microsoft) and CSPs. The technical constructs are as follows:

• Interface specification: CSPs and vendors should know to specify which attributes, network function (NF) interfaces, and integration points are core for existing network operations and which ones are complementary. With a multi-vendor ecosystem, agreement and alignment is required to establish functional interfaces to do life cycle management of infrastructure, network, and application components. Moving in a different direction and at different time frames may not be ideal for smooth operability and serviceability of 5G networks.
• Component verifiability: Whether it is a single-vendor or a multiple-vendor automation strategy, it is important to establish cohesiveness of operations. That enables CSPs to monitor and measure automation capabilities and interfaces so that they can verify that operations specifications are met. With a multi-vendor deployment, as is the case with 5G Core and Open RAN, individual monitoring of granular network metrics and statistics may not come without challenges. In that case, automation capabilities require all-encompassing assurance and monitoring, which means that component suppliers must provide complete visibility of all necessary alarms and network Key Performance Indicators (KPIs). This will aid CSPs to avoid back doors that can give rise to (invisible) dependencies between apps and workflows.
• Interface predictability: Vendors will be required to work closely with CSPs’ operations teams to avoid any poorly understood or unpredictable interdependencies across NFs and interfaces. Whether it is a single-vendor or a multi-vendor 5G deployment, CSPs should be able to monitor how the inner components of their execution environment(s) will interact with each other. That enables them to run network operations with predictable consequences. But there may be times when there are complex and unpredictable interfaces in a 5G network. In that case a single-vendor, the ‘pursue automation by design’ approach that spans those interfaces may be more efficient from a Time-To-Market (TTM) and maintenance perspective.

There are two challenges that CSPs face for automation. One, CSPs typically look at automation as a cosmetic exercise to existing processes and workflows. That remains a challenge because CSPs have not considered automation by design, but rather as an afterthought. An equally important challenge in ecosystem automation is simplification. An undertaking to automate ‘everything’ is plausible. However, before CSPs take a holistic automation view to their operations and infrastructure, they need to simplify their approach on how they build automation. Specifically, they need to identify, and subsequently reduce, processes that cannot be automated by design. The more they simplify, the easier it will be for them to achieve end to end automation across all the layers of the stack. This is particularly important when considering billions of ‘things’ that stand to be connected in 5G networks.

Increasingly, CSPs need to meet different requirements for network connectivity, and they need to deliver that at the time their (enterprise) customers need it. Making that happen manually may not be easy. So solutions with calcified processes are certain to be refashioned, as are the overarching automation frameworks currently in place. To that end, Ericsson and Nokia are two vendors among many others that are bringing to the market Ericsson Intelligent Automation Platform and Nokia Network Operations Master, respectively. These solutions help CSPs digitize and automate the specialized, hardwired processes and workflows found in their operations. Further, to achieve simplicity in operations, vendors should help CSPs identify a set of parameters that are common regardless of site, radio equipment or hardware/software. This will go a long way to achieving infrastructure, network, and service automation across any (cloud) platform, abstraction, or application.

For vendors, the key takeaway is to be clear on two strands: one, what are the benefits that CSPs will get from automation solutions; and two, how will they realize ecosystem simplification to realize those benefits. Vendors should guide their CSPs partners towards clarity on what they are aiming for in their automation journey. Further, in addition to selling technology, vendors (e.g., Ericsson, Huawei, Nokia, ZTE) should aid their CSPs’ partners to adopt automation capabilities by design. Dish, though a greenfield CSP, is a good case in point. Dish maps out the entire value chain of a customer journey. Then they list the automation requirements that realize that journey in a simple, end-to-end fashion. Rakuten and Telefonica follow a similar approach. Brownfield CSPs, on the other hand, should ensure that solutions they adopt are easy to implement whilst keeping customer requirements in mind. A foundation on the three technical constructs this ABI insight outlines goes some way to realizing that.