Comprehensive technical knowledge base covering 12 GSMA eSIM specifications. 84+ articles on Remote SIM Provisioning — SGP.02, SGP.22, SGP.32, SGP.41, SGP.29, SGP.23, SGP.25, SGP.26 and more.
🏠 eUICC.tech > SGP.22 Consumer RSP > SM-DS and Companion Devices: Discovery, Cascading, and Multi-Device Provisioning
💡 Why this matters: The SM-DS is the unsung hero of the eSIM ecosystem. It’s the reason your carrier can push a profile to your smartwatch without you scanning a QR code, and why enterprise device fleets can be provisioned in bulk. Understanding the SM-DS: and its cascading architecture: is essential for anyone building multi-device or companion provisioning systems.
Key takeaways:
- The SM-DS (Subscription Manager: Discovery Server) is a notification bulletin board: SM-DP+ posts Events, devices poll for them
- Three protocols govern SM-DS operation: ES11 (LPA → SM-DS for event retrieval), ES12 (SM-DP+ → SM-DS for registration/deletion), ES15 (SM-DS → SM-DS for cascading)
- SM-DS cascading creates a tree structure: Alternative SM-DSs forward events to a Root SM-DS using ES15
- The event lifecycle is: Register → Retrieve → Delete : events are one-shot and must be explicitly removed
- Companion device scenarios (Annex C.2) use a Primary Device as a conduit, with PSK-TLS for secure pairing
- Companion devices without their own UI must delegate User Intent capture to a Primary Device
The SM-DS is the most misunderstood component in the RSP architecture. It doesn’t store profiles. It doesn’t generate keys. It doesn’t authenticate devices. It’s simply a discovery service: a place where SM-DP+ servers post notices saying “I have a profile waiting for eUICC X,” and where eUICCs come to check their mail.
This article covers the full SM-DS protocol suite (ES11, ES12, ES15) and the companion device scenarios that make the SM-DS especially valuable.
Section 3.6 defines the SM-DS’s core function: Event management. An Event is a record containing:
| Field | Description |
|---|---|
| EID | The eUICC Identifier: which chip the Event is for |
| RSP Server Address | The FQDN of the SM-DP+ that has the profile |
| EventID | A unique identifier for this Event, generated by the registering entity |
The SM-DS stores these records and returns them when the matching eUICC comes asking. That’s it. The SM-DS never sees a profile, never handles encryption keys, and never participates in the actual download.
The relationship between SM-DS and SM-DP+ is many-to-many. A single SM-DS can serve events from hundreds of SM-DP+ servers. Conversely, an SM-DP+ can register events on multiple SM-DS instances (though typically one is sufficient).
ES11 is the interface between the LPA (specifically the LDS/LDSe) and the SM-DS. It has two functions:
This starts the mutual authentication procedure defined in section 3.1.2. The client (LPA) authenticates the SM-DS using its TLS certificate (CERT.DS.TLS), then the eUICC authenticates to the SM-DS using CERT.EUICC.ECDSA.
The LPA builds a ctxParams1 data object containing:
The eUICC signs this context, and the signature is verified by the SM-DS. This proves that the eUICC genuinely owns the EID it claims.
After mutual authentication succeeds, the SM-DS looks up pending events:
The SM-DS returns a set of {RSP Server Address, EventID} pairs, ordered as they were registered. The LPA then processes these sequentially: for each pair, it contacts the indicated SM-DP+ and initiates the profile download using the EventID as the MatchingID.
ES12 is the interface between SM-DP+ and SM-DS. It’s authenticated by TLS with mutual authentication: both parties present their certificates.
When an SM-DP+ has a profile ready for an eUICC (typically after the operator has called ES2+.ConfirmOrder), it registers an Event:
SM-DP+ → SM-DS: RegisterEvent(EID, RSP Server Address, EventID, ForwardingIndicator)
The ForwardingIndicator is critical:
false: This is the final registration. The Event Record is stored directly.true: The Event should be forwarded/cascaded (triggering ES15).The EventID must be unique per SM-DP+ and must not be reused. It’s typically a random value or a hash.
After a profile has been successfully downloaded (or the download order cancelled), the SM-DP+ cleans up:
SM-DP+ → SM-DS: DeleteEvent(EID, EventID)
The SM-DS verifies that the SM-DP+ OID (from the TLS certificate) matches the OID stored in the Event Record. This prevents one SM-DP+ from deleting another’s events.
The deletion is permanent: events are not recoverable. This is why the SM-DP+ only deletes after confirming successful download or explicit cancellation.
ES15 is the interface between SM-DS instances. It enables a tree topology where Alternative SM-DSs register events with a Root SM-DS.
The GSMA operates a Root SM-DS with a well-known address. Every device can find it. But operators and SM-DP+ providers may want their own discovery servers for:
Operator → SM-DP+ → Alternative SM-DS → Root SM-DS
│ │
ES12.Register ES15.Register
EventID1 EventID2
The flow (section 3.6.1.2):
truefalseWhen the device polls the Root SM-DS, it gets back {Alternative SM-DS Address, EventID2}. The device then contacts the Alternative SM-DS using EventID2 as the MatchingID (case (b) retrieval). The Alternative SM-DS looks up the original EventID1 and returns {SM-DP+ Address, EventID1}.
Deletion follows the same chain in reverse:
Cascading can theoretically go deeper (SM-DS → SM-DS → SM-DS), but the spec primarily addresses the two-level case.
SM-DP+ SM-DS LPA/eUICC
│ │ │
│ ES12.RegisterEvent │ │
│──────────────────────→│ │
│ (EID, EventID) │ │
│ │ ES11.Authenticate │
│ │←───────────────────────│
│ │ (mutual auth) │
│ │ │
│ │ {Address, EventID} │
│ │───────────────────────→│
│ │ │
│ ES9+.InitiateAuth │ │
│←───────────────────────────────────────────────│
│ (EventID as │ │
│ MatchingID) │ │
│ │ │
│ Profile Download │ │
│←─────────────────────────────────────────────→│
│ │ │
│ ES12.DeleteEvent │ │
│──────────────────────→│ │
│ (EID, EventID) │ │
The key insight: the SM-DS is involved in only two steps: registration and retrieval. The actual profile download is a separate flow between the LPA and the SM-DP+.
Annex C defines requirements for devices that participate in companion provisioning: scenarios where one device (the Primary) helps provision another (the Companion).
A smartwatch has a small screen (or no screen), no keyboard, and possibly no camera. How do you scan a QR code on it? How do you display profile names and get user consent? SGP.22 addresses this with the Primary/Companion model.
Key requirements from Annex C.1:
The most architecturally interesting part of companion provisioning is the secure pairing between Primary and Companion devices. Annex C.2 defines a PSK-TLS based mechanism:
The URL format is: https://<Companion Device address>/<LPA_access_token>
This is a clever design: the one-time secret key embedded in the URL serves as both the PSK for TLS and as a rendezvous mechanism. No certificate infrastructure is needed between the two devices: the physical proximity (NFC tap, QR scan) provides the initial trust anchor.
Once the PSK-TLS session is established, the Primary Device can:
The complete flow:
Annex C.1 enumerates 14 device requirements (DEV1-DEV14). The most impactful for companion scenarios:
| Req | Requirement |
|---|---|
| DEV1 | Support at least one 3GPP/3GPP2 network access technology |
| DEV6 | Handle an eUICC without any installed profiles |
| DEV7 | Companion Devices without SM-DP+ capability use Primary Device as conduit |
| DEV8 | At least one device must have UI for User Intent |
| DEV14 | Operate with default file system (no Enabled Profile) : complete CAT initialisation |
For SM-DS operators: Your service is the discovery backbone for the entire eSIM ecosystem. Latency in event retrieval directly impacts user experience: a device that can’t find its profile is a device that can’t connect.
For SM-DP+ operators: Always delete events after successful download. Leaking events on the SM-DS is a security and user-experience problem: a stale event could cause a device to attempt a download that will always fail.
For companion device OEMs: The PSK-TLS pairing model in Annex C.2 is your blueprint for secure Primary-Companion communication. Implement it correctly and your smartwatch can pair with any phone, regardless of brand. Implement it wrong and you’ll have interoperability nightmares.
For enterprise fleet managers: The SM-DS cascading model means you can operate your own Alternative SM-DS. Point your devices at your own discovery server, register events there, and cascade only what’s needed to the Root SM-DS. This gives you control over the discovery infrastructure without breaking global interoperability.
For developers: Test with the Root SM-DS address configured. Test with no SM-DS configured (only default SM-DP+). Test with both. The fallback paths in profile discovery are critical for robustness.
The SM-DS and companion device architecture complete the SGP.22 picture. From the initial architecture (article 01) through the eUICC internals (article 02), profile download (article 03), security (article 04), local management (article 05), developer interfaces (article 06), LPAe (article 07), boot (article 08), policy (article 09), and notifications (article 10) : we’ve now covered the full consumer eSIM stack. The SM-DS is the final piece: the infrastructure that makes discovery automatic and companion devices possible.
| ← Previous: SGP.22 v2.7: Notifications and Post-Install: Keeping Operators in the Loop | Section Index |