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.33-3 eIM Testing > eIM Test Architecture: Simulated eIM and Reference IPA
💡 Why this matters: Testing the eUICC IoT Manager (eIM) is architecturally unique: it’s a server under test, not a chip or a device. Unlike eUICC testing (where a physical card sits on a reader) or LPAd testing (where a device runs test software), the eIM is a remote network service that must be tested across four different simulated counterparts simultaneously. Understanding how SGP.33-3 constructs this test environment reveals the engineering challenge of proving that an IoT remote management server works correctly before it ever touches a real IoT device.
Key takeaways:
- The eIM is the sole Implementation Under Test (IUT) : all other components (SM-DP+, SM-DS, eUICC, IPA) are simulators implemented by the test tool provider
- Five simulator types surround the eIM: S_SM-DP+ (ES9+’), S_SM-DS (ES11’), S_eUICC (ESep), S_IPA (ESipa), and S_CLIENT/S_SERVER (TLS testing)
- Four interfaces are in scope for eIM testing: ESep, ES9+’, ES11’, and ESipa: while ES2+, ES6, ES8+, ES9+, ES10a, ES10b, ES11, and ES12 are out of scope
- The test architecture mirrors the IoT eSIM reference architecture from SGP.31/SGP.32, with the eIM positioned as the central orchestrator between the IoT Device, SM-DP+, and SM-DS
- Test environments mirror those from SGP.23 but adapted for IoT-specific interfaces: the eIM plays the role of LPAd for ES9+’ and ES11’ testing
- Test tools MUST implement all simulators; the specification provides methods (MTD_) and procedures (PROC_) as building blocks, but leaves implementation details to tool providers
SGP.33-3 v1.2 defines a test architecture where the eIM sits at the centre of a simulated IoT eSIM ecosystem. Every other component is a simulator: this isolation is essential because the eIM is a server, and you cannot test a server’s protocol behaviour without controlled, deterministic counterparts.
The test environment (Section 3.2.3.1) places the eIM IUT at the centre of four simulated interfaces:
S_SM-DP+
|
ES9+'
|
S_SM-DS: ES11' : IUT (eIM) : ESep: S_eUICC
|
ESipa
|
S_IPA
The test environment consists of:
Implementation of all simulators is the responsibility of the test tool providers. The test tools must also implement S_CLIENT and S_SERVER simulators for TLS-level testing: these MAY be the same as S_SM-DP+ or S_SM-DS depending on which component is under test.
SGP.33-3 defines a clear boundary for what is tested:
| Interface | Between | Description | Tested |
|---|---|---|---|
| ESep | eIM → eUICC | Logical end-to-end interface for eUICC Packages (Profile State Management and eIM Configuration) | ✓ |
| ES9+’ | eIM → SM-DP+ | Secure transport for Bound Profile Package delivery, with eIM acting as LPAd | ✓ |
| ES11’ | eIM → SM-DS | Event Record retrieval from SM-DS, with eIM acting as LPAd | ✓ |
| ESipa | eIM → IPA | Trigger profile download at IPA; secure transport for eUICC Package delivery; notification handling | ✓ |
| Interface | Between | Description |
|---|---|---|
| ES2+ | Operator → SM-DP+ | Profile ordering |
| ES6 | Operator → eUICC | OTA management of Operator services |
| ES8+ | SM-DP+ → eUICC | Secure end-to-end channel for ISD-P administration |
| ES9+ | SM-DP+ → IPA | Secure transport for Bound Profile Package (IPA-side) |
| ES10a | IPA → eUICC | Profile discovery |
| ES10b | IPA → eUICC | Transfer Bound Profile Package to eUICC |
| ES11 | IPA → SM-DS | Event Record retrieval (IPA-side) |
| ES12 | SM-DP+ → SM-DS | Event Registration management |
This scoping means SGP.33-3 tests the eIM as the IoT remote management orchestrator: how it talks to profile servers, discovery servers, eUICCs, and the device-side IPA.
A distinctive feature of SGP.33-3 is its extensive reuse of SGP.23 test cases. Rather than redefining every test from scratch, SGP.33-3 frequently states: “This test sequence is the same as SGP.23 [32] … where the eIM plays the role of LPAd.”
This applies to:
ES9+’ testing (Sections 4.2.10–4.2.15): The eIM communicates with SM-DP+ using the same ES9+ interface the LPA uses in consumer eSIM, but over the IoT-specific ES9+’ variant. Test cases for InitiateAuthentication, GetBoundProfilePackage, AuthenticateClient, HandleNotification, CancelSession, and HTTPS are all adapted from SGP.23’s LPAd test cases.
ES11’ testing (Sections 4.2.16–4.2.18): The eIM communicates with SM-DS using the same patterns as the LPA’s ES11 communication in consumer eSIM.
This reuse gives SGP.33-3 a foundation of proven test methodology while allowing IoT-specific additions (ESep, ESipa, eIM configuration) to be the focus of new test development.
The ESipa interface (eIM-to-IPA) is the most IoT-specific interface tested in SGP.33-3. It defines 11 functions:
As of v1.2, the test sequences for all ESipa functions are marked FFS (For Future Study) : a recognition that the eIM-to-IPA interface testing methodology is still maturing. However, the behaviour testing section (Section 5) does contain a concrete test case for Profile Enable via ESipa (TC_eIM_ProfileEnable_TLS_eIM_Pkg_Retrieval).
SGP.33-3 defines a library of reusable test building blocks:
The simulated eUICC (S_eUICC) must be pre-configured for eIM testing (Annex G):
Based on GSMA SGP.33-3 v1.2 (27 January 2025) : eUICC IoT Manager Test Specification, Sections 3, Annexes A–D, G
| ← Previous: SGP.33 Overview: The IoT eSIM Test Family | Section Index | Next: Key eIM Test Cases: PSMO, Notifications, and Configuration → |