S6a (Diameter — MME ↔ HSS) in LTE 4G

Introduction

S6a is the control-plane reference point between the MME (Mobility Management Entity) and the HSS (Home Subscriber Server) in the Evolved Packet Core. It carries no user traffic — it is pure signalling, and it runs the IETF Diameter protocol as a 3GPP application defined in TS 29.272. Everything on it serves one of two goals: authentication (fetching the material the MME needs to challenge the UE) and subscription management (learning, tracking, and receiving live updates to what the subscriber is entitled to).

It fires at the pivotal moments of the mobility lifecycle. At attach the MME uses S6a to pull authentication vectors and then to register itself as the serving node while downloading the subscription profile. At a tracking-area update into a new MME the same registration repeats, and the HSS cleans up the old MME. While the UE is registered, the HSS can push profile changes down at any time — add an APN, change QoS, bar roaming — without the UE re-attaching. And when the MME drops a stale context, it tells the HSS so the two stay in sync.

It matters because the MME is deliberately stateless about a subscriber until S6a tells it who they are. The permanent secret key K never leaves the HSS/AuC and the USIM, so the MME must fetch derived vectors rather than hold the key; and the subscription profile is stored centrally so it is identical across every MME the UE ever visits. S6a is the single channel through which both of those truths reach the serving MME.

Why S6a is needed

Concretely, S6a exists because two pieces of information the MME needs are held only at the centre. First, proof of identity: the secret key K is shared solely between the USIM and the HSS/AuC, so the MME can never compute an authentication challenge itself — it must fetch ready-made vectors. Second, entitlements: what APNs, QoS, and rate caps a subscriber may use is operator policy stored once in the HSS, so that it applies identically no matter which MME serves the UE. S6a is how the MME asks both questions — "how do I prove this UE is genuine?" and "what is this UE allowed to do?" — and how the HSS pushes fresh answers down whenever either changes.

What S6a Is

S6a is the reference point between the MME (Mobility Management Entity) and the HSS (Home Subscriber Server) in the EPC. It is a pure control-plane, signalling-only interface — no user traffic ever crosses it. Everything it does falls into two buckets: authentication (getting the material to challenge the UE) and subscription management (learning, tracking, and receiving live updates to what the subscriber is entitled to).

Why Diameter, Not SS7/MAP

In the 2G/3G world the equivalent conversation — the SGSN or MSC/VLR talking to the HLR — ran over SS7 using the MAP (Mobile Application Part) protocol. EPS deliberately walked away from that and adopted Diameter, an IETF AAA (Authentication, Authorization, Accounting) protocol defined in the Diameter base protocol RFC. Understanding why is a favourite interview opener, and it explains the shape of everything that follows.

SS7 was designed for a circuit-switched telephony network: a specialised, tightly-managed signalling transport with its own point-code addressing, engineered for voice call control. EPS is an all-IP packet core. Forcing legacy SS7/MAP onto it would mean maintaining a parallel, non-IP signalling stack. Diameter instead rides directly on IP transport, uses IP-style realm and host routing (so operators are addressed by domain names, not point codes), scales horizontally, and was purpose-built as an AAA protocol — exactly the "authenticate the user, authorize their services" job S6a performs. It is the direct successor to RADIUS, fixing RADIUS's reliability and security shortcomings.

Diameter Basics — Commands, AVPs, Realms, Application-Id

Before the S6a commands make sense you need the shape of the protocol carrying them. Four concepts do all the work: the base protocol, the command, the AVP, and the routing primitives (realm, host, Application-Id).

The base protocol. The Diameter base protocol defines the common machinery every Diameter application reuses: how peers connect and stay alive (the Capabilities-Exchange (CER/CEA), Device-Watchdog (DWR/DWA), and Disconnect-Peer (DPR/DPA) commands), the message header format, error handling, and the mandatory AVPs carried in every message. S6a is not a protocol from scratch — it is a Diameter application layered on that base, adding only the command set and AVPs specific to MME–HSS signalling.

The message header. Every Diameter message begins with a fixed 20-octet header: an 8-bit Version (1), a 24-bit Message Length, a Command Flags octet (the R Request bit, P proxiable, E error, T potentially-retransmitted), a 24-bit Command-Code, a 32-bit Application-Id, then the 32-bit Hop-by-Hop Identifier and 32-bit End-to-End Identifier. AVPs follow the header.

Commands. Every Diameter message is a command identified by a Command-Code plus the Request/Answer (R) bit — that is why S6a commands always come as a pair, e.g. Update-Location-Request (ULR) and Update-Location-Answer (ULA) share one Command-Code (S6a assigns codes such as 316 for Update-Location and 318 for Authentication-Information) and differ only in the R-bit. Requests and answers are matched by the Hop-by-Hop identifier (peer-to-peer) and the End-to-End identifier (edge-to-edge, unchanged across relays so duplicates can be detected), and grouped under a Session-Id.

AVPs. The actual data lives in Attribute-Value Pairs — self-describing type-length-value fields. An AVP carries an AVP-Code, an AVP Flags octet (notably the M-bit, "mandatory": if a peer does not understand a mandatory AVP it must reject the message; and the V-bit, "vendor-specific"), an AVP Length, an optional 32-bit Vendor-Id when the V-bit is set, and the value. AVPs can be grouped — a single AVP whose value is itself a list of AVPs — which is how a whole subscription profile nests inside one Subscription-Data AVP. 3GPP registers its own AVPs under Vendor-Id 10415, so you will see the V-bit set and Vendor-Id = 10415 on 3GPP AVPs.

Realms, hosts, and Application-Id. Diameter routes by name. Each message carries an Origin-Host/Origin-Realm and, for requests, a Destination-Realm (and optionally Destination-Host). A realm is essentially the operator's domain (e.g. epc.mnc001.mcc234.3gppnetwork.org), and intermediate agents route on it — this is exactly how a roaming MME's request reaches the home HSS through a DRA (Diameter Routing Agent). Finally, every message declares an Application-Id that names which Diameter application it belongs to; S6a/S6d has its own registered Application-Id (16777251), so a node knows a message is "S6a" and applies the TS 29.272 rules.

Transport. Diameter runs over SCTP (strongly preferred, for multi-streaming and multi-homing) or TCP — never bare UDP the way legacy RADIUS did. In real LTE cores S6a almost always uses SCTP.

The S6a Command Pairs

S6a is a small, closed set of request/answer pairs. Learn these six and you know the interface. Group them by who initiates: the MME pulls or reports; the HSS pushes changes down.

Authentication-Information-Request/Answer (AIR/AIA) — MME→HSS. The MME asks for one or more EPS authentication vectors for EPS-AKA. Each vector holds RAND (128-bit random challenge), AUTN (128-bit network authentication token, so the UE can verify the network), XRES (expected response), and KASME (256-bit master key from which all NAS and AS keys are derived). The HSS, together with its AuC, computes these from the subscriber's secret key K. The MME requests them in the Requested-EUTRAN-Authentication-Info AVP (which carries the Number-Of-Requested-Vectors and, on a re-sync, the Re-synchronization-Info containing RAND+AUTS) and never sees K itself. This is the first thing the MME needs before it can challenge the UE.

Update-Location-Request/Answer (ULR/ULA) — MME→HSS. At attach, or at a TAU into a new MME, the MME registers itself as the UE's serving node so the HSS knows where to route mobile-terminated signalling. The ULR carries User-Name (IMSI), Visited-PLMN-Id, RAT-Type and ULR-Flags. In the ULA the HSS returns the grouped Subscription-Data AVP: subscribed APN-Configurations, the subscribed UE-AMBR, access restrictions, the default APN, and more. One exchange both updates location and downloads the profile.

Cancel-Location-Request/Answer (CLR/CLA) — HSS→MME. When a UE registers on a new MME, the HSS tells the old MME to drop it: CLR flows HSS→old-MME carrying a Cancellation-Type so the stale context is purged. This guarantees exactly one MME is registered as serving the subscriber and prevents duplicate contexts after relocation.

Insert-Subscriber-Data / Delete-Subscriber-Data (IDR/IDA, DSR/DSA) — HSS→MME. These are HSS-initiated profile pushes. When an operator changes a subscriber's data — adds an APN, changes QoS, bars roaming — the HSS sends IDR to insert/update or DSR to delete, and the serving MME applies the change live, with no need for the UE to re-attach. The DSR names what to remove via the DSR-Flags bitmask. IDR is also how the HSS requests certain UE state on demand (via IDR-Flags).

Purge-UE-Request/Answer (PUR/PUA) — MME→HSS. When the MME removes a detached or long-idle UE's context from memory to reclaim resources, it tells the HSS with PUR so the HSS marks the UE as purged from that MME. The PUA-Flags in the answer may tell the MME whether to keep or discard freshly-fetched unused vectors.

Notify-Request/Answer (NOR/NOA) — MME→HSS. The MME notifies the HSS of events that must keep HSS state in sync — for example a change in UE reachability (for MT-SMS or MT data delivery, via the NOR-Flags), or a newly allocated dynamic PDN GW identity for an APN, so the HSS records which P-GW is anchoring the session.

S6a at Attach — AIR/AIA then ULR/ULA

The two exchanges you must be able to draw, in order, during an initial attach: first the authentication fetch, then the location update that downloads the profile.

1. The UE sends its identity (IMSI) to the MME in the NAS Attach Request. 2. Having no vectors, the MME sends Authentication-Information-Request (AIR) to the HSS, carrying the IMSI in User-Name, the serving network in Visited-PLMN-Id, and the number of vectors it wants in Requested-EUTRAN-Authentication-Info. 3. The HSS/AuC derives the vectors from K and returns them in Authentication-Information-Answer (AIA): RAND, AUTN, XRES, KASME. The MME now runs the EPS-AKA challenge with the UE over NAS. 4. Once the UE is authenticated and NAS security is established, the MME registers with Update-Location-Request (ULR). 5. The HSS records this MME as serving — sending CLR to any previous MME if one existed — then returns Update-Location-Answer (ULA) with the full Subscription-Data. The MME now knows the subscribed APNs and QoS and can build the default bearer.

The Subscription Data — What the ULA Delivers

The single most important payload on S6a is the grouped Subscription-Data AVP returned in the ULA (and pushed later in IDR). It is the MME's rulebook for this subscriber: it decides which bearers can exist, how fast they may run, and where the UE is allowed to be.

Aggregate rate cap. The UE-AMBR (subscribed Aggregate Maximum Bit Rate) sets the ceiling, uplink and downlink, on the combined throughput of all the UE's non-GBR bearers. The MME enforces this across bearers and passes it to the eNB. It is a subscription attribute, so a "premium" subscriber simply carries a higher UE-AMBR in the HSS.

APN configuration. The APN-Configuration-Profile is a list of APN-Configuration AVPs, one per subscribed APN. Each entry names the APN (the Service-Selection AVP), its PDN-Type (IPv4, IPv6, IPv4v6), the EPS subscribed QoS profile for its default bearer — the default QCI and ARP (Allocation and Retention Priority) — and the per-APN AMBR (APN-AMBR). The profile also carries the Context-Identifier of the default APN, which the MME uses when the UE requests attach without naming an APN.

Access restrictions and status. The Access-Restriction-Data bitmask tells the MME which access is barred for this subscriber — for example handover to UTRAN or GERAN not allowed, or NB-IoT restricted. The Subscriber-Status AVP says whether the subscriber is operator-determined-barred, and Network-Access-Mode indicates whether packet and/or circuit access is permitted. If everything is barred, the MME rejects the attach outright — the HSS is the policy source, not the MME.

Command & AVP Reference

The complete S6a command set, grouped by initiator, followed by the AVPs you are most likely to be asked to name.

Summary

S6a is the MME↔HSS control-plane interface of the EPC, defined in TS 29.272 and run as a Diameter application (Application-Id 16777251) over SCTP. It replaced the 2G/3G SS7/MAP conversation with an all-IP AAA interface: the HLR became the HSS, MAP operations became Diameter commands, MAP parameters became AVPs, and point-code routing became realm/host routing.

Everything on it is a request/answer command pair built from typed AVPs. The MME pulls or reports — AIR/AIA fetches EPS-AKA vectors (RAND, AUTN, XRES, KASME) computed from the never-exposed key K; ULR/ULA registers the serving MME and downloads the grouped Subscription-Data; PUR and NOR report purge and event state. The HSS pushes down — CLR cleans up the old MME on relocation, IDR/DSR apply live profile changes, and RSR flags a restart. The Subscription-Data tree (UE-AMBR, APN-Configuration with QCI/ARP and APN-AMBR, Access-Restriction-Data) is the MME's rulebook for building bearers.

In 5G the same two jobs move to the AMF↔UDM service-based interfaces (Nudm), swapping Diameter/AVPs for HTTP/2/JSON and EPS-AKA for 5G-AKA — but the shape of the conversation, "prove the UE, then tell me what it may do," is unchanged.

Interview Quickfire