NAS-EPS in a Real VoLTE Capture: Attach, Default Bearers, and Six Voice Bearers

The NAS layer of the LTE attach and VoLTE walkthrough, followed on its own. One phone, UE 70, talks to its MME in 40 NAS messages. The first 16 attach it and open two packet data networks in under 0.7 s. The other 24 add and remove a voice bearer for each of six calls. Every message is readable, including the ones marked "ciphered".

💡 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.

Where NAS sits

NAS is the one box that reaches past the eNB. Its peer is the MME (Mobility Management Entity), a core-network node. On the radio side, RRC carries each NAS message as an opaque string of bytes, either alone in an Information Transfer message or bundled into the reconfiguration that builds a bearer; the RRC companion shows which is which. Between the eNB and the MME, S1AP carries the same bytes; the S1AP companion shows that side. This page reads the bytes themselves.

The capture is the eNB's radio log, so every NAS message here is seen on the air, inside RRC. NAS timings therefore include a trip through the eNB to the MME and back.

What NAS does

NAS (Non-Access Stratum, TS 24.301) is what the phone says to the core network rather than to the cell. "Access Stratum" means the radio layers. NAS has two sublayers, and they are worth keeping apart:

• EMM, EPS Mobility Management. Attach, identification, authentication, security mode control, tracking area updates, detach. It answers "is this subscriber allowed on the network, and where is it?"
• ESM, EPS Session Management. PDN connections and EPS bearers: create, modify, delete. It answers "which data paths does this subscriber have, and with what quality of service?"

The first octet tells them apart: protocol discriminator 7 is EMM and 2 is ESM. They also have separate cause tables, Annex A of TS 24.301 for EMM and Annex B for ESM, so a cause number means nothing until you know which sublayer sent it. This session has no EMM cause at all and two ESM causes, #50 and #36.

An EPS bearer is the core network's unit of quality of service: one path from the phone to the packet gateway with one QCI (QoS Class Identifier). Each PDN connection has one default bearer and may add dedicated bearers with their own QoS. On the radio, each EPS bearer gets its own DRB (Data Radio Bearer).

A few fields carry most of the story:

The five security header types

TS 24.301 §9.3.1 defines the security header types. UE 70's session uses all five:

The table is in the order the values appear. The last two rows are the surprise, and the security section explains them.

The session we're following

💡 Where this diagram comes from. VisualEther, which decoded this capture and drew the diagrams here, splits a capture into one session per protocol entity. This diagram is the session it keys nas-eps::70: every NAS message to or from C-RNTI 70, 40 messages over frames 4 to 3288.

C-RNTI 70 is the short identifier the cell uses for one connected phone. UE 70 is an iPhone; UE 71, the phone it calls, has a NAS session of its own that this page uses only for comparison.

Two reading notes:

• 40 arrows, 37 frames. Frames 4, 24, and 27 each carry an EMM message with an ESM message inside its container. The diagram draws the ESM message as a second arrow on the same frame.
• Each arrow shows the outer security header and sequence number. On frames 4, 24, and 27, the ESM arrow repeats them: the ESM message has no protection of its own and travels under the EMM message's.

All times below are seconds from the capture's first frame.

The flow at a glance

After frame 34 the session is ESM only: twelve request and accept pairs, one add and one remove for each call. The UE side of each EPS bearer has two states (TS 24.301 §6.1.3.2), and the six voice bearers each pass through both once:

Attach and identity: frames 4 to 7

Frame 4 — a combined attach. The phone's first NAS message rides RRC Connection Setup Complete. EPS attach type: Combined EPS/IMSI attach asks to register for packet service and, in the same procedure, for circuit-switched services such as SMS and CS fallback (TS 24.301 §5.5.1.3). The phone wants both because it lists its voice preference as "IMS PS voice preferred, CS voice as secondary".

It names itself with a GUTI (Globally Unique Temporary Identity) from an earlier registration: MME group 2, MME code 1, M-TMSI 0xf500883c. It also signs the message. Security header type 1 means the phone still holds a NAS security context from that earlier session, key set 0, and uses it: sequence number 16, message authentication code 0x65492599. The body stays in the clear, as an initial NAS message must.

The ESM message container holds the phone's first ESM request, a PDN Connectivity Request with PTI 51 and PDN type IPv4v6. It names no APN (Access Point Name), so the network will choose the subscriber's default. Its protocol configuration options ask for DNS servers, a P-CSCF address, and the link MTU.

Frame 6 — the MME asks for the IMSI, 1.9 ms later. The GUTI names this same MME (the new GUTI it assigns in frame 24 has the same group and code), but the MME holds no context for M-TMSI 0xf500883c. Without that context it can't map the GUTI to a subscriber or check frame 4's integrity tag. The capture can't show why the context is gone; a restarted MME is the likely reason. So the MME runs the identification procedure (TS 24.301 §5.4.4) and asks for the IMSI.

The request has security header type 0, plain, because the MME has no key for this phone. TS 24.301 §4.4.4.2 lets the UE accept an unprotected Identity Request only when it asks for the IMSI, as this one does.

Frame 7 — the IMSI. 001011234567895 arrives 38 ms later, in MCC 001 / MNC 01, the 3GPP test network. The phone signs it with the old context again (sequence number 17). The MME still can't check that tag, and it doesn't have to: TS 24.301 §4.4.4.3 lets the MME process an Identity Response carrying the IMSI without integrity protection. With the IMSI in hand, the MME can fetch authentication vectors from the HSS (Home Subscriber Server).

EPS AKA: frames 9 and 11

EPS AKA (Authentication and Key Agreement, TS 33.401 §6.1) proves the phone holds the subscriber's secret key and gives both ends a fresh shared key, K_ASME.

Frame 9 — the challenge. The Authentication Request carries two values from the HSS:

• RAND, a 128-bit random challenge;
• AUTN, which proves the challenge came from the phone's home network. It holds the sequence number masked with an anonymity key, a MAC (message authentication code), and an AMF (authentication management field) of 0x8000. Its first bit is the separation bit, which an EPS vector must have set.

NAS key set identifier 0 names the key set this run creates.

Frame 11 — the response, 214 ms later. The USIM checks AUTN, then computes RES (4ffa455904e320d8) and the keys CK and IK, from which the phone derives K_ASME. The 214 ms is the SIM working. The MME compares RES with the expected value it got from the HSS; a match authenticates the phone. The phone still signs with its old context, sequence number 18.

NAS security: frames 13 and 14

Frame 13 — Security Mode Command, 1.9 ms after the response. It selects EEA0 (null ciphering) and 128-EIA2 (AES-based integrity) for NAS, key set 0. Security header type 3, "integrity protected with new EPS security context": the MME signs the command with keys derived from the new K_ASME, but doesn't cipher it (TS 24.301 §5.4.3.2). The sequence number is 0, because a new K_ASME restarts the NAS COUNT in both directions (TS 24.301 §4.4.3).

Three more fields ride along:

• Replayed UE security capabilities: the algorithms the phone listed in frame 4, EEA0 to EEA3 and EIA0 to EIA3, sent back so the phone can check no one stripped the strong ones from its request.
• IMEISV request: send the device identity in the reply.
• HashMME: a hash of the Attach Request as the MME received it. The MME includes it because it couldn't check frame 4's integrity tag.

Frame 14 — Security Mode Complete, 38 ms later. It has security header type 4, "integrity protected and ciphered with new EPS security context", and sequence number 0. It carries the IMEISV. It carries no copy of the Attach Request, which the phone would add if its own hash of frame 4 didn't match HashMME (TS 24.301 §5.4.3.3). So frame 4 reached the MME unaltered.

Why a ciphered body still reads. Every message from here on is security header type 2, "integrity protected and ciphered". Wireshark shows the field Ciphered message, and then decodes it anyway. The cipher is EEA0: it XORs the message with a keystream of zeros, so the ciphered bytes are the plaintext. In frame 14 they begin 07 5e: protocol discriminator 7 (EMM) and message type 0x5e, Security mode complete. The decode recipe turns on nas-eps.null_decipher for this reason. With a real cipher, the same setting would make the dissector invent fields from ciphertext. The integrity tags are real: EIA2 signs every message from frame 13 on. The main walkthrough explains why every layer of this lab uses a null cipher.

Attach Accept and the default bearer: frames 24 to 29

Frame 24 — Attach Accept, 94 ms after frame 14. Most of that gap is radio work. The MME had already sent the accept to the eNB inside S1AP Initial Context Setup; the eNB held it while it started radio security and fetched the phone's capabilities, then delivered it inside RRC reconfiguration 1, together with DRB 1. Its sequence number is 1.

The EMM part:

• Attach result: Combined EPS/IMSI attach: both registrations succeeded.
• A new GUTI, M-TMSI 0xe700d192, replacing the one the MME didn't know.
• A tracking area list with one entry, TAC 1, and T3412 (the periodic tracking area update timer) of 54 min. The capture is 113 s long, so the timer never fires.
• EPS network feature support with IMS voice over PS session in S1 mode: Supported. That bit tells the phone it may make voice calls over IMS here (TS 24.301 §9.9.3.12A).

The ESM container holds the default bearer, Activate Default EPS Bearer Context Request:

ESM cause #50 is worth a second look. It comes from Annex B of TS 24.301, and here it sits in an accept, not a rejection. The network grants the PDN connection and uses the cause to say which part of the request it didn't grant (TS 24.301 §6.5.1.3).

Frame 27 — Attach Complete, 26 ms later, the first message on SRB2, with Activate Default EPS Bearer Context Accept for EBI 5 in its container. Its sequence number is 1 again, in the uplink counter this time. UE 70 is EMM-REGISTERED 420 ms after its Attach Request, and EPS bearer 5 is active on DRB 1.

Frame 29 — EMM Information, 174 ms later: the network's name, Open5GS (the open-source core this lab ran), and its time zone, GMT+2. The procedure is optional (TS 24.301 §5.4.5).

The IMS PDN: frames 30 to 34

VoLTE keeps IMS signaling and voice on their own PDN connection, apart from internet traffic. Six milliseconds after the EMM Information, the phone asks for it.

Frame 30 — PDN Connectivity Request for APN ims, PTI 1, PDN type IPv4v6. This is a standalone ESM message, and its two headers show the split between the sublayers. The outer security header carries protocol discriminator 7, because security protection is an EMM function. The message inside carries 2, ESM.

Frame 32 — the IMS default bearer, 8 ms later, inside RRC reconfiguration 2 with DRB 2: EBI 6, PTI 1, APN ims, QCI 5 (IMS signaling), address 192.168.101.2, ESM cause #50 again, and P-CSCF 172.22.0.21 in the protocol configuration options. That P-CSCF address is where the phone sends its SIP REGISTER next.

Frame 34 — accepted, 32 ms later. UE 70 now holds two PDN connections: internet on EBI 5 and ims on EBI 6. NAS goes quiet for 23 s while the phone registers with IMS over EBI 6. The SIP companion follows that registration.

UE 71 does it differently

UE 71's Attach Request (frame 304) sets the ESM information transfer flag. That flag asks the network to collect the PDN details only after NAS security is running, so the APN and protocol options aren't sent in the clear (TS 24.301 §6.5.1.2). The MME does just that: after UE 71's Security Mode Complete, it sends an ESM Information Request (frame 316, PTI 49), and the phone answers with APN internet (frame 317). UE 70 leaves the flag clear, so its session has no such exchange. With a null cipher the protection is nominal here, but the message flow is the one a real network would see.

Six voice bearers: frames 846 to 3288

From here the session repeats one pattern twelve times. When a call is answered with media details, the IMS core asks the packet gateway for a voice bearer. The gateway sends a Create Bearer Request through the serving gateway to the MME, which picks an EBI and sends the NAS request to the phone, inside an S1AP E-RAB Setup (TS 23.401 §5.4.1). At hang-up, the same chain removes it.

Frame 846 — the voice bearer for call 1. UE 70 dialed in frame 821, and UE 71's SIP 183 Session Progress carried the media details. UE 71's bearer came first, in frame 844, then UE 70's. The Activate Dedicated EPS Bearer Context Request:

• EBI 7, linked EBI 6. The new bearer belongs to the IMS PDN connection and shares its IP address. A dedicated bearer has no address of its own.
• PTI 0. The network started this procedure, so there is no UE transaction to answer.
• QCI 1, conversational voice, the one class here with a guaranteed bit rate. The maximum and guaranteed bit rates are 80 kbps each, up and down.
• A traffic flow template (TFT) with four packet filters.

The TFT makes the bearer carry voice and nothing else. The phone checks every uplink packet against the filters of its bearers and sends a match down that bearer. The gateway does the same for downlink. All four filters match UDP to or from 172.22.0.16, the media relay:

Port 49016 is the RTP port the P-CSCF wrote into the 183 before it reached UE 70, so the filter follows the media address the phone was given. Port 49017 is the matching RTCP port, filtered even though the SDP turned RTCP off and none appears in the capture. Nothing names the phone's own port: matching the remote end is enough.

Frame 847 — accepted, 33 ms later. EPS bearer 7 is active on DRB 3.

Frame 1146 — removed. UE 71 hung up in frame 1143. Deactivate EPS Bearer Context Request, EBI 7, ESM cause #36, "regular deactivation" (TS 24.301 Annex B). The phone accepts in frame 1152, 40 ms later. The RRC Reconfiguration Complete went up alone first, in frame 1148, so this accept rides a transmission of its own.

80 kbps here, 82 kbit/s on S1AP

The S1AP companion shows the MME asking the eNB for a guaranteed 82,000 bit/s per direction. NAS says 80 kbps. Both describe the same bearer. S1AP carries a bit rate as an integer number of bits per second. NAS carries it in one octet with a coarse scale (TS 24.301 §9.9.4.3, using the coding of TS 24.008 §10.5.6.5):

82 kbps falls between two steps, 80 and 88. The octet in frame 846 is 0x42 (66): 64 + (66 − 64) × 8 = 80 kbps, the step below 82.

The other five calls

Calls 2 to 6 repeat call 1 exactly, apart from three things: the EBI, the remote ports, and the timing. Every add carries linked EBI 6, PTI 0, QCI 1, 80 kbps, and the same four-filter TFT shape. Every removal carries ESM cause #36.

The EBI column only climbs. EBI 7 is free again from frame 1146, yet call 2 gets 8. TS 23.401 §5.4.1 only requires an EBI the UE isn't already using, so EBI 7 could have come back; this MME takes the next number instead. On the radio side, srsRAN derives the DRB and its logical channel from the EBI, so they climb too, and the RRC companion shows where that ends: call 6's DRB uses LCID 10, the last one a DRB can have. The capture stops as call 7 begins, and the S1AP log shows the MME asking for EBI 13.

What never happens

• No EMM cause, no reject, no retransmission. Each NAS sequence number appears once per direction: 0 to 15 downlink and 0 to 15 uplink after the Security Mode Command.
• No tracking area update, service request, or detach. The phone never leaves RRC_CONNECTED, and T3412's 54 minutes outlast the capture.
• No bearer modification and no PDN disconnect. EPS bearers 5 and 6 stay exactly as frames 24 and 32 created them.
• No ESM Information exchange for UE 70, because it left the flag clear.

The last NAS message is frame 3288, the accept for call 6's removal, 11 s before the capture ends.

Takeaways

1. EMM and ESM are separate protocols that travel together. The attach carries the first PDN request inside it; protocol discriminators 7 and 2 and two cause tables keep them apart.
2. An unknown GUTI costs a round trip. The MME asks for the IMSI, then authenticates from scratch. TS 24.301 lets it process the few messages it can't yet verify for exactly this case.
3. A new security context restarts the counters. The phone signs with its old context until frame 14, then both sequence numbers start again at 0.
4. "Ciphered" doesn't mean unreadable. EEA0 leaves the plaintext in place, while EIA2 still signs every message.
5. A dedicated bearer is QoS plus a filter. QCI 1 and 80 kbps say how to treat the voice; the TFT says which packets are voice.

Where this sits in the stack

• An LTE Attach and a VoLTE Call on the Air Interface: the full walkthrough this page is a slice of, with every layer on one timeline.
• LTE-RRC: One Connection, Fourteen Reconfigurations: how each NAS message on this page crosses the air, and the DRB built for each EPS bearer.
• SIP: IMS Registration and the VoLTE Call: the call signaling that triggers each voice bearer, and the SDP the TFT follows.
• S1AP: Attach, E-RABs, and Six VoLTE Calls: the same NAS messages between the eNB and the MME, inside Initial Context Setup and E-RAB Setup.
• NAS-5GS in a Real 5G Capture: the same layer in 5G, where a real cipher keeps half the messages sealed.