Cloud-native disaggregation of mobile networks is a process which involves one or several of the following: migration of network workload to the cloud, separation of the software elements from the hardware and moving to a fully-containerised architecture. Our primary research confirms that for many operators, cloud-native disaggregation is an essential stage towards network automation; it can also be an arduous journey which tests organisations’ ability to change and transform themselves. This article explains why.
How do operators typically define cloud-native disaggregation?
When we spoke with mobile operators pursuing cloud-native disaggregation, we learned that there is no single approach to disaggregation and little consensus on how to define it.
First, cloud-native disaggregation can affect different parts of the network: the radio access network (RAN), the transport network (IP and optical), or the mobile core.
Second, cloud-disaggregation can cover different types of transformation:
- the disaggregation of hardware and software components, aka network function virtualisation
- the separation and abstraction of software components, i.e. separating the control plane and the user plane functions
- the move to cloud-native functions, i.e. to a fully containerised architecture based on microservices architecture.
Finally, the CSPs we spoke to had different drivers for disaggregation which ultimately mapped either to reducing cost, enhancing innovation or both. For many, having open interfaces in the network, i.e. having software that is hardware agnostic, was a goal in itself. This enables vendor diversification, allowing operators to pursue a best-of-breed approach when it comes to sourcing network elements and/or to negotiate lower prices or improved service quality and support. For others, disaggregation was driven by the desire to enable new types of services in the network, such as edge computing or dynamic network slicing. We have summarised these findings in Figure 1.
Figure 1: Operator definitions and drivers for disaggregation
Our primary research points to four main takeaways on the implementation of cloud-native disaggregation
Disaggregation and network automation are mutually reinforcing
Cloud-native disaggregation is deeply tied to automation. When our interviewees referred to automation in the context of cloud-native disaggregation, they cited automation within domains (which some operators have made significant progress on) but, more significantly, across domains. For example, an interviewee at a group operator described how their organisation had replaced a collection of management systems specific to different vendors and network functions with a single standardised system. For example, a Kubernetes-based platform that delivered management and orchestration of network functions across domains because those network functions had all been migrated to a micro-services architecture, i.e. cloud-native. This had allowed the operator to achieve greater automation in the provision, operation, management and orchestration of the operators’ networks and services.
Disaggregation and automation go hand-in-hand, but the purpose of disaggregation is not merely to automate and nor is the purpose of automation to disaggregate. There are other drivers for both disaggregating and automating the network. While you can have one without the other, many operators we spoke to were pursuing both, because of the role each plays in enhancing the other and delivering wider transformation to the network. In the view of one interviewee from a North American operator:
“[Automation, disaggregation] It’s a chicken and egg thing. You automate to enable you to disaggregate, but you disaggregate to enable not just domain automation but cross-domain automation”
For operators pushing network transformation with the goal of creating on-demand, self-orchestrating and intent-driven networks, cloud-native disaggregation and automation work together as mutually reinforcing transformation processes, enabling operators to reach these goals.
Management buy-in is essential in leading cloud-native disaggregation
In our conversations with operators, it was clear that those operators who were much further ahead in pursuing cloud-native disaggregated networking had significant leadership buy-in. This was critical and accelerated the initiatives and efforts at the technological level, but also at from an operational and cultural perspective.
This view was corroborated by Run Almog, head of product strategy at DriveNets, who agreed that “the benefits of network cloud from TCO, innovation and control are very clear from a leadership standpoint so once these are communicated to the right audience, the obstacles are removed.” In fact, we saw that in organisations where leadership had really bought into cloud-native disaggregation, there were fewer challenges from a people and culture perspective. Where executives took the time to set out a vision for the network that included cloud-native disaggregation, change was viewed by network teams and internal stakeholders as an important step in network evolution as opposed to a potentially detrimental break from conventional network operation approaches.
New replaces old: mindset change is needed to reap the benefit of cloud-native transformation
One of the challenges cited in our interview programme with operators is the need for a fundamental mindset change when it comes to the operating model for cloud-native networking. One operator interviewee we spoke to mentioned the need for network redundancy as an example of where and how operators need to change their philosophy when it comes to moving to cloud-native.
In this example, instead of having redundancy to deal with a failure incident, the operator cited the ability to kill an instance and build up a new one within 50ms. Given the level of granularity operators can potentially go down to with cloud-native disaggregation, operators can automate the recovery process and debug or heal an issue down to a single subscriber. In this context, there is a need for the network teams to embrace a different, more adaptive, approach in dealing with incidents in a closed loop fashion without the need for redundancy. In this scenario, operators can reduce the need for duplicating active resources, thus saving costs and simplifying operations. However, removing such redundancy is often an area of friction for operators from a mindset perspective, largely because it is seen as a risk and reflects a lack of trust in new approaches.
Envisaging change as an opportunity for better, not a challenge to overcome
More broadly, change involved in disaggregation is seen as the challenge to be overcome by some operators rather than the goal when it comes to establishing a cloud-native networking approach; this is often due to the reasons outlined above, i.e. legacy ways of thinking and working, as well as having other priorities.
The risks or challenges are always around when adopting new technology and this is also the case with cloud-native disaggregation. The learning curve and adoption of a new model changes organisational fundamentals which have existed for many years. The benefit is, quite obviously, breaking these existing paradigms which led service providers to a point where their existence shrunk to access pipelines while anything else in the ‘service’ is carried by other ‘providers’. Explicitly, the benefits are improved TCO, better control of the network and faster path to innovation
At its core, cloud-native disaggregation is about improving the operating of networks, but it brings with it the opportunity to work in new and innovative ways, with agile ways of working e.g. CI/CD pipeline, and to improve the adaptability of networks and network services. It also offers network teams, engineers and architects the chance to learn new skills and bring greater value to their work. To this point, Run shared that:
For those who envisage the change involved in disaggregation as the goal, becoming cloud-native in the network as well as in the organisational process and culture is an important and beneficial step.
Do you want to know more about our research in this area?
5G standalone: Has the party ended just as it began?
This article examines when, if ever, 5G standalone adoption will become widespread. We look at the insights from our Telco Cloud Deployment Tracker
Network APIs: Unlocking new value in the telco cloud
Network APIs may offer an answer to the question of how to monetise recent and upcoming telco cloud deployments. Virtualised networks upgrade APIs and enhance the value they offer to developers and customers. To unlock their potential, telcos should focus on optimising their commercial models.
Progress in telco cloud: How do we measure agility?
In the January 2023 update to our Telco Cloud Deployment Tracker, which was looking back at the entirety of calendar year 2022, we recorded an overall slowdown in deployments.