I attended the Private Networks Forum on Tuesday. My interest of course was to understand the management plane (orchestration, lifecycle management, closed loop automation) perspective, especially for Private 5G. Here is what I learnt:

1. It was fascinating to see that almost every time the management topic came up, the number one comment was around the need for simplicity. Enterprises, unlike telcos, are not in the business of running networks and are unable to put together a complex 5G network.
2. Another requirement is flexibility — flexibility in supporting Standalone Non Public Networks (S-NPN) vs. Public Network Integrated NPN (PNI-NPN), choosing different 5G core and RAN vendors for eMBB vs. uRLLC vs. MMTC workloads, placing network functions differently depending on the performance requirements, and E2E 5G network slicing.
3. Next speakers echoed how Private 5G deployment will include edge computing applications. There are of course scenarios where purely a high performance, low latency, highly reliable wireless network makes sense as an alternative to wired networks; but by and large the speakers talked about the need for edge computing applications to extract business value. From my point of view, a Private 5G network is a means to an end, rather than the ultimate goal in itself.
4. A Private 5G network will be a very dynamic environment. There will be major upgrades going on e.g. Rel 15 to Rel 16 (the underlying assumption being that  Network Functions will be virtualized or containerized). Network functions might get updated every so often. Dynamic slicing may be going on. All of this makes it very important to plan for a dynamic environment.
5. Finally, the speakers talked about the need for tailored solutions based on use cases. Extrapolating, I can imagine solutions tailored for hospitals, factories, farms, etc. that include the right network functions in the best proven reference architectures, provided along with most popular edge computing applications for that use case.

As you can imagine, these requirements are a great fit for us. The Aarna.ml Multi Cluster Orchestration Platform (AMCOP) product is specifically designed for the orchestration, management, automation, and network slicing of Private 5G networks and edge computing applications. Try AMCOP for free today! Or if you would like to see a private demo of any of the aspects described including network slicing, please contact us.

With 5G, the entire environment becomes cloud/edge and software-driven, unlike 4G. This makes network service management which includes orchestration, lifecycle management (configuration and security settings), and service assurance complex and not viable via existing mechanisms. Given the flexibility with software, the permutations of configuration and security settings for 5G result in a very large number, and choosing the right settings becomes very challenging. So, having to sort through these different configurations and combinations makes the eventual network service deployment a big challenge.

‍

AARNA and REBACA Joint Offering:

The solution has two key components:

• AMCOP – Aarna.ml Multi-Cluster Orchestration Platform
• REBACA’s ABot – 4G/5G Network Tester

One of the key elements in the process of automation is to validate the setup, be it some device under test or an emulator. ABot is a uniquely different from other emulators as follows:

• Emulation of any 4G/5G network components for validation as per 3GPP standard
• Ability to support any IP based protocol like SIP, MQTT
• Interop, Performance Benchmark and Integration Testing support
• Reusable test templates in natural language for easy user acceptance and faster deployment
• Test results analysis for detecting failure of procedures, messages, events, and associated KPIs
• Insight like: Coverage, Product Maturity, Consistency, Build-by-build analysis
• Redundant or missing test vectors in a test suite identification
• Root Cause Analysis and Event Suppression thus facilitating in debugging
• Completely cloud-native and seamless integration with any Orchestrator and CI/CD pipeline
• Distributed deployment across Operator’s Network, Cloud Provider’s Data Centre and Edge Network
• Network functions simulated by ABot can be deployed as Kubernetes pod on any hypervisor
• Can be managed by any Network Orchestrator like AMCOP, OSM, Juju, Cloudify, etc.

‍

Key Features of AMCOP:

1. Kubernetes cluster registration
2. Cloud-Native Network Function (CNF) and Cloud-Native Application (CNA) onboarding
3. Network Service (with CNFs) or Composite Application (with CNAs) design
4. Intent-Based Orchestration of network service or composite application
5. Ongoing lifecycle management and day 1, 2 configuration of network service or composite application
6. Monitoring of CNFs or CNAs resulting in real-time policy-driven closed-loop automation

A high-level block diagram of AMCOP is shown below:

‍

A joint solution with AMCOP and ABot results in seamless design of a 5G core as follows:

• AMCOP is used to configure and provision any 4G and 5G Network Function with both SUT and ABot emulated nodes
• AMCOP then invokes ABot end-to-end test scenarios to exercise different use cases
• ABot Analytics captures different Mobility KPIs, Infra KPIs, and other test statistics
• ABot Analytics can provide relevant analytics insights to AMCOP (as events)
• AMCOP’s Analytics Program (AAP) drives orchestration and configuration changes, and if needed, reruns the tests to make sure the new configuration is what we desired.

‍

With AMCOP and ABot working together, one can automate the entire process by going through this closed-loop repeatedly and arrive at an ideal environment/configuration. It will also help the user understand how the network would work under different configurations. In this manner when the 5G Core is put into production, the user is assured that it will work optimally to meet their specific requirements.

‍

See a recording of the technical meetup that covered this topic in more depth along with a hands-on demo. If you would like to replicate any of this work in your environment, please contact us.

In my previous two blogs in this three-part series, I covered O-RAN Architecture and SMO and Non-Real-Time Radio Intelligent Controller (non-RT RIC) : Data driven RAN optimizer topics. In this last blog of the series, we will look at a traffic steering example Non-RT RIC use case that deals with optimizing traffic management or achieving balanced cell load.

Traffic management Use case

The Non-RT RIC configures the desired optimization policies, utilizes the right performance criteria, and leverages machine learning to enable intelligent and proactive traffic steering control. This use case is primarily based on the O-RAN architecture and its constituent entities.

Roles

As a refresher from the first blog in this series, here are the roles of each of the entities from a traffic steering use case point of view:

SMO/Non-RT RIC

1. Retrieve necessary performance, configuration, and related data for defining and updating policies to guide the behavior of traffic steering function in the near-RT RIC.

2. Support communication of policies and enrichment information to the near-RT RIC and measurement configuration parameters to RAN nodes.

Near-RT RIC

1. Support interpretation and enforcement of policies from non-RT RIC.

2. Use enrichment information to optimize control function.

CU/DU/RU Nodes

1. Send FM/PM/other data with required granularity to SMO.

The Non-RT RIC platform resides inside the SMO, collects the data, and derives analytics information which is used in the traffic steering use case and same can be extended to other use cases as well.

Policy Management

This section deals with the traffic management in RAN according to defined policies and configuration.

Prerequisites:

• All the RAN components (CU, DU, Near-RT RIC etc.) and SMO are deployed
• A1 and O1 interfaces are configured correctly
• SMO collects the data and send it to the Non-RT RIC platform that derives analytics out of this data

Trigger:

The Non-RT RIC platform monitors the performance data and different counters from the various E2 nodes. Based on the trigger (defined by operator) or a generated event, the Non-RT RIC initiates a change.

Operations:

1. The Non-RT RIC decides upon an action and communicates relevant policies to the Near-RT RIC over the A1 interface. The example policies may include:
2. QoS targets
3. Preferences on which cells to allocate control plane and user plane
4. The Near-RT RIC receives relevant information from Non-RT RIC over A1 interface, interprets the policies and enforces them.
5. The Non-RT RIC decides that conditions to continue the policy are no longer valid.
6. The Non-RT RIC deletes the policy.
7. The Non-RT RIC continues to monitor the performance data (events and counters from E2 nodes).

Example:

Let us look at an example scenario to describe the use of A1 for traffic steering, where the Non-RT RIC sends policies for allocation of the control plane (RRC) and the user plane for different services, identified by their 5QI (5G Quality Service Indicator).

‍

Cell A & B:

• Low band, narrow bandwidth, low latency
• Ideal for voice and control plane

Cell C & D:

• High band, wide bandwidth, high latency
• Ideal for data connection

In the scenario a UE with UEid=9999999999, belonging to a subnet slice identified by S-NSSAI=10, having a Voice (5QI=1) and an MBB (5QI=9) connection established, enters an area covered by four frequency bands.

The Non-RT RIC understands the requirements and characteristics of the services and decides to let the Voice and RRC connection reside on the low band (here covered by a macro cell B becoming the PCell), while the MBB (MobileBroadBand) connection should preferably use the higher band (here provided by small cells C and D becoming the SCells) and avoid the low band if possible. Cell A is used for MBB if required for coverage reasons.

NonRTRIC policy change directs control pane and voice on cell B:

‍

Policy change from NonRTRIC related to MBB:

‍

Summary

We have seen how the Non-RT RIC can take decisions on pushing the optimal policies to the Near-RT RIC based on the cell characteristics. This use case explains this capability of the Non-RT RIC in the traffic steering example and the same principles can be applied to various other scenarios as well.

References: O-RAN specification documents

Images credit: O-RAN-SC

In this part 2 of a 3 part series (part 1 here), I am going to introduce the non-RT RIC. Before jumping into the non-RT RIC capabilities, let's evaluate the limitations of current RAN infrastructures and future needs.

Rapid traffic growth and multiple frequency bands utilized in a commercial network make it challenging to steer the traffic in a balanced distribution.

Current controls are limited to:

1. Adjusting the cell re-selection and handover parameters
2. Modifying load calculations and cell priorities
3. RRM (Radio Resource Management) features in the existing cellular network that are all cell-centric
4. Base stations based on traditional control strategies treat all UEs in a similar way and are usually focused on average cell-centric performance, rather than being UE-centric

The current semi-static QoS framework does not efficiently satisfy diversified quality of experience (QoE) requirements such as cloud VR or video applications. The framework is limited to looking at previous movement patterns to reduce the number of handovers.

The non-RT RIC, which is part of O-RAN Service Management & Orchestration (SMO) layer, addresses these current limitations and supports various use cases. It allows operators to flexibly configure the desired optimization policies, utilize the right performance criteria, and leverage machine learning to enable intelligent and proactive traffic control.

The following figure shows a functional view of non-RT RIC platform.

As described in O-RAN architecture, the non-RT RIC will communicate with near-RealTime RIC element via the A1 interface. Using the A1 interface the non-RT RIC will perform actions such as:

1. Policy Management: facilitate the provisioning of policies for individual UEs or groups of UEs
2. Monitoring: monitor and provide basic feedback on the policy state from near-RT RICs
3. Enrichment Information: provide enrichment information as required by near-RT RICs
4. AI/Ml updates: facilitate ML model training, distribution and inference in cooperation with the near-RT RICs

Data Collection

The Non-RT RIC platform within the SMO collects FCAPS (fault, configuration, accounting, performance, security, management) data related to RAN elements over the O1 interface. Examples of collected items:

1. Events
2. Performance data.
3. Cell load statistics
4. UE level radio information, connection and mobility/handover statistics.
5. Various KPI metrics from CU/DU/RU nodes

Derived Analytics Data

The collected data is used to derive analytics data. Derived analytics data includes measurement counters and KPIs that appropriately get aggregated by cell, QOS type, slice, etc. Examples of derived data analytics:

1. Measurement reports with RSRP/RSRQ/CQI information for serving and neighboring cells
2. UE connection and mobility/handover statistics with indication of successful and failed handovers
3. Cell load statistics such as information in the form of number of active users or connections, number of scheduled active users, utilization of PRB and CCE
4. Per user performance statistics such as PDCP throughput, RLC or MAC layer latency

The non-RT RIC can provide data driven operations to various RAN optimizations. AI-enabled policies and ML-based models generate messages in non-RT RIC that are conveyed to the near-RT RIC. The core algorithm of non-RT RIC is owned and deployed by network operators.

These algorithms provides the capability to modify the RAN behavior based by deployment of different models optimized for individual operator policies and optimization objectives.

Following are few such examples and applicable scenarios:

1. Adapt  RRM control for diversified scenarios and optimization objectives.
2. Capabilities to predict network and UE performance.
3. Optimal traffic management with improved response times by selecting the right set of UEs for control action. This results in an optimal system and UE performance with increased throughput and reduced handover failures.
4. The O1/EI data collection is used for offline training of models, as well as for generating A1 policies for V2X handover optimization like handover prediction and detection.
5. The non-RT RIC can influence how RAN resources are allocated to different users through a QoS target statement in an A1 policy.

In this next post we will see the use cases where the non-RT RIC can play a pivotal role to optimize the RAN resources.

5G network slicing holds tremendous promise in terms of allowing services with completely different characteristics to share a particular 5G network. Even in a private 5G network, enterprises will be able to use the network for multiple applications. When we talk about a 5G network, there are typically three components that come into play:

• Radio Access Network
• Transport Network
• Core Network

When we say we are creating a slice, the slice needs to be created end-to-end across these three domains: RAN slice, Transport slice, and Core slice.

‍

‍

The Linux Foundation Open Network Automation Platform (ONAP) provides comprehensive support for end-to-end network slicing. It can be used to create a slice and configure the above three domains and/or spin up new instances of network functions. The slice can be activated once we have set the different configuration parameters.

The diagram below shows a high-level 3rd Generation Private Partnership (3GPP) view of how a network slice should look the different constituent components:

‍

‍

ONAP can be used to design network slice template and then an operator can order a slice using APIs or a graphical user interface via the communication service management function (CSMF). Next, the network slice management function (NSMF) chooses the network slice instance and hands off the actual domain specific tasks to specific RAN, Core, or Transport network slice subnet management function (NSSMF). External NSSMFs are also supported.

To see a thorough explanation of these concepts and to see a recording of a hands-on demo using ONAP's upcoming Honolulu release, view a recording of our End-to-End Network Slicing technical meetup from two weeks ago (1 hour at 1x speed). If you don't have the time, you can watch just the demo portion of the meetup (10 minutes at 1x speed).

A surprisingly large number of companies want to try ONAP network slicing in their labs. If you are one of these companies, and need some help, feel free to contact us.

In this three part blog series, I am going to talk about O-RAN architecture with a little extra emphasis on the Service Management & Orchestration component, the NONRTRIC, and finally some NONRTRIC use cases. Today we'll cover the first topic.

The O-RAN specification allows service providers to speed up 5G network development through its standardized architecture. It minimizes proprietary hardware dependency and makes the network more accessible to a broader range of designers.

The O-RAN alliance architecture principles are:

• Radio area network (RAN) virtualization, open interfaces, and AI-capable RAN
• Disaggregation of RAN element deployment and leveraging multi vendor solutions
• Minimization of proprietary hardware and a push toward merchant silicon and off-the-shelf hardware
• Interfaces and APIs to drive "standards to adopt them as appropriate" and explore "open source where appropriate"
• O-RAN Architecture

O-RAN Components

• Service Management & Orchestrator (SMO): The component that oversees all the orchestration aspects, management and automation of RAN elements. It supports O1, A1 and O2 interfaces.
• Non-RT RIC (non-real-time RAN Intelligent Controller): A logical function that enables non-real-time control and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in near-RT RIC.
• Near-RT RIC (near-real-time RAN Intelligent Controller): A logical function that enables near-real-time control and optimization of O-RAN elements and resources via fine-grained data collection and actions over the E2 interface. It includes interpretation and enforcement of policies from Non-RT RIC. and supports enrichment information to optimize control function.
• O-CU (O-RAN Central Unit): A logical node hosting RRC, SDAP and PDCP protocols. O-CU includes two sub-components O-CU-CP (O-RAN Central Unit – Control Plane) and O-CU-UP (O-RAN Central Unit – User Plane).
• O-DU (O-RAN Distributed Unit): A logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional split.
• O-RU (O-RAN Radio Unit): A logical node hosting Low-PHY layer and RF processing based on a lower layer functional split.

O-RAN SMO Interfaces

The key O-RAN SMO interfaces are:

• O1: Interface between management entities in Service Management and Orchestration Framework and O-RAN managed elements, for operation and management, by which FCAPS management, software management, and file management shall be achieved.
• O2 (previously O1*): Interface between Service Management and Orchestration Framework and Infrastructure Management Framework supporting O-RAN virtual network functions.
• A1: Interface between non-RT RIC and near-RT RIC. Over this interface non-RT RIC performs policy management, enrichment information and AI/ML model updates on the near-RT RIC.

In the next post we will see the various requirements and current limitations, and how the O-RAN architecture — especially the non-RT RIC — optimizes the 5G network.