5G’s O-RAN E2 interface works

• 5G’s O-RAN E2 interface work
  • Introduction
  • Role of near-RT RIC and its functionalities
  • E2 protocol stack
  • E2AP Terminologies
  • Constituents of an E2 Node
  • Structure of E2AP
  • General workflow on E2 interface
  • A practitioner’s view of E2AP Protocol and challenges in adopting
• Near RT RIC and E2 Communication
  • Architecture Near-RT RIC
    • General Function
    • xApps
    • Open APIs for xApp
  • Function of E2 interface, E2 nodes, and E2AP in communication between Near-RT RIC
    • Relationship between Near-RT RIC, E2 Interface, E2 Nodes, and Other RAN Components:
      • 1. E2 Interface
      • 2. A1 Interface
      • 3. O1 Interface
    • Connection Near-RT RIC, E2 Interface, and E2 Node:
    • Near RT RIC Arch
    • Near-RT RIC Platform Components
      • Repositories
  • Functionalities Messages of the Near-RT RIC and E2 Node
  • Relationship between RIC Services and E2AP Procedures

Introduction

Open RAN breaks down a cell tower's baseband unit into three parts. In 5G Open RAN, functions are split between a centralized unit (CU) and distributed unit (DU), allowing operators to use units from various vendors for customized networks. However, this relies on interoperable units connected by standardized interfaces, such as the E2 interface, which is crucial for Open RAN functionality.

The O-RAN Alliance has established a disaggregated architecture for 4G and 5G RAN, featuring:

1. Lower layer split: Dividing the physical layer, with the lower portion handled by a radio unit (RU) and the upper portion managed by the O-DU (O-RAN distributed unit).
2. Non-Real-Time RIC: Employing control logic with slower timescales exceeding 1 second.
3. Near Real-Time RIC: Utilizing low-latency control logic operating between 10ms and 1 second.
4. Service management and orchestration (SMO): Handling the management and orchestration of RAN network functions, with the Non-RT RIC potentially co-located with the SMO.

Role of near-RT RIC and its functionalities

Figure above shows the logical architecture. The O-RU is a physical appliance while the other components — gNB O-DU/gNB O-CU-CP/gNB O-CU-UP/O-eNB — can be either physical appliances or virtualized instances running over an O-Cloud layer. The interface lines shown in green are low-latency interfaces. The interface lines shown in purple are management plane interfaces, and the interfaces shown in black are the 3GPP-defined interfaces. The near-RT RIC is a platform that allows closed-loop control of RAN-optimization applications to be onboarded as xApps. The xApps use platform services available in the near-RT RIC to communicate with the downstream network functions through the E2 interface, where the downstream network functions can be gNB O-DU, gNB O-CU-CP, gNB O-CU-UP, or O-eNB.

The E2 interface supports the following functions:

• Allows southbound nodes to set up the E2 interface and register the list of applications the southbound nodes support.
• Allows xApps running in the near-RT RIC to subscribe for events from the southbound nodes such as prescribe an action to execute upon encountering an event where the action can be to report the event, report, and wait for further control instructions from the xApp, or execute a policy.
• Provide control instructions.

Table show E2 interface is currently specified to support the RAN optimization :

Use case	Description
Traffic steering	- Load balancing handovers - Selection of CA Scell/ENDC SN - Service based traffic steering
QoS-based resource optimization	- Monitor QCI/5QI specific statistics - Update resource allocation policies in RAN network functions
Massive MIMO optimization	- Monitor PRB utilization, UE level statistics from DU - Aid DU in massive MIMO beamforming and MU-MIMO pairing of users
RAN slice SLA assurance	- Monitor slice specific KPIs - Update resource partition per slice to meet SLA
RAN analytics information exposure	- Stream near-real time RAN statistics for analytics on QoE
General reporting of PM counters for all the above	- All measurements are identified based on 3GPP defined measurement names (TS 28.552 and TS 32.425) - Reporting granularity from 1 ms.

E2 protocol stack

Now that we know the organization of RAN functions, we look at the E2 interface. Figure above shows the E2 interface protocol stack.

An application protocol called E2AP is specified by O-RAN Alliance over SCTP/IP as the transport protocol. On top of E2AP, application-specific controls and events are conveyed through E2 service models (E2SM). The xApps in the Near-RT RIC use the E2SMs.

E2AP Terminologies

To get a deeper understanding of the E2 interface, you should first understand the E2AP terminologies. Key E2AP terminologies include:

1. E2 node: in the O-RAN architecture, each of the disaggregated network function O-CU-CP, O-CU-UP and O-DU of a gNB or a combined O-eNB are called the E2 nodes. E2 nodes support E2 interface towards near RT-RIC and O1 interface towards non-RT RIC.
2. RAN function: a specific function in an E2 Node; examples include network interfaces (i.e. X2AP, F1, S1AP, Xn, NGc) and RAN internal functions handling user equipment context handlers, call handlers, paging, and so on.
3. RIC service: a Service provided on an E2 Node to provide access to messages and measurements and / or enable control of the E2 Node from the Near-RT RIC. RIC Services Include:
   • REPORT
   • INSERT
   • CONTROL
   • POLICY
   • QUERY
4. RAN Function ID: local identifier of a specific RAN Function within an E2 Node that supports one or more RIC Services using a specific E2 Service Model. Note that same E2SM may be used by more than one RAN Function in the same E2 Node.
5. Style: for each RIC Service, different types of data can be grouped as a style. A given E2SM may support many styles for each RIC service.

Constituents of an E2 Node

An E2 node can consist of one or many RAN Functions. Each RAN Function is identified by a RAN Function ID. The E2 node advertises to the E2SM the RAN functions it supports using the RAN Function OID as the identifier. Figure above shows a logical view of an E2 node.

Each RAN function exposes a RAN function definition through its E2SM, which could contain some or all of the following definitions.

1. Event trigger definition: contains the definition of event triggers for which E2 node can be requested to report the event to near-RT RIC. The definition includes the event styles supported by the E2 node.
2. Report definition: contains the definition of event reports and the report styles supported by the E2 node.
3. Insert definition: contains the definition of information on which the E2 node has to exhibit “report and wait for control” semantics and the insert styles supported by the E2 node.
4. Control definition: contains the definition of attributes/configurations/call parameters to be controlled on the E2 node and the control styles supported by the E2 node.
5. Policy definition: contains the definition of policy to apply at the E2 node when the specified event trigger is hit.

Structure of E2AP

The messages and procedures of the E2AP protocol are structured as given below:

1. Global procedures are responsible for the setup and maintenance of the E2 link between the near-RT RIC and the E2 nodes. The global procedures supported on the E2 interface include E2 interface setup, E2 node configuration update, E2 service update, E2 connection update, E2 reset, and E2 error indication.
2. Functional procedures are responsible for getting information and events from the E2 nodes to provide further control or policy information back to the E2 nodes. The functional procedures include RIC subscription request/deletion request, RIC indication (for REPORT service and for INSERT service from E2 node to near-RT RIC) and RIC control request (for controlling parameters in E2 node — from near-RT RIC to E2 node).

General workflow on E2 interface

In General workflow, First, the interface link between the E2 node and the Near-RT RIC is set up. During this process, the E2 node advertises the list of RAN functions it supports and the corresponding E2SM supported for each RAN function. The xApps running in the Near-RT RIC subscribe to the E2 node, providing the event triggers and what actions to perform upon hitting those event triggers. If the action to perform is either REPORT or INSERT, the E2 node notifies the near-RT RIC when the event occurs. If the notification is due to INSERT action, the xApp in the near-RT RIC provides a corresponding CONTROL request to the E2 node. If the notification is due to REPORT action, the xApp in the Near-RT RIC may provide a subsequent CONTROL request to the E2 node. Through the CONTROL request, the xApp can control the call processing, radio resource allocation, handover control, idle mode mobility control, radio admission, carrier aggregation, and dual connectivity behaviors on a per-user (UE) basis in the E2 node. All the red-colored items in Figure 3 are carried as opaque payloads over E2AP as OCTET STRINGs. The interpretation of these OCTET STRINGS into the right structures is done based on the “RAN Function ID” carried in the message headers and the E2SM the corresponding RAN Function advertised during the E2 setup process.

A practitioner’s view of E2AP Protocol and challenges in adopting

The E2AP protocol allows any application to operate over it, using E2 service models (E2SM) to control specific RAN functions. Messages and information in E2AP and E2SM are defined using ASN.1 PER schema. RAN function-related triggers, actions, and controls are conveyed as an OCTET STRING payload in E2AP, decoded using the E2SM ASN.1 specified by the "RAN Function ID". The mapping of "RAN Function ID" to E2SM OID is obtained during E2 Setup. Most information in standard E2SMs is contained as OCTET STRING, interpreted using normative tables in E2SM specifications, often referring to 3GPP-defined information, which is decoded using 3GPP ASN.1 PER schema.

Near RT RIC and E2 Communication

Architecture Near-RT RIC

General Function

Detailed function from Internal Architecture above is as follows:

• Database, which allows reading and writing of RAN/UE information
  • UE related information to be stored in the UE-NIB (UE-Network Information Base) database;
  • radio access network related information to be stored in the R-NIB (Radio-Network Information Base) database;
• xApp subscription management, which merges subscriptions from different xApps and provides unified data distribution to xApps;
• Conflict mitigation, which resolves potentially overlapping or conflicting requests from multiple xApps;
• Messaging infrastructure, which enables message interaction amongst Near-RT RIC internal functions;
• Security, which provides the security scheme for the xApps;
• Management services
  • Fault management, configuration management, and performance management as a service producer to SMO;
  • Life-cycle management of xApps;
  • Logging, tracing and metrics collection, which capture, monitor and collect the status of Near-RT RIC internals and can be transferred to external system for further evaluation;
• Interface Termination
  • E2 termination, which terminates the E2 interface from an E2 Node;
  • A1 termination, which terminates the A1 interface from the non-RT RIC;
  • O1 termination, which terminates the O1 interface from Service Management & Orchestration layer;
• Functions hosted by xApps, which allow services to be executed at the Near-RT RIC and the outcomes sent to the E2 Nodes via E2 interface.

xApps

xApps is an application designed to run on the Near-RT RIC, is also likely to consist of one or more microservices and at the point of on-boarding will identify which data it consumes and which data it provides. The application is independent of the Near-RT RIC and may be provided by any third party. E2 enables a direct association between the xApp and the RAN functionality.

The xApp descriptor provides and includes:

• xApp management services with necessary information for the LCM of xApps, such as deployment, deletion, upgrade etc.
  • Includes the basic information of xApp for LCM, including name, version, provider, URL of xApp image, virtual resource requirements (e.g. CPU), etc.
• Extra parameters related to the health management of the xApps, such as auto scaling when the load of xApp is too heavy and auto healing when xApp becomes unhealthy.
• FCAPS and control parameters to xApps when xApp is launched.
  • Includes the FCAPS management specifications that specify the options of configuration, performance metrics collection, etc. for the xApp.
  • Includes the control specifications that specify the data types consumed and provided by the xApp for control capabilities (e.g. PM data that the xApp subscribes, the message type of control messages).

The architecture of an xApp consists of the code implementing the xApp's logic and the RIC libraries that allow the xApp to:

1. Send and receive messages.
2. Read from, write to, and get notifications from the SDL layer.
3. Write log messages.

Open APIs for xApp

• A1 related APIs: the APIs between xApps and A1 Termination.
  • provide value added services based on the policies or enrichment information or both which are transferred through A1 interface by non-RT RIC.
  • enable the exchange of information between xApps and A1 termination, which includes:
    • Policy Enforcement API: used for policy enforcement request/response.
    • Enrichment Information API: used for enrichment information transfer/response.
• E2 related APIs: the APIs between xApps and E2 Termination.
• Management APIs: the APIs between xApps and management related functions, such as O1 termination, management services and logging, tracing, metrics collection.
  • xApp life-cycle management related APIs include the following functions:
    • ML Model Deployment Request.
    • ML Model Update Request.
    • ML Model Uninstall Request.
  • FCAPS related APIs include the following functions:
    • Configuration API: The xApp is configured by SMO via O1 interface. The API transfers the configurations from SMO to xApp.
    • PM API: xApps provide PM related data to O1 PM Consumer via PM API.
    • FM API xApps provide faults and events information to O1 FM Consumer via FM API.
• Control APIs: the APIs between xApps and the functions which are responsible for control, such as conflict mitigation, xApp subscription management, etc.
• SDL APIs: the APIs between xApps and Shared Data Layer.
  • provide a simple yet flexible way to store and retrieve data while hiding details such as type and location of database, management operations of database layer such as high availability, scaling, load-balancing.
  • allow multiple xApps to access the data independently of each other.
  • Includes:
    • Register API: xApps can register at SDL for the permissions to access the database.
    • Deregister API: xApps can request to delete the API which has been registered in SDL.
    • Modify API: It allows to modify or delete data from the database.
    • Fetch API: It allows the xApps to fetch data from the database.
    • Store API: It allows the xApps to store data in the database.
    • Notification API: The database can notify the xApps the update information on the database via the notification API. The database will ignore the notification to the xApp when update occurs if the notification API is not registered by the xApp.

Function of E2 interface, E2 nodes, and E2AP in communication between Near-RT RIC

Relationship between Near-RT RIC, E2 Interface, E2 Nodes, and Other RAN Components:

Based on above, the Near-RT RIC supports the following functions:

• A1 interface termination
  • Terminates the A1 interface from the non-RT RIC and forwards A1 messages.
• O1 interface termination
  • Terminates the O1 interface from Service Management & Orchestration layer and forwards management messages to the Near-RT RIC management function;
• E2 interface termination
  • Terminates the E2 interface from an E2 Node;
  • Routes xApp-related messages to the target xApp;
  • Routes non xApp-related messages to the E2 Manager;
• Hosted xApps
  • allow RRM control functionalities to be executed at the Near-RT RIC and enforced in the E2 Nodes via E2 interface;
  • Initiates xApp-related transactions over E2 interface;
  • Handles xApp-related responses from the E2 interface;
  • Handles A1 messages from A1 interface;

1. E2 Interface

E2: Interface connecting the Near-RT RIC and one or more O-CU-CPs, one or more O-CU-UPs, and one or more O-DUs.

E2 Node: a logical node terminating E2 interface. In this version of the specification, ORAN nodes terminating E2 interface are:

• for NR access: O-CU-CP, O-CU-UP, O-DU or any combination;
• for E-UTRA access: O-eNB.

2. A1 Interface

Interface between non-RT RIC and Near-RT RIC to enable policy-driven guidance of Near-RT RIC applications/functions, and support AI/ML workflow.

3. O1 Interface

Interface between orchestration & management entities (Orchestration/NMS) and O-RAN managed elements, for operation and management, by which FCAPS management, Software management, File management and other similar functions shall be achieved.

Connection Near-RT RIC, E2 Interface, and E2 Node:

Near RT RIC Arch

In Figure 3, Near-RT RIC is shown to include a Database that stores data from xApp applications and E2 Nodes, providing the data back to xApp applications. The E2 interface acts as the connectivity medium between the Near-RT RIC and E2 Nodes, which can come from various vendors. This interface facilitates the sharing of selected E2 Node data, such as network measurements and context information, with the Near-RT RIC. It also allows Near-RT RIC to control certain functions within the E2 Node, as illustrated in Figure 2.

E2AP, which is a component of the E2 interface, encompasses the procedures used to transfer application-specific messages between Near-RT RIC applications and targeted functions in an E2 Node. Near-RT RIC contains xApp applications, database holding data from E2 nodes and xApp, and E2 termination to control E2 interface. E2 interface connects Near-RT RIC and E2 Node, where application specific messages passing between both will be taken care of by procedures in E2AP functional procedures module.

Near-RT RIC Platform Components

1. A1 Mediator
2. Demo1 (xApp demo maintained by RICP project)
3. E2 Manager (E2M)
4. E22 Terminator (E2T)
5. Logging
6. RIC Alarm System
7. RIC Message Router (RMR)
8. RNIB
9. Routing Manager
10. xApp Frameworks (CXX, Go, Python)

Repositories

Repository	Desciption
com/log	A thread-safe logging C API library with Mapped Diagnostics Context (MDC) support.
com/golog	Golang implementation of the common logging library
com/pylog	Python implementation of the common logging library
ric-plt/a1	Terminating the northbound A1 interface. It is translating information received over A1 it into conrete actions that xApps must take to adpat their behavior accordingly and it sends back feedback on the implementation status of such actions.
ric-plt/appmgr	Provides a flexible and secure way for deploying and managing various RIC xApp applications in a Kubernetes environment.
ric-plt/dbaas	Adaptation of the single-instance Redis database
ric-plt/dbaas/hiredis-vip	Adaptation of the Redis database as a cluster of Redis instances to provide high-availability
ric-plt/e2	The E2 termination component that actually establishes E2 SCTP connections (as requested by the E2 manager) and routes messages received/sent over E2 to/from RMR.
ric-plt/e2mgr	The E2 manager implementation. The E2 manager controls E2 connection establishment and provides REST APIs to manage these connections.
ric-plt/lib/rmr	RIC message routing - A library originally based on NNG (nano-messaging nxt generation) for low latency message routing. Starting from Bronze (Feb-2020) we replaced NNG with plain usage of TCP in that library (see RIC-49).
ric-plt/nodeb-rnib	R-NIB APIs/libraries to store and retrieve RAN configuration data, like a list of cells per gNB.
ric-plt/rtmgr	Routing Manager (ric-plt/rtmgr) is a basic RIC platform service, responsible for generating and distributing routing policies to xApps.
ric-plt/sdl	SDL (Shared data layer) data access libraris for Redis including Redis server-side modules allowing multi-key atomic operations and publish channels.
ric-plt/sdlgo	same as ric-plt/sdl, but for the Go language
ric-plt/sdlpy	same as ric-plt/sdl, but for python
ric-plt/submgr	Near-realtime RIC Platform Subscription Manager
ric-plt/utils	Utilities and common configurations for the (near realtime) RIC Platform
ric-plt/jaegeradapter	This repository includes files needed for starting the Jaeger Agent in a side-car container, and also files needed for starting Jaeger all-in-one of full collector containers.
ric-plt/tracelibcpp	This repo includes a small C++ library for using OpenTracing from near-RT RIC xApps and near-RT RIC platform components
ric-plt/tracelibgo	This repo includes a small golang library for using OpenTracing from near-RT RIC xApps and near-RT RIC platform components
ric-plt/vespamgr	The VESPA manager uses the VES Agent (https://github.com/nokia/ONAP-VESPA) to adapt near-RT RIC internal statistics collection using Prometheus (xApps and platform containers) to ONAP's VES (VNF event streaming).
ric-plt/xapp-frame	Artifacts for the (near realtime) RIC xapp framework, including common libraries, etc
ric-plt/asn1-documents	ASN.1 definitions and related documents that are needed by other components
ric-plt/streaming-protobufs	Contains protobuf definitions that xApps can use, for example, to derive statistics from streams of messages obtained from the RAN.
ric-plt/ric-test	This repo includes test cases that span the full RIC platform, i.e., that cannot run against a single RIC component.
ric-plt/ric-dep	Code and configuration files that are needed for deploying a near-RT RIC platform instance
ric-plt/demo1	A simple demo xApp running on the RIC platform.
ric-plt/o1	o1 mediator
ric-plt/xapp-frame-py	The near-RT RIC python xapp framework
ric-plt/xapp-frame-cpp	The near-RT RIC C++ xapp framework
ric-plt/alarm-go	The near-RT RIC alarm adapter and Go library
ric-plt/alarm-cpp	The near-RT RIC alarm library for C++

Functionalities Messages of the Near-RT RIC and E2 Node

• REPORT Message: This message is sent by the E2 Node to the Near-RT RIC in response to a defined event trigger. It is used for monitoring and can contain various types of information, such as measurement data or other notifications from the E2 Node.
• INSERT Message: This is not a typical message in the context of Near-RT RIC and E2 Node communication. This message type is generally not used to suspend procedures in the E2 Node. Instead, if the Near-RT RIC wants to modify or insert a procedure or event trigger, it would use different mechanisms, typically through the configuration.
• CONTROL Message: This message is sent by the Near-RT RIC to the E2 Node to control certain operations. It could be used to start or stop a procedure, modify configurations, or send specific control commands to the E2 Node.
• POLICY: This term typically refers to the policy-based control that can be implemented in the E2 Node through the Near-RT RIC. The Near-RT RIC might request that the E2 Node applies a specific policy or set of rules during its operations. However, this isn't necessarily triggered by an event but is more about defining behaviors or actions for the E2 Node to follow.

Relationship between RIC Services and E2AP Procedures

E2AP RIC Services	Function
E2AP RIC Subscription procedure	install Event Trigger and Actions corresponding to RIC services REPORT, INSERT and/or POLICY
E2AP RIC Indication procedure	carry outcome of RIC services REPORT and INSERT
RIC Control procedure	initiate RIC service CONTROL

RIC Services may be combined within a common subscription (e.g. POLICY then REPORT, REPORT then REPORT) or as a sequence of RIC Services (e.g. REPORT followed by POLICY, INSERT followed by CONTROL, REPORT followed by CONTROL).