Skip navigation
Like what you’re reading?

Want to get ahead in service management and orchestration?

Service management and orchestration (SMO) is an exciting and innovative development in our industry. A new concept defined within the Open RAN architecture for RAN management, SMO provides automation and orchestration of the Open RAN domain and is critical for driving automation within the operator network. We explore how to extend it across different RAN architectures, and why now’s the time for CSPs to ‘get one's skates on’ to stay ahead of the competition.

Head of Strategic Projects

Senior Solutions Marketing Manager OSS

Hashtags
Hashtags
#Core
Skating

Head of Strategic Projects

Senior Solutions Marketing Manager OSS

Head of Strategic Projects

Contributor (+1)

Senior Solutions Marketing Manager OSS

Hashtags
#Core

The capability to drive automation within the operator network makes SMO immediately attractive to every mobile operator who wants to increase automation to drive down operational costs and, ultimately, improve profitability.

However, the fundamental problem with SMO is that it's designed to automate Open RAN networks which only make up one to two percent of deployed networks today[1].

To put that in context, it’s like inventing a perpetual motion machine to replace the internal combustion engine and then, in the small print, explaining it only works in Porches or Ferraris. Great news in principle, but not actually that helpful for 98 percent of motorists.

So, the key question is: “Is there a way to make the SMO concept applicable to 100 percent of radio access networks deployed globally?”

Thankfully, we think that there is an answer – a simple answer – to this ultimate question. And that answer is to extend this to address the existing, purpose-built RAN.

But where are with this now?

Open RAN is an exciting and disruptive development in our industry, but the technology is still at the early stage. We see a couple of new, greenfield entrants, looking to deploy new 100 percent Open RAN networks. We also see lots of leading communication service providers (CSPs) testing the technology, often in remote, rural areas or controlled environments such as university or business campuses.

Industry analyst firm, Gartner, developed an interesting model to look at the introduction of new technologies called the 'Gartner Hype Cycle.’  The hype cycle outlines a number of stages between the ‘innovation trigger,’ where the new technology is conceived and the ‘plateau of productivity,’ where the technology is widely adopted and starts to deliver results. It's difficult to estimate where Open RAN is on the cycle, but widespread media coverage and speculation makes it feel like Open RAN is just passing the ‘peak of inflated expectations:' essentially, it’s still in a relatively early stage.

 

Open RAN architecture

Let’s briefly look at the O-RAN Alliance. The O-RAN Alliance is a service provider-led consortium of over 300 companies working on the Open RAN concept. They have defined an Open RAN architecture which, as the name suggests, has openness at its heart.

The O-RAN Alliance - Open RAN architecture

Figure 1. The O-RAN Alliance - Open RAN architecture

 

The Open RAN architecture defines, or is in the process of defining, a number of open interfaces imaginatively named the O1, O2, A1 and R1 interfaces. These interfaces are not yet standardized in the same way that, for example, the 3GPP Release 17 is standardized, but there are strong aspirations for openness and standardization within Open RAN.

Ericsson is a major contributor to service management and orchestration working groups, and we have a number of ideas about how the SMO concept should be implemented.

 

Expanding SMO to support multi-technology

At the start of this blog, I gave the analogy that Open RAN SMO is a little bit like building a perpetual motion engine to replace the internal combustion engine, but having it only work with one brand of high-performance car. Brilliant, innovative, but not actually useful for 98 percent of motorists.

But what would happen if you could take the SMO concept and extend the automation capabilities brought about by SMO – non-real-time RAN intelligent controllers (non-RT-RIC) and their automation rApps – into the domain of the existing, purpose-built RAN networks? In effect, building a perpetual motion engine for every motorist.

At Ericsson, we believe this is very much possible. To achieve this, we will start with the existing centralized self-optimizing networks (C-SON) and network design and optimization (NDO) applications already deployed in networks. Today, these applications are often deployed on tightly integrated application platforms to perform specific automation operations. The SMO architecture effectively allows you to recreate these applications as RAN automation applications or rApps, as well as standardizing the underlying application environment: the SMO’s non-RT-RIC, which uses an R1 interface that enables interoperability between platforms and vendors.

“This report…analyzes the evolution of C-SON modules and use cases becoming apps in the RAN Intelligent Controller (RIC) needed in open RAN, open virtual RAN, and software defined RAN (SD-RAN) architectures” – Stéphane Téral, Chief Analyst

A recent report from analyst firm Light Counting highlights the expectation that existing C-SON applications will become applications in the RAN intelligent controller (RIC).

The ability to run rApps to optimize both Open RAN and existing purpose-built 4G and 5G networks is profound. If this can be achieved one of the major barriers to adoption of the SMO will be crossed – scalability.

Obviously, it’s hard to justify investment in an automation platform for a tiny percentage of your current network. This is why we are expanding the scope of the SMO to cover Open RAN and purpose-built RAN.  –  this results in the investment, covering the entire network with the benefits of automation being similarly applied to the entire network. At Ericsson, we call this approach multi-technology: the ability to automate and orchestrate Open RAN and purpose-built RAN.

 

Avoiding SMO siloes

Another major barrier to adoption is the management of multiple vendors’ RAN. For Open RAN networks the open A1 and O1 interfaces enable a common approach to managing the new Open RAN technologies, but the challenge is how to manage multiple vendors’ purpose-built 4G and 5G RAN networks.

Extending SMO to address purpose-built RAN

Figure 2. Extending SMO to address purpose-built RAN

 

These networks have a vendor specific equipment management system, or EMS, such as Ericsson’s own Ericsson Network Manager (ENM) or Nokia’s NetAct. There have been successful approaches, such as the Operational Support Systems interworking initiative (OSSii) to encourage interworking between equipment vendors, but not every vendor is actively participating. However, what OSSii proves is that there are ways to manage multiple vendors EMS and RAN.

The reason this is important is that without effective interworking in the existing purpose-built RAN networks, there will be a tendency to deploy vendor specific SMOs. Having one SMO per equipment vendor is counter-intuitive and would appear to add to complexity rather than reduce it.

Our belief is that an operator network should have a single SMO: deployed on-premises, in the cloud, or as-a-Service (aaS), depending on the wishes of the service provider. This single SMO will handle the new Open RAN technologies via the open A1 and O1 interfaces and purpose-built networks from multiple vendors through their own proprietary interfaces.

This approach gives a single ‘pane of glass' operational overview of the network, which reduces complexity and ultimately drives down operational costs.

At Ericsson, we call this approach multi-vendor.

 

Recommendations to accelerate SMO adoption

In Ericsson’s new SMO white paper, An intelligent platform: The use of O-RAN’s SMO as the enabler for openness and innovation in the RAN domain, we outline five recommendations to accelerate the adoption of SMO and shorten the hype cycle:

  1. Deploy in complex RAN environments: we recommend deploying SMO into complex multi-vendor, multi-technology networks where the automation platform can create the greatest operational impact.
  2. Target addressable areas of high operational costs: network deployment and network operation are two of the largest addressable areas of OPEX, we recommend that these areas are early targets for new automation rApps and xApps.
  3. Leverage proven use cases: there is an opportunity to take proven capabilities and deploy them at scale by taking the existing centralized SON and network design and optimization applications and using them to create new automation applications running on a common platform.
  4. Use best in class applications: use automation applications from a wide selection of developers including network equipment vendors, CSPs and third-party specialists. Be prepared to test similar applications and select those that best utilize any tools that accelerate open innovation such as software development toolkits, partner development ecosystems and even marketplaces to maximize choice.
  5. Deploy across multi-technology networks: SMO provides maximum return on investment (ROI) where it enables automation for 100 percent of the network. Having high levels of automation in an Open RAN network is a way of ensuring that the new technology is future-proof. However, adding high levels of automation to the existing purpose-built RAN that makes up more than 98 percent of CSP networks today is also highly desirable.

 

Learn more

 

[1] Source: Article: RAN market smashes expectations in 2020: Dell’Oro Group – 19 Feb 2021

 

 

The Ericsson Blog

Like what you’re reading? Please sign up for email updates on your favorite topics.

Subscribe now

At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.