In 5G networks, id-RAN-UE-NGAP-ID refers to the RAN UE NGAP ID—an identifier used in the NGAP (Next Generation Application Protocol) interface between the gNB and the AMF. The main purpose this ID is :
- Uniquely identifies a UE within the context of the RAN node (e.g., gNodeB) during communication with the 5G Core Network (5GC) via the NG interface.
- Ensures proper management of UE-specific procedures (e.g., handovers, session setup, release) between the RAN and the AMF.
Followings are the topics to be covered in this note
- Executive Summary
- Key Characteristics and Functions
- Which part of the gNB allocates it ?
- What else identifies the same UE inside the RAN ?
- What happens to it when the UE goes to RRC INACTIVE ?
- How does the identifier change when the UE moves ?
- Reference
Executive Summary
|
Area |
Main Topics Covered |
Summary |
What it means in practice |
|---|---|---|---|
|
What it identifies |
|
RAN UE NGAP ID names one UE association as the NG-RAN node sees it. The AMF half of the pair is covered on the AMF UE NGAP ID page. |
Read it as the RAN node's handle for an association, not as a name for a subscriber. It means nothing outside the node that issued it. |
|
Which node allocates it |
|
In a split gNB the NG interface terminates at the gNB-CU. The control plane part of the CU allocates and holds this identifier, and no F1AP message carries it. |
Do not look for RAN UE NGAP ID in an F1 trace. The DU's view of the same UE is the F1AP identifier pair and the C-RNTI. |
|
Scope |
|
The specification scopes the value to the NG-RAN node. A gNB connected to several AMFs in a pool allocates from a single space across all of them. |
Two UEs on one gNB never share a value, even when their NG connections terminate at different AMFs. |
|
The other RAN-side identifiers |
|
One UE in RRC_CONNECTED carries several identifiers at once. Each belongs to a different interface, and each has its own scope and lifetime. |
Establish which interface a trace is showing before matching identifiers. Values from different interfaces are unrelated counters. |
|
Behaviour across RRC states |
|
A UE in RRC_INACTIVE is still CM-CONNECTED, so the NG-AP association and both NGAP identifiers survive. Going to RRC_IDLE releases them. |
RRC_INACTIVE is the state where the RAN-side identifiers and the NGAP identifiers stop agreeing with each other. Check the RRC state before concluding anything is stale. |
|
Mobility |
|
The identifier belongs to the node that allocated it, so any change of serving node produces a new value. |
A changed RAN UE NGAP ID with an unchanged AMF UE NGAP ID is the normal signature of mobility, not of a second UE. |
Key Characteristics and Functions
In short, id-RAN-UE-NGAP-ID is simply the RAN’s unique identifier for a UE in NGAP signaling, ensuring correct association of messages with the appropriate UE context on the gNB side.
Unique RAN-Side Identifier
- The gNB allocates RAN UE NGAP ID when a new UE-associated signaling connection is set up over the NG interface.
- This ID uniquely identifies a particular UE for all NGAP messages on the RAN side (i.e., within the gNB).
Pairing with AMF UE NGAP ID
- On the core network side, the AMF allocates another unique ID called AMF UE NGAP ID.
- Together, the (RAN UE NGAP ID, AMF UE NGAP ID) pair provides a globally unique context reference for a given UE across the gNB and AMF.
Usage in NGAP Procedures
- Once assigned, the RAN UE NGAP ID is included in subsequent NGAP messages—such as Initial UE Message, Uplink/Downlink NAS Transport, and other UE-associated signaling—to ensure the UE is correctly identified at the RAN.
- It ensures that both gNB and AMF can correlate all signaling and data to the correct UE context.
Significance
- Efficient, unambiguous UE identification is critical for mobility management, paging, handover, and session management procedures.
- By maintaining this ID, the RAN can handle multiple UEs simultaneously and direct messages properly.
id-RAN-UE-NGAP-ID in Signaling
At the first NGAP message from gNB to AMF, gNB assigns a id-RAN-UE-NGAP-ID for the UE. From this point on, all the NGAP messages from gNB to AMF for this UE uses this ID.
Message: 127.0.1.1:33620 Initial UE message
initiatingMessage: {
procedureCode id-InitialUEMessage,
criticality ignore,
value {
protocolIEs {
{
id id-RAN-UE-NGAP-ID,
criticality reject,
value 1
},
{
id id-NAS-PDU,
criticality reject,
value '7E014295C6102E7...0530101'H
},
{
id id-UserLocationInformation,
criticality reject,
value userLocationInformationNR: {
nR-CGI {
pLMNIdentity '00F110'H,
nRCellIdentity '001234501'H
},
tAI {
pLMNIdentity '00F110'H,
tAC '000064'H
}
}
},
{
id id-RRCEstablishmentCause,
criticality ignore,
value mo-Signalling
},
{
id id-UEContextRequest,
criticality ignore,
value requested
}
}
}
}
At the first NGAP message from AMF to gNB, the AMF assigns a id-AMF-UE-NGAP-ID for the UE. From this point on, all the NGAP messages from AMF to gNB for this UE uses this ID.
Message: 127.0.1.1:33620 Downlink NAS transport
initiatingMessage: {
procedureCode id-DownlinkNASTransport,
criticality ignore,
value {
protocolIEs {
{
id id-AMF-UE-NGAP-ID,
criticality reject,
value 100
},
{
id id-RAN-UE-NGAP-ID,
criticality reject,
value 1
},
{
id id-NAS-PDU,
criticality reject,
value '7E005B01'H
}
}
}
}
Which part of the gNB allocates it ?
I used to picture the gNB as a single box while reading NGAP traces. In a split deployment it is not one box, and that changes which part of it owns this identifier.
The NG interface terminates at the gNB-CU, and control plane signalling terminates specifically at the gNB-CU-CP. That is where the RAN UE NGAP ID is allocated and held. The gNB-DU has no NG interface of its own. It never sees the value, and no F1AP message carries it.
The DU identifies the same UE by other means. Over F1 it uses the gNB-DU UE F1AP ID that it allocated. That is paired with the gNB-CU UE F1AP ID from the CU. Over the air it uses the C-RNTI, which is scoped to one cell. Three separate identifiers therefore name one UE at the same moment, each on a different interface.
The scope of the RAN UE NGAP ID is the NG-RAN node, and not one NG interface instance. A gNB connected to several AMFs in a pool allocates from a single space across all of them. Two UEs served by the same gNB therefore never carry the same value, even when their NG connections terminate at different AMFs.
Figure 1 places each identifier on the interface that carries it, for one UE at one moment.
Figure 1. The identifier belongs to the interface, not to the UE. Crossing from one interface to another means changing which pair names the same subscriber.
The gNB-CU-CP allocates it : NG terminates at the CU, and control plane signalling terminates at the CU-CP.The gNB-DU never sees the value : No F1AP message carries RAN UE NGAP ID, so an F1 trace is the wrong place to look for it.Three identifiers name one UE at once : C-RNTI on the air interface, the F1AP pair over F1, and the NGAP pair over NG.The scope is the NG-RAN node : One allocation space covers every AMF the node is connected to, so values never collide within a gNB.
What else identifies the same UE inside the RAN ?
One UE in RRC_CONNECTED carries a handful of identifiers at the same time. Each belongs to a different interface, and confusing them is the usual reason a trace stops making sense.
The table below lists them together. The column that matters most is the scope. It explains why two values can never be compared across a row. Each identifier counts inside a different boundary, so equal values in two rows mean nothing at all.
|
Identifier |
Interface or layer |
Allocated by |
Unique within |
Released when |
|---|---|---|---|---|
|
|
MAC, over the air |
The serving gNB-DU |
One cell |
The UE leaves the cell, or the connection ends |
|
|
F1 |
The gNB-DU |
One gNB-DU |
The F1 UE context is released |
|
|
F1 |
The gNB-CU |
One gNB-CU |
The F1 UE context is released |
|
|
E1 |
The gNB-CU-CP |
One gNB-CU-CP |
The bearer context is released |
|
|
NG |
The gNB-CU-CP |
One NG-RAN node |
The NG-AP UE association is released |
|
|
Xn |
Each of the two nodes, one each |
One NG-RAN node |
The Xn UE-associated signalling ends |
|
|
RRC, in RRC_INACTIVE |
The last serving gNB |
The RAN paging area |
The UE resumes, or moves to RRC_IDLE |
The AMF half of the NGAP pair is deliberately missing from that table, because it is not a RAN-side identifier. The AMF UE NGAP ID page covers it, together with the field widths of both halves and the way the pair is established.
Each identifier belongs to one interface : C-RNTI is air interface, the F1AP pair is F1, the E1AP pair is E1, and RAN UE NGAP ID is NG.Scope is what stops values being comparable : Each counts inside a different boundary, so the same number in two rows is a coincidence.Only C-RNTI is per cell : Every other identifier in the table is scoped to a node or wider, so it survives a cell change within that node.I-RNTI only exists in RRC_INACTIVE : It names the stored UE AS context, and it has no meaning while the UE is in RRC_CONNECTED.
What happens to it when the UE goes to RRC INACTIVE ?
I had this wrong for a while. I assumed that a UE leaving RRC_CONNECTED released everything the RAN was holding for it. RRC_INACTIVE does not work that way, and this identifier is the clearest example.
From the core network's point of view a UE in RRC_INACTIVE is still CM-CONNECTED. The NG-AP UE association stays up, and so do the N3 tunnels. Both halves of the NGAP pair therefore survive the transition, and the AMF is not told that anything happened.
The RAN-side identifiers behave differently. The C-RNTI is released. The UE is no longer in the connected context of any cell. The F1 UE context is released at the gNB-DU, so the F1AP pair goes with it. In their place the last serving gNB allocates an I-RNTI, which names the stored UE AS context.
RRC_IDLE is the case that does release the pair. The UE moves to CM-IDLE, the NG-AP association is released through the UE CONTEXT RELEASE procedure, and both NGAP identifiers go with it. That difference between the two states is what makes RRC_INACTIVE worth a section of its own.
Figure 2 sets the identifiers against the three RRC states, so the split is visible in one place.
Figure 2. The middle column is the one worth memorising. RRC_INACTIVE is the state where the RAN-side identifiers and the NGAP identifiers stop agreeing with each other.
RRC_INACTIVE is CM-CONNECTED : The core network still holds an association, so both NGAP identifiers survive and the AMF is not notified.The RAN-side identifiers are released : C-RNTI goes, and the F1 UE context at the gNB-DU goes with its F1AP pair.I-RNTI replaces them : The last serving gNB allocates it to name the stored UE AS context.RRC_IDLE is the state that releases the pair : UE CONTEXT RELEASE ends the NG-AP association, and both NGAP identifiers end with it.
How does the identifier change when the UE moves ?
Movement replaces this identifier more often than anything else does. The rule behind it is short. A RAN UE NGAP ID belongs to the node that allocated it, so a new serving node always means a new value.
A handover follows that rule directly. The target NG-RAN node allocates its own RAN UE NGAP ID and reports it to the AMF. The AMF half of the pair is unchanged, unless the AMF itself is relocated. The AMF UE NGAP ID page covers that exchange with a sequence diagram, so it is not repeated here.
A resume from RRC_INACTIVE at a different gNB reaches the same outcome by a longer route. The UE sends RRCResumeRequest carrying its I-RNTI. The new gNB uses that value to fetch the UE context from the last serving gNB over Xn. Only then does it allocate its own RAN UE NGAP ID and switch the path at the AMF.
Figure 3 follows that resume, using the same AMF-side value that appears in the examples on the AMF UE NGAP ID page.
Figure 3. The context fetch over Xn is the extra step that a resume has and a handover does not. What happens to the identifier pair afterwards is identical.
A new serving node means a new value : The identifier belongs to the node that allocated it, so it cannot be carried across.The AMF half usually survives : It changes only when the UE is relocated to a different AMF.A resume adds a context fetch in front : RETRIEVE UE CONTEXT over Xn happens before the new gNB allocates anything.The I-RNTI is what makes the fetch possible : It tells the new gNB which node is holding the stored context.One changed half is the signature of mobility : A new RAN UE NGAP ID beside an unchanged AMF UE NGAP ID is normal, and not a second UE.
Reference :
[1] TS 38.413 - NG-RAN; NG Application Protocol (NGAP). Defines RAN-UE-NGAP-ID and the UE-associated logical NG-connection.
[2] TS 38.401 - NG-RAN; Architecture description. Describes the CU and DU split, and where the NG interface terminates.
[3] TS 38.473 - F1 Application Protocol (F1AP). Defines gNB-CU UE F1AP ID and gNB-DU UE F1AP ID.
[4] TS 38.423 - Xn Application Protocol (XnAP). Defines the Retrieve UE Context procedure and the NG-RAN node UE XnAP ID pair.
[5] TS 38.331 - NR; Radio Resource Control (RRC) protocol specification. Defines RRC_INACTIVE, the I-RNTI and the resume procedure.
[6] AMF UE NGAP ID - the other half of the pair, on this site.