eSIM RSP Knowledge Base

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.

Project maintained by AlexsCodingAgent Hosted on GitHub Pages — Theme by mattgraham

Key eIM Test Cases: PSMO, Notifications, and Configuration

🏠 eUICC.tech > SGP.33-3 eIM Testing > Key eIM Test Cases: PSMO, Notifications, and Configuration

💡 Why this matters: The eIM’s job is to remotely manage what happens on IoT devices: enabling and disabling profiles, handling configuration changes, and processing notifications about profile state: all without any End User pressing buttons. SGP.33-3’s test cases verify that the eIM correctly orchestrates these operations across four different interfaces (ESep, ES9+’, ES11’, ESipa) and through multiple communication patterns. If the eIM gets any of these wrong, IoT devices in the field could be left with the wrong profile enabled, missed notifications, or an unmanageable eUICC.

Key takeaways:

  • Profile State Management Operations (PSMO) test cases cover five eUICC Package functions: Enable, Disable, Delete, ListProfileInfo, and GetRat: all sent via the ESep logical interface
  • eIM Configuration test cases cover four functions: AddEim, UpdateEim (including anti-replay counter updates), DeleteEim, and ListEim: managing the eIM-eUICC association itself
  • Notification handling is tested across ES9+’ (eIM-to-SM-DP+) with 9 nominal test sequences covering PIR, Install, Enable, Disable, and Delete notifications with various SM-DP+ address configurations
  • The ESipa interface (eIM-to-IPA) defines 11 functions for profile download orchestration, eIM Package transfer, and notification relay: though test sequences remain FFS as of v1.2
  • The only fully-defined behaviour test case in v1.2 is Profile Enable via eIM Package Retrieval mode, with four nominal sequences and error cases for wrong EID and eIM request errors
  • Most interface test cases reference SGP.23 and substitute the eIM for the LPAd role, reusing well-proven consumer eSIM test methodology

SGP.33-3 organises its test cases into two major sections: Interface Compliance Testing (Section 4) and Procedure / Behaviour Testing (Section 5). The interface tests verify correct message formats, protocol sequences, and error handling. The behaviour tests verify end-to-end procedures.

ESep: Profile State Management Operations (PSMO)

The ESep interface (eIM-to-eUICC) carries eUICC Packages containing PSMO commands. Five PSMO functions are tested:

Enable (4.2.1)

Requests the eUICC to enable a specific Operational Profile. Tests verify correct eUICC Package construction with Enable commands, conforming to SGP.22 sections 2.11.1.1, 2.11.1.1.3, 2.11.2.1, 3.3.1, and SGP.32 section 5.13.1. Test sequences FFS in v1.2.

Disable (4.2.2)

Requests the eUICC to disable a currently Enabled Profile. Conformance references: SGP.22 sections 2.11.1.1, 2.11.1.1.3, 2.11.2.1, 3.3.1, and SGP.32 section 5.13.2. Test sequences FFS in v1.2.

Delete (4.2.3)

Requests the eUICC to delete an installed Profile. Conformance references: SGP.22 sections 2.11.1.1, 2.11.1.1.3, 2.11.2.1, 3.3.1, and SGP.32 section 5.13.3. Test sequences FFS in v1.2.

ListProfileInfo (4.2.4)

Allows the eIM to retrieve the list of Profile information for installed Profiles, including their current state (Enabled/Disabled) and associated Profile Metadata. This is the eIM’s equivalent of the LPA’s GetProfilesInfo. Conformance references: SGP.22 sections 2.11.1.1, 2.11.1.1.3, 2.11.2.1, 3.3.1, and SGP.32 section 5.13.4. Test sequences FFS in v1.2.

GetRat (4.2.5)

Allows the eIM to retrieve the Rules Authorisation Table (RAT) from the eUICC: essential for knowing which profile management operations are permitted. Conformance references: SGP.22 sections 2.11.1.1, 2.11.1.1.3, 2.11.2.1, 3.3.1, and SGP.32 section 5.13.5. One test sequence is defined: Test Sequence #01 Nominal Case.

ESep: eIM Configuration Operations (eCO)

Four eIM Configuration functions manage the eIM-eUICC association:

AddEim (4.2.6)

Adds an Associated eIM to the eUICC by providing its eIM Configuration Data including the eimID. This is the eIM equivalent of the initial provisioning step where a remote manager registers itself with an IoT device’s eUICC. Test sequences FFS.

UpdateEim (4.2.7)

Updates eIM Configuration Data: specifically the public key or Certificate and the related anti-replay counter value of an Associated eIM with a given eimID, while keeping the same eimID. This function is critical for key rotation and security maintenance: when an eIM updates its credentials, it must increment the anti-replay counter to prevent replay attacks. Test sequences FFS.

DeleteEim (4.2.8)

Deletes an Associated eIM identified by its eimID from the eUICC. If the successfully deleted Associated eIM was the last available Associated eIM, the eUICC SHALL allow ES10b.AddInitialEim again: enabling a fresh association to be established. Test sequences FFS.

ListEim (4.2.9)

Requests the eUICC to provide a list of all currently configured Associated eIMs. This is an audit function allowing the eIM (or a new eIM) to discover what remote managers are currently associated with a given device. Test sequences FFS (one error case sequence defined but not detailed).

ES9+’: eIM-to-SM-DP+ Testing

The ES9+’ interface is the eIM’s channel to the SM-DP+ for profile delivery. All test cases reuse SGP.23 LPAd test sequences with the eIM playing the LPAd role:

InitiateAuthentication (4.2.10)

GetBoundProfilePackage (4.2.11)

AuthenticateClient (4.2.12)

HandleNotification (4.2.13)

CancelSession (4.2.14)

HTTPS (4.2.15)

ES11’: eIM-to-SM-DS Testing

InitiateAuthentication (4.2.16)

AuthenticateClient (4.2.17)

HTTPS (4.2.18)

ESipa: eIM-to-IPA Testing (FFS)

All 11 ESipa interface functions have test sequences marked FFS in v1.2, though the conformance requirements are documented:

Behaviour Testing: Profile Enable via eIM Package Retrieval

The only fully-defined behaviour test case in v1.2 is TC_eIM_ProfileEnable_TLS_eIM_Pkg_Retrieval (Section 5.2.1). It tests the end-to-end flow where:

  1. The IPA establishes a TLS connection to the eIM (PROC_TLS_INITIALIZATION_SERVER_AUTH_ESIPA)
  2. The IPA sends a GetEimPackage request to the eIM
  3. The eIM responds with the pending eUICC Package Request (containing the Enable PSMO)
  4. The IPA delivers the result via ProvideEimPackageResult (or HandleNotification)
  5. The eIM forwards notifications to the SM-DP+ via ES9+’ HandleNotification

Four nominal sequences are defined:

Error case sequences cover:

Each sequence includes conditional branching on O_S_TRID (whether a TransactionId is sent with eUICC Package Requests) : demonstrating how optional features drive test behaviour.

📋 Summary

← Previous: eIM Test Architecture: Simulated eIM and Reference IPA · 🏠 Home Next: eIM Security Testing: DTLS, Certificates, and Signed Packages →

Based on GSMA SGP.33-3 v1.2 (27 January 2025) : eUICC IoT Manager Test Specification, Sections 4–5

← Previous: eIM Test Architecture: Simulated eIM and Reference IPA Section Index Next: eIM Security Testing: DTLS, Certificates, and Signed Packages →