SCTP (Signalling Transport) in 5G NR

Introduction

SCTP (Stream Control Transmission Protocol) is a general-purpose transport-layer protocol — it sits in the stack exactly where TCP and UDP sit, directly on top of IP. In 5G it plays one specific role: it is the reliable pipe underneath every NG-RAN control-plane (signalling) interface. It carries no user data; user data rides GTP-U. SCTP carries the signalling that sets everything else up.

You meet SCTP the instant any control interface comes to life. Before a gNB can exchange a single NGAP message with the AMF, the two open an SCTP association on N2; the same is true for F1-C between gNB-CU and gNB-DU, E1 between CU-CP and CU-UP, and Xn between gNBs. That association is long-lived — it typically stays up for as long as the two nodes are peered — and every UE-attach, handover, paging and context-management message for all the UEs on that interface flows through it.

It matters because signalling has an unusual pair of requirements: it must be perfectly reliable (a lost registration or handover message cannot be tolerated) and perfectly resilient (a single link failure must not drop thousands of calls). TCP gives reliability but not resilience or independence between messages; UDP gives neither. SCTP was designed, for the SS7-over-IP world, to give both at once, and 3GPP adopted it as the mandatory transport for NG-RAN signalling.

Why SCTP is needed

The concrete problem is that NG-RAN signalling multiplexes thousands of independent conversations — one per UE, per procedure — over a single interface between two nodes. Those conversations must not interfere with each other, every message must arrive exactly once, message boundaries must be preserved so the application gets whole PDUs, and the link must survive a transport failure. No single conventional transport gives all of that.

TCP is reliable but is a single ordered byte-stream bound to one address pair: one dropped segment head-of-line-blocks everything queued behind it (so one UE's retransmission stalls unrelated UEs), it has no message boundaries (the application must re-frame a byte-stream), and if the one IP path dies the connection dies. UDP gives up reliability and ordering entirely — unusable for signalling that must arrive. SCTP was built precisely to close this gap: it keeps TCP-grade reliability while adding streams (independent ordered sub-channels), message framing (PDU boundaries preserved), multihoming (multiple IPs with automatic failover), and a cookie handshake (flood resistance). Each of those is a direct answer to a specific weakness of TCP for carrier signalling.

What SCTP Is and Why NR Uses It

SCTP (Stream Control Transmission Protocol) is a transport-layer protocol, sitting exactly where TCP and UDP sit in the stack, on top of IP. Every NG-RAN application protocol runs its PDUs over an SCTP association: NGAP on the N2 interface between the gNB and the AMF, XnAP on Xn between gNBs, F1AP on F1-C between the gNB-CU and gNB-DU, and E1AP on E1 between the CU-CP and CU-UP. In each case there is one SCTP association per interface instance, and that association is the reliable pipe the application protocol assumes underneath it.

Why not TCP? TCP is a single ordered byte-stream bound to one address pair. One dropped segment blocks everything queued behind it (head-of-line blocking), so one UE's stalled message would delay unrelated UEs sharing the same connection; and if the one IP path dies, the connection dies with it. Why not UDP? UDP is unreliable and unordered — unacceptable for signalling that must arrive exactly once and, where it matters, in order. SCTP was designed for the SS7-over-IP world precisely to close this gap, and 3GPP inherited it as the mandatory transport for NG-RAN signalling. The design choices below — streams, multihoming, the cookie handshake, message framing — are each a direct answer to a specific weakness of TCP for carrier signalling.

The features that matter for RAN signalling

SCTP has many knobs, but a handful of features are why 3GPP chose it, and each maps to a concrete benefit for a mobile network carrying millions of signalling messages. Keep this table as the mental model; the following sections unpack each row.

Streams — Killing Head-of-Line Blocking

An SCTP association is subdivided into multiple streams, negotiated at setup through the Number of Outbound Streams and Number of Inbound Streams fields in INIT/INIT-ACK. Ordered delivery is guaranteed within a stream, but streams are independent of one another. So if a message on one stream is lost and awaiting retransmission, only that stream stalls — messages on every other stream keep being delivered in order.

This is the single most important property for RAN signalling. Consider a busy N2 link carrying thousands of UEs. Under TCP, one dropped segment belonging to one UE's message would block the delivery of every byte queued behind it, including unrelated UEs' messages — classic head-of-line blocking. Under SCTP the node spreads traffic across streams, so a retransmission on one stream never delays another. The conventional mapping is: stream 0 carries non-UE-associated signalling (interface setup, configuration updates), and UE-associated procedures are distributed across the remaining streams. A given UE's messages stay on one stream so their relative order is preserved, while different UEs land on different streams so they are mutually independent.

How does the application choose? NGAP tags each message as either non-UE-associated or UE-associated. Non-UE-associated goes to stream 0. For a UE-associated message the CU/AMF picks a stream when the UE context is created and keeps using it, so that UE's INITIAL CONTEXT SETUP, later UE CONTEXT MODIFICATION, and eventually UE CONTEXT RELEASE all arrive in the order they were sent. Cross-UE independence and per-UE ordering, at the same time — that is what streams buy.

Multihoming — Path Redundancy

A single SCTP endpoint can advertise several IP addresses, listed in the address parameters of INIT/INIT-ACK. The association then spans every combination of the two endpoints' addresses. One address pair is designated the primary path; the others are backups. SCTP continuously probes the idle paths with HEARTBEAT chunks, so it always knows which alternates are reachable. If the primary path fails — heartbeats and retransmissions on it exceed Path.Max.Retrans — traffic fails over to a validated alternate address without tearing the association down or losing the UE contexts riding on it.

For a carrier this is not a nicety, it is a requirement. A gNB and an AMF are typically dual-homed across two independent transport networks so that a single fibre cut, switch failure or router reboot triggers a sub-second failover rather than dropping every call on that interface. TCP has no equivalent: a TCP connection is bound to exactly one source/destination address pair and dies when that path dies, forcing the whole application to detect the failure, reconnect and re-establish state.

The Four-Way Handshake and Path Upkeep

SCTP opens an association with a four-way handshake — one step more than TCP's three-way — and that extra step exists specifically to resist flooding attacks using a stateless cookie:

1. INIT — the initiator proposes its Initiate Tag, advertised receive window, outbound/inbound stream counts, initial TSN, and its list of IP addresses.
2. INIT-ACK — the responder answers with its own tag, streams and addresses and a signed State Cookie. Crucially, it allocates no association state yet.
3. COOKIE-ECHO — the initiator echoes the cookie straight back, proving its source address is real and reachable.
4. COOKIE-ACK — the responder validates the cookie, only now creates the association, and the link is ESTABLISHED.

Because the responder holds no state until a valid cookie returns, a flood of spoofed INITs from forged source addresses cannot exhaust its memory — there is nothing to exhaust until step three completes. This is the built-in analogue of TCP SYN-cookies, and it matters because N2 faces the core network where such attacks are a real threat.

Once established, the association is kept alive and monitored. HEARTBEAT/HEARTBEAT-ACK chunks probe each path, confirm reachability and measure round-trip time for retransmission timing. SACK chunks acknowledge received DATA. Graceful teardown is a three-message SHUTDOWN / SHUTDOWN-ACK / SHUTDOWN-COMPLETE exchange that flushes any in-flight data first; an abrupt error is signalled with a single ABORT.

Chunks, TSNs, Bundling and Delivery Order

SCTP does not send raw messages on the wire. Everything is packaged into chunks, and one SCTP packet (one IP payload) can carry several chunks bundled together. A chunk has a type, flags, a length and a value; the common types you will meet are below.

Two numbering schemes work together. The TSN (Transmission Sequence Number) is association-wide: every DATA chunk gets the next TSN, and SACKs acknowledge TSNs, so reliability and retransmission operate across the whole association regardless of stream. Independently, each stream has its own Stream Sequence Number (SSN) that orders messages within that stream. Splitting the two is precisely what lets streams be reliable-but-independent: a gap in TSNs triggers retransmission, while the SSN decides in what order a given stream's delivered messages are handed up.

Bundling packs multiple small chunks — several DATA chunks, or DATA plus a SACK — into one packet to cut per-packet overhead, useful when signalling is bursty. Ordered vs unordered delivery is per-message: the default is ordered (delivered up in SSN order within the stream), but a DATA chunk can set the U (unordered) bit so it is delivered as soon as it arrives, skipping the SSN queue. NG-RAN signalling almost always uses ordered delivery so procedure steps arrive in sequence.

Interfaces, PPIDs and Stream Mapping

Because SCTP is a generic transport, something has to say which application protocol a given DATA chunk carries. That is the PPID (Payload Protocol Identifier), a 32-bit value the sender writes into every DATA chunk and SCTP passes through untouched. The receiver's SCTP stack uses it to hand the payload to the right application. Each NG-RAN protocol has an IANA-registered PPID and a well-known SCTP port.

The PPID does not change how SCTP transports the chunk — it is advisory addressing for the layer above — but it makes the payload self-describing, which matters when a node runs several application protocols. On the stream side, every one of these protocols follows the same discipline: stream 0 for non-UE-associated procedures, other streams for UE- or context-associated ones. NGAP is the canonical example, mapping its common procedures (those about the interface or the node as a whole, like NG SETUP or AMF CONFIGURATION UPDATE) onto stream 0, and its UE-dedicated procedures (each tied to one UE-associated logical connection) onto the remaining streams, one stream per UE for the UE's lifetime. F1AP and XnAP mirror this split for their own common versus context-associated procedures.

SCTP vs TCP, and the Association Picture

Side by side, every difference below is a reason a signalling designer reaches for SCTP over TCP:

The figure below draws a single gNB–AMF association: each endpoint owns two IP addresses (multihoming), the association is subdivided into streams carrying NGAP PDUs, and the two paths are shown as a primary carrying data and a secondary kept warm by heartbeats.

Summary

SCTP is the reliable transport underneath every NG-RAN signalling interface — NGAP/N2, XnAP/Xn, F1AP/F1-C, E1AP/E1 — and it exists because signalling needs TCP-grade reliability plus three things TCP cannot give: independence between messages, message-boundary preservation, and survival of a path failure. It delivers these with streams (ordered within, independent across, so one UE never head-of-line-blocks another; stream 0 = non-UE-associated, other streams = per-UE), message framing (whole PDUs, no re-parsing), and multihoming (multiple IPs, primary + heartbeat-probed backups, sub-second failover).

Under the hood, an association is opened by the four-way INIT/INIT-ACK/COOKIE-ECHO/COOKIE-ACK handshake whose stateless State Cookie resists INIT-floods; data travels as DATA chunks carrying a PPID (NGAP=60, XnAP=61, F1AP=62, E1AP=64) and two counters — the association-wide TSN for reliability and the per-stream SSN for ordering — acknowledged by SACK and monitored by HEARTBEAT. It is defined in RFC 4960, with its NR usage pinned down in TS 38.412 and the sibling 38.4xx transport specs.

Quick Q&A