Skip to content

N32 — SEPP ⇔ SEPP (inter-PLMN interconnection / N32-c · N32-f)

Difficulty: Advanced / Estimated study time: 20 min / Endpoints: SEPP ⇔ SEPP (opposing PLMN) / Protocol: HTTP/2 over TLS (N32-c/N32-f, PRINS possible) / Related interfaces: SBI in general (protection targets)

Learning objectives

After reading this page, you will be able to:

  • Explain that N32 is not a usual inter-NF SBI but an inter-PLMN interconnection IF connecting different PLMNs (operators).
  • Explain that N32 is composed of two layers, N32-c (control) and N32-f (forwarding).
  • Explain that N32-c handles the initial handshake · security capability negotiation · agreement on the protection method (TLS/PRINS) between SEPPs.
  • Explain that N32-f protects and forwards inter-PLMN SBI messages, and that PRINS is a method that keeps integrity/confidentiality end-to-end even with an intervening IPX relay provider.
  • Explain the correspondence with 4G (EPC) DEA (Diameter Edge Agent) / IPX Diameter interconnection.

Prerequisites

The following are helpful to understand first:

  • The positioning of SBA / SBI and HTTP/2 · TLS → Protocol dictionary
  • The NF standing at both ends of N32 (the security gate at the PLMN boundary) → SEPP
  • The signaling that reaches the HPLMN's NFs during roaming → Authentication
  • SBI security in general (TLS · the concept of protection) → Security
  • The concept of interfaces and reference points → Interface dictionary

Why — why it is needed

The NFs of the 5GC converse with each other over SBI (HTTP/2 + JSON). However, when a subscriber roams, the NFs of the visited PLMN (VPLMN) need to interact with the NFs of the home PLMN (HPLMN) (AUSF/UDM/SMF, etc.). What becomes an issue here is crossing the boundary of different operator networks. If NFs of the counterpart PLMN were hit directly, the internal topology (the number and addresses of NFs) would leak, and because relay providers such as an IPX (Interconnect Provider Exchange) intervene along the path, the risk of eavesdropping and tampering of messages arises.

Therefore, a security gate is placed at each PLMN's boundary, and inter-PLMN signaling is always routed through it. This is SEPP (Security Edge Protection Proxy), and the interconnection IF connecting SEPPs is N32. Without N32, there is no common foundation to flow SBI messages safely between operators, and neither topology hiding nor E2E protection is possible. N32 is the foundation of roaming signaling.

Analogy: N32 is an international line connecting the customs (SEPP) of two countries. First, a diplomatic agreement (N32-c: agreeing on which cipher method to speak with) is exchanged, and thereafter the actual documents are sealed and sent (N32-f). The special sealing method that protects the contents even with an intermediary carrier (IPX) in between is PRINS.

Overview

N32 is an interconnection IF connecting SEPP ⇔ SEPP (opposing PLMN). Its positioning differs from a usual inter-NF SBI; it is not for NFs to call each other's services, but for protecting and relaying signaling that crosses the PLMN (operator) boundary. It is the same as SBI in using HTTP/2 over TLS as the common transport stack, but its role is not "inter-NF service invocation" but "inter-PLMN interconnection."

N32 is composed of the following two sub-IFs.

  • N32-c (control): The control IF that performs the initial handshake between SEPPs. It handles security capability negotiation, agreement on the protection method (TLS or PRINS), and the necessary parameter exchange.
  • N32-f (forwarding): The forwarding IF that actually protects and forwards inter-PLMN SBI messages. Following the method agreed on N32-c, it relays messages to the counterpart SEPP while keeping their integrity/confidentiality.

The protection method is TLS (setting up TLS directly between SEPPs) or PRINS (PRotocol for N32 INterconnect Security). PRINS is an N32-dedicated protection method that keeps integrity/confidentiality end-to-end even with an intervening IPX relay provider along the path. Furthermore, the SEPP is also responsible for topology hiding of its own PLMN's internals over N32. The specifications are laid down in TS 29.573 (N32) and TS 33.501 (N32 security).

The division of roles between N32-c and N32-f

N32 is not a single line but is made of two layers with different roles. N32-c is, so to speak, the "negotiating table," where SEPPs first connect and agree on "which security capabilities each has" and "whether to connect directly with TLS or protect relay with PRINS." N32-f is the "actual transport route" based on that agreement, protecting and carrying the SBI messages during roaming. Because control (agreement) and forwarding (actual operation) are separated, understand the order as: first the agreement is completed on N32-c, and then N32-f functions.

Basic Concept — explanation for beginners

Let us compare N32 to an international line connecting the customs of two countries.

When you use your smartphone abroad (roaming), the NFs of the visited destination (VPLMN) need to query the NFs of your contract origin (HPLMN) "authenticate this subscriber" or "establish this session." However, the counterpart is a different company's network. Therefore, each company places customs (SEPP) at the border and always routes the cross-border exchanges through customs. What connects the SEPPs is N32.

The customs first make a diplomatic agreement. This is N32-c, where they agree "we can use this cipher method" and "then let us go with PRINS this time" (security capability negotiation and agreement on the protection method). Once the agreement is made, sealing and sending the actual documents (SBI messages) is N32-f.

At this time, a carrier (IPX) may come in between. The special sealing method that protects end-to-end so that the carrier cannot peek at or rewrite the contents is PRINS. When TLS can connect the customs directly, TLS is used. Furthermore, the SEPP also performs topology hiding, not showing its own country's internal circumstances (the addresses and number of NFs) to the counterpart.

Protocol / Transport

Item Content
Positioning Inter-PLMN interconnection IF (separate from a usual inter-NF SBI. Not an NF service invocation)
Protocol HTTP/2 over TLS (uses the SBI common stack, but the purpose is inter-PLMN interconnection)
Sub-IF N32-c (control: handshake · capability exchange · agreement on the protection method) / N32-f (forwarding: protected relay of inter-PLMN SBI messages)
Protection method TLS (direct connection between SEPPs) or PRINS (E2E protection under IPX intervention) — TS 33.501
Specification TS 29.573 (N32) / TS 33.501 (N32 security · PRINS · topology hiding)
Lower transport TCP, protected by TLS. SCTP not used
Port The listening port is implementation-dependent. No specific number is asserted

Uses the SBI common stack, but its positioning differs from an 'inter-NF service invocation'

N32 also rides on the SBI common stack of HTTP/2 over TLS, but whereas the other SBIs (N7/N8/N10/N11, etc.) are service invocations among NFs within the same PLMN, N32 is an interconnection connecting the SEPPs of different PLMNs. Therefore, do not regard N32 as "just one SBI line," but distinguish it as a protection · relay layer for crossing the PLMN boundary. For the details of N32-f forwarding and the PRINS cipher, refer to TS 33.501 / TS 29.573.

Architecture

This shows the context in which N32 connects the SEPPs of both PLMNs, the NFs of each PLMN interact with the opposing PLMN via the SEPP, and the composition in which an IPX may relay.

flowchart LR
  vNF["NF (VPLMN)"] --> vSEPP["SEPP (VPLMN side)"]
  vSEPP =="N32-c / N32-f"==> hSEPP["SEPP (HPLMN side)"]
  hSEPP --> hNF["NF (HPLMN)"]
  IPX["IPX (relay · optional)"] -.intervene.- hSEPP

  classDef edge fill:#efe,stroke:#3a3,stroke-width:2px;
  class vSEPP,hSEPP edge;

How to read the diagram: The NFs of each PLMN communicate with the outside via their own PLMN's SEPP. Between SEPPs, they first agree on the security capabilities and protection method with N32-c, and thereafter protect and forward SBI messages with N32-f (thick line). Even if an IPX intervenes as a relay along the path, integrity/confidentiality is protected end-to-end if PRINS is used. Note that the NF does not hit the opposing PLMN directly but always goes via the SEPP, and that the SEPP is also responsible for topology hiding.

Procedures used

N32 is used in establishing the connection between SEPPs and in relaying inter-PLMN signaling during roaming.

  • N32-c (initial handshake · capability exchange · agreement on the protection method): The SEPPs first connect and perform security capability negotiation, agreement on the protection method (TLS/PRINS), and the necessary parameter exchange. This becomes the prerequisite for the subsequent N32-f forwarding.
  • N32-f (protected forwarding of inter-PLMN SBI messages): During roaming, SBI messages originating from VPLMN NFs (those heading to the HPLMN's AUSF/UDM/SMF in authentication, PDU session, etc.) are protected by the agreed method and relayed to the HPLMN-side SEPP. When an IPX intervenes, E2E protection is provided by PRINS.

For the details of these procedures (message sequence, IEs, conditions) and how they are used in the authentication/security context, refer to the descriptions of SEPP and Authentication. The details of the procedure are to be confirmed, and this page does not assert them.

Main Messages

N32 operates over HTTP/2, but each of the two layers has a different role. The representative exchanges are as follows.

Sub-IF Exchange (conceptual) Purpose
N32-c Security Capability Negotiation Security capability negotiation between SEPPs (selection of TLS/PRINS)
N32-c Parameter Exchange / handshake Initial handshake of protection-method agreement · parameter exchange
N32-f Protected message forwarding Protected forwarding of inter-PLMN SBI messages (protection with JWE, etc.)

Note (to be confirmed): The table above is a conceptual arrangement of roles. The concrete API names, service operation names, operation directions, and resource URIs follow the definitions of TS 29.573 and differ by Release, so they are individually to be confirmed. For the details of cipher processing such as JWE in PRINS, refer to TS 33.501. For details of each message, refer to the Message dictionary.

Packet Analysis (Wireshark)

Because N32 is HTTP/2 over TLS, it is observed on capture as HTTP/2 and TLS (an L4-dedicated protocol like NGAP/SCTP does not appear).

Purpose Display Filter
Extract HTTP/2 messages http2
Check the TLS layer tls

Decode highlights:

  • N32 is encrypted with TLS. To see the contents, a decryption key (TLS session keys, etc.) is required. Without the key, it is only visible as the encrypted payload of tls.
  • When PRINS is used on N32-f, the protected messages are carried in a JSON/JWE structure. Observing the contents requires a decryption key.
  • Unlike N2's NGAP (binary, over SCTP), the point of observation for N32 is that it is Web-like (HTTP/2). SCTP is not used, and filters such as sctp.port are not used.

Comparison with EPC

  • In 4G: The signaling boundary between operators (roaming) was handled by the DEA (Diameter Edge Agent), and operators were connected by Diameter interconnection via an IPX. Protection · relay at the boundary was done on a Diameter basis.
  • In 5G: The role of the roaming boundary is handled by SEPP, and N32 connects the SEPPs. The transport was replaced from Diameter to HTTP/2 + TLS (PRINS/TLS protection), and PRINS, which realizes E2E protection even under IPX intervention, was introduced (TS 29.573).
4G (EPC) 5G (5GC)
DEA (Diameter Edge Agent) SEPP (Security Edge Protection Proxy)
Diameter interconnection via IPX N32 (between SEPPs, HTTP/2 + PRINS/TLS)
Diameter (over dedicated L4) SBI protection: HTTP/2 over TLS (+ PRINS)
— (depends on Diameter's protection) TS 29.573 (N32) / TS 33.501 (N32 security)

4G's roaming boundary (DEA/IPX Diameter interconnection) was replaced by N32/SEPP in 5G. While the philosophy of placing a security gate at the boundary and protecting inter-operator signaling continues, the main change is the addition of PRINS, which is HTTP/2-based and can protect E2E even under IPX intervention.

3GPP Specification

  • 3GPP TS 29.573 — N32 (inter-PLMN interconnection / N32-c · N32-f). Individual clause numbers are to be confirmed
  • 3GPP TS 33.501 — N32 security (PRINS / TLS / topology hiding). Individual clause numbers are to be confirmed
  • 3GPP TS 23.501 §4 — System architecture and reference points, §6.2.17 (SEPP). Individual clause numbers are to be confirmed
  • 3GPP TS 29.500 — SBI framework (HTTP/2-based common conventions). Individual clause numbers are to be confirmed

Note (to be confirmed): That N32 is composed of the two layers N32-c/N32-f, that the protection method is TLS/PRINS, and that the SEPP is responsible for topology hiding, are general arrangements of the 3GPP architecture. The exact API names, resource URIs, procedure/HTTP method assignments, and detailed clause numbers of each service operation differ by Release, so they are individually to be confirmed. For the details of N32-f forwarding and the PRINS cipher, refer to TS 33.501 / TS 29.573.

Summary

  • N32 is an inter-PLMN interconnection IF connecting SEPP ⇔ SEPP (opposing PLMN), and its positioning differs from a usual inter-NF SBI.
  • It is composed of two layers: N32-c (control: handshake · capability negotiation · agreement on the protection method) and N32-f (forwarding: protected relay of inter-PLMN SBI messages).
  • The protection method is TLS or PRINS. PRINS is an N32-dedicated method that keeps integrity/confidentiality end-to-end even with an intervening IPX relay provider (TS 33.501 / TS 29.573).
  • The SEPP is also responsible for topology hiding of its own PLMN over N32, and N32 becomes the foundation of roaming signaling.
  • It corresponds to 4G's DEA / IPX Diameter interconnection; in 5G it was replaced by N32/SEPP.

Next Step