E2 Interface

The E2 interface operates within a strict latency budget of 10ms to 1 second, enabling xApps to execute closed-loop control for radio resource management. This is distinct from the Non-RT RIC's A1 interface, which handles policy guidance on timescales greater than 1 second. The interface supports event-triggered, periodic, and on-demand reporting to balance responsiveness with signaling overhead.

The E2 interface abstracts RAN functions through standardized E2 Service Models (E2SMs) defined by the O-RAN Alliance. Each E2SM exposes a specific set of RAN control and data collection procedures:

• E2SM-KPM: Key Performance Measurement for collecting cell and UE-level metrics.
• E2SM-RC: RAN Control for configuring radio resources, handover parameters, and QoS policies.
• E2SM-NI: Network Interface for managing transport and fronthaul interfaces. This abstraction allows xApps to be developed independently of the underlying RAN vendor hardware.

The E2 interface uses a publish-subscribe mechanism for efficient data delivery. An xApp sends an E2 Subscription Request to a RAN node, specifying the service model, reporting frequency, and trigger conditions. The RAN node responds with an E2 Indication message containing the requested data. This model prevents the RIC from polling the RAN continuously, drastically reducing control plane load and enabling scalable monitoring of thousands of cells.

The E2 interface protocol stack is built for reliability and performance:

• E2 Application Protocol (E2AP): The application layer protocol defining procedures for interface setup, reset, configuration, and reporting. Modeled after 3GPP's NGAP and XnAP.
• SCTP (Stream Control Transmission Protocol): Provides message-oriented, multi-stream transport with built-in multi-homing and congestion control, ensuring reliable delivery of control messages.
• IP Layer: Standard IPv4 or IPv6 networking for routing between the Near-RT RIC and RAN nodes.

A core principle of the E2 interface is RAN Function Exposure. The interface does not expose raw, vendor-specific internal APIs. Instead, it presents a standardized, abstracted view of RAN capabilities. An O-CU or O-DU declares which E2SMs it supports during the E2 Setup procedure. This allows a single xApp to control equipment from multiple vendors without modification, fulfilling the O-RAN promise of true multi-vendor interoperability.

The E2 interface mandates strong security to protect the critical control plane:

• Mutual TLS (mTLS): Both the Near-RT RIC and the RAN node authenticate each other using X.509 certificates, ensuring only authorized entities establish a connection.
• OAuth 2.0 Token-Based Authorization: For fine-grained access control, xApps must present valid access tokens when initiating E2 subscriptions, limiting which service models and procedures they can invoke.
• SCTP over IPsec: Optional IPsec tunneling provides an additional layer of encryption and integrity protection at the network layer.

A standardized abstraction that defines what a specific RAN function exposes over the E2 interface. Each E2SM specifies the data structures, event triggers, and control actions for a particular use case. Key examples include:

• E2SM-KPM: Key Performance Measurement collection and reporting.
• E2SM-RC: RAN Control for fine-grained UE and cell-level operations.
• E2SM-NI: Network Interface management for flow-level control.
• E2SM-CC: Coordination and Control for multi-vendor interoperability. An E2 Node advertises its supported E2SMs during the E2 Setup procedure, allowing the Near-RT RIC to discover node capabilities dynamically.

The mechanism by which an xApp registers interest in specific RAN events via the E2 interface. The flow operates as follows:

• The xApp sends a RIC Subscription Request to the Near-RT RIC, specifying event triggers (e.g., UE handover, PRB utilization threshold).
• The RIC translates this into an E2 Subscription Request and forwards it to the target E2 Node.
• When the trigger condition is met, the E2 Node sends an E2 Indication message containing the requested data.
• The RIC routes the indication to the subscribing xApp for processing. This publish-subscribe pattern decouples data producers from consumers, enabling multiple xApps to independently consume the same telemetry stream.

The CONTROL service model enables the Near-RT RIC to actively modify RAN behavior. Unlike passive monitoring, control operations directly influence radio resource management:

• UE Context Modification: Change bearer configurations or handover thresholds for a specific user.
• Cell Resource Allocation: Adjust PRB allocation ratios between slices or traffic classes.
• Carrier Activation/Deactivation: Dynamically switch component carriers on or off for energy saving.
• Beam Steering: Modify massive MIMO beam weights and patterns. Control messages are acknowledged by the E2 Node, providing a closed feedback loop. The RIC can also issue control requests with acknowledgment to verify execution success before proceeding with dependent actions.

The E2 interface relies on a robust transport stack to meet near-real-time latency requirements of 10ms to 1s:

• Transport Protocol: SCTP (Stream Control Transmission Protocol) provides multi-homing, ordered delivery, and message boundary preservation.
• Security: Mutual TLS authentication between the Near-RT RIC and E2 Node, with X.509 certificate-based identity verification.
• IPSec: Optional network-layer encryption for additional confidentiality in untrusted transport networks.
• SCTP Heartbeats: Continuous path monitoring detects link failures and triggers automatic failover to redundant paths. The combination of SCTP multi-homing and TLS ensures both high availability and integrity for critical control plane traffic.

The initialization procedure that establishes the E2 connection and enables plug-and-play interoperability between multi-vendor components:

• The E2 Node initiates an SCTP association to the configured Near-RT RIC IP address.
• The node sends an E2 Setup Request containing its identity, supported RAN Function IDs, and corresponding E2SM definitions.
• The RIC validates the node's certificate and responds with an E2 Setup Response, acknowledging the supported functions.
• The RIC updates its internal R-NIB with the node's topology, capabilities, and cell inventory. This zero-touch discovery eliminates manual configuration and enables dynamic scaling as new RAN nodes are deployed.