Service management and orchestration, or SMO, provides the crucial automation necessary for Open RAN architecture. It enables telcos to automate tasks in the network to reduce costs and increase returns. However, only open RAN architectures use this concept, leaving out 98% of the present networks. In this article, you can read how to implement Service Management and Orchestration framework for regular RAN architectures. 

Automation in network operations

Contents [hide]

• 1 Automation in network operations
• 2 Open RAN architecture and SMO
• 3 How to implement SMO on 100% operator networks?
• 4 How to accelerate SMO adoption?
• 5 Functions of service management and orchestration platform
• 6 Service management and orchestration market
• 7 Conclusion
• 8 FAQs

Fig 1: Benefits of RAN automation for telecom firms

Image credit: rantcell.com

As telcos become more powerful, they become more complex. For example, the rise of mobile applications has driven CSPs to provide more complex services for both consumers and enterprises; this complexity necessitates automation. Moreover, technological evolution has caused multiple RAN generations within a network; the small cell-based networks have also increased the network elements CSPs have to manage. Therefore, you need a robust method for automating RAN functions.

Open RAN architecture and SMO

Open RAN architecture can disrupt the telecom industry once it passes the early stage. Only a few startups plan to deploy a hundred percent open RAN, and a few leading companies are performing Open RAN experiments at small scales. 

The O-RAN Alliance published the Open RAN architecture to make telecom infrastructure vendor agnostic, improving collaboration and reducing costs. They have defined several open interfaces in the architecture, named O1, O2, A1, and R1. These interfaces connect to the SMO framework that includes the non-real-time RIC component.

ORAN Components:

• Service Management & Orchestrator: A component that manages RAN automation suing O1, A1, and O2 interfaces.
• Non-RT RIC: A non-real-time controller for optimization of RAN elements, resources, and AI/ML workflows and a policy-based guide for near-RT RIC.
• Near-RT RIC: A controller that enables near-real-time optimization of RAN elements using fine-grained data collections and the E2 interface.
• O-CU: This component has two sub-components: Control Plane and User Plane; they are responsible for hosting RRC, SDAP, and PDCP protocols. 
• O-DU: This component hosts RLC, MAC, and High-Physical layers.
• O-RU: A component for processing RF signals.

The zero-touch operations are necessary for 5G and IoT functionalities. This requires modifying the service layer of the traditional operational support systems; Service management and orchestration framework is the key. 

Fig 2: SMO platform

Image credit: ericsson.com

The current challenge is to use the Service Management and Orchestration framework shown above on the existing purpose-built RAN networks; this means using the non-real-time RAN intelligent controllers or non-RT-RIC and the rApps. The rApps are the automation software for non-RT-RICs.

SMO Interfaces:

• R1 interfaces enable portability for multi-vendor rApps. Their services include service registration and discovery, authentication and authorization, and AI/ML workflows.
• A1 interface provides fine-grained policy services, including changing the frequency of the user equipment. 
• O1 interfaces support all the operations and management functions, including fault, configuration, accounting, performance, and security management. 
• O2 function manages the O-cloud infrastructure where you host the ORAN functions. It provides inventory, monitoring, provisioning, software and lifecycle management services.  
• Open Fronthaul M1 plane is an alternative to the O1 interface for managing functions like startup installation, software management, configuration management, and performance management. 

How to implement SMO on 100% operator networks?

We can use SMO architecture to recreate Centralized Self-optimizing Networks (C-SON) and Network Design and Optimization (NDO) for RAN automation. According to a LightCounting report, existing C-SON applications will become RIC applications.

Using the rApps in Open and Purpose-Built RAN can improve the scalability; scalability is a significant barrier in adopting SMO. 

It is necessary to have only one service management and orchestration framework to manage the Open RAN and the multiple vendors in an operator’s network. Otherwise, you will only increase the complexity and reduce the efficiency if you use an SMO for each vendor. A single SMO with the A1 and O1 interfaces can manage all the networks, including Open RAN and other vendor networks. 

How to accelerate SMO adoption?

We can accelerate the deployments of SMO using the following methods:

• To create the most impact from automation, deploy service management and orchestration framework in complex networks.
• Reduce overall expense by targeting automation with the highest operational cost.
• Accelerate deployments using the existing CSON and NDO automation applications.
• Use the best software from various developers; search and test several from various places, including partner development ecosystems and marketplaces. 
• Ensure that SMOs are deployed in Open RAN and purpose-build RAN networks, thereby improving 100 per cent of networks.  

Besides this, CSPs must consider the following design principles to get ahead with Service management and orchestration:

• Use an intent and model-driven orchestration where the workflows depend on a catalogue. Experts are not required to implement the SMO framework. 
• Integrate a cloud-native architecture that runs container-based services, resulting in various benefits, including on-demand scaling, rapid deployments, faster upgrades, and better operational efficiency. 
• The SMO must be capable of using AI to automate operations in a closed loop, including detecting issues and solving problems without human intervention. 

Functions of service management and orchestration platform

Fig 3: Elements and Benefits of an SMO platform

Image credit: netcracker.com

O-RAN has several definitions for SMO; a platform for rapidly developing applications is one. A data collection platform is another definition where the platform manages RAN data and mediates O1, O2, and A1 interfaces. O-RAN defines SMO as a licensing, access control, and AI/ML lifecycle management support that uses northbound interfaces. SMO also handles service orchestration, inventory, topology, and policies. 

The SMO platform comes under the Operation and Support Services (OSS) in the Open RAN architecture; according to Zero-touch Service European Telecommunication Standards Institute (ETSI), the SMO is a domain controller for RAN operation and management. SMO can be deployed on-premise or on the cloud as a service. 

This SMO supervises the management of the lifecycle of network functions and the O-Cloud using a non-real-time RIC. 

The service management and orchestration implement automation at scale to reduce complexity and improve performance, enhancing customer experience. Service management and orchestration manage RAN services as intended. 

SMO can handle existing purpose-built RANs using specific southbound interfaces. 

Service management and orchestration market

According to the Lightcounting report, the SMO market will rapidly grow during 2024-25, providing huge opportunities. 

Stéphane Téral of LightCounting Market research said, “The RIC and SMO market take off that we anticipated by year-end is not materializing, and instead, SON keeps shining while RIC, baked in the O-RAN Alliance, is being pushed out by the global Open RAN market lull until 2024. Regarding the SMO, a need to cover all radios rather than just shiny open RAN radios is emerging and delaying its adoption.”

Conclusion

The rapid evolution of markets places enormous demands on networks, making service orchestration necessary. CSPs need to deploy new features and services quickly. They need to roll out upgrades faster, and this need will only increase as 5G becomes more popular. 

Network functions are becoming cloud-native, and multiple vendors are entering the market; this increases the complexity. Therefore, we need a new layer mediating functions between the business support system (BSS), the operation support system (OSS), and core, edge, and transport network domains.

Real-time end-to-end service management and orchestration framework are necessary to realize the full power of 5G. CSPs can then automate the cross-domain service. 

To learn more about STL’s Managed Services, click here.

FAQs

1. Why do telecom companies need to focus on automating RAN functions?

Telecom companies need to drive their focus on attaining automation of RAN functions. It is to ensure streamlined workflow, custom satisfaction, accurate outputs, increased speed, reduction of cost and enhanced business productivity. Thus, automating RAN functions will make it easy for the telcos to handle complex service requests. 

2. What are some of the primary components of ORAN?

ORAN architecture is a perfect deployment for enhancing the service potential of telecom companies. Some of the primary components of ORAN architecture that contributes to this execution are:

• Near-RT RIC
• Non-RT RIC
• Orchestration Management
• Service Management
• O-CU
• O-DU
• O-RU

3. How can we accelerate the adoption of SMO platforms?

We can accelerate the adoption of SMO platforms by ensuring some critical practices, which includes:

• Creating the maximum impact out of automation. 
• Deploying the orchestration and service management framework upon complex networks
• Reducing the overall expenses by targeting automation
• Boosting deployments with the use of NDO and CSON automation
• Use the software that is provided from the best of developers. 
• Ensuring that SMO gets deployed only within purpose-built RAN or ORAN networks.

4. Why should we integrate cloud-native architecture that runs container-based services when implementing an SMO platform?

By integrating the cloud-native architecture for running the container-based services while deploying SMO platform, ensures rapid deployments, on-demand scaling, better efficiency in operations and quicker upgrades. 

5. What are some of the primary functions of an SMO platform?

The primary functions associated with the SMO platforms include closed-loop control, hybrid delivery service, model-driven orchestration and real-time assurance. It also simplifies the multi-vendor interactions, accelerates the time-to-market and optimizes OPEX & TCO. SMO is a service-agnostic deployment strategy, which is driven by intent and has open APIs for added efficiency.