E1AP (E1 — CU-CP ↔ CU-UP) in 5G NR

Introduction

E1 is the interface that appears the moment you take the gNB-CU disaggregation one step further than most diagrams show. The familiar picture is CU / DU / RU; the less familiar one is that the CU itself splits into a gNB-CU-CP (control plane) and one or more gNB-CU-UP (user plane). E1 is the wire between those two, and E1AP (TS 38.463) is the application protocol that runs on it, layered over SCTP over IP.

You meet E1 in the connection life-cycle of every UE served by a disaggregated gNB, but you never see it on the air. It carries no RRC, no NAS, and — importantly — no user data. It is a pure control channel whose entire job is to let the control plane, which owns the decisions, drive the user plane, which owns the bearers. When a PDU session is set up, modified during handover, or released, E1 is where the CU-CP tells the CU-UP exactly what user-plane state to build or destroy.

It matters because the CU-CP/CU-UP split is what lets an operator place bulk user-plane processing near the transport edge (low latency, local breakout, slicing) while keeping RRC, security and mobility logic centralised. That separation only works if there is a clean, standardised command channel between the two boxes — and that channel is E1.

Why E1 is needed

Concretely, once you separate the control and user planes inside the CU, three problems appear that E1 solves. First, the CU-CP still terminates RRC and derives all security keys, but it no longer holds the user-plane PDCP entities — so it needs a way to hand the user-plane keys (K_UPenc, K_UPint) to the node that will actually cipher and integrity-protect the data. Second, the CU-CP decides which DRBs and PDU sessions exist and what their QoS is, but the CU-UP is the node that must allocate the PDCP/SDAP entities and the GTP-U tunnel endpoints — so the decision has to be transmitted, not just made. Third, the two ends of every user-plane tunnel (N3 toward the UPF, F1-U toward the DU) must learn each other's transport addresses and TEIDs, and E1 is where those endpoints are exchanged. Without E1 the split simply cannot be assembled into a working data path.

What E1 Is

The NG-RAN disaggregation story starts with the CU/DU/RU split, but it does not stop there. The gNB-CU itself can be broken into two logical nodes that run on different hardware, in different processes, or even at different sites: the gNB-CU-CP hosts RRC and the control-plane part of PDCP (PDCP-C), while the gNB-CU-UP hosts the user-plane part of PDCP (PDCP-U) and SDAP. E1 is the interface between those two nodes, and it carries signalling only — there is deliberately no user data on E1. It is a pure control interface. The protocol that runs on it is E1AP, layered over SCTP over IP.

Because a single CU-CP can control several CU-UPs (for load balancing, slicing, or user-plane locality near the edge), and each CU-UP can be reached by more than one CU-CP, E1 is a many-to-many interface at the deployment level. But every E1 instance is a point-to-point SCTP association between one CU-CP and one CU-UP. Everything below is described from the perspective of that single association.

Where E1 Sits in the Split gNB

In a fully disaggregated gNB you have one gNB-CU-CP, one or more gNB-CU-UP, and one or more gNB-DU. The control plane holds it all together. The CU-CP terminates F1-C to each DU (the control part of F1, carrying F1AP) and E1 to each CU-UP. The CU-UP terminates F1-U to the DU (the GTP-U user-plane tunnel toward the radio) and N3 to the UPF (the GTP-U tunnel toward the 5G core). Northbound, the CU-CP terminates NG-C (NGAP) to the AMF, while user data on NG-U (N3) runs between the CU-UP and the UPF.

So the CU-CP never touches user data — but it decides which bearers exist, what their QoS is, and what security keys protect them, then pushes that down to the CU-UP over E1. The CU-UP owns the user-plane PDCP/SDAP entities and the GTP-U tunnel endpoints, but it does nothing on its own initiative for a UE: it acts on E1AP commands. For how the control part of F1 fits, see F1AP.

Who Holds What: CU-CP vs CU-UP

The clean way to understand E1 is to keep straight which node owns which piece of state. The split is not arbitrary — it follows the control/user-plane boundary of PDCP and the location of the radio-side security. The table below is worth memorising.

Transport: E1AP over SCTP

E1AP is a signalling protocol, so like the other NG-RAN application protocols it runs on SCTP (Stream Control Transmission Protocol) over IP, not on TCP. The choice is deliberate: SCTP gives E1AP reliable, in-order delivery per stream, plus two features TCP lacks and that a control interface leans on heavily.

• Multi-streaming. A single SCTP association carries multiple independent ordered streams. E1AP places non-UE-associated signalling on one stream and can spread per-UE procedures across others, so a stalled or retransmitting message for one UE does not head-of-line-block another UE's bearer setup.
• Multi-homing. An SCTP endpoint can bind several IP addresses, so if one transport path fails the association survives on another — useful when CU-CP and CU-UP sit on separate hardware or sites.

E1AP itself does no message-level retransmission — it relies on SCTP for that. The IANA-registered SCTP Payload Protocol Identifier (PPID) for E1AP is 64, and the standardised SCTP destination port for E1 is 38462. (For comparison: NGAP uses port 38412 / PPID 60, XnAP 38422 / PPID 61, F1AP 38472 / PPID 62, X2AP 36422 / PPID 27.) Because E1 carries key material (see below), TS 33.501 requires the transport to be protected — typically IPsec ESP, or DTLS over SCTP.

Interface Management: Non-UE-Associated Procedures

Before any UE can be served, the interface itself has to be established and kept in sync. These procedures are global to the E1 instance — they carry no per-UE identity and use the non-UE-associated signalling of E1AP.

Bearer Context Procedures — the Heart of E1

This is what E1 exists to do. When a UE's DRBs need to come into being, change, or go away, the CU-CP drives the CU-UP through the Bearer Context procedures. All three are CU-CP-initiated and UE-associated, and each UE's context is identified on E1 by a pair of identifiers described further below.

In BEARER CONTEXT SETUP REQUEST the CU-CP passes the CU-UP everything it needs to build the user plane for the UE. The most important IEs are:

A few of those values have precise encodings worth carrying in your head. The S-NSSAI is an 8-bit SST plus an optional 24-bit SD. The 5QI is an integer in the range 0–255 (standardised values are listed in TS 23.501). The GTP-U TEID in every TNL Information IE is a 32-bit value, and the transport-layer address is an IPv4 and/or IPv6 endpoint. The PDCP SN length in PDCP Configuration is 12 or 18 bits. And both UE E1AP IDs (below) are INTEGER (0..4294967295) — a 32-bit handle.

The CU-UP allocates the resources, builds the PDCP/SDAP entities, and answers with BEARER CONTEXT SETUP RESPONSE, returning the endpoints it now owns:

Bearer Context Setup — Message Sequence

The sequence below shows the CU-CP driving the CU-UP to create a UE's user plane. Watch how the two UE E1AP IDs are established (the CU-CP's in the request, the CU-UP's in the response) and how the TNL/TEID endpoints are exchanged in both directions so that both ends of every GTP-U tunnel end up knowing where to send packets.

Two identifiers deserve a note. The gNB-CU-CP UE E1AP ID is chosen by the CU-CP and appears first, in the request. The gNB-CU-UP UE E1AP ID is chosen by the CU-UP and returned in the response. Both are INTEGER (0..4294967295). From then on, both IDs are quoted in every message for that UE, so each node can index straight into its own context. This mirrors the paired-ID pattern you see on F1 (gNB-CU UE F1AP ID / gNB-DU UE F1AP ID) and on NG (AMF UE NGAP ID / RAN UE NGAP ID).

E1, F1 and NG Together in One PDU-Session Setup

E1 never works alone. A single "set up a PDU session for this UE" request from the core touches three interfaces in a defined order, and the whole point of the exchange is to stitch two GTP-U tunnels end to end: N3 between the UPF and the CU-UP, and F1-U between the CU-UP and the DU. Follow the endpoints and it all clicks into place.

Notice the pattern: E1 is entered twice — once to allocate the CU-UP endpoints, and again to inject the DU's F1-U endpoint after F1 has produced it. That "two-visit" shape is why BEARER CONTEXT MODIFICATION is so central even during a plain first-time setup. By the end, the CU-UP knows where to send uplink N3 packets (to the UPF) and downlink F1-U packets (to the DU), the UPF knows the CU-UP's N3 downlink endpoint, and the DU knows the CU-UP's F1-U endpoint. Every arrow of the user plane has both ends filled in — and none of that user data ever went near E1. Meanwhile the CU-CP has also delivered the RRC reconfiguration to the UE over F1-C/SRB so the radio side of the DRB is set up too.

Summary

E1 is the interface you reach for whenever the gNB-CU is disaggregated into a control plane and a user plane. Keep three facts in the front of your mind and the rest follows. First, E1 is control-only: E1AP over SCTP, no user data, ever — the data it configures flows on N3 and F1-U. Second, the CU-CP commands, the CU-UP executes: the CU-CP owns RRC, all key derivation and mobility decisions, and drives the CU-UP through the BEARER CONTEXT procedures to build, modify and release PDCP-U/SDAP entities and their GTP-U endpoints. Third, a UE is addressed by a pair of IDs — gNB-CU-CP UE E1AP ID + gNB-CU-UP UE E1AP ID, each a 32-bit integer, one allocated by each node.

When you trace a PDU-session setup, remember that E1 is visited twice: once in BEARER CONTEXT SETUP to allocate the CU-UP's N3-downlink and F1-U endpoints, and again in BEARER CONTEXT MODIFICATION to feed back the DU's F1-U TEID after F1 has produced it. Only when both visits complete are both GTP-U tunnels stitched end to end. That "two-visit" shape, and the paired-ID addressing, are the two ideas that make every other E1 exchange — handover, DU change, re-keying, release — easy to read.

Quick Q&A