Open radio-access networks (Open RAN) disaggregate a cell tower’s baseband unit into three units. The 5G Open RAN architecture specified by 3GPP separates functions into a centralized unit (CU) and distributed unit (DU), where these functions were otherwise contained in the baseband unit, which also included the radio. These units provide network operators with the ability to install units from different vendors rather than rely on a single source, which enables customized RANs. This disaggregation, however, depends on interoperable RAN units connected through standardized hardware and software interfaces. That’s more easily said than done. One of these interfaces is the E2 interface. Here’s where the E2 interface fits into a RAN and how it works.
The O-RAN Alliance has defined a disaggregated architecture of the 4G and 5G RAN. Some of the key aspects of disaggregated architecture are:
- Lower layer split: splitting the physical layer with the lower part of the physical layer running in a radio unit (RU) and the upper part of the physical layer running in the O-DU (O-RAN distributed unit).
- Non-Real-Time RIC: running slower timescale control loop logic greater than 1 second.
- Near Real-Time RIC: running the low latency timescale control loop logic operating between 10ms and 1 second timescale.
- Service management and orchestration (SMO): running the management and orchestration of the RAN network functions. The Non-RT RIC can be co-located with the SMO.
3GPP further specified a control-user plane split in the CU, splitting it into the CU-control plane (CU-CP) and the CU-user plane (CU-UP). The Open RAN concept further disaggregates the DU into two parts: the radio unit (O-RU), which runs the lower physical layer functions and the O-DU, which runs the higher physical-layer functions and the rest of the 3GPP-defined DU functions. When the 3GPP defined CU-CP and CU-UP functions, it also calls for additional interfaces defined by the O-RAN Alliance called O-CU-CP and O-CU-UP. (The term “interface” refers to the network protocol interface carrying some payload information for software-based control of the Open RAN functions. When a 5G radio base station — called gNodeB or gNB — follows the O-RAN Alliance split architecture, they are called gNB O-DU, gNB O-CU-CP, and gNB O-CU-UP.)
The O-RAN Alliance has also specified splitting intelligence away from the CU-CP, CU-UP, and the DU into the RIC. You can view the RIC as a RAN’s software-defined network (SDN) controller. O-RAN Alliance has defined inner and outer levels of closed-loop control of the RAN through the RIC. The outer loop is responsible for longer time-scale (greater than 1 sec) control functions handled by non-real time RIC. In the inner loop, the near-real time RIC controls shorter time-scale functions in the 10 msec to 1 second time scale.
For the inner loop, low latency control of the Open RAN network functions O-DU, CU-CP, or CU-UP, the O-RAN Alliance has defined the E2 interface; a network interface carrying events, control, and policy information to the Open RAN network functions.
Figure 1 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.
Role of near-RT RIC and its functionalities
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.
Through these broad functionalities, the E2 interface is currently specified to support the RAN optimization use cases in Table 1.
|QoS-based resource optimization||
|Massive MIMO optimization||
Aid DU in massive MIMO beamforming and MU-MIMO pairing of users so that multiple UEs are scheduled in the same time-frequency resources but in different beams.
|RAN slice SLA assurance||
|RAN analytics information exposure||
|General reporting of PM counters for all the above||
Table 1. Use cases for the E2 interface.
The use cases in Table 1 occur through RAN control mechanisms that include radio bearer control, radio resource allocation, connected mode mobility control, radio access control, carrier aggregation and dual connectivity control, and idle mode mobility control.
E2 protocol stack
Now that we know the organization of RAM functions, we look at the E2 interface. Figure 2 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.
To get a deeper understanding of the E2 interface, you should first understand the E2AP terminologies. Key E2AP terminologies include:
- 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.
- 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.
- 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:
- 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.
- 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 3 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.
- 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.
- Report definition: contains the definition of event reports and the report styles supported by the E2 node.
- 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.
- 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.
- Policy definition: contains the definition of policy to apply at the E2 node when the specified event trigger is hit.
Lure of E2AP
The messages and procedures of the E2AP protocol are structured as given below:
- 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.
- 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
Using the procedures defined above, a general workflow to be followed between the near-RT RIC and E2 node appears in Figure 4.
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 is defined generically to allow any application to run on top of it. Applications use E2 service models (E2SM) for the control and handling of specific RAN functions in E2 nodes. The messages and information carried in both E2AP and E2SM are defined using ASN.1 PER schema. The RAN function-related event triggers, actions and controls are carried as an OCTET STRING payload over the E2AP messages. The OCTET STRING is decoded using the ASN.1 PER schema of the E2SM. The RAN function E2SM ASN.1 to use for such decoding is identified by the “RAN Function ID” in the header of the E2AP messages. The mapping of the “RAN Function ID” to the E2SM OID is obtained from the E2 Setup procedure. In the standard defined E2SMs, most of the information is again contained as OCTET STRING. The interpretation of such OCTET STRING is based on the normative tables in the respective E2SM specifications. Generally, such OCTET STRINGs refer to 3GPP-defined information. Such 3GPP-defined information is again to be decoded using 3GPP ASN.1 PER schema.
This structuring of an E2AP message is shown below in Figure 5.
While such a design of E2AP procedures allows for independent evolution of 3GPP and O-RAN specifications and makes the maintenance of O-RAN E2-related specifications easier, it has the following issues from a practitioner’s point. These make it challenging to adopt the E2SM models “as is” from standards:
- When message traces are taken, it is extremely hard to decode them with message parsers such as Wireshark because the decoding logic relies on prior information where “RAN function ID” was mapped to a specific OID in the E2 setup procedure. This makes the protocol decoding completely stateful. Network protocols are generally defined such that each message is self-contained and decodable in itself — each message is stateless on its own.
- Debugging the interface requires implementing stateful protocol dissectors, for example in Wireshark.
The original intent of the E2 interface was to allow any application (vendor-defined, operator defined, and third-party) to have a closed loop, low latency, feedback-based control of the RAN. The design of the E2 interface and the E2AP protocol makes integration and debugging hard.
To avoid such nested OCTET STRING decoding, alternate approaches taken include defining custom E2SMs with self-contained ASN.1 PER schema, which don’t define further nested OCTET STRINGs. Resorting to such custom approaches, however, defeats the purpose of standardization. If you were to develop applications using standard-defined E2SMs that are easy to integrate and debug, you need protocol dissectors that support full dissection and decoding of E2AP and E2SM in a stateful manner.