The telecom industry is witnessing a massive shift towards virtualization and cloud technologies. Software Defined Networking (SDN) and Network Function Virtualization (NFV) will soon encompass all segments of the network and become pervasive over the next few years. Agility in all facets—be it service lifecycle management, onboarding and management of (physical and virtual) resources, network (re)configuration, sustaining QoS compliance levels, improving end-user experience, and providing highly-personalized services—has become very essential for telcos to retain the competitive edge while optimizing both OPEX and CAPEX.
The proliferation of 5G deployments over the next few years brings complexities: scale; densification; multifaceted heterogeneity in access types, xhaul (fronthaul, mid-haul, and backhaul), spectrum bands, and deployment variants; a wide diversity of use cases; the need to cater to industry vertical–specific (custom) requirements; the cloudification of RAN and edge deployments; and new security challenges. Another essential feature of 5G is Network Slicing, which aims to address the requirements of the wide diversity of use cases in an optimal manner.
From a communication service provider (CSP) perspective, despite all the complexity, service rollouts are expected to improve by orders of magnitude and be completed in tens of minutes. Service assurance is expected to be achieved at an optimal cost with minimal (ideally no) human intervention. From an end-user perspective, making the quality of experience proportionate to the subscriber class and service priority have become a prerogative.
The above aspects make end-to-end orchestration imperative, be it for services or the network slices catering to those services. This paper examines the evolution of the orchestration space and its trends, looks at a commonly followed solution approach in line with the trends, and briefly touches upon Wipro’s offerings to address OEM, solution provider, or CSP needs.
Evolution and Industry Trends
Telecom service providers today are inclined to use fully open source–based management and orchestration solutions. However, at present, open source–based orchestration products and solutions are not fully production-ready with the required carrier-grade features. On the other hand, OEMs are keen to leverage the years of investment made in building network management and orchestration products and components and are willing to consider open source–based components and solutions to complement their product capabilities and ensure wider interoperability.
Analytics, artificial intelligence (AI), and machine learning (ML) are all touted to play an important role in the facets of orchestration—service fulfilment, configuration, network slicing, service assurance, and SON. Regardless of the approach chosen, the following aspects are essential from the perspective of service orchestration in the context of 5G and beyond networks.
Network Slicing
Network slicing is gradually gaining prominence, and vendors and service providers are viewing it as an essential capability to achieve the value promised by 5G in an efficient and cost-effective manner. The industry is witnessing initial realizations of network slicing, while truly dynamic, adaptive, and federated end-to-end network slicing may still be some time away. Different architectures and approaches are being proposed to realize network slicing. The figure below illustrates a few possible options to realize the slice management functions specified by 3GPP.
Figure 1: Network slicing orchestration options
While 3GPP standards related to network slicing are evolving, IETF and MEF are addressing transport slicing, and the O-RAN Alliance is working on the RAN slicing functionality.
Intent-based networking
Intent-based networking aims to simplify the operator tasks with respect to network operation and service rollouts while ensuring operational efficiency and SLA adherence by the network. It also eliminates human intervention as well as human errors. Thus, intent-based networking is an important enabler for network automation.
As can be seen in Figure 2, an intent translation engine maps the operator intent into a set of high-level policies and network-level configurations. This is then broken down into operational, control loop, and domain level policies and configurations. After the network functions are configured and the intent is fulfilled, continuous monitoring and feedback to the intent translation engine ensures that the intent translation engine adapts itself and autonomously improves the extent of intent fulfillment over time.
Figure 2: Intent-based networking
Network Automation and Closed Loop Control
Network automation and closed loop controls are leap-frogging operational efficiency while ensuring end-customer satisfaction is at an all-time high. Standards bodies, such as ETSI, have also started addressing many aspects of this through zero-touch network and service management (ZSM)1 trends. The need for network automation is captured in Figure 3.
Figure 3: Need for Network Automation
Many network automation requirements can be realized through closed-loop control. Thus, closed-loop control is imperative for service providers as well as enterprises and industry verticals. Closed-loop control is an evolutionary path, as outlined in Figure 4. The industry has been witnessing this journey over the last decade, and at present for individual domains, the industry is taking rapid strides in Stage 4, whereas from an end-to-end or multi-domain orchestration perspective, there is considerable ground to cover before Stage 4 can be attained. Another dimension of closed-loop control is effectively predicting fault and performance issues and addressing them before they occur. While prediction exists already today in many use cases, there is still a need to predict service degradation by examining data from different network segments and correlating them with non-network data.
While analytics, AI, and ML are already playing a key role in network automation, their role will further increase in breadth and depth. Given the network densification and heterogeneity of 5G, enormous amounts of diverse data have to be collected and analyzed. With the need to perform near-real time prediction and subsequent resolution, the velocity of data will also be very high. This necessitates performing data collection, aggregation, analysis, and closed loop control actions at the appropriate place in the network for optimum results.
Figure 4: Evolution of closed-loop control
Self-Organizing Networks and Autonomic Networking
Although self-organizing networks (SON) have existed for quite some time, they are expected to expand in scope beyond radio access networks (RAN). The industry is also witnessing disaggregated SON with dedicated cloud-native functions performing specific SON-related functions. This offers greater flexibility, reuse, and loose coupling, thereby accelerating time-to-market as well as catering to different deployment configurations. SON functions may be located at the edge of the network with coordination performed either centrally (by a central entity) or autonomously through east-west communication. Further, the use of AI and ML is expected to improve the effectiveness of SON for self-configuration, self-optimization, and self-healing from a network segment as well as the end-to-end services and slices, thus paving the way for truly autonomic networks in the future.
Interoperability
Interoperability of network functions and segments has been a concern for quite some time. With the increase in softwarization of the network, this has become more important not just from an interface between network functions, but even the components inside network functions that can be supplied by different solution providers. While standards bodies, such as ETSI, TMF, IETF, MEF, 3GPP and recently the O-RAN alliance, are working to standardize the interfaces, the ability to insert new components in a plug-and-play fashion is essential. In order to achieve this, open interfaces and adaptors/plug-ins must abstract the functions behind these interfaces.
Another facet of interoperability is the increase in interaction of the orchestration functions across domains, which is again, necessitated by softwarization of the network. For example, the RAN controller has to interact with the NFV orchestrator (NFVO) for the RAN virtual network functions (VNF) lifecycle management and service chaining. Similarly, the RAN slice subnet management function has to interact with the NFVO as well as the transport slice subnet management function for RAN VNF allocation and xhaul slice subnet allocation respectively.
Cloud-native Approach
To fulfill service provider goals of end-to-end orchestration and network automation in the rapidly evolving technological landscape, there is a need for a loosely coupled architecture that integrates the best components quickly in a plug-and-play fashion, as we see in different X-as-a-Service models. Further, the industry is also seeing a convergence of service fulfilment/service assurance functionality with network automation. One of the key enablers for addressing this need is a cloud-native approach. This is the reason the entire telecom industry is seeing a shift towards a cloud-native architecture in the control and management layers. From an orchestration perspective, apart from the components being implemented in a cloud-native manner, the architecture should also aim to reuse the capabilities that exist in open source with respect to platform functions, such as service mesh, API gateways, and containers, to address many non-functional requirements faster. This is essential to accelerate the time-to-market by focusing on the core features and differentiators while leveraging the best of open source, such as Docker, Kubernetes, and Istio, to name a few.
Solution Approach
In the context of 5G wherein SDN and NFV are assumed an integral part of all network segments, the industry is also witnessing a hierarchical orchestration at least from a logical perspective to address the key elements discussed earlier. Figure 5 shows a typical end-to-end orchestrator. The functional blocks can apply to an open-source architecture (such as ONAP2) or other commercial and vendor product(s). This architecture enables loose coupling between the components, realizing them in a truly cloud-native manner, and supports different types of deployment configurations. The domain orchestrators can be either functional blocks within the end-to-end orchestrator or distinct external products interacting with the end-to-end orchestrator.
Figure 5: End-to-end orchestrator: Functional architecture
Trend | How it is addressed? |
---|---|
Network slicing | Network slice orchestrator depicted as a separate component within the end-to-end orchestrator, which can also be integrated within the service orchestrator or realized as a stand-alone component outside the end-to-end orchestrator. Regardless of the solution approach, standard interfaces and functional split ensure interoperability particularly in a multi-vendor environment spanning different network segments. |
Intent-based networking | The intent translation engine shown to be a part of the end-to-end orchestrator shall interact with both design (e.g., service design) and run-time functions (e.g., Policy component to specify config, operational, and control loop policies; service orchestrator for service requirements and SLAs; slice orchestrator for slice requirements; data collection engine to monitor and report intent fulfillment through specific KPI adherence). |
Network automation and closed-loop control | The following components of the orchestrator play a key role in Closed-loop control:
|
Self-organizing networks and autonomic networking | As the scope of SON expands beyond just the RAN, orchestrators (service as well as domain) shall play a key role in SON realization and, in some cases, perform C-SON functions. Even if the C-SON functions are realized as stand-alone component(s), the orchestrator will play an important role in providing additional data points, as well as to implement some of the actions recommended by the C-SON function. |
Interoperability | To achieve interoperability in a plug-and-play fashion to accommodate enhancements and customizations to specific interfaces, there will be a need for plug-ins or adaptors. From a time-to-market perspective, it is important that the core orchestration functions are agnostic of interface-specific variations as long as the functionality and capabilities exposed and consumed remain the same. |
Cloud-native approach | From Figure 5, it is evident that the components in the illustrative functional architecture have been chosen to enable loose coupling, independent scaling, addressing service fulfilment as well as service (and slice) assurance. |
Wipro’s Offerings
Wipro helps deploy existing solutions across many different scenarios. Wipro’s orchestration offerings help organizations realize the following management and orchestration solution variants:
Further, Wipro’s re-usable test assets optimize verification and system integration efforts, thereby accelerating time-to-market for our customers.
References
1https://www.etsi.org/technologies/zero-touch-network-service-management
2http://wiki.onap.org