No RAN is an island: Why Intelligent Automation Platform is a RAN automation booster

“No man is an island,
Entire of itself;
Every man is a piece of the continent,
A part of the main...”
- ‘No Man Is an Island.’ John Donne, 1624

“I am a bloody island –I am bloody Ibiza!”
- Hugh Grant in ‘About a Boy’, 2002

(Apologies to the readers with a classical education that may object to the quotes above. I will try to make them worthy of the story.)

Discussions about Open RAN have been occurring for some time now, and the marketplace for Open RAN service management and orchestration solutions and/or the non-real-time RAN Intelligent Controller (RIC) is quickly becoming crowded. Any analyst report from the last months, or a simple Internet search, shows a good number of companies working in these areas.

So, among the number of SMO implementation that can be and will be found in the market, what makes for a great SMO? And why do we think our Ericsson Intelligent Automation Platform may be the best SMO?

We think the answer can be found by taking a step back and looking at the bigger picture. We'll do this in three consecutive steps.

Step 1: New solutions need to make life simpler

Almost every time we discuss new OSS solutions or approaches with a CSP they ask us: “Are you making my life simpler or harder?” Even if the idea of SMO is promising, if it’s just sitting on top of the Open RAN stack – like any another network domain manager that coexists with your other RAN technology stacks – then it isn’t simplifying anything.

For this reason, a 'great SMO’ (bear with me for the naming) should aim to be the unique umbrella system for RAN management and automation. That means it must be able to deal with every fault, configuration, accounting, performance and security (FCAPS) interface on the southbound: FCAPS is the standard acronym for ‘all you need to manage your equipment’, even though it cannot be covered with just one set of interfaces. This system will create an abstraction on top of all RAN technologies so that all other systems can think of this 'great SMO' as the place where they go for all things RAN – without caring about the underlying RAN type or vendor.

People working in the OSS space for some time have reasonable doubts regarding generic ’multi-vendor’ and ’multi-technology’ claims. In the Open RAN domain, the expectation is that the interfaces involved (namely O1, O2, A1, and R1) will be specified soon and that should establish a common ground for every rApp developer or Open RAN equipment vendor.

Beyond the Open RAN domain, at Ericsson we co-founded with Nokia and Huawei back in 2013 the OSS Interoperability Initiative to promote exchange of OSS information that allows a straightforward operation of multi-vendor equipment. This is a step in the right direction and there are now 17 more companies participating in the initiative, with the memorandum of understanding (MoU) renewed in 2019.

The second step has to do with the need to create the most attractive platform for innovation.

Step 2: New solutions should help scaling up RAN automation innovation

If one believes in the idea of splitting the RAN automation architecture – having the platform on one side and apps on the other –one probably wants these application developers to be as incentivized as possible so that they create many great rApps that can be deployed into the non-RT RIC and let them automate RAN operations. That will save time and resources that may be employed better somewhere else.

To make this happen, there are two main things required for rApp developers to be motivated to work on your platform.

• Robust design, development and testing tools: This is typically packaged in what is called an SDK (Software Development Kit), and it gives the developers the technical capabilities to build quickly and with quality. An average SDK can always have workarounds and developers are infinitely resourceful, but only if the next condition is supported.
• Large addressable market: Without this there is no SDK beautiful enough to motivate developers. This is what makes them put their talents into this platform and not in some other alternative (or forget about SMO and work on something completely different; development languages are widely used across industries, and the same C++, Python, or Go developer who can build an rApp may be building something entirely different). In the case of RAN automation developers, this connects to the first pillar above. If they have a development platform that allows them to address the whole spectrum of RAN, and not only Open RAN footprint, then it makes a whole world of difference in terms of how much value their rApps can bring – which in the end defines how much they can expect to be rewarded.

And the third pillar is related to how RAN is part of the wider challenge of end-to-end orchestration.

Step 3: The network is many networks

When we talk about the network, and we do that a lot here, we usually mean more than one. Every time you pick up your phone to interact with your friends on your favorite social network, or to play your song of the day, an amazingly complex process is triggered. It is not only the Internet itself, but the fact that you would be accessing it from anywhere in the world while moving freely (and even beyond, but this is not our topic for today) requires the coordination of different technologies and in the end complete networks on their own right. The largest of all these networks are the radio access networks (RAN).

At the highest level, every time your mobile phone wants to send any data to another phone or to the Internet, three networks, or domains, are crossed.

The first one is the already mentioned RAN that keeps your very capable mobile handset connected to the antennas you can see in the streets or countryside and makes sure this connection is maintained as you move around even at high speeds like on a car, bus, or train. Not to over-complicate things, but even the RAN is composed, to some extent, of different networks as the different generations like 5G, 4G and 3G use different protocols that are perfectly integrated via open 3GPP standards, but you may still call them different networks within the RAN domain. This brings up back to the opening quote, “no RAN is an island”.

Once the piece of data from your phone has reached this RAN, it goes to the transport network, where it is transported (not surprisingly) long distances to make sure your data reaches the central infrastructure: the core network. You can think of the core network as the major commuting hub for your data, where it can take, say, ‘the short distance bus connection to another phone’ or server nearby, or maybe leave for a long-distance jump to the Internet or another operator’s commuting hub, i.e., another core network.

Figure 1 provides a good representation of this flow and brings one modern addition with network slices that let us take the analogy one step forward. You can imagine slices as being different lines covering the same trip: some of them go at a high-speed, non-stop and some of them more of a ’scenic route’ if you like. All of them take you there, but not exactly in the same way.

Figure 1: Network slices working across network domains to fulfill different Quality of Service (QoS) requirements

Every network domain is coordinated, even if adhering to different standards, and evolving at their own pace. However, one trend is common to all: they all want more automation.

But how can operators make sure that their investments in RAN automation are properly connected to the end-to-end service monitoring and operations that are required to take care of what matters to the end users –the full service?

To explain this, I will use quite standard process naming for telco: fulfillment and assurance.

On the fulfillment area, that takes care of bringing the service to life as it is being requested, operations in the RAN are coordinated from a service orchestration level. This service orchestration level can decide in real time which resources are required to satisfy the service specifications and does that by requesting an online inventory system to perform the most adequate service design and come back with the resources and configuration required. With this information, the service orchestration solution is able to build a service specification (in the form of a TOSCA descriptor, for instance) that defines how each domain needs to create or setup their specific part of the service in order to build the service that connects your phone with any of the URLs we all know and love.

The service orchestration solution then sends the specification to each domain and when all domains are done, the service is up and running. RAN domain gets its part of the service specification and performs all required actions in the different parts of the RAN, that may typically include more than one RAN vendor and technology. Here you have your multi-domain fulfillment ‘magic.’

From then on, everything falls into the assurance department. This is the part when the service is monitored continuously, and actions can be triggered to correct service malfunction or performance degradations. By now you have already realized that this means multi-domain monitoring, i.e., RAN, core and transport are monitored separately in coordination, and we are not even touching some extensions like adding the handset as a monitoring point. Multi-domain service monitoring is usually described with the beautiful ‘single pane of glass’ image, and it implies one solution that can collect the information from all domains contributing to the service. Connecting to step 1 above, ’the great SMO’ will make use of the available interfaces to gather specially the fault and performance parts of FCAPS info and feed them into a service model that calculates a set of resource and service key performance indicators (KPIs). A solution like this will typically need to maintain more than 150 KPIs.

In this area of ‘cross-domain-ness' (if that is a thing), network slices are expected to become more and more relevant. Large commercial deployments of end-to-end (E2E) network slices will most likely be a reality when Open RAN gains market traction, becoming part of network slices for many operators. We believe Ericsson’s delivery of network slicing technology to CSPs globally, and our recently demonstrated ability to create cross-domain slices that connect RAN, transport and core domains –while still delivering the committed quality and being deployed and monitored individually on a slice basis – is of major importance, especially when it comes to increasing monetization of 5G and advanced services.

Bearing in mind that “no RAN is an island, entire of itself”, if we go back to our original question: “Why do we think Ericsson Intelligent Automation Platform will be a RAN automation booster?” we would argue there are three main reasons:

• It makes life simpler by becoming the umbrella system for RAN automation and management across vendors and technologies. All benefits enabled by rApp can be applicable to the whole RAN
• It widens the addressable market for rApp developers from day one and provides differential capabilities that make rApps running on top of this platform instantly more valuable
• It guarantees a future-proof RAN automation platform that is slice-aware and connected to the end-to-end service for fulfillment and assurance

It is for all these reasons that we were so excited on November 16, 2021 when we launched the Intelligent Automation Platform because we know it checks all the boxes.

Learn more

• Discover what the Intelligent Automation Platform can do for your business
• Read more about rApps
• Read more about telecom SDK
• Read our blog: Want to get ahead in service management and orchestration?
• Read our blog: How open development ecosystems drive rApp innovation