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 v3.x Unified RSP > Version Interoperability: How v2.x and v3.x Coexist
💡 Why this matters: The eSIM ecosystem won’t flip from v2.x to v3.x overnight. Billions of deployed v2.x eUICCs, thousands of v2.x SM-DP+ servers, and countless v2.x LPA implementations will remain in the field for years. A v3.x device must be able to talk to a v2.x SM-DP+ and SM-DS. A v3.x SM-DP+ must serve both v2.x and v3.x eUICCs. Version interoperability is not an optional feature: it’s the foundation that allows the whole ecosystem to evolve without breaking. SGP.22 v3.x bakes this in from day one with explicit version discovery, capability negotiation, and backward-compatible protocol design.
Key takeaways:
- Version interoperability uses RSP capability fields exchanged during Common Mutual Authentication (for device↔server) and X-Admin-Protocol HTTP header (for server↔server)
- The absence of
rspCapabilityfrom a server indicates a pre-v3 implementation : the LPA limits itself to v2.x data- The eUICC declares its
highestSvnandadditionalProfilePackageVersions, allowing the SM-DP+ to select the right profile package version- v3.x servers and devices MUST handle absent capability fields gracefully: this is the core backward-compatibility contract
- ES6 (Operator → eUICC) uses protocol/functions corresponding to the eUICC’s capabilities as declared in
EUICCInfo2- EShri (HRI Server) has no SVN negotiation: the HRI Server versions its services using different URLs
- v2.x devices and v3.x devices can coexist on the same SM-DP+ and SM-DS infrastructure
Section 2.11 of SGP.22 v3.1 defines the version interoperability framework. It distinguishes three communication patterns, each with its own negotiation mechanism:
For LPA/eUICC to RSP Server communication, the specification provides a built-in capability indication mechanism within Common Mutual Authentication (section 3.0.1):
rspCapability / lpaRspCapability / EuiccRspCapabilityrspCapability is absent from a server, it indicates a party implementing a version prior to version 3For server-to-server communication, the RSP Server acting as client indicates its SVN (Specification Version Number) using the HTTP header X-Admin-Protocol (section 6.2). This is the same mechanism used in v2.x: the receiving server checks the SVN and adapts its processing accordingly.
The LPAd determines the eUICC’s highestSvn using ES10b.GetEUICCInfo (section 5.7.8). The LPAd then uses ES10 functions and associated parameters in line with EuiccRspCapability for further communication with the eUICC. The eUICC doesn’t need to know the LPAd’s SVN: it simply operates according to the LPAd’s requests.
This is the most common backward-compatibility scenario: a new v3.x device connecting to an existing v2.x SM-DP+:
rspCapability in its response: because v2.x servers don’t know about this fieldrspCapability as meaning “this is a pre-v3 server”#SupportedFromV3.X.Y#)lpaRspCapability in its requests (the server ignores unknown fields per HTTP/JSON conventions)The result: the v3.x device operates exactly like a v2.x device when talking to a v2.x server.
The reverse scenario: a v3.x SM-DP+ must serve a v2.x eUICC:
EuiccRspCapability : v2.x eUICCs don’t know about this fieldrspCapability=v3.1 in its response, but the v2.x LPA ignores the unknown fieldThe result: the v3.x SM-DP+ degrades gracefully to v2.x behavior.
A v3.x eUICC declares profileVersion (the baseline, typically 2.x for backward compatibility) plus additionalProfilePackageVersions (e.g., [3.2]). The SM-DP+ selects:
This allows eUICC manufacturers to ship chips that support both v2.x and v3.x profile packages, with the SM-DP+ selecting the appropriate version at download time.
For post-install communication over ES6, the Operator SHALL use the protocol and functions corresponding to the capabilities communicated by the eUICC in EUICCInfo2 during Profile Download and Installation. This means:
The EShri interface (to the HRI Server) has no SVN negotiation. Instead, the HRI Server versions its services using different URLs. This is a pragmatic approach: the HRI Server’s web interface can evolve independently, and the Activation Code format determines which URL version the LPA accesses.
v3.x servers (SM-DP+, SM-DS) are required to:
rspCapability in their Common Mutual Authentication responsesEuiccRspCapability and lpaRspCapability from v2.x clients| Scenario | Behaviour |
|---|---|
| v2.x Device + v2.x Server | Standard v2.x operation (no change) |
| v3.x Device + v2.x Server | v3.x device operates in v2.x-compatible mode: no v3 features used |
| v2.x Device + v3.x Server | v3.x server degrades to v2.x compatible responses |
| v3.x Device + v3.x Server | Full v3.x feature set available, negotiated via capability exchange |
| v2.x eUICC + v3.x SM-DP+ downloading profile | SM-DP+ selects v2.x profile package; no RPM commands included |
| v3.x eUICC + v2.x SM-DP+ downloading profile | SM-DP+ selects v2.x profile package (only version it knows) |
rspCapability means “pre-v3” : both sides adapt accordinglyX-Admin-Protocol HTTP header for SVNhighestSvn and additionalProfilePackageVersions for profile package selectionBased on GSMA SGP.22 v3.1 (01 December 2023), Section 2.11: Overview of Version Interoperability, Section 3.0.1: Common Mutual Authentication Procedure, and Section 6.2: HTTP Header Fields
| ← Previous: Feature Support: Capability Negotiation in v3.x | Section Index | Next: Remote Profile Management: RPM Initiation, Download, and Execution → |