NAS Overview (EMM & ESM) in LTE 4G

Introduction

The Non-Access Stratum is the control-plane dialogue between the UE and the MME that governs two things: whether the UE is registered and reachable, and what data connections it holds. Defined in TS 24.301, it is deliberately independent of the radio — the same NAS messages would work over any access technology, which is exactly the point of keeping mobility and session state out of the radio layer.

NAS is used at every milestone of the UE lifecycle. It runs at power-on (Attach), whenever the UE changes location beyond its registered area (Tracking Area Update), whenever it wakes to send or receive data (Service Request / Paging), whenever it authenticates and switches on security (Authentication / Security Mode Command), and whenever a data pipe is created, changed, or torn down (the ESM bearer procedures). If you can read a NAS trace, you can debug almost every "why won't this UE get on the network" ticket.

Because NAS is really two protocols (EMM and ESM) sharing one connection, and because every message rides inside a radio (RRC) container on the air and an S1AP container on S1, a failure almost always lives in one identifiable place: a specific protocol, a specific message, or a specific transport hop. That is why a layered, message-by-message habit pays off here just as it does for random access.

Why NAS is needed

Concretely, the network needs a place to keep two kinds of long-lived state that must survive the UE moving between cells — and even between radio technologies. The first is mobility and identity: is this UE registered, where (to tracking-area granularity) is it, can it be paged, and is it authenticated? The second is sessions: what EPS bearers does it have, to which PDN, and with what QoS? If either of these lived in the eNB, it would be lost on every handover. Anchoring them in the core, reachable over a radio-independent protocol, is what lets a UE roam across a whole network while staying "the same known subscriber with the same IP session."

What NAS Is

The LTE control plane splits into two layers. The Access Stratum (AS) is everything about the radio between the UE and the eNB — RRC, the scheduler, HARQ, measurements, the physical channels. The Non-Access Stratum (NAS) sits above that: it is the end-to-end signalling between the UE and the MME that deals with mobility and sessions, and it does not care which cell, which frequency, or even which radio technology carries it.

The crucial idea for a fresher is that the eNB relays NAS transparently. It never decodes a NAS message. On the radio, the NAS payload is carried as an information element inside an RRC message (for example the dedicatedInfoNAS field). On the S1 interface between eNB and MME, the same NAS payload rides inside an S1AP message. The eNB copies the octets from one container into the other and forwards them — it is a postman, not a reader. That is precisely why the layer is called Non-Access Stratum: it is the stratum that is not part of the access network.

Two Protocols: EMM and ESM

NAS is not one protocol but two, running in parallel over the same signalling connection. They are distinguished by the Protocol Discriminator in the NAS message header, so a single received message is unambiguously either an EMM message or an ESM message.

EMM — EPS Mobility Management — handles everything about the UE's presence and identity in the network: Attach and Detach, Authentication, NAS security setup via Security Mode Command, Tracking Area Update (TAU), Service Request, responding to Paging, and GUTI reallocation. Think of EMM as "am I registered, where am I, and can I be reached."

ESM — EPS Session Management — handles the data connections themselves: activation, modification and deactivation of the default and dedicated EPS bearer contexts, and PDN Connectivity requests. A default bearer is created for every PDN connection and lives for as long as that connection does; dedicated bearers are added on top to give specific traffic flows their own QoS (a distinct QCI and, for GBR bearers, a guaranteed bit rate). Think of ESM as "what pipes do I have to the packet network, and with what QoS."

They cooperate closely. When a UE performs an initial Attach, the EMM Attach Request actually carries a piggybacked ESM PDN Connectivity Request inside it, so that registering and getting your first (default) bearer happen in one round trip. That is why a fresh attach leaves the UE both registered and with a working default bearer — ready to pass user data immediately.

NAS Message Structure

Every NAS message begins with a small header, and the shape of that header depends on whether the message is EMM or ESM. Getting the fields straight makes protocol traces far easier to read, because the first one or two octets tell you almost everything about how to interpret the rest.

All NAS messages start with a Protocol Discriminator (4 bits) that says EMM or ESM. Alongside it, the interpretation of the other half of the first octet differs by protocol:

• For EMM messages, the first octet also carries the Security Header Type (4 bits). This tells the receiver how the message is protected — plain, integrity-protected, integrity-protected and ciphered, or a special value for the security-mode and service-request cases. When the message is security-protected, it is wrapped in an outer security-protected NAS message header that prepends the Message Authentication Code (MAC, 4 octets) and a NAS sequence number, and the real EMM message sits inside as the plaintext (or ciphered) payload.
• For ESM messages, the first octet carries the EPS Bearer Identity (4 bits) instead of a security header type — because every ESM message is about a specific bearer — and the second octet carries the Procedure Transaction Identity (PTI). The PTI ties a request to its response for UE-initiated procedures (like a PDN Connectivity Request and the Activate Default EPS Bearer Context Request that answers it). For network-initiated procedures with no pending transaction, the PTI is set to "no procedure transaction identity assigned."

After the header comes the Message Type octet, which names the exact message (e.g. Attach Request, Activate Dedicated EPS Bearer Context Request), followed by the mandatory and optional information elements for that message. Because ESM messages are transported inside EMM (they ride the same connection), the EPS bearer identity of a plain EMM message is set to "no EPS bearer identity assigned."

NAS Security: Integrity, Ciphering, Keys and COUNT

NAS has its own security, entirely separate from AS (radio) security. This matters because the two protect different things: AS security (set up by the eNB via the RRC SecurityModeCommand) protects the radio bearers between UE and eNB, while NAS security protects the UE–MME signalling — it is anchored in the core and must survive even as the UE hands over between eNBs.

NAS security provides two services. Integrity protection lets the MME trust that a message really came from this UE and was not altered in flight; it is computed as a Message Authentication Code using the key KNASint. Ciphering makes the NAS payload confidential using the key KNASenc. Both keys are derived from the master key K_ASME (itself produced during authentication), together with the identifiers of the chosen algorithms. In LTE, integrity protection is mandatory once a security context exists — every protected NAS message is integrity-checked — whereas ciphering may in principle use the null algorithm (EEA0), though operators normally enable it.

Two more concepts tie the scheme together:

• The eKSI (evolved Key Set Identifier) is a small tag that names which security context (which set of keys) a message uses. Because a UE and MME can hold a cached native context and also a mapped one (e.g. after inter-RAT movement), the eKSI lets both sides agree on the active keys without re-running authentication every time.
• The NAS COUNT is a counter that feeds both the integrity and ciphering algorithms as input, guaranteeing that the same plaintext never produces the same ciphertext or MAC twice — which is what defeats replay. It is maintained separately for uplink and downlink and is built from an overflow counter (the high bits) plus a sequence number (the low 8 bits). Only the sequence number is carried in the message header; the receiver reconstructs the full COUNT by tracking overflow locally.

All of this is switched on by the NAS Security Mode Command (SMC) procedure. The MME sends a Security Mode Command that selects the integrity and ciphering algorithms and echoes the UE security capabilities (so the UE can detect a bidding-down attack); this message is integrity-protected but not yet ciphered. The UE verifies the MAC and replies with a fully protected (integrity + ciphered) Security Mode Complete. From that point on the NAS connection is secured with KNASint and KNASenc.

EMM, ECM and ESM States

NAS tracks several independent state machines in the UE and network, and it helps to keep them apart. Two of them — EMM and ECM — are the ones a fresher is asked about most.

The EMM state says whether the UE is registered. In EMM-DEREGISTERED the network holds no valid location or context for the UE — this is the state after power-on before attach, or after a detach. After a successful Attach, the UE moves to EMM-REGISTERED: the MME knows its tracking area, holds a valid GUTI and security context for it, and it can be paged.

The ECM (EPS Connection Management) state says whether there is an active NAS signalling connection right now. In ECM-IDLE the UE is registered but has no S1 or RRC connection — it is camped, saving battery, and is only reachable via Paging; the network knows its location only to tracking-area granularity. In ECM-CONNECTED there is an active connection: an RRC connection on the radio and an S1-MME association in the core, and the eNB knows the UE at cell granularity.

These map cleanly onto RRC states. ECM-IDLE corresponds to RRC_IDLE; ECM-CONNECTED corresponds to RRC_CONNECTED. Moving from idle to connected is exactly what the Service Request procedure (or an attach / TAU) does — it establishes the RRC connection and the S1 signalling connection so that data or signalling can flow. The reverse transition to ECM-IDLE happens when the connection is released after inactivity.

Separately, ESM maintains a state per EPS bearer context — essentially BEARER CONTEXT INACTIVE versus BEARER CONTEXT ACTIVE — and per-procedure states while an activation or modification is in flight. A bearer context is a piece of persistent state (it survives the UE going to ECM-IDLE), which is why a UE can drop its radio connection to save power and still resume its data session immediately on the next Service Request without re-establishing bearers from scratch.

How NAS Rides on RRC and S1AP

The picture below is worth memorising. Follow a NAS message from the UE to the MME and notice how it changes container but never changes content. The same NAS PDU that the UE's NAS layer produced is what the MME's NAS layer consumes; the eNB simply moves it from the RRC container into the S1AP container.

On the air interface, NAS is carried over Signalling Radio Bearers. SRB1 carries most NAS signalling once the RRC connection is set up; SRB2 (established after security) carries higher-volume or lower-priority NAS messages. The very first NAS message of a connection is often piggybacked in RRCConnectionSetupComplete as the dedicatedInfoNAS field — that is how an Attach Request or Service Request reaches the eNB. On S1, the initial NAS message travels in the S1AP INITIAL UE MESSAGE, and thereafter in UPLINK NAS TRANSPORT and DOWNLINK NAS TRANSPORT, which exist for no purpose other than shuttling a NAS PDU between eNB and MME.

Notice the double layer of security a NAS message enjoys. First, NAS integrity/ciphering with KNASint/KNASenc is applied end-to-end between UE and MME, so even the eNB cannot read a ciphered NAS payload. Then, on the radio, PDCP applies AS integrity and ciphering to the SRB carrying it. A single Attach Request is therefore protected once by NAS and again by AS — belt and braces, at two independent layers with two independent key sets.

Reading NAS in the logs

Because the eNB does not decode NAS, the two ends worth tracing are the UE's NAS log and the MME's NAS log — and the S1AP container in between confirms the payload was carried unchanged. A NAS trace usually prints the header (protocol, security header type, message type) and then the decoded IEs. The one-line habit is: read the header to know what kind of message it is and whether it is protected, then read the message type and IEs to know what it does.

Representative NAS trace (UE/MME decode) — illustrative, values vary by vendor/build:

Summary

NAS is the UE–MME control-plane conversation the eNB only carries. Keep three things straight and the rest follows. First, two protocols: EMM (registration, location, reachability, security) and ESM (bearers, PDN connectivity), told apart by the Protocol Discriminator. Second, the header tells you how to read the body: Security Header Type says whether an EMM message is protected; the EPS Bearer Identity + Procedure Transaction Identity say which bearer and transaction an ESM message belongs to. Third, two independent axes of state: EMM (registered or not) and ECM (connected or not), which is why a UE can be registered yet asleep in ECM-IDLE.

When something breaks, localise it the same way you would a RACH failure — by layer and by hop. Is the NAS message present in the RRC log but not on S1? Does the Message Authentication Code verify? Is the Security Header Type what it should be for this stage of the connection? Does the ESM PTI pair up? Each answer narrows a vague "attach/NAS failure" into a specific, testable cause.

Quick Q&A