id-AMF-UE-NGAP-ID (often simply called the AMF UE NGAP ID) is an identifier allocated by the Access and Mobility Management Function (AMF). It is used on the 5G core side to uniquely identify a UE within the context of NGAP-based signaling between the gNB and the AMF.. The main purpose this ID is :
- Uniquely identifies a UE within the context of the AMF during communication with the RAN (e.g., gNodeB) over the NG interface.
- Ensures proper coordination of UE-specific procedures (e.g., session setup, handovers, UE context release) between the AMF and RAN.
Followings are the topics to be covered in this note
- Executive Summary
- Key Characteristics and Functions
- How wide are the two identifiers ?
- How does the pair get established ?
- What is the scope and the lifetime of each ID ?
- What happens at handover and at AMF change ?
- What happens when the pair does not match ?
- Where else does this pair pattern appear ?
- Reference
Executive Summary
|
Area |
Main Topics Covered |
Summary |
What it means in practice |
|---|---|---|---|
|
What the pair is |
|
Neither identifier means anything on its own. Each is unique only inside the node that allocated it, and only the pair is unique across the NG interface. |
Never look up a UE by one half of the pair. A trace that shows only one identifier has not yet reached the point where the association exists. |
|
Widths |
|
TS 38.413 defines both as integers. The AMF side is 40 bits and the RAN side is 32 bits, and neither has fields inside it to decode. |
There is nothing to parse out of these values. Two values seen side by side are independent counters from two different nodes. |
|
How the pair forms |
|
The NG-RAN node allocates first and reports its identifier. The AMF allocates its own on receipt and returns the completed pair. |
For exactly one message the pair is incomplete, and that is normal. An INITIAL UE MESSAGE with no AMF identifier is not a fault. |
|
Scope and lifetime |
|
The pair is created when the UE-associated logical NG-connection is set up and released when that connection ends. |
These are per-association handles, not names for a subscriber. The identity that survives across associations is the 5G-GUTI. |
|
Mobility |
|
A handover replaces the RAN half of the pair. The AMF half survives unless the UE is relocated to a different AMF. |
Following one UE across mobility means following a changing pair. Two different pairs in one call flow are not necessarily two UEs. |
|
Failure handling |
|
NGAP does not drop a message carrying an identifier it cannot resolve. It replies with ERROR INDICATION, and the cause distinguishes two different faults. |
The cause value narrows the search. An unknown local ID points at release handling, and an inconsistent remote ID points at association setup. |
|
The same pattern elsewhere |
|
Every UE-associated 3GPP interface uses a pair of node-local identifiers. NGAP is one instance of a general arrangement. |
Learn the pattern once and it transfers. The questions to ask on any of these interfaces are which node allocated which half, and when. |
Key Characteristics and Functions
In short, id-AMF-UE-NGAP-ID is the core (AMF) side’s unique identifier for a UE, used in conjunction with the gNB’s RAN UE NGAP ID to ensure all NGAP messages can be properly associated with the correct UE context.
Allocation by AMF
- Whenever a new UE-associated signaling connection is established, the AMF generates and assigns the AMF UE NGAP ID to that UE.
Pairing with RAN UE NGAP ID
- On the gNB side, there is another ID called RAN UE NGAP ID.
- Together, (AMF UE NGAP ID, RAN UE NGAP ID) form a unique pair identifying the UE context for all NGAP procedures and messages.
Usage in NGAP Messages
- Once assigned, the AMF UE NGAP ID appears in subsequent NGAP messages—such as Uplink/Downlink NAS Transport and other UE-related signaling—so that the AMF can correctly link messages to the relevant UE.
Importance
- Consistent use of the AMF UE NGAP ID ensures the AMF can track and manage the UE’s signaling context, facilitating mobility management, session management, and any other procedures across the NG interface.
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
}
}
}
}
How wide are the two identifiers ?
I assumed the two identifiers were the same width for a long time. They are not, and the difference is deliberate.
TS 38.413 defines both as plain integers. AMF-UE-NGAP-ID is an INTEGER in the range 0 to 2^40 - 1, so it is 40 bits wide. RAN-UE-NGAP-ID is an INTEGER in the range 0 to 2^32 - 1, so it is 32 bits wide. Neither has any internal structure. There is no PLMN field, no node field and nothing to decode inside the value.
The reason for the asymmetry is scale. One AMF serves UEs across many NG-RAN nodes, and its identifier has to stay unique across all of them at once. An NG-RAN node counts only the UEs it is serving itself. The wider field therefore sits on the side with more to count.
One consequence catches people who read traces. The value 1 in the RAN field and the value 100 in the AMF field are not related to each other in any way. They are two independent counters, each maintained by a different node. Reading either value on its own tells you nothing about the other.
Both are plain integers : AMF-UE-NGAP-ID and RAN-UE-NGAP-ID have no fields inside them, so there is nothing to decode from a value.The widths differ : 40 bits on the AMF side and 32 bits on the NG-RAN side.Scale explains the asymmetry : One AMF counts UEs across many NG-RAN nodes, while a RAN node counts only its own.The two values are unrelated counters : Seeing 1 next to 100 says nothing, because two different nodes allocated them independently.
How does the pair get established ?
The two identifiers do not appear at the same moment. One node allocates first, the other answers, and for one message the pair is incomplete. The two traces in Key Characteristics and Functions show exactly that.
The NG-RAN node allocates first. When it has a UE to report and no association yet, it allocates a RAN UE NGAP ID and sends INITIAL UE MESSAGE. That message carries id-RAN-UE-NGAP-ID and no AMF identifier at all, because none has been assigned yet. In the trace on this page the allocated value is 1.
The AMF answers, and that is when the pair completes. It creates a UE context, allocates an AMF UE NGAP ID, and puts both identifiers into its first downlink message for that UE. In the trace on this page that message is DOWNLINK NAS TRANSPORT, and the allocated value is 100. From that point onward every NGAP message about this UE carries both.
The pair is what the specification actually names. TS 38.413 calls it the UE-associated logical NG-connection. Neither identifier is meaningful by itself, because each is unique only inside the node that issued it. Together they are unique across the NG interface.
Figure 1 follows that exchange, using the same two values that appear in the traces on this page.
Figure 1. For exactly one message the pair is incomplete. An INITIAL UE MESSAGE with no AMF identifier is the normal case, not a fault.
The NG-RAN node allocates first : It picks a RAN UE NGAP ID and sends INITIAL UE MESSAGE before any AMF identifier exists.One message carries half a pair : INITIAL UE MESSAGE has no AMF identifier, and that is correct rather than a fault.The AMF completes the pair : Its first downlink message for the UE carries both identifiers, and every later message does the same.The pair is the named object : TS 38.413 calls it the UE-associated logical NG-connection, and uniqueness belongs to the pair rather than to either half.
What is the scope and the lifetime of each ID ?
Scope and lifetime are the two questions that decide whether a stored identifier is still usable. Each has a different answer on the two sides of the interface.
Scope comes first. An AMF UE NGAP ID is unique inside one AMF. Two different AMFs may hand out the same value at the same moment, and nothing is wrong. A RAN UE NGAP ID is unique inside one NG-RAN node, with the same caveat. Uniqueness across the NG interface comes from the pair, and never from one half of it.
Lifetime comes next. The pair lives as long as the UE-associated logical NG-connection. It is created when that connection is set up, and it is released when the connection ends. In normal operation the end is the UE CONTEXT RELEASE procedure. A UE that moves to CM-IDLE loses the association, so both identifiers are released with it.
These identifiers therefore say nothing about the subscriber. They are handles for one association, not names for a UE. The identity that survives across associations is the 5G-GUTI, which the AMF stores and reissues independently of any NGAP identifier.
Each half is node-local : An AMF UE NGAP ID is unique inside one AMF, and a RAN UE NGAP ID is unique inside one NG-RAN node.Only the pair is unique on the interface : Two AMFs may use the same value at the same time without any conflict.The lifetime is the association, not the UE : Both identifiers are released when the UE-associated logical NG-connection is released.Going idle releases the pair : A UE in CM-IDLE has no association, so it has no NGAP identifiers at all.The lasting identity is elsewhere : The 5G-GUTI survives across associations, and NGAP identifiers do not.
What happens at handover and at AMF change ?
Mobility is where the two halves stop travelling together. One of them survives a handover and the other does not.
Take an Xn handover with no AMF change. The target NG-RAN node allocates its own RAN UE NGAP ID, because the value the source used means nothing to it. The AMF keeps the AMF UE NGAP ID it already had, because the UE context inside the AMF did not move anywhere. The pair therefore changes in one half only. The AMF learns the new half from PATH SWITCH REQUEST, which carries the target's RAN UE NGAP ID alongside the AMF identifier already in use.
An N2 handover behaves the same way seen from the RAN. The AMF sends HANDOVER REQUEST carrying its own identifier. The target node allocates a fresh RAN UE NGAP ID and reports it in HANDOVER REQUEST ACKNOWLEDGE.
An AMF change is the case where both halves move. When the UE is relocated to a different AMF, that AMF allocates its own AMF UE NGAP ID, and the previous value carries no meaning there. A trace following one UE across an AMF relocation therefore shows two entirely different pairs, and neither of them is an error.
Figure 2 follows one UE through an Xn handover, starting from the pair that Figure 1 established. The three lifelines are the source NG-RAN node, the target NG-RAN node and the AMF. The values called out beside each message are the two NGAP identifiers. The band at the foot compares that outcome against the AMF relocation case.
Figure 2. An Xn handover replaces the RAN half and leaves the AMF half alone. Only an AMF relocation replaces both, which is why one changed identifier is not by itself evidence of a second UE.
The target node always allocates a new RAN half : A RAN UE NGAP ID is meaningless outside the node that issued it, so it cannot be carried over.The AMF half survives an Xn handover : The UE context in the AMF does not move, so its identifier does not change.PATH SWITCH REQUEST is where the AMF learns the new half : It carries the target's RAN UE NGAP ID together with the AMF identifier already in use.An AMF relocation replaces both halves : The new AMF allocates its own identifier, so the pair changes completely.Two pairs in one call flow need not mean two UEs : Follow the mobility procedures before concluding that a trace covers more than one subscriber.
What happens when the pair does not match ?
This is the section I reach for when signalling fails in a way that looks like a state problem. A mismatched identifier pair produces symptoms that are easy to blame on something else.
NGAP does not quietly drop a message carrying an identifier it cannot resolve. It answers with ERROR INDICATION, and the cause value says what went wrong. Two causes matter here. One reports that the local UE NGAP ID is unknown. The other reports that the remote UE NGAP ID is inconsistent with the local one.
The two causes describe different faults. An unknown local ID means the receiver holds no context under the identifier that was addressed to it. That usually follows a context release which one side did not observe. An inconsistent remote ID means the receiver did find a context, but the partner identifier in the message does not match the one it stored. That usually follows a lost or reordered message during association setup.
The practical value is in narrowing the search. An unknown local ID points at a lifecycle problem, so the release procedures are where to look. An inconsistent remote ID points at the association setup, so the question becomes which node allocated what, and in what order.
A bad identifier produces ERROR INDICATION : NGAP answers rather than dropping the message, so the failure is visible in the trace.Unknown local ID means no context : The receiver has nothing stored under the identifier addressed to it, which usually follows an unobserved release.Inconsistent remote ID means the wrong partner : A context exists, but the other half of the pair does not match what was stored.The cause value narrows the search : One points at release handling and the other at association setup, which are different parts of the code to inspect.
Where else does this pair pattern appear ?
The NGAP pair is not a design that stands alone. Every UE-associated 3GPP interface uses the same arrangement, and recognising it saves reading each specification from the beginning.
The pattern is always the same. Each end allocates its own identifier for the association. Each identifier is unique only within the node that allocated it. Both travel in every UE-associated message once the association is complete. The end that allocates first is the end that initiates the association.
|
Interface |
Identifier allocated by one end |
Identifier allocated by the other end |
Widths |
Specification |
|---|---|---|---|---|
|
|
RAN UE NGAP ID, by the NG-RAN node |
AMF UE NGAP ID, by the AMF |
32 and 40 bits |
TS 38.413 |
|
|
NG-RAN node1 UE XnAP ID |
NG-RAN node2 UE XnAP ID |
32 and 32 bits |
TS 38.423 |
|
|
gNB-DU UE F1AP ID, by the DU |
gNB-CU UE F1AP ID, by the CU |
32 and 32 bits |
TS 38.473 |
|
|
gNB-CU-UP UE E1AP ID, by the UP |
gNB-CU-CP UE E1AP ID, by the CP |
32 and 32 bits |
TS 37.483 |
|
|
eNB UE S1AP ID, by the eNB |
MME UE S1AP ID, by the MME |
24 and 32 bits |
TS 36.413 |
One column in that table is worth a second look. Every identifier is 32 bits except two. The AMF side of NG is 40 bits, and the eNB side of S1 is 24 bits. Both exceptions follow the same logic, which is how many UEs the node has to count at one time.
The five panels below run the same exchange on each interface in the table. Every panel has the identical shape, and only the node names, the message names and the identifier names change. Reading them in order makes the shared arrangement easier to see than any single one of them does.
Figure 3 is the NG case, repeated here in the compact form so that the five can be compared side by side. The NG-RAN node allocates first and reports its identifier in INITIAL UE MESSAGE. Figure 1 shows the same exchange with more detail.
Figure 3. NG. The NG-RAN node allocates first, and the AMF completes the pair in its first downlink message for that UE.
Figure 4 is the Xn case. TS 38.423 writes the identifier type generically, as NG-RAN node1 and NG-RAN node2 UE XnAP ID. Inside a handover the two roles have names, so the messages carry a source reference and a target reference. The node that starts the procedure is the node that allocates first.
Figure 4. Xn. Neither node is permanently the first allocator. Whichever node starts the procedure allocates first, so the roles swap with the direction of the handover.
Figure 5 is the F1 case. The gNB-DU allocates first, because the DU is the end that sees the UE arrive. It reports its identifier in INITIAL UL RRC MESSAGE TRANSFER, together with the RRCSetupRequest it has just received.
Figure 5. F1. The gNB-DU allocates first, because it is the end that sees the UE arrive.
Figure 6 is the E1 case, and it is the one that breaks the habit of expecting the edge node to allocate first. Bearer setup is started by the control plane, so gNB-CU-CP allocates before gNB-CU-UP does. The user plane then answers with an identifier of its own.
Figure 6. E1. The control plane allocates first here, which is the opposite of F1. What decides it is which end initiates the procedure, not where the node sits in the architecture.
Figure 7 is the S1 case, included because it is where the arrangement started. The shape is identical to NG, with an eNB in place of the NG-RAN node and an MME in place of the AMF. Only the field widths differ, at 24 bits and 32 bits.
Figure 7. S1. The same two-step exchange as NG, several releases earlier, with narrower fields.
The arrangement is general, not NGAP-specific : Xn, F1, E1 and S1 all identify a UE association with a pair of node-local identifiers.The initiating end allocates first : On NG that is the NG-RAN node, and on F1 it is the gNB-DU.E1 is the case that breaks the habit : Bearer setup starts in the control plane, so gNB-CU-CP allocates before gNB-CU-UP. Position in the architecture does not decide it.Most halves are 32 bits : The AMF side of NG at 40 bits and the eNB side of S1 at 24 bits are the two exceptions.The same three questions transfer : Which node allocated which half, when it was allocated, and what releases it.
Reference :
[1] TS 38.413 - NG-RAN; NG Application Protocol (NGAP). Defines AMF-UE-NGAP-ID, RAN-UE-NGAP-ID and the UE-associated logical NG-connection.
[2] TS 38.401 - NG-RAN; Architecture description. Describes the UE-associated logical NG-connection in context.
[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 NG-RAN node UE XnAP ID pair.
[5] TS 37.483 - E1 Application Protocol (E1AP). Defines gNB-CU-CP UE E1AP ID and gNB-CU-UP UE E1AP ID.
[6] TS 36.413 - S1 Application Protocol (S1AP). Defines MME UE S1AP ID and eNB UE S1AP ID, shown here for comparison.