S1AP (S1-MME — eNB ↔ MME) in LTE 4G
S1 Setup, Initial Context Setup, E-RAB setup and paging over S1-MME.
When an eNB and an MME need to talk about a UE — attach it, page it, set up its bearers, hand it over — they don't open a fresh socket per event. They share one long-lived control association on the S1-MME interface and speak S1AP over it. This page is grounded in TS 36.413 (S1AP protocol) and TS 36.410 (S1 general aspects and principles), and it walks the whole protocol: the transport it rides on, how one UE is told apart from another on a shared link, and every elementary procedure from bringing the interface up to tearing a UE down.
Introduction
S1AP (S1 Application Protocol) is the control-plane signalling protocol between the E-UTRAN and the EPC — specifically between an eNB and an MME across the S1-MME interface, defined in TS 36.413. It is the language the radio and the core use to coordinate everything about a subscriber that is not user data itself.
You meet S1AP at every boundary between RAN and core. It brings the interface up when an eNB first reaches an MME, it carries the UE's NAS signalling up and down, it builds the UE's context and data bearers, it pages idle UEs, it hands UEs between eNBs through the core, and it releases everything when the UE goes quiet. All of that runs over a single reliable transport association, with a compact pair of identifiers keeping thousands of UEs apart on it.
Because S1AP is a structural protocol — a catalogue of elementary procedures over a shared association rather than one linear call flow — the way to learn it is to understand its transport, its addressing, and then each family of procedures. That is the order this page takes.
On this page
Why S1AP is needed
In plain words: think of the eNB and the MME as two departments in different buildings that manage the same customers. Rather than couriering a fresh sealed letter for every event, they keep one permanent, reliable phone line open between them and reference each customer by an agreed case number. S1AP is the etiquette on that phone line — how to open it, how to name the customer both ends are discussing, and the fixed set of things they are allowed to ask each other to do.
The RAN and the core are separate nodes, frequently built by different vendors, and they must agree on a UE without either side reaching into the other's internals. The eNB owns the radio; the MME owns mobility, authentication and session management. Something has to let them open the interface, confirm they serve the same PLMNs and Tracking Areas, relay the UE's NAS conversation with the core, provision the bearers and security the eNB needs, and coordinate paging and handover — all reliably, and all independent of the radio details below and the NAS details above. S1AP is that standardised, reliable contract.
The control protocol spoken between eNB and MME over S1-MME, transported on SCTP. It defines elementary procedures such as S1 Setup, Initial UE Message, Initial Context Setup, E-RAB Setup, Paging, UE Context Release and the S1 handover set.
The RAN and core are separate nodes, often from different vendors. They need one standardised, reliable way to manage the interface and every UE's context on it — independent of the radio details below and the NAS details above.
One SCTP association per eNB–MME pair carries all S1AP. Every procedure is either non-UE-associated (about the interface as a whole) or UE-associated (about one UE, glued together by a pair of identifiers described below).
What S1AP Is and Where It Runs
S1AP is the application-layer signalling protocol on the S1-MME interface — the control-plane link between an eNB in the E-UTRAN and an MME in the EPC. It carries everything the two nodes need to coordinate: bringing the interface up, relaying NAS messages between the UE and the MME, setting up and tearing down radio bearers, paging idle UEs, and moving a UE between eNBs. Its user-plane sibling is the S1-U interface (eNB↔S-GW), which carries no S1AP at all — only GTP-U tunnels. S1AP lives entirely on the control plane.
The transport stack under S1AP is deliberately robust. S1AP messages are carried in the payload of SCTP (Stream Control Transmission Protocol), which in turn runs over IP. SCTP is chosen over TCP for three concrete reasons: it gives reliable, in-sequence delivery per stream; it supports multi-streaming, so signalling for independent UEs travels on different streams and one lost packet never head-of-line-blocks another UE; and it supports multi-homing, where an endpoint advertises several IP addresses so the association survives a path failure. Per TS 36.412, S1AP uses a registered SCTP payload protocol identifier, and a single association per eNB–MME pair carries all traffic — non-UE-associated signalling typically pinned to stream 0, UE-associated signalling spread across the remaining streams.
One line to remember: S1AP is to LTE's S1-MME what NGAP is to 5G's N2 — the RAN↔core control protocol. It moves NAS transparently and manages the UE's context and bearers over a single reliable SCTP association.
Logical Connections and the Two UE IDs
Every S1AP procedure falls into one of two buckets, and knowing which bucket a message is in tells you how it is addressed on the shared association.
Non-UE-associated signalling concerns the interface itself, not any particular subscriber. S1 Setup Request/Response, eNB Configuration Update, MME Configuration Update, Overload Start/Stop, Reset and Error Indication (in its non-UE form) are examples. These carry no per-UE identity because they are not about a UE; they use the interface-wide logical connection.
UE-associated signalling concerns exactly one UE. Because many UEs share the single SCTP association, each side needs a way to say "this message is about that UE." That is done with two identifiers allocated when the UE's signalling connection is first created, and both then ride in every subsequent message of that connection:
eNB UE S1AP ID— the UE's context identity at the eNB, chosen by the eNB. Unique within that eNB, 24 bits wide.MME UE S1AP ID— the UE's context identity at the MME, chosen by the MME. Unique within that MME, 32 bits wide.
The eNB allocates its ID and sends it up in the very first UE-associated message (Initial UE Message); the MME allocates its own and returns it in the first downlink message it sends for that UE. From then on both IDs travel in every UE-associated message, together forming the logical UE-associated signalling connection for that UE — the S1 equivalent of NGAP's RAN UE NGAP ID/AMF UE NGAP ID pair in 5G. A mismatch or an unknown ID is exactly what Error Indication exists to flag.
| Identifier | Allocated by | First appears in | Scope & width | Purpose |
|---|---|---|---|---|
eNB UE S1AP ID | eNB | Initial UE Message (uplink) | Unique within the eNB; 24 bits | Names the UE's context at the eNB so the MME can address the right UE downlink. |
MME UE S1AP ID | MME | First MME→eNB message for the UE (e.g. Downlink NAS Transport or Initial Context Setup Request) | Unique within the MME; 32 bits | Names the UE's context at the MME so the eNB can address the right UE uplink. |
| The pair together | — | Every UE-associated message after setup | Globally identifies one connection | Binds the two contexts into one logical S1 signalling connection; non-UE-associated procedures carry neither. |
The gluing pair: eNB UE S1AP ID + MME UE S1AP ID together identify one UE's S1 signalling connection. If the eNB releases a UE but a stray message still references its old eNB UE S1AP ID, the receiver answers with Error Indication carrying the offending IDs and a Cause.
Interface Management
Before any UE can be served, the eNB and MME must agree they can work together, and they must be able to keep each other's view of the interface current over time. This is the job of the non-UE-associated interface-management procedures.
S1 Setup. When the SCTP association comes up, the eNB initiates the S1 Setup procedure — the first S1AP conversation on a fresh interface. The eNB sends S1 Setup Request advertising itself: Global eNB ID, the eNB Name, and its Supported TAs (the Tracking Areas and PLMNs it serves). The MME replies with S1 Setup Response carrying the MME Name, its Served GUMMEIs (which MME groups and codes it represents), and the Relative MME Capacity used for load balancing across a pool of MMEs. If the MME cannot accept the eNB, it returns S1 Setup Failure with a Cause and optionally a Time To Wait before retry. Only after setup succeeds may UE-associated traffic flow.
Configuration Update. Interfaces are not static — an operator adds Tracking Areas, renames nodes, or rebalances an MME pool. Rather than tearing the association down, either side updates the other in place. eNB Configuration Update (eNB→MME, acknowledged by eNB Configuration Update Acknowledge) revises the eNB's Supported TAs, name or default paging DRX. MME Configuration Update (MME→eNB, acknowledged by MME Configuration Update Acknowledge) revises the Served GUMMEIs or the Relative MME Capacity. Each has a matching ...Failure message.
Overload and Reset. An MME under load protects itself with Overload Start (telling eNBs to throttle certain traffic, e.g. reject non-emergency Attach) and later Overload Stop. If either node loses its state — a restart, a software fault — the Reset procedure (Reset / Reset Acknowledge) re-synchronises them by releasing either all UE-associated connections or a specified list.
| Procedure | Initiating message | Response | Key IEs / purpose |
|---|---|---|---|
S1 Setup | S1 Setup Request | S1 Setup Response / Failure | Global eNB ID, Supported TAs ↔ Served GUMMEIs, Relative MME Capacity. Brings the interface up. |
eNB Configuration Update | eNB Configuration Update | ...Acknowledge / ...Failure | Revise eNB's Supported TAs, name, paging DRX without dropping the association. |
MME Configuration Update | MME Configuration Update | ...Acknowledge / ...Failure | Revise Served GUMMEIs / Relative MME Capacity. |
Overload | Overload Start | Overload Stop (no ack) | Ask eNBs to throttle traffic while the MME is congested. |
Reset | Reset | Reset Acknowledge | Re-synchronise state after a fault; release all or a listed set of UE connections. |
Carrying NAS Transparently
A large part of S1AP's job is to be a courier for NAS. NAS (the Attach, Authentication, Security Mode, and ESM/EMM messages defined in TS 24.301) is a conversation between the UE and the MME. The eNB sits in the middle but is not supposed to read or understand NAS — it just relays it. S1AP provides the envelope and the addressing.
When a UE first sends a NAS message over RRC (say an Attach Request or Service Request), the eNB has no S1 connection for it yet, so it wraps that NAS blob in an Initial UE Message and sends it up. This message allocates the eNB UE S1AP ID and includes the NAS-PDU, the TAI, the E-UTRAN CGI (which cell), and the RRC Establishment Cause. Receiving it is what makes the MME create the UE context and allocate its MME UE S1AP ID. After that, NAS flows through two dedicated relay procedures:
Downlink NAS Transport— MME→eNB, carries aNAS-PDUdown to the UE.Uplink NAS Transport— eNB→MME, carries aNAS-PDUup from the UE.
In each case the NAS message rides inside the NAS-PDU IE and the eNB simply forwards it to or from RRC without interpreting it. If the eNB cannot deliver a downlink NAS message to the UE (radio link lost), it tells the MME with NAS Non Delivery Indication, returning the undelivered NAS-PDU and a Cause so the MME can retry or abandon.
Mental model: the NAS-PDU IE is a sealed envelope. The eNB reads the address on the outside (which UE, which direction, via the two UE S1AP IDs) but never opens it. Only the UE and the MME read the letter inside. That is exactly what "transparent NAS transport" means.
UE Context and E-RAB Management
Once the MME has authenticated the UE and the subscription is known, it tells the eNB to build a full UE context and establish the data radio bearers. This is the Initial Context Setup procedure — arguably the busiest single message on S1AP, because it wires up security, QoS and the user-plane tunnels all at once.
Initial Context Setup Request (MME→eNB) bundles a great deal into one message:
- The E-RAB(s) to set up — an
E-RAB To Be Setup List, each entry carrying anE-RAB ID, its QoS (E-RAB Level QoS Parametersincluding theQCIand the ARP), and the S1-U uplink transport address + GTP-U TEID at the S-GW. - The security context — the
Security Key(KeNB) and the allowedUE Security Capabilities, from which the eNB derives the AS keys and selects the ciphering and integrity algorithms. - The UE Aggregate Maximum Bit Rate (
UE-AMBR) capping the total non-GBR throughput across all the UE's bearers, and usually an initialNAS-PDUto deliver (for exampleAttach Accept).
The eNB configures the radio bearers over the air (an RRC reconfiguration), derives its AS security keys from KeNB, allocates its own S1-U downlink GTP-U TEID for each E-RAB, and answers with Initial Context Setup Response containing the E-RAB Setup List — each E-RAB's eNB S1-U transport address + downlink TEID. With both endpoints' TEIDs now known, the S1-U GTP-U tunnel for each bearer is complete and user data can flow eNB↔S-GW. Any bearer the eNB could not admit is reported in an E-RAB Failed to Setup List with a per-E-RAB Cause.
After the context exists, individual bearers are managed independently:
E-RAB Setup— add a dedicated bearer (E-RAB Setup Request/Response), e.g. when a VoLTE call needs a QCI 1 GBR bearer.E-RAB Modify— change a bearer's QoS (E-RAB Modify Request/Response), e.g. adjust its GBR or ARP.E-RAB Release— drop one or more bearers, either MME-initiated (E-RAB Release Command/Response) or eNB-initiated via the class-2E-RAB Release Indication.
There is also UE Context Modification, a lighter procedure to change context-wide parameters — a new Security Key after key refresh, updated UE-AMBR, or revised UE Security Capabilities — without touching individual E-RABs.
Paging, Context Release, and S1 Handover
Three more procedure families round out day-to-day S1AP, plus the catch-all error procedure.
Paging. When downlink data or signalling arrives for a UE that is in ECM-IDLE, the MME sends Paging (non-UE-associated) to every eNB in the UE's registered Tracking Areas. It carries the UE Identity Index Value (which paging frame the UE listens on), the UE Paging Identity (S-TMSI, or IMSI as a fallback), the CN Domain, and the TAI List naming where to page. The eNBs broadcast the page over the air; the UE responds by launching a Service Request, which brings its S1 connection back up with a fresh Initial UE Message.
UE Context Release. When a UE goes idle or must be dropped, the connection is torn down with the UE Context Release procedure. The eNB may ask for it with the class-2 UE Context Release Request (carrying a Cause such as user inactivity or radio-link failure); the MME then orders the release with UE Context Release Command, and the eNB confirms with UE Context Release Complete. This frees the two UE S1AP IDs and the S1-U tunnels. The MME can also start the command on its own initiative, for example on detach.
S1 Handover. When a target cell is on a different eNB with no X2 link between them, mobility goes through the core. This splits into two class-1 procedures. In Handover Preparation the source eNB sends Handover Required to the MME and the MME answers with Handover Command (or Handover Preparation Failure). In Handover Resource Allocation the MME asks the target eNB with Handover Request; the target reserves resources and replies Handover Request Acknowledge (or Handover Failure). Data loss is minimised by the class-2 eNB Status Transfer/MME Status Transfer pair (carrying PDCP sequence numbers), and the switch is confirmed by the class-2 Handover Notification. The full inter-eNB S1 handover flow is covered on its own page — see the bridge below.
Error Indication. Whenever a node receives a message it cannot process — an unknown pair of UE S1AP IDs, a missing mandatory IE, a syntactically broken message — it reports the problem with Error Indication, carrying a Cause and, where relevant, the offending IDs. It is the protocol's general fault-reporting valve rather than a procedure you deliberately trigger.
Idle-to-active in one arc: Paging wakes the UE → the UE's Service Request arrives as Initial UE Message → Initial Context Setup rebuilds the bearers → when the UE goes quiet again, UE Context Release tears it all down. That loop is the everyday life of an S1 signalling connection.
Class 1 vs Class 2 Procedures
TS 36.413 sorts every elementary procedure into two classes by whether it expects a response — and this classification tells you immediately how to reason about failure and timeouts.
Class 1 procedures have a response. They complete with either a successful outcome (an Acknowledge/Response/Complete) or an unsuccessful one (a Failure), and the initiator runs a timer waiting for it. S1 Setup, Initial Context Setup, E-RAB Setup/Modify/Release (command form), UE Context Release, UE Context Modification, Handover Preparation, Handover Resource Allocation, Reset, and the two Configuration Update procedures are all class 1.
Class 2 procedures have no response. They are fire-and-forget: the sender transmits and relies on SCTP for delivery, with no protocol-level acknowledgement and no failure message. Paging, Initial UE Message, Downlink NAS Transport, Uplink NAS Transport, NAS Non Delivery Indication, Error Indication, UE Context Release Request, E-RAB Release Indication, Overload Start/Stop, Handover Notification and the Status Transfer pair are class 2. A quick tell: if the message name is a bare noun or ends in "Indication"/"Request" with no matching "Response," it is almost always class 2.
| Procedure | Initiating message | Response | Class / purpose |
|---|---|---|---|
S1 Setup | S1 Setup Request | S1 Setup Response / Failure | Class 1 — bring the S1-MME interface up. |
Initial UE Message | Initial UE Message | — (none) | Class 2 — carry first NAS up, create the UE connection, allocate eNB UE S1AP ID. |
Downlink NAS Transport | Downlink NAS Transport | — (none) | Class 2 — relay a NAS-PDU to the UE. |
Uplink NAS Transport | Uplink NAS Transport | — (none) | Class 2 — relay a NAS-PDU from the UE. |
Initial Context Setup | Initial Context Setup Request | ...Response / ...Failure | Class 1 — build UE context: E-RABs, KeNB, UE security caps, UE-AMBR. |
E-RAB Setup | E-RAB Setup Request | E-RAB Setup Response | Class 1 — add a bearer and its S1-U TEID. |
E-RAB Modify | E-RAB Modify Request | E-RAB Modify Response | Class 1 — change a bearer's QoS. |
E-RAB Release | E-RAB Release Command | E-RAB Release Response | Class 1 — drop bearers (eNB-initiated form is class-2 E-RAB Release Indication). |
Paging | Paging | — (none) | Class 2 — page an idle UE across its Tracking Areas. |
UE Context Release | UE Context Release Command | UE Context Release Complete | Class 1 — tear down the connection and S1-U tunnels (triggered by class-2 ...Request). |
Handover Preparation | Handover Required | Handover Command / Preparation Failure | Class 1 — source-side S1 handover. |
Handover Resource Allocation | Handover Request | Handover Request Acknowledge / Failure | Class 1 — target-side S1 handover. |
Error Indication | Error Indication | — (none) | Class 2 — report an unprocessable message / bad IDs with a Cause. |
LTE ↔ NR: the 5G equivalent of S1AP is NGAP (TS 38.413) on the N2 interface between the gNB and the AMF, and the mapping is close to one-to-one. The UE-ID pair becomes RAN UE NGAP ID/AMF UE NGAP ID; S1 Setup becomes NG Setup; Initial Context Setup becomes Initial Context Setup still, but bearers are now PDU Sessions with QoS Flows (QFI/5QI) instead of E-RABs (QCI); the S-GW user-plane peer becomes the UPF and the tunnels are still GTP-U. The class-1/class-2 distinction, the single SCTP association, and transparent NAS transport all carry over unchanged — learning S1AP is most of the way to reading NGAP.
Summary
S1AP (TS 36.413) is the control-plane protocol on S1-MME between eNB and MME, carried over a single reliable, multi-streamed, multi-homed SCTP association per eNB–MME pair. Every procedure is either non-UE-associated (about the interface: S1 Setup, Configuration Update, Overload, Reset) or UE-associated, in which case the eNB UE S1AP ID/MME UE S1AP ID pair keeps thousands of UEs apart on the shared link.
Its work divides into interface management, transparent NAS courier duty (Initial UE Message, Uplink/Downlink NAS Transport), UE-context and E-RAB provisioning (Initial Context Setup wiring security, QoS and the S1-U GTP-U TEIDs together), and the everyday idle-to-active arc of Paging → Initial Context Setup → UE Context Release, with S1 handover through the core when there is no X2. Sorting each procedure into class 1 (has a response and a guard timer) or class 2 (fire-and-forget over SCTP) is the fastest way to reason about how any of them can fail — and the whole structure maps almost directly onto 5G's NGAP.
Q. Why does S1AP run over SCTP rather than TCP?
A. Signalling needs reliable, in-sequence delivery but also multi-streaming (to avoid head-of-line blocking between independent UEs) and multi-homing (path redundancy). SCTP provides all three; TCP provides neither of the latter two. One SCTP association per eNB–MME pair carries all S1AP.
Q. How is a single S1AP message associated with the right UE?
A. Via the pair eNB UE S1AP ID and MME UE S1AP ID. The eNB allocates its ID in the Initial UE Message; the MME allocates its own and returns it; both then appear in every UE-associated message, identifying that UE's connection. Non-UE-associated procedures like S1 Setup carry neither.
Q. What does Initial Context Setup hand the eNB that no other message does?
A. In one shot: the E-RAB To Be Setup List (QoS + S-GW S1-U TEID per bearer), the Security Key KeNB and the allowed UE Security Capabilities, and the UE-AMBR. It is where security, QoS and the user-plane tunnel are all provisioned together.
Q. What is the difference between class 1 and class 2 procedures?
A. Class 1 procedures have a response — a success (Response/Acknowledge/Complete) or a Failure — and the initiator times out waiting for it (e.g. S1 Setup, Initial Context Setup). Class 2 procedures have no response at all and rely on SCTP for delivery (e.g. Paging, Uplink NAS Transport, Error Indication).
Q. Where do the S1-U GTP-U tunnels actually get bound?
A. During Initial Context Setup (and later E-RAB Setup/Modify). The request carries the S-GW's uplink TEID and transport address per E-RAB; the response carries the eNB's downlink TEID. With both TEIDs known, the S1-U tunnel for that bearer is fully bound and user data can flow.
Where S1AP connects
S1AP is the LTE control link between RAN and core; its neighbours are the 5G equivalent, the inter-node mobility it drives, and the tunnels it provisions.