End-to-End Cloud-Native Automation Poised to Redefine Telco Networks—How Should CSPs Forge Ahead?
31 Jul 2023 |
IN-7002
Log In to unlock this content.
You have x unlocks remaining.
This content falls outside of your subscription, but you may view up to five pieces of premium content outside of your subscription each month
You have x unlocks remaining.
31 Jul 2023 |
IN-7002
Telco Automation Maturity Journey |
NEWS |
5G networks continue to act as catalysts for accelerating automation adoption due to their requirements for cloud-native tooling, redefined network architectures, and new consumer and enterprise services. 5G also natively introduces increased digitization, in turn creating more business processes and interfaces. This native digital setting has a richer and more complex network plumbing. In fact, it is reported that 400+ network procedures need to be tracked in the 5G era, each with its own dedicated Key Performance Indicators (KPIs). That means that network parameters, processing algorithms, and the number of alarms are expected to grow, increasing Communication Service Providers’ (CSPs) operational complexity. For example, Huawei notes that there will be more than a tenfold increase in Call Data Records (CDRs) from 4G to 5G. According to Ericsson, an upsurge in data and network KPIs increases network operations costs by 100% to 130%.
The above factors mean that CSPs must increase their levels of automation to redesign their operations based on cloud-native architecture and technologies. However, CSPs’ automation maturity journey is as much about technology innovation as it is about implementation challenges, in other words deploying End-to-End (E2E) network automation. More specifically, ecosystem fragmentation, change management, and highly customized networks built upon siloes are currently the top three challenges CSPs face in their automation journeys. This ABI Insight explores some learnings from CSPs’ efforts, to date, to achieve cross-domain E2E automation in their networks and service operations.
From Single-Domain to Cross-Domain Automation |
IMPACT |
Implementing automation for CSPs means accommodating significant change in their operations, constant trial and error, and the ability to fail and learn fast. But it promises to reduce Operational Expenditure (OPEX) and Capital Expenditure (CAPEX). Vodafone, for example, reports savings of €500 million from automating back-office functions. Another example is Deutsche Telekom (DT). Partnering with Netcracker, DT implements automation in its core network, among other domains. On the whole, most CSPs implement automation on a per-domain basis. Increasingly, however, CSPs are targeting E2E, best-in-class automation stacks in a bid to break down siloes. However, only a few Tier Ones can afford employing experienced software developers and the significant resources required for E2E best-in-class automation stacks. Bell is an example, among a few others. Most other CSPs’ attempts have not been as successful with E2E best-in-class automation stacks. Reasons vary, but chief among them are incompatible Application Programmable Interfaces (APIs), diverse technology stacks, siloed business units with their own commercial objectives, and different costs for every product in the automation stack.
A common and often posed question is how much automation has been achieved to date. That is a function of which domain CSPs seek to address first. As a rule of thumb, priority domains appear to be access and transport domains, which are high-density in terms of edge Data Centers (DCs) and cell site footprint. Access and transport constitute approximately 80% of tickets that can be automated in terms of optimizing overall operations. By contrast, the core network poses a bigger task because a single change can have an impact on thousands of subscribers. So, it is recommended to approach with caution. Implementing automation is a technical challenge and an easier one vis-à-vis what to automate. For CSPs, evaluating what can and/or cannot be automated by design is essential. That is important, particularly when we consider that today’s network design, fulfillment, and maintenance are highly disjointed. They often require manual interventions and inter-departmental handovers.
As for vendor selection, for some CSPs, architectural-based differentiation typically around functionality, reliability, and convenience is key. Regarding convenience, what matters is this: 1) a vendor’s positioning to establish interoperability with the wider supplier ecosystem; and 2) automation portfolio scope across several domains. A strong system integration services practice to alleviate CSPs’ business risks and the ability to integrate best-of-breed products with core business activity are key aspects worth considering. So is a vendor’s ability to bring learnings from other domains; for example, the relevance of cloud-native tooling and APIs to aid CSPs with adopting highly efficient practices as they redefine their networks. The broader vendor landscape and how it helps CSPs establish their own automation blueprint will be explored in an upcoming ABI Research competitive assessment report.
Learnings from the Industry |
RECOMMENDATIONS |
There are a range of automation projects set by CSPs and vendors, as well as numerous industry initiatives by standard bodies, including the TM Forum. Some key lessons are emerging from these efforts. Ultimately, CSPs will obtain the most benefits if they implement automation in an E2E fashion—either across all layers within a single domain or across all layers in a cross-domain setting. Implementing automation partially may not introduce large-scale benefits. For example, replacing an old workflow-centric orchestration task introduces some operational efficiency, but keeping an old hard-coded assurance process in place does not improve the rigidity of the entire stack. Below, ABI Research outlines three potential key areas that CSPs should focus on as they forge ahead with their automation investments:
- Obtain Awareness of Overlay Applications: Today, most automation tools for underlay networks and/or infrastructure have no awareness of the applications that run on top. Limiting observability to just the underlay infrastructure level does not help connect network resources to higher-level service abstractions and applications. So, there is a growing requirement in the market for solutions that enable CSPs to tie the application layer for user experience and app performance with the resource layer for low-level resource lifecycle management.
- Avoid a Narrow Automation Scope: Many automation products in the market automate new technologies. Cloudify is a case in point, as a platform that offers an Environment-as-a-Service platform to manage any cloud environment. However, even a siloed automation scope like this, limited to a single technology (e.g., the cloud in Cloudify’s case) will interact with some part of the existing brownfield landscape. CSPs should avoid being isolated in a silo, or avoid locking themselves into just one technology, by requesting that their suppliers automate legacy technologies and emerging ones.
- Identify Whether to Obtain Standard System Integration or Non-Standard System Integration Services: Some vendors (e.g., Ciena Blue Planet) offer a suite of system integration services around their own logos. Others (e.g., Amdocs) offer a full range of system integration services, including program management not just around their own logos, but also those of their competitors. Which suits best is a function of the CSP’s ability to use sophisticated cloud-native tools, and the maturity to agree on technology decisions across organizational units. In the end, irrespective of the type of system integration services, automation suppliers need to enable CSPs to automate horizontally across domains, and vertically across all layers of the stack to maximize operational efficiencies and/or improve market share or revenue.
This ABI Insight presents some learnings that have resulted from automation initiatives to date. These insights go some way in highlighting a way to adopt cloud-native automation, rather than the way to do it. One thing is for certain: an all or nothing approach may well preclude CSPs from taking the first steps in their journey toward E2E automation stacks. Greenfield CSPs like 1&1 (Germany) DISH (United States), and Rakuten Mobile (Japan) may face less friction during that journey. Brownfield CSPs like BT, Telefónica, and Telenor should pursue a path that aligns with their unique circumstances—their business, their market strategy, and their customers.