NGAP (N2 — gNB ↔ AMF) in 5G NR

Introduction

NGAP (NG Application Protocol) is the application-layer signalling protocol on the NG interface between an NG-RAN node (the gNB) and the 5G core's Access and Mobility Management Function (AMF). It is specified in TS 38.413, with the interface itself framed by TS 38.410. It is the successor to LTE's S1AP and occupies the same place in the architecture: the standardised contract across which the radio and the core cooperate on a per-subscriber basis.

NGAP comes into play the moment a UE tries to reach the network and stays involved for as long as that UE has a presence on the interface. It carries the UE's first NAS message into the core, brings back the security material and policy the gNB needs to build an access-stratum context, wires up the user-plane tunnels for each PDU session, pages idle UEs, and drives core-anchored mobility. None of the user's actual data flows on NGAP — it only describes and controls the pipes that carry it.

Because it sits exactly on the RAN/core boundary, NGAP is where two ownership domains meet: the RAN owns the radio, the core owns subscription, security roots and session policy. Reading NGAP well means keeping that boundary in mind — every message is one side asking the other to do something only it can do.

Why NGAP is needed

Concretely, the RAN cannot serve a subscriber on its own. It does not hold the subscription, it cannot run authentication, it does not own the security root, and it does not decide which network slices or QoS the user is entitled to — all of that lives in the core. Equally, the core cannot reach into the radio to reserve resources or configure bearers. NGAP is the contract that lets each side ask the other to do exactly what only it can do: the gNB relays the UE's NAS to the core and reserves radio resources on command; the core authenticates, supplies the K_gNB security anchor, and describes the PDU sessions and QoS flows to build.

What NGAP Is

NGAP (NG Application Protocol) is the application-layer signalling protocol on the NG interface between an NG-RAN node (the gNB) and the core's AMF. It is specified in TS 38.413, while the interface it lives on — its general principles, the plane split, the transport — is framed by TS 38.410. Keeping those two documents apart in your head is the first step: 38.410 is the "what and why of NG", 38.413 is the "how of NGAP".

Like all the 3GPP application protocols in this family (S1AP, X2AP, XnAP, F1AP, E1AP), NGAP is defined in ASN.1 and encoded with the aligned variant of the Packed Encoding Rules — a different choice from RRC's unaligned PER, but the same ASN.1 discipline of extensible IEs and criticality handling that lets releases co-exist. Its messages are grouped into elementary procedures, each an initiating message plus (for class 1) a defined response, which is the unit you actually reason about when reading a call flow.

The NG Interface and Its SCTP Transport

NG divides cleanly into a control plane and a user plane, and it pays to hold them apart because only one of them is NGAP's business.

NG-C (control plane). NGAP application messages are carried over SCTP over IP between the gNB and the AMF. SCTP is the load-bearing choice here, and the reasons matter. It is connection-oriented and reliable like TCP, but it adds multi-streaming — many logically independent ordered streams inside one association — so that one UE's blocked signalling does not head-of-line-block every other UE's. It also supports multi-homing, where an endpoint advertises several IP addresses and traffic fails over to an alternate path without tearing the association down. A single SCTP association per gNB–AMF pair carries both the non-UE common signalling and all per-UE dedicated signalling.

Two transport details are worth carrying in your head because they anchor the packets in a trace. NGAP uses the registered SCTP port 38412, and it identifies itself to SCTP with a dedicated Payload Protocol Identifier (PPID), so a capture can tell NGAP chunks apart from any other SCTP traffic on the box. By convention the non-UE-associated common procedures use SCTP stream 0, while UE-associated signalling is spread across the remaining streams so that per-UE flows stay mutually independent — the practical realisation of "no head-of-line blocking between UEs".

NG-U (user plane). User data between the gNB and the UPF travels on the N3 reference point as GTP-U, one tunnel per PDU session, each end identified by an IP address plus a TEID (Tunnel Endpoint Identifier). NGAP's role is only to tell each side which UP Transport Layer Information (UP TNL — the GTP-U endpoint address plus TEID) to use; the payload bytes themselves never touch NGAP.

Interface Management (Non-UE-Associated)

Before any subscriber can be served, the gNB and AMF must agree they can talk. These are non-UE-associated procedures: they concern the interface as a whole, carry no UE identifiers, and run on the common signalling.

NG SETUP REQUEST / NG SETUP RESPONSE. The instant the SCTP association comes up, the gNB sends NG SETUP REQUEST advertising its identity (Global RAN Node ID), its Supported TA List (the tracking areas plus the S-NSSAIs and PLMNs it serves in each), and its RAN Node Name. The AMF answers with NG SETUP RESPONSE carrying its Served GUAMI List, its PLMN Support List (including supported S-NSSAI per PLMN) and its Relative AMF Capacity, a weight used to balance load across the AMFs of a set. If the AMF cannot serve the gNB it returns NG SETUP FAILURE with a Cause and optionally a Time To Wait. Only after a successful NG Setup is the interface considered operational; until then no UE-associated message is allowed.

The identifiers exchanged here are structured, and knowing their make-up makes the messages legible. A GUAMI (Globally Unique AMF Identifier) is PLMN ID + AMF Region ID + AMF Set ID + AMF Pointer, which is exactly what lets a UE's 5G-S-TMSI be routed back to the AMF that allocated it. An S-NSSAI (the slice identifier) is an 8-bit Slice/Service Type (SST) optionally plus a 24-bit Slice Differentiator (SD). And a Global RAN Node ID carries the PLMN ID plus the gNB ID. These are the fields a real NG SETUP trace is full of.

Configuration updates. Either side can renegotiate without dropping the association. RAN CONFIGURATION UPDATE lets the gNB change its served TAs, cells or node name; AMF CONFIGURATION UPDATE lets the AMF change its GUAMIs, PLMN support or capacity, and can even add or remove the TNL (transport) endpoints of the association. Each is a class 1 procedure: it is answered with ... UPDATE ACKNOWLEDGE or, on rejection, ... UPDATE FAILURE. There is also NG RESET, used to release UE contexts in bulk (for one side or all) after a failure, again with an acknowledge.

UE-Associated Signalling and the Two NGAP IDs

NGAP splits every message into one of two worlds. Non-UE-associated signalling (the interface management above, plus paging and warning broadcast) concerns the interface itself. UE-associated signalling concerns exactly one subscriber and is bound to a UE association — a piece of shared state that both nodes keep for the life of that UE's presence on the interface. The UE association is named by a pair of identifiers, one allocated at each end:

The two-ID design lets each node index its own context in O(1): the receiver reads the ID that it allocated and jumps straight to the stored state. The very first uplink message, INITIAL UE MESSAGE, carries only the RAN UE NGAP ID, because the AMF has not yet created a context and so has no ID to offer. The AMF allocates the AMF UE NGAP ID and returns it on the first downlink message of the association; from that point on every UE-associated message carries both IDs. A message that arrives with an unknown or mismatched pair is answered with an ERROR INDICATION (see below), and a stale context is torn down.

The UE identity that travels inside these messages is distinct from the NGAP IDs and worth separating out: the 5G-S-TMSI is the temporary subscriber identity the core uses to page and to route, and it is itself derived from the allocating AMF's GUAMI plus a 5G-TMSI. So there are two naming layers in play at once — the NGAP ID pair names the association on this interface, while the 5G-S-TMSI names the subscriber across the core.

The Core Per-UE Procedures

These are the heart of NGAP — the messages that actually move a subscriber through registration, security, session setup and release.

NAS transport. The gNB is a transparent relay for NAS (the signalling between the UE and the AMF/core that the RAN does not interpret). When a UE first appears, the gNB wraps its initial NAS message (e.g. a Registration Request) into INITIAL UE MESSAGE together with the RRC Establishment Cause, User Location Information and a 5G-S-TMSI if the UE supplied one. Every later NAS PDU rides inside DOWNLINK NAS TRANSPORT (AMF → gNB) or UPLINK NAS TRANSPORT (gNB → AMF). This is how authentication, security-mode command and the registration accept cross the RAN — NGAP carries the NAS as an opaque byte string.

INITIAL CONTEXT SETUP REQUEST / RESPONSE. Once NAS security is established, the AMF tells the gNB to build the UE's access-stratum context. The request carries what the gNB cannot derive itself: the Security Key (the K_gNB the gNB roots its AS ciphering and integrity on), the UE Security Capabilities (the algorithms the UE supports), the UE Aggregate Maximum Bit Rate (UE-AMBR), the GUAMI, the Allowed NSSAI (the slices this UE may use), a Mobility Restriction List, and optionally a first PDU Session Resource Setup List. The gNB configures RRC/PDCP/RLC/MAC, admits what it can, and replies with INITIAL CONTEXT SETUP RESPONSE reporting the admitted PDU session resources and their RAN-side UP TNL; on failure it returns INITIAL CONTEXT SETUP FAILURE.

PDU SESSION RESOURCE SETUP / MODIFY / RELEASE. These manage the user plane of a UE whose context already exists. PDU SESSION RESOURCE SETUP REQUEST asks the gNB to establish one or more sessions, each described by a PDU Session Resource Setup Request Transfer that lists the QoS flows (each with a QoS Flow Identifier and its 5QI and Allocation and Retention Priority) together with the UPF-side UL NG-U UP TNL Information — the N3 GTP-U address and TEID that uplink data must be sent to. The gNB maps QoS flows onto DRBs, allocates its own downlink N3 endpoint, and returns the DL UP TNL/TEID in the response. PDU SESSION RESOURCE MODIFY adds, removes or re-QoSes flows on an existing session; PDU SESSION RESOURCE RELEASE tears sessions down. There is also a class 2 PDU SESSION RESOURCE NOTIFY the gNB uses to report, unsolicited, that a GBR flow was released or restored.

A subtlety that trips people up: several of the session IEs (the ... Request Transfer / ... Response Transfer octet strings) are NGAP containers that the AMF does not build or read — they are produced by the SMF and passed through the AMF transparently, the same way the gNB passes NAS transparently through to the core. So on a single PDU SESSION RESOURCE SETUP there are actually two transparent relays happening at once: NAS through the gNB, and the SMF's session-transfer container through the AMF. The 5QI in those flows indexes the standardised QoS characteristics (resource type — GBR / non-GBR / delay-critical GBR, priority level, packet-delay budget, packet-error rate) defined by 5GC QoS.

Context release and paging. UE CONTEXT RELEASE COMMAND / COMPLETE (AMF-initiated, class 1) tears down the whole UE association, e.g. when the UE goes idle. The gNB can ask for this with a class 2 UE CONTEXT RELEASE REQUEST. There is also UE CONTEXT MODIFICATION for changing security or AMBR mid-connection. When downlink data or signalling arrives for an idle UE, the AMF sends PAGING — a non-UE-associated message, since the UE has no active association — to every gNB in the UE's registration area, addressing it by 5G-S-TMSI and a TAI List for Paging.

NG Handover, Path Switch and Error Indication

Mobility is where NGAP's per-UE procedures and the distinction between N2 and Xn come sharply into focus.

NG (N2) handover. When the source and target gNBs have no Xn link, or the move crosses an AMF boundary, the handover is run entirely through the core in NGAP. It has two elementary procedures. On the source side, Handover Preparation: the source gNB sends HANDOVER REQUIRED, the AMF responds with HANDOVER COMMAND (or HANDOVER PREPARATION FAILURE). On the target side, Handover Resource Allocation: the AMF sends HANDOVER REQUEST to the target gNB, which reserves resources and replies HANDOVER REQUEST ACKNOWLEDGE (or HANDOVER FAILURE). The move is finalised with a class 2 HANDOVER NOTIFY from the target, and can be aborted with HANDOVER CANCEL. Downlink data buffered at the source is described to the target with a RAN STATUS TRANSFER.

PATH SWITCH REQUEST — not NG handover, clarify. It is easy to file Path Switch under "NGAP handover", and while the message is an NGAP procedure, it belongs to a different mobility flow. An Xn handover is executed directly between source and target gNBs over the Xn interface without core involvement in the radio move; only after the UE has landed on the target does the target gNB send PATH SWITCH REQUEST to the AMF to ask it to switch the downlink N3 path from the source to the target UPF endpoint. The AMF (via the SMF) redirects the tunnel and answers PATH SWITCH REQUEST ACKNOWLEDGE (or FAILURE). So Path Switch is the RAN-to-core completion of an Xn handover, whereas HANDOVER REQUIRED/REQUEST is a full core-driven N2 handover. Same protocol, two very different triggers.

ERROR INDICATION. When a node receives a message it cannot process — an unknown UE NGAP ID pair, a mandatory IE missing, a semantic error — and no other response is defined, it sends ERROR INDICATION carrying a Cause and, where relevant, a Criticality Diagnostics IE that pinpoints the offending IE. It can be UE-associated (quoting the ID pair) or non-UE-associated. It is a class 2 procedure: it reports a problem but itself expects no reply.

Class 1 vs Class 2, and Procedures at a Glance

Every NGAP elementary procedure is one of exactly two kinds, and knowing which is which tells you immediately whether to expect an answer.

Class 1 procedures have a response: they complete with an explicit successful outcome (an ... RESPONSE, ... ACKNOWLEDGE or ... COMPLETE) or an unsuccessful one (a ... FAILURE). NG Setup, Configuration Update, Initial Context Setup, all three PDU Session Resource procedures, UE Context Release/Modification, Handover Preparation, Handover Resource Allocation, Path Switch and NG Reset are class 1. Class 2 procedures are fire-and-forget: a single message with no response defined at the NGAP layer. Initial UE Message, Downlink/Uplink NAS Transport, Paging, Handover Notify, UE Context Release Request, PDU Session Resource Notify, the RAN/AMF status and configuration transfers, and Error Indication are class 2. A class 2 procedure that goes wrong is not "failed" — there is simply nothing to fail; the peer may raise a separate ERROR INDICATION instead.

LTE ↔ NR: S1AP ↔ NGAP

NGAP is the direct evolution of LTE's S1AP, so if you know one you already know most of the other — but the differences map precisely onto what 5G changed in the core.

The one-layer-down analogue is worth holding alongside this: just as NGAP is the gNB's contract with the core, F1AP is the CU's contract with the DU — same ASN.1/SCTP family, same two-ID association pattern, one seam deeper inside the gNB.

Summary

NGAP is the control-plane contract on the N2 interface between the gNB and the AMF, defined in TS 38.413 and carried on SCTP. It never carries user data — it only describes and drives the NG-U/N3 GTP-U tunnels that do. Everything the RAN cannot decide alone about a subscriber crosses here: NAS relay, security anchoring, PDU-session and QoS-flow setup, paging, and core-anchored mobility.

Three ideas unlock the whole protocol. First, the non-UE vs UE-associated split: interface management (NG SETUP, config updates) versus per-subscriber work bound to the RAN UE NGAP ID + AMF UE NGAP ID pair, with the first uplink message carrying only the RAN half. Second, the class 1 vs class 2 distinction, which tells you at a glance whether a message expects a response. Third, the N2 vs Xn mobility split, where HANDOVER REQUIRED/REQUEST is core-driven and PATH SWITCH REQUEST merely completes a RAN-driven Xn move.

Hold those three, remember the TNL/TEID handshake that arms the N3 tunnel, and any NGAP trace resolves into a clear conversation between two peers who each do only what they alone can.

Quick Q&A