S1AP in a Real LTE Capture

The core network's side of the LTE attach and VoLTE walkthrough. The radio page follows two phones over the air. This page follows the same run on S1, the link between the eNB and the MME: 109 messages, logged by the same srsRAN eNB on the same clock, so every S1AP message can be placed against the radio frame it caused or answered.

Interactive viewer

The annotated S1AP sequence diagram and the full packet field trees, side by side — click any message to open its complete Wireshark field tree. Best on Chrome, Edge, or Firefox.

HTML sequence diagram

The annotated S1AP flow as a self-contained, scrollable web page — clicking any message opens its full Wireshark field tree. Works in every browser.

Printable PDF

The annotated S1AP sequence diagram as a PDF.

💡 Read the walkthrough and the diagram side by side: open the interactive diagram in a split-screen window, or open it in a new tab and snap the two windows side by side.

What S1AP does

S1AP (TS 36.413) is the control protocol between an eNB and its MME, on the S1-MME interface. The radio page showed the eNB relaying NAS messages between the phone and the MME. S1AP is the envelope for that relay, and it carries the eNB's own business with the core:

NAS transport. Initial UE Message carries a phone's first NAS message and creates its S1 context. After that, Downlink NAS Transport and Uplink NAS Transport carry NAS each way.
UE context. Initial Context Setup hands the eNB the phone's security key and its first bearer. The eNB can't start radio security or carry user data without it.
E-RAB management. An E-RAB (E-UTRAN Radio Access Bearer) is the access part of an EPS bearer: a radio bearer from phone to eNB, plus a GTP-U tunnel from eNB to the serving gateway. E-RAB Setup and E-RAB Release add and remove them.

Each phone gets two identifiers on S1, one chosen by each end: eNB-UE-S1AP-ID and MME-UE-S1AP-ID. Here ID 1 is UE 70 (C-RNTI 70 on the radio page) and ID 2 is UE 71. On a real network S1AP rides SCTP over IP; srsRAN logs the bare S1AP messages, so the diagram has just two lanes, eNB and MME.

One clock, two captures

The eNB wrote both logs, so their timestamps share a clock. That turns two separate traces into one timeline. Some key moments:

Event	S1AP frame	Radio frame	Gap
UE 70's Attach Request reaches the MME	3	4	S1AP 0.7 ms after the radio
UE context arrives, AS security starts	10	16	radio 0.75 ms after S1AP
Call 1: callee's SIP 183 → voice E-RAB requested	37	839	S1AP 7 ms after the radio
Call 1: E-RAB Setup Response vs RRC Reconfiguration	38	844	response 1 ms before the radio
Call 1: BYE → E-RAB released	43	1143	S1AP 8.7 ms after the radio

The first rows are what you'd expect from a relay: a message arrives on one side and leaves on the other within a millisecond. The fourth row is the surprise, covered below.

The flow at a glance

S1 Setup (frames 1–2): the eNB registers with the MME, 4.5 s before any phone appears.
UE 70's attach (frames 3–14): NAS relayed both ways, then Initial Context Setup.
UE 70's IMS PDN (frames 15–18): E-RAB 6, QCI 5.
UE 71's attach and IMS PDN (frames 19–36): the same, plus an ESM Information exchange.
Six calls and the start of a seventh (frames 37–109): for each call, an E-RAB Setup to each phone, then an E-RAB Release to each phone.

stateDiagram-v2 accTitle: E-RAB life cycle on one UE accDescr: After attach the UE holds E-RAB 5 for internet and E-RAB 6 for IMS. Each call adds a QCI 1 E-RAB with the next ID, from 7 to 13, and an E-RAB Release removes it. state "E-RABs 5 and 6" as DEF state "Plus voice E-RAB N (QCI 1)" as CALL [*] --> DEF: Initial Context Setup + E-RAB Setup DEF --> CALL: E-RAB Setup (N = 7, 8, ... 13) CALL --> DEF: E-RAB Release

E-RABs on one UE: E-RAB 5 (internet) and E-RAB 6 (IMS) stay up. Each call adds a QCI-1 voice E-RAB with a new ID, 7 through 13, and removes it at hang-up.

S1 Setup (frames 1–2)

Before it can serve anyone, the eNB introduces itself. Its S1 Setup Request names it srsenb01, gives its macro eNB ID (411, hex 0x0019b), and lists the tracking area it serves: TAC 1 in PLMN 001/01, the 3GPP test network. The S1 Setup Response comes from open5gs-mme0 with relative capacity 255, a weight eNBs use to balance new phones across the MMEs in a pool. That's the only non-UE procedure in the capture.

UE 70's attach (frames 3–14)

sequenceDiagram accTitle: S1AP view of the attach accDescr: The eNB sends Initial UE Message with the Attach Request. NAS messages for identity, authentication, and security mode are relayed in Downlink and Uplink NAS Transport. The MME sends Initial Context Setup Request with the security key, the default E-RAB, and the Attach Accept. The eNB forwards the UE capabilities and answers with Initial Context Setup Response, then relays the Attach Complete. participant eNB participant MME eNB->>MME: Initial UE Message (Attach Request) MME->>eNB: Downlink NAS Transport (Identity, Auth, Security Mode) eNB->>MME: Uplink NAS Transport (responses) MME->>eNB: Initial Context Setup Request (K eNB, E-RAB 5, Attach Accept) eNB->>MME: UE Capability Info Indication eNB->>MME: Initial Context Setup Response eNB->>MME: Uplink NAS Transport (Attach Complete)

Frame 3 — Initial UE Message. 0.7 ms after the phone's RRC Connection Setup Complete (radio frame 4), the eNB opens an S1 context for it, eNB-UE-S1AP-ID 1, and passes the NAS Attach Request through unchanged. The MME answers with its own ID in frame 4, and from then on both IDs label every message for this phone.

Frames 4–9 — NAS relayed. Identity, authentication, and NAS Security Mode travel in Downlink and Uplink NAS Transport. The eNB doesn't read them; it only forwards. These are the same messages as radio frames 6–14, seen from the other side of the eNB.

Frame 10 — Initial Context Setup Request. The MME now gives the eNB the phone's context:

K_eNB, the 256-bit key the eNB derives the radio security keys from,
the phone's security capabilities: EEA1–3 and EIA1–3. The null cipher seen on the radio page was the network's choice, not a phone limitation,
the default E-RAB: ID 5, QCI 9, and the serving gateway's GTP-U endpoint (172.22.0.6, tunnel ID 0x2),
a UE aggregate maximum bit rate of 1 Gbit/s downlink,
the NAS Attach Accept to deliver to the phone.

0.75 ms later the eNB sends the radio Security Mode Command (radio frame 16). That's the K_eNB being used.

Frames 11–12 — Capabilities and the response. The eNB fetches the phone's radio capabilities over the air (radio frames 19–22) and forwards them in UE Capability Info Indication. The MME stores them and hands them to the next eNB. Then the eNB answers Initial Context Setup Response, and the Attach Complete follows in frame 13.

The IMS PDN, and UE 71 (frames 15–36)

When UE 70 asks for the ims APN (frame 15), the bearer comes as an E-RAB Setup Request (frame 16): E-RAB 6, QCI 5, ARP priority 1, with the ESM Activate Default EPS Bearer message inside. The response (frame 17) returns the eNB's own GTP-U endpoint, 172.22.0.22 with tunnel ID 0x2. With a tunnel ID from each end, the GTP-U tunnel for IMS traffic exists.

UE 71 repeats the attach in frames 19–36 as eNB-UE-S1AP-ID 2. It also has the ESM Information Request and Response (frames 26–27) seen on the radio page, because this phone asked for its PDN details to be collected under NAS security. After frame 36, S1 goes quiet for 6.6 s. Both phones register with IMS during that time, but SIP rides the user plane, so S1AP never sees it.

Six calls and the start of a seventh (frames 37–109)

sequenceDiagram accTitle: One VoLTE call on S1AP accDescr: After the callee sends SIP 183, the MME sends E-RAB Setup Request for a QCI 1 bearer to the callee, then to the caller. The eNB answers each at once. Both phones accept the dedicated bearer in Uplink NAS Transport. At hang-up the MME sends E-RAB Release Command to each phone, the eNB answers, and both phones accept the deactivation. participant MME participant eNB MME->>eNB: E-RAB Setup Request (callee, QCI 1, 82 kbit/s) eNB->>MME: E-RAB Setup Response MME->>eNB: E-RAB Setup Request (caller) eNB->>MME: E-RAB Setup Response eNB->>MME: Uplink NAS Transport (Activate Dedicated Bearer Accept, x2) Note over MME,eNB: The call runs on the user plane MME->>eNB: E-RAB Release Command (x2, NAS cause normal release) eNB->>MME: E-RAB Release Response (x2) eNB->>MME: Uplink NAS Transport (Deactivate Bearer Accept, x2)

On S1AP, each call is twelve messages: an E-RAB Setup Request and Response for each phone and two bearer accepts, then the same six again for the release. The radio page followed call 1 in detail. Here they all line up:

Call	Caller	Voice E-RAB	Bearer up (S1AP frame)	Held for
1	UE 70	7	37	6.4 s
2	UE 71	8	49	6.5 s
3	UE 71	9	61	6.7 s
4	UE 70	10	73	4.7 s
5	UE 70	11	85	11.7 s
6	UE 71	12	97	6.1 s
7	UE 71	13	109	capture ends

The callers come from the SIP INVITEs on the radio capture. Three patterns stand out.

The callee's bearer comes first. In every call, the first E-RAB Setup goes to the phone being called, and the caller's follows 4.6–7.0 ms later. The trigger is the callee's 183 Session Progress, the first SIP message with its SDP answer. In call 1 the E-RAB Setup Request leaves the MME 7 ms after UE 71 sends the 183 (radio frame 839). Once the codec and ports are agreed, the IMS core asks the core network for a voice bearer at both ends.

A new bearer ID every call. The voice E-RAB is 7 in call 1, 8 in call 2, and so on up to 13. The E-RAB ID is the EPS bearer identity, and the MME moves on to the next identity for each call instead of reusing the one just released. Both phones get the same number because each phone has its own set of bearer identities.

The same QoS every time. Every voice E-RAB is QCI 1 with ARP priority 2, and a guaranteed and maximum bit rate of 82,000 bit/s each way. The phone's NAS QoS on the radio page reads 80 kbps, because the NAS bit-rate field is coarser than S1AP's and can't express 82.

The last message, frame 109, sets up E-RAB 13 for a seventh call that UE 71 dialed 89 ms earlier. The radio capture stops 3 ms before it, so that bearer never appears on the air. No UE Context Release appears anywhere: both phones stay connected to the end.

srsRAN answers before the radio

TS 23.401's attach and dedicated-bearer flows put each S1AP response after the radio work it reports on. The eNB reconfigures the phone, the phone answers RRC Connection Reconfiguration Complete, and only then does the eNB send its response to the MME. srsRAN doesn't wait:

Procedure	S1AP response	Radio reconfiguration sent	Response early by
Initial Context Setup (UE 70)	frame 12	radio frame 24	2.7 ms
E-RAB Setup, IMS (UE 70)	frame 17	radio frame 32	1.1 ms
E-RAB Setup, call 1 (UE 71)	frame 38	radio frame 844	1.0 ms
E-RAB Release, call 1 (UE 70)	frame 44	radio frame 1146	0.5 ms

In each case the response leaves before the RRC message has even been sent, so it can't reflect whether the phone accepted the change. In a lab with good radio conditions, that rarely matters. On a real network, a reconfiguration the phone rejects or never receives would leave the MME believing in a bearer that doesn't exist. Only a trace with both sides on one clock shows this ordering.

Takeaways

S1AP wraps NAS and adds the eNB's own procedures. NAS rides Initial UE Message and the two NAS Transport messages. Context setup and E-RAB management are S1AP's own.
Initial Context Setup is what lets the eNB act. It delivers K_eNB, so radio security can start, and the first E-RAB, so user data can flow.
An E-RAB is a radio bearer plus a GTP-U tunnel. The request carries the gateway's tunnel endpoint and the response returns the eNB's.
VoLTE is visible on S1 only as bearers. SIP never touches S1AP, but each call shows up as a QCI-1 E-RAB set up after the callee's 183 and released after the BYE.
A shared clock exposes ordering. Lining S1AP up against the radio shows srsRAN reporting success before the radio work is done.