The Interface Model of 5G
The 5G system defines a set of reference points (N-interfaces) between network functions. While the Service-Based Interface (SBI) handles NF-to-NF control-plane communication using HTTP/2, the N-interfaces connect the UE, RAN, and specific core NFs using protocols optimized for their particular role -- NGAP for RAN-core signaling, GTP-U for user-plane tunneling, and PFCP for user-plane control.
Understanding every N-interface, what it carries, and which protocol it uses is fundamental for anyone involved in 5G deployment, integration testing, or troubleshooting. The interface definitions are spread across multiple 3GPP specifications, primarily TS 23.501 (architecture), TS 38.413 (NGAP), TS 29.281 (GTPv1-U), and TS 29.244 (PFCP).
Complete N-Interface Reference Table
| Interface | Endpoint A | Endpoint B | Protocol | Function |
|---|---|---|---|---|
| N1 | UE | AMF | NAS (5G-MM, 5G-SM) | Registration, authentication, session management |
| N2 | gNB | AMF | NGAP over SCTP | RAN-core signaling, UE context, handover |
| N3 | gNB | UPF | GTP-U over UDP | User-plane tunnel for PDU session data |
| N4 | SMF | UPF | PFCP over UDP | Session rules, forwarding policy, QoS enforcement |
| N6 | UPF | Data Network | IP (native) | User traffic to/from internet or enterprise DN |
| N7 | SMF | PCF | HTTP/2 (SBI) | SM policy association |
| N8 | AMF | UDM | HTTP/2 (SBI) | Registration context storage |
| N9 | UPF | UPF | GTP-U over UDP | Inter-UPF tunnel for chained UPFs |
| N10 | SMF | UDM | HTTP/2 (SBI) | Session subscription data retrieval |
| N11 | AMF | SMF | HTTP/2 (SBI) | PDU session context relay |
| N12 | AMF | AUSF | HTTP/2 (SBI) | Authentication procedures |
| N13 | AUSF | UDM | HTTP/2 (SBI) | Authentication vector retrieval |
| N14 | AMF | AMF | HTTP/2 (SBI) | UE context transfer during AMF change |
| N15 | AMF | PCF | HTTP/2 (SBI) | AM policy association |
| N16 | SMF | SMF | HTTP/2 (SBI) | Inter-SMF handover context |
| N22 | AMF | NSSF | HTTP/2 (SBI) | Slice selection |
| N27 | NF | NWDAF | HTTP/2 (SBI) | Analytics data collection |
| N32 | SEPP | SEPP | TLS/PRINS | Inter-PLMN security |
| N33 | AF | NEF | HTTP/2 (SBI) | Third-party application exposure |
Protocol Stack for N2, N3, and N4
Understanding the protocol layering is critical for troubleshooting and packet capture analysis.
N2 Protocol Stack (gNB to AMF)
| Layer | Protocol |
|---|---|
| Application | NGAP (NG Application Protocol) |
| Transport | SCTP (Stream Control Transmission Protocol) |
| Network | IP (IPv4 or IPv6) |
| Data Link | Ethernet |
NGAP is defined in 3GPP TS 38.413. It uses ASN.1 encoding (PER -- Packed Encoding Rules) for messages. SCTP provides reliable, in-order delivery with multi-homing support, which is critical for high-availability signaling links.
N3 Protocol Stack (gNB to UPF)
| Layer | Protocol |
|---|---|
| Payload | User IP packet (UE traffic) |
| Tunnel | GTP-U (GTPv1-U header with TEID) |
| Transport | UDP port 2152 |
| Network | IP (outer, transport network) |
| Data Link | Ethernet |
GTP-U is defined in 3GPP TS 29.281. Each PDU session has a unique GTP tunnel identified by a TEID (Tunnel Endpoint Identifier) at each end.
N4 Protocol Stack (SMF to UPF)
| Layer | Protocol |
|---|---|
| Application | PFCP (Packet Forwarding Control Protocol) |
| Transport | UDP port 8805 |
| Network | IP |
| Data Link | Ethernet |
PFCP is defined in 3GPP TS 29.244. It evolved from the Sx interface used in CUPS-enabled EPC (Release 14).
NGAP vs S1AP Comparison
NGAP replaced S1AP as the RAN-to-core signaling protocol. The table below highlights the key differences.
| Feature | S1AP (4G) | NGAP (5G) |
|---|---|---|
| Specification | TS 36.413 | TS 38.413 |
| Transport | SCTP | SCTP |
| Endpoint (RAN) | eNB | gNB |
| Endpoint (Core) | MME | AMF |
| UE identity | MME UE S1AP ID + eNB UE S1AP ID | AMF UE NGAP ID + RAN UE NGAP ID |
| Slice support | No | Yes (S-NSSAI in initial context) |
| QoS model | Bearer-based (EPS bearer ID) | Flow-based (QFI -- QoS Flow ID) |
| PDU session support | No (EPS bearer) | Yes (PDU session resource) |
| Handover types | Intra-LTE, Inter-RAT | Intra-NR, Inter-RAT, Xn-based |
| AMF selection at gNB | MME selection via S1 | AMF selection via NSSF-derived info |
| Paging | TAI list | TAI list + paging priority |
| Max procedures | ~45 elementary procedures | ~55 elementary procedures |
GTP-U Tunnel -- Worked Example
Consider a UE with IP address 10.0.1.50 on T-Mobile 5G SA sending a 1400-byte IP packet to a server at 8.8.8.8. The packet traverses the N3 GTP tunnel between gNB and UPF.
Uplink path (UE -> gNB -> UPF):- UE transmits the IP packet over the radio (SDAP -> PDCP -> RLC -> MAC -> PHY)
- gNB receives and decapsulates the radio layers, recovering the IP packet
- gNB encapsulates the IP packet in a GTP-U header:
- GTP-U version: 1, Protocol type: 1 (GTP), Message type: 0xFF (T-PDU)
- TEID: 0x00A1B2C3 (assigned by UPF during session setup)
- Sequence number: optional
- gNB wraps GTP-U in UDP (destination port 2152) and outer IP (destination: UPF N3 IP)
- Complete packet structure:
`
[Outer Ethernet] [Outer IP: gNB -> UPF] [UDP: sport=random, dport=2152]
[GTP-U: TEID=0x00A1B2C3] [Inner IP: 10.0.1.50 -> 8.8.8.8] [TCP payload]
`
Packet size calculation:
- Inner IP packet: 1400 bytes
- GTP-U header: 8 bytes (minimum, without optional fields)
- UDP header: 8 bytes
- Outer IP header: 20 bytes (IPv4)
- Outer Ethernet: 14 bytes
- Total on N3: 1450 bytes (excluding Ethernet)
The UPF receives the server response, matches it to the PDU session via the UE IP prefix, and encapsulates it in GTP-U using the gNB TEID (e.g., 0x00D4E5F6 assigned by gNB). The gNB decapsulates and delivers to the UE over the radio.
Operator data -- Verizon: In their 2024 network architecture paper, Verizon reported that N3 GTP-U tunnels carry an average of 450 Gbps aggregate traffic during peak hours across their 5G SA footprint, with individual UPF instances handling up to 100 Gbps of GTP-U throughput using DPDK-accelerated packet processing.Worked Example -- TEID Allocation Tracking
During a PDU session setup for two UEs:
UE-1 session:- UPF assigns uplink TEID = 0x00000001 on N3 (gNB sends to this TEID)
- gNB assigns downlink TEID = 0x80000001 on N3 (UPF sends to this TEID)
- If UPF chain with I-UPF: N9 uplink TEID = 0x00010001, N9 downlink TEID = 0x80010001
- UPF assigns uplink TEID = 0x00000002 on N3
- gNB assigns downlink TEID = 0x80000002 on N3
Each TEID is locally unique per GTP-U endpoint. The SMF tracks the TEID mapping in its session context and programs them into the UPF via PFCP on N4.
PFCP Session Establishment Flow
The N4 interface between SMF and UPF uses PFCP to program forwarding rules. Here is the detailed message flow for establishing a PFCP session (TS 29.244 Section 7.5.2).
Step 1 -- PFCP Association Setup:Before any sessions, the SMF and UPF establish a PFCP association. The SMF sends a PFCP Association Setup Request containing its Node ID and supported features. The UPF responds with its capabilities (e.g., supported QoS, DPI features, TEID range).
Step 2 -- PFCP Session Establishment Request (SMF -> UPF):The SMF sends the session establishment request containing:
- Create PDR (Packet Detection Rule): Defines how to match incoming packets. For uplink: source interface = Access (N3), TEID, UE IP. For downlink: source interface = Core (N6), UE IP prefix.
- Create FAR (Forwarding Action Rule): Defines what to do with matched packets. Forward, drop, buffer, or duplicate. Includes outer header creation (GTP encapsulation parameters).
- Create QER (QoS Enforcement Rule): MBR, GBR values per QoS flow. Maps to the 5QI from the PCF policy.
- Create URR (Usage Reporting Rule): Volume or time thresholds for charging triggers.
The UPF installs the rules and responds with the created TEID(s) for the N3 interface, confirming the session is active.
Step 4 -- PFCP Session Modification (after gNB TEID received):Once the gNB provides its downlink TEID via NGAP, the SMF sends a PFCP Session Modification Request to update the downlink FAR with the gNB outer header creation parameters.
Operator data -- SK Telecom: In their 2024 technical report on 5G SA optimization, SK Telecom documented that their N4 interface handles approximately 8,000 PFCP session establishment/modification transactions per second per SMF instance, with a median latency of 3.2 ms per transaction. They use PFCP heartbeat intervals of 10 seconds to detect UPF failures within 30 seconds (3 missed heartbeats).Interface Troubleshooting Quick Reference
| Symptom | Interface to Check | Tool | What to Look For |
|---|---|---|---|
| UE cannot register | N1 (NAS), N2 (NGAP) | Wireshark NGAP dissector | Registration Reject cause code |
| PDU session fails | N2, N4 (PFCP) | Wireshark PFCP dissector | Session Establishment Response cause |
| No user data flow | N3 (GTP-U) | tcpdump on UPF N3 port | GTP-U T-PDU packets, correct TEID |
| High latency | N3, N9 | iPerf + GTP analysis | N9 additional hop, UPF processing delay |
| Charging failures | N4 (URR reports) | PFCP trace | Usage Report trigger not firing |
Key Takeaway: The N-interfaces form the physical and logical connectivity fabric of 5G. N2 carries NGAP signaling between gNB and AMF, N3 tunnels user data via GTP-U, N4 programs UPF forwarding via PFCP, and N6 connects to the data network. Mastering these four interfaces and their protocol stacks is essential for any 5G engineer involved in integration or optimization.