SM-DS

The SM-DS (Subscription Manager Discovery Server) is a lookup service that tells an eSIM device where to fetch a profile. When an operator prepares a profile on an SM-DP+, the SM-DP+ can register an event for the device’s EID on an SM-DS; the device later polls the SM-DS, finds the event and connects to the right SM-DP+ — no activation code needed.

How discovery works

1. Event registration: the SM-DP+ registers the EID, an event ID and its own address with an SM-DS over the ES12 interface.
2. Polling: the device’s LPA — or IPA in IoT devices — authenticates to the SM-DS and asks for pending events for its eUICC over ES11.
3. Retrieval: the SM-DS returns an event record containing the SM-DP+ address and event ID.
4. Download: the device contacts that SM-DP+ and runs a normal profile download, after which the event is deleted.

The device authenticates to the SM-DS with the same eUICC certificates it uses with an SM-DP+, so the SM-DS only returns events registered for that chip.

Root and Alternative SM-DS

SGP.22 defines a Root SM-DS — a globally identified central access point whose address is configured on the eUICC — and Alternative SM-DS instances that other parties can operate. An Alternative SM-DS can work in cascade with the Root, forwarding registrations so that a device polling only the Root still finds the event.

Where SM-DS is used

• Consumer devices: the LPA can poll the SM-DS during device setup or on request, which lets an operator deliver a profile to a phone whose EID it already knows.
• IoT under SGP.32: an eIM can tell the IPA to contact an SM-DS, or query the SM-DS itself on the device’s behalf over ES11’, so a fleet can pick up profiles without per-device codes.
• Operator-initiated swaps: discovery suits flows where the operator, not the user, decides when a new profile should be fetched.

Why it matters for testing

Discovery adds failure points of its own: an event registered against the wrong EID, registered on an SM-DS the device never polls, or left behind after use. Because polling happens in the background, these failures are easy to miss without a log of each discovery attempt. Testing discovery-based flows on a real eUICC with a live network connection is the reliable way to confirm a profile can be found as well as downloaded — see how to test SGP.32 devices.