Consumer-eSIM versus IoT-eSIM: SGP.22, SGP.32 und weitere GSMA-Architekturen erklärt

Eine eSIM im Smartphone eines Reisenden und eine eSIM in einem entfernt installierten Stromzähler können beide herunterladbare Mobilfunkbetreiberprofile speichern. Sie verwenden jedoch nicht unbedingt dieselbe Provisioning-Architektur oder dasselbe Betriebsmodell.

Consumer-eSIM wurde für Geräte mit Bildschirm, Betriebssystem, Internetzugang und Menschen entwickelt, die eine Installation bestätigen können. IoT-Einsätze können Tausende unbeaufsichtigte Geräte mit begrenzter Energie, zeitweiliger Konnektivität, ohne Kamera und ohne praktikable Möglichkeit zum Scannen eines QR-Codes umfassen.

Die GSMA hat deshalb unterschiedliche Architekturen für Remote SIM Provisioning für verschiedene Umgebungen entwickelt:

• SGP.01 und SGP.02 definieren die etablierte M2M-Architektur;
• SGP.21 und SGP.22 definieren die Consumer-Architektur, die in Smartphones und anderen Verbrauchergeräten weit verbreitet ist;
• SGP.31 und SGP.32 definieren die neuere IoT-Architektur für Geräte mit eingeschränkter Netzkommunikation oder Benutzeroberfläche;
• SGP.41 definiert Architektur und Anforderungen für In-Factory Profile Provisioning, kurz IFPP.

Die Nummern sind wichtig, sollten aber nicht der Ausgangspunkt einer kommerziellen Entscheidung sein. Die richtige Architektur hängt vom Gerät, Einsatzmodell, verfügbarer Konnektivität, Nutzerbeteiligung, erwarteter Lebensdauer und der für die Profilverwaltung verantwortlichen Partei ab.

Wichtigste Erkenntnisse

• Consumer-, M2M- und IoT-eSIM-Architekturen lösen unterschiedliche betriebliche Probleme. Sie sind nicht bloß verschiedene Namen für denselben Ablauf.
• SGP.21 beschreibt Architektur und Anforderungen der Consumer-eSIM. SGP.22 liefert die entsprechende technische Spezifikation.
• SGP.31 beschreibt die neuere eSIM-IoT-Architektur und ihre Anforderungen. SGP.32 liefert die technische Implementierungsspezifikation.
• Consumer-eSIM verwendet üblicherweise einen SM-DP+, einen Local Profile Assistant und optional einen SM-DS. Nutzer oder Gerät wirken normalerweise direkt am Profil-Download mit.
• Die IoT-Architektur SGP.31/32 ergänzt einen IoT Profile Assistant und einen eSIM IoT Remote Manager für Geräte ohne geeignete lokale Benutzeroberfläche und mit eingeschränkter Konnektivität.
• Die IoT-Architektur kann SM-DP+-Infrastruktur verwenden. Das bedeutet aber nicht, dass jeder Consumer-eSIM-Dienst automatisch für SGP.32-Flotten geeignet ist.
• Die etablierte M2M-Architektur nutzt Komponenten wie SM-DP und SM-SR und wird stark durch Server gesteuert. Für bestehende Fahrzeug- und Industrieeinsätze bleibt sie relevant.
• SGP.32 rüstet nicht jedes eingesetzte M2M- oder Consumer-Gerät remote auf. eUICC, Gerätesoftware, Kommunikationsweg und Managementsysteme müssen die Architektur unterstützen.
• Eine Flotte muss während einer langen Migration möglicherweise mehrere Architekturen unterstützen.
• Eine gute kommerzielle Plattform trennt Profil-Provisioning, Netzkonnektivität und Flotten-Lebenszyklusmanagement, statt alles als eine Funktion namens „eSIM“ zu behandeln.

Warum benötigt eSIM mehr als eine Architektur?

Remote SIM Provisioning muss unter den tatsächlichen Bedingungen des Zielgeräts funktionieren.

Ein Smartphone hat normalerweise:

• einen Bildschirm und ein Einstellungsmenü;
• einen Nutzer, der zustimmen kann;
• WLAN oder eine andere Internetverbindung;
• ein Betriebssystem mit eSIM-Schnittstelle;
• ausreichend Energie und Rechenleistung für eine interaktive Installation;
• eine Kamera, Anwendung oder Funktion zum Öffnen von Links.

Ein vernetzter Sensor besitzt möglicherweise keine dieser Eigenschaften. Er kann unterirdisch, in einer versiegelten Maschine oder als Teil eines länderübergreifenden Einsatzes installiert sein. Er wacht womöglich nur periodisch auf, kommuniziert über eine eingeschränkte Funktechnologie und muss zehn Jahre ohne manuelle Betreuung funktionieren.

Ein Fahrzeughersteller hat wiederum andere Anforderungen. Fahrzeuge können in einem Land produziert, weltweit ausgeliefert, verschiedenen Dienstanbietern zugewiesen und während einer langen Lebensdauer für Notrufe, Diagnose und vernetzte Dienste genutzt werden.

Eine einzige Architektur lässt sich nicht für all diese Bedingungen gleichermaßen optimieren.

GSMA-Spezifikationen im Überblick

Diese Tabelle ist bewusst vereinfacht. Jede Spezifikation enthält detaillierte Rollen, Schnittstellen, Sicherheitsverfahren und Lebenszyklusfunktionen. Unternehmen sollten die geltende Version und Implementierung mit ihren eUICC-, Geräte-, Connectivity- und Plattformlieferanten bestätigen.

Was bedeuten die GSMA-Dokumentnummern?

Die eSIM-Standards der GSMA sind in zusammengehörige Dokumente aufgeteilt.

Dokumente zu Architektur und Anforderungen

Sie beschreiben Rollen, Anwendungsfälle, Grundsätze und Anforderungen einer Architektur.

• SGP.01 behandelt die M2M-Architektur und ihre Anforderungen.
• SGP.21 behandelt die Consumer-Architektur und ihre Anforderungen.
• SGP.31 behandelt die IoT-Architektur und ihre Anforderungen.
• SGP.41 behandelt Architektur und Anforderungen des In-Factory Profile Provisioning.

Technische Spezifikationen

Sie definieren die detaillierten technischen Verfahren, Schnittstellen, Nachrichten und Sicherheitsfunktionen für interoperable Implementierungen.

• SGP.02 ist die technische Spezifikation der M2M-Architektur.
• SGP.22 ist die technische Spezifikation für Consumer Remote SIM Provisioning.
• SGP.32 ist die technische Spezifikation der eSIM-IoT-Architektur.

Die Kurzformen „SGP.22-eSIM“ oder „SGP.32-eSIM“ sind praktisch, beschreiben aber kein anderes physisches SIM-Format. Die Dokumente beschreiben Remote-Provisioning-Architekturen und technisches Verhalten rund um eine kompatible eUICC und ein Profil-Ökosystem.

So funktioniert die Consumer-eSIM-Architektur

Die Consumer-Architektur ist Smartphone-Nutzern am vertrautesten. Ein Kunde kauft einen Tarif und fügt ihn über Geräteeinstellungen, QR-Code, Betreiber-App, Benachrichtigung, Aktivierungslink oder einen vom Betriebssystem unterstützten Transferprozess hinzu.

SGP.21 definiert Architektur und Anforderungen. SGP.22 enthält die technische Spezifikation.

Zentrale Consumer-Komponenten

eUICC

Die eUICC ist die geschützte Komponente zum Speichern und Verwalten von Betreiberprofilen. Sie kann mehrere Profile speichern; das Gerätedesign bestimmt jedoch, wie viele gleichzeitig aktiviert sein können.

eSIM-Profil

Das Profil enthält die Betreiber-Subskription und geschützten Zugangsdaten für Netzauthentisierung und Dienstkonfiguration.

SM-DP+

Der Subscription Manager Data Preparation Plus bereitet Profile vor, schützt sie und liefert sie an berechtigte Consumer-Geräte.

Local Profile Assistant

Der Local Profile Assistant, kurz LPA, arbeitet auf der Geräteseite. Er unterstützt Profil-Download und -Verwaltung und vermittelt zwischen SM-DP+ und eUICC.

Im Smartphone ist der LPA normalerweise mit den Mobilfunkeinstellungen des Betriebssystems und den sicheren eSIM-Funktionen integriert. Der Nutzer sieht möglicherweise eine Marken-App oder einen Shop, doch geschützte Profiloperationen bleiben über die Geräteplattform kontrolliert.

SM-DS

Der optionale Subscription Manager Discovery Service kann dem Gerät helfen, ein verfügbares Profil zu entdecken. Er ermöglicht Abläufe, die nicht vollständig von der manuellen Eingabe einer SM-DP+-Adresse oder dem Scannen eines klassischen QR-Codes abhängen.

Ein typischer Consumer-Provisioning-Ablauf

1. Der Kunde kauft oder bestellt einen Mobilfunktarif.
2. Betreiber oder Anbieter bereitet über den SM-DP+ ein Profil vor oder weist es zu.
3. Das Gerät erhält Aktivierungsinformationen oder entdeckt das verfügbare Profil.
4. Der Nutzer bestätigt die Installation, soweit erforderlich.
5. Der LPA stellt die erforderliche Interaktion mit dem SM-DP+ her.
6. Das Profil wird sicher heruntergeladen und auf der eUICC installiert.
7. Nutzer oder System aktiviert das Profil.
8. Das Modem verwendet es zur Registrierung in einem zulässigen Netz.

Die Consumer-Architektur funktioniert gut, wenn ein Nutzer auf Aufforderungen reagieren, zustimmen, die passende Leitung auswählen und Internetzugang für den Profil-Download bereitstellen kann.

Wo Consumer-eSIM am besten passt

• Reise-eSIM für Smartphones;
• primäre Mobilfunkverträge;
• Tablets und Laptops mit geeigneter eSIM-Schnittstelle;
• mit einem Verbraucherkonto gekoppelte Smartwatches;
• Anwendungen, bei denen der Gerätebesitzer aktiv einen Anbieter auswählt;
• kleinere Gerätebestände mit zugänglicher Oberfläche und individueller Verwaltung.

Stärken der Consumer-Architektur

• ausgereifte Unterstützung in vielen Smartphones und Betriebssystemen;
• vertraute QR-Code- und digitale Aktivierungsabläufe;
• Kundenwahl und Zustimmung als Teil des Betriebsmodells;
• gemeinsames SM-DP+-Ökosystem;
• direkter Einzelhandel und appgestützter Vertrieb;
• mehrere gespeicherte Subskriptionen auf kompatiblen Geräten.

Einschränkungen für IoT-Flotten

Das Consumer-Modell kann schwierig werden, wenn Geräte unbeaufsichtigt sind oder keine geeignete Benutzeroberfläche haben.

Ein Flottenbetreiber kann möglicherweise nicht:

• für jedes Gerät einen QR-Code scannen;
• auf jedem Bildschirm eine Aufforderung bestätigen;
• jedes Gerät während des Provisionings durchgehend verbunden halten;
• nach einem fehlgeschlagenen Download physisch auf ein Gerät zugreifen;
• eine Consumer-Betriebssystemoberfläche voraussetzen;
• Tausende Profilwechsel manuell koordinieren.

Das bedeutet nicht, dass die Consumer-Architektur niemals in einem IoT-ähnlichen Gerät eingesetzt werden kann. Ein Router mit Bildschirm, Weboberfläche und überschaubarer Flottengröße kann sie nutzen. Die betriebliche Prüfung ist wichtiger als die Produktbezeichnung.

So funktioniert die etablierte M2M-eSIM-Architektur

Die M2M-Architektur wurde für remote verwaltete Geräte entwickelt, insbesondere in Fahrzeugen und industriellen Umgebungen. Ihre wichtigsten GSMA-Dokumente sind SGP.01 und SGP.02.

Anders als beim Consumer-Modell wird nicht vorausgesetzt, dass ein Endnutzer einen Tarif auswählt und mit einem LPA auf dem Gerät interagiert.

Zentrale M2M-Komponenten

SM-DP

Die Funktion Subscription Manager Data Preparation bereitet Betreiberprofile für die Auslieferung vor und schützt sie.

SM-SR

Die Funktion Subscription Manager Secure Routing verwaltet die sichere Kommunikation mit der eUICC und unterstützt remote ausgeführte Profil-Lebenszyklusoperationen.

M2M-eUICC

Die eUICC unterstützt die relevanten M2M-Remote-Provisioning-Verfahren und empfängt Befehle über diese Architektur.

Allgemeines M2M-Betriebsmodell

Die Architektur wird stark durch Server gesteuert. Managementsysteme initiieren Profil-Download, Aktivierung, Deaktivierung und Löschung, ohne von einem Verbraucher neben dem Gerät abhängig zu sein.

Das passt zu entfernt installierter Ausrüstung, die über Unternehmensvereinbarungen kontrolliert wird. Seit vielen Jahren unterstützt dieses Modell bedeutende Connected-Car- und Industrieeinsätze.

Stärken der M2M-Architektur

• für zentral kontrollierte Geräte entwickelt;
• keine Consumer-Benutzeroberfläche erforderlich;
• in langlebigen Fahrzeug- und Industrieprogrammen etabliert;
• Unterstützung für Remote-Lebenszyklusmanagement;
• passend für streng geregelte Unternehmenslieferketten.

Betriebliche Herausforderungen

Der SM-SR spielt im M2M-Modell eine zentrale Rolle. Die kommerziellen und technischen Beziehungen rund um diese Komponente können einen Anbieterwechsel komplizierter machen, als Käufer zunächst erwarten.

Mögliche Herausforderungen sind:

• komplexe Integration zwischen mehreren Parteien;
• lange Onboarding- und Zertifizierungsprogramme;
• Abhängigkeit von der gewählten Subscription-Management-Kette;
• komplizierte Eigentums- und Migrationsregelungen;
• begrenzte Eignung für kleinere oder flexiblere Einsätze;
• kommerzielle Hürden beim Wechsel des Connectivity-Lieferanten.

Die etablierte M2M-Architektur bleibt für darauf ausgelegte Einsätze gültig. Ein neues IoT-Projekt sollte sie dennoch mit SGP.31/32 vergleichen, statt „M2M-eSIM“ als einzige remote verwaltbare Option anzusehen.

So funktioniert die IoT-Architektur SGP.31/32

Die GSMA entwickelte die neuere IoT-Architektur für eUICCs in IoT-Geräten mit eingeschränkter Netzkommunikation und/oder eingeschränkter Benutzeroberfläche.

SGP.31 definiert Architektur und Anforderungen. SGP.32 beschreibt die technischen Verfahren für Remote Provisioning und Management, die eUICC-Architektur, Schnittstellen und Sicherheitsfunktionen.

Das Design verbindet nützliche Prinzipien früherer Architekturen:

• flottengeeignetes Remote-Management;
• Nutzung von SM-DP+-Infrastruktur aus dem Consumer-Ökosystem;
• geräteseitige Funktionen für eingeschränkte IoT-Ausrüstung;
• Verwaltung ohne eine Person, die einen lokalen Bildschirm bedient.

Zentrale IoT-Komponenten

SM-DP+

Die IoT-Architektur nutzt einen SM-DP+ für Profilvorbereitung und -bereitstellung. Das kann den Bedarf an einem vollständig separaten Ökosystem zur Profilvorbereitung reduzieren.

Es bedeutet nicht, dass jede SM-DP+-Integration automatisch einen vollständigen SGP.32-Dienst bietet. IoT-Gerät, eUICC, Managementrollen, Schnittstellen und Sicherheitsverfahren müssen die entsprechende Architektur unterstützen.

IoT Profile Assistant

Der IoT Profile Assistant, kurz IPA, unterstützt Profiloperationen auf der Geräteseite der IoT-Architektur.

Die Funktion kann an unterschiedlichen Stellen implementiert sein:

• IPAd, wenn der IPA im IoT-Gerät implementiert ist;
• IPAe, wenn der IPA in der eUICC implementiert ist.

Die passende Variante hängt von Geräteressourcen, Softwarekontrolle, eUICC-Implementierung und Einsatzdesign ab.

eSIM IoT Remote Manager

Der eSIM IoT Remote Manager, kurz eIM, unterstützt Remote-Management-Interaktionen mit IoT-Geräten und ihren IPAs.

Der eIM ermöglicht einem autorisierten Flottenmanagementprozess, Profil-Lebenszyklusoperationen auszulösen und zu koordinieren, ohne auf jedem Gerät einen QR-Code scannen zu müssen. Seine signierten Pakete können Profil-Download-Auslöser, Profilzustandsverwaltung, eIM-Konfigurationsoperationen, Anforderungen von IPA- oder eUICC-Daten und Bestätigungen unterstützen.

Der eIM ist nicht mit einem SM-DP+ zu verwechseln. Der eIM unterstützt Remote-Orchestrierung und -Management, während der SM-DP+ Profile vorbereitet und liefert.

Ein eIM ist zentral für remote orchestrierte Flottenoperationen. Dennoch muss nicht jeder SGP.32-Profil-Download mit einer eIM-Anweisung beginnen. Die Spezifikation unterstützt auch IPA-initiierte Verfahren, einschließlich der Nutzung konfigurierter SM-DP+-Informationen und implementierter Discovery-Mechanismen.

IoT-eUICC

Die eUICC muss die relevante IoT-Architektur und ihre technischen Verfahren unterstützen. Ein Gerät mit eingebettetem Secure Element ist nicht automatisch SGP.32-kompatibel.

Ein vereinfachter remote verwalteter SGP.32-Ablauf

1. Ein Unternehmens- oder IoT-Serviceprozess identifiziert ein Gerät, das eine Profiloperation benötigt.
2. Die autorisierte Managementumgebung kommuniziert die erforderliche Aktion über einen eIM.
3. Der IPA des Geräts beteiligt sich am Verfahren.
4. Das Profil wird über ein unterstütztes direktes oder indirektes Downloadverfahren von einem SM-DP+ bezogen.
5. Das Profil wird auf der IoT-eUICC installiert und verwaltet.
6. Das Gerät nutzt das ausgewählte Profil zur Verbindung gemäß den geltenden Netz- und Dienstrichtlinien.

Beim direkten Download kommuniziert der IPA mit dem SM-DP+. Beim indirekten Download beteiligt sich der eIM am Bezug und an der Übertragung des geschützten Profilpakets über die definierten Schnittstellen. SGP.32 umfasst außerdem Discovery-, Profil-Rollback-, Fallback-Profil- und Fehlerbehandlungsmechanismen.

Die genaue Reihenfolge hängt von Anwendungsfall, verfügbarer Konnektivität, IPA-Implementierung und technischer Konfiguration ab. Der geschäftliche Nutzen liegt darin, die Operation auf Flottenebene ohne Consumer-Oberfläche auf jedem Gerät verwalten zu können.

Was bedeutet „eingeschränktes IoT-Gerät“?

Einschränkungen können mehr betreffen als die physische Größe.

Einschränkungen der Benutzeroberfläche

Das Gerät hat möglicherweise:

• kein Display;
• keine Tastatur oder keinen Touchscreen;
• keine Kamera für QR-Codes;
• keinen lokalen Bediener;
• ein versiegeltes oder unzugängliches Gehäuse.

Einschränkungen der Netzkommunikation

Das Gerät hat möglicherweise:

• nur zeitweise Konnektivität;
• begrenzte Bandbreite;
• hohe Latenz;
• eingeschränkte Protokolle;
• lange Schlafintervalle;
• energiesparende Weitverkehrskonnektivität;
• Abdeckung nur zu bestimmten Zeitpunkten seines Betriebszyklus.

Ressourcenbeschränkungen

Das Gerät kann außerdem begrenzt sein hinsichtlich:

• Rechenleistung;
• Speicher;
• Energiebudget;
• möglicher Anwendungskomplexität;
• Gelegenheiten für Firmware-Updates.

Nicht jedes eingeschränkte Gerät hat all diese Eigenschaften. Die Architektur muss anhand der tatsächlichen Hardware und Betriebsbedingungen bewertet werden.

Consumer SGP.22 versus IoT SGP.32

Die Tabelle entscheidet nicht jeden Grenzfall. Manche Router verhalten sich wie Consumer-Geräte. Manche Industrieanlagen besitzen ein leistungsfähiges Betriebssystem und eine lokale Oberfläche. Manche Wearables werden über ein gekoppeltes Telefon statt direkt verwaltet.

Die Architekturauswahl sollte dem tatsächlichen Lebenszyklus folgen, nicht einer Marketingkategorie.

SGP.32 versus etablierte M2M-Architektur

SGP.32 wird oft als Nachfolger des früheren M2M-Modells beschrieben. Das zeigt die Entwicklungsrichtung, kann betrieblich aber irreführend sein.

Bestehende M2M-Einsätze verschwinden nicht sofort. Fahrzeuge, Zähler und Industriegeräte können zehn Jahre oder länger aktiv bleiben. Ihre eUICCs und Software wurden für SGP.01/02 entwickelt und lassen sich nicht unbedingt remote auf eine andere Architektur umstellen.

Wesentliche Unterschiede

Was SGP.32 verbessern kann

Für passende neue Einsätze kann die Architektur bieten:

• einen besser skalierbaren Weg für eingeschränkte IoT-Geräte;
• geringere Abhängigkeit von Consumer-Interaktion;
• Nutzung des breiteren SM-DP+-Ökosystems;
• Orchestrierung auf Flottenebene durch eIM-Funktionen;
• mehr Flexibilität beim Aufbau von Connectivity-Lieferketten;
• bessere Abstimmung zwischen Geräteherstellern, IoT-Serviceanbietern und Connectivity-Anbietern.

Das sind architektonische Möglichkeiten, keine garantierten kommerziellen Ergebnisse. Vertragsgestaltung, Implementierungsqualität, Interoperabilität und Ausstiegsrechte bleiben entscheidend.

Was ist In-Factory Profile Provisioning?

Einige Geräte benötigen bereits während Fertigung, Tests oder Erstdistribution ein passendes Profil. SGP.41 der GSMA definiert Architektur und Anforderungen für In-Factory Profile Provisioning, kurz IFPP.

IFPP betrifft einen anderen Abschnitt als die normale Profilverwaltung im Feld. Es kann Herstellern helfen, Konnektivität während der Produktion bereitzustellen, statt eine separat personalisierte SIM-Karte einzusetzen oder den ersten Profil-Download erst nach dem Einsatz des fertigen Geräts zu verlangen.

Mögliche Vorteile sind:

• vereinfachte Fertigungsvarianten;
• automatisierte Profilzuweisung während der Produktion;
• frühere Konnektivitätstests;
• weniger physische SIM-Handhabung;
• Unterstützung für Geräte, die unmittelbar nach dem Einschalten Konnektivität benötigen.

Werkseitiges Provisioning sollte nicht als vollständige Lebenszyklusstrategie behandelt werden. Das Gerät kann nach Verlassen der Fabrik weiterhin Remote-Profil- und Connectivity-Management benötigen.

Architekturauswahl nach Anwendungsfall

Reise-eSIM für Smartphones

Wahrscheinliche Wahl: Consumer-Architektur.

Der Kunde besitzt ein kompatibles Telefon, kann der Installation zustimmen und einen QR-Code, Aktivierungslink oder eine App verwenden. Kommerzielle Prioritäten sind sofortige Bereitstellung, klare Anleitungen, Abdeckung, Preise und Support.

Unternehmensverwaltete Mitarbeiter-Smartphones

Wahrscheinliche Wahl: Consumer-Architektur kombiniert mit Enterprise-Gerätemanagement und Betreiberprozessen.

Die Telefone bleiben Consumer-Geräte, auch wenn ein Unternehmen sie kauft und verwaltet. Unternehmenskontrollen machen sie nicht automatisch zu SGP.32-IoT-Geräten.

Verwaltete Router

Mögliche Wahl: Consumer- oder IoT-Architektur, abhängig vom Router.

Ein Router mit Weboberfläche und zugänglichem Installationsprozess kann Consumer-eSIM nutzen. Eine große unbeaufsichtigte Flotte kann von einer IoT-Architektur profitieren. Käufer müssen die konkrete Unterstützung von Modem, eUICC, Firmware und Management prüfen, statt „eSIM-ready“ als ausreichend anzusehen.

Fahrzeugtelematik

Mögliche Wahl: etabliertes M2M für bestehende Programme, SGP.32 für geeignete Neuentwicklungen.

Fahrzeugprogramme haben lange Lebenszyklen, Sicherheitsanforderungen und komplexe Lieferketten. Eine Migration erfordert sorgfältige Hardware- und Plattformplanung.

Intelligente Zähler und Umweltsensoren

Wahrscheinliche Wahl für neue eingeschränkte Gerätedesigns: IoT-Architektur.

Diese Geräte besitzen möglicherweise keine Bildschirme, arbeiten mit begrenzter Energie und bleiben jahrelang im Einsatz. Remote-Management auf Flottenebene ist passender als die individuelle Installation per QR-Code.

Zahlungsterminals und Kioske

Mögliche Wahl: Consumer- oder IoT-Architektur.

Die Entscheidung hängt davon ab, ob das Terminal eine kontrollierte lokale Oberfläche bereitstellen kann, ob Außendienstpersonal verfügbar ist und wie viele Geräte koordinierte Profilwechsel benötigen.

Bereits im Werk vernetzte Geräte

Mögliche Wahl: IFPP für das initiale Provisioning kombiniert mit M2M- oder IoT-Lebenszyklusmanagement.

Der Fabrikprozess kann die erste Konnektivität herstellen, während die eingesetzte Architektur spätere Änderungen bestimmt.

Fragen vor der Wahl von SGP.22 oder SGP.32

1. Hat das Gerät eine nutzbare lokale Oberfläche?
2. Wird beim initialen Provisioning eine Person anwesend sein?
3. Kann das Gerät Consumer-Aktivierungsinformationen scannen, öffnen oder empfangen?
4. Ist vor Installation des neuen Profils zuverlässiger Internetzugang verfügbar?
5. Wie viele Geräte müssen verwaltet werden?
6. Erfolgen Profilwechsel individuell oder flottenweit?
7. Wie lange bleiben die Geräte im Einsatz?
8. Können Gerätefirmware und eUICC die erforderliche Architektur unterstützen?
9. Ist der IPA im Gerät oder in der eUICC implementiert?
10. Wer betreibt oder liefert den eIM?
11. Welche SM-DP+-Plattformen und Profilanbieter sind kompatibel?
12. Welche Bootstrap- oder Fallback-Konnektivität ist verfügbar?
13. Was passiert bei einem unterbrochenen Profil-Download?
14. Kann das Gerät ohne physischen Zugriff wieder funktionsfähig werden?
15. Welche Partei darf Profilwechsel beauftragen und genehmigen?
16. Wie wird die Flotte zu einem anderen Connectivity-Anbieter migriert?
17. Welche Zertifikate, Konformitätsverfahren und Produktionskontrollen gelten?
18. Welche Lebenszyklusereignisse kann die Managementplattform tatsächlich beobachten?

Warum Bootstrap-Konnektivität wichtig ist

Ein Remote-Profil-Download benötigt einen Kommunikationsweg. Ein neues Profil kann dem Gerät erst nach seinem Download helfen, einen Provisioning-Dienst zu kontaktieren.

Ein IoT-Design braucht deshalb eine Strategie für die initiale Konnektivität. Abhängig von der Implementierung kann sie umfassen:

• ein initiales oder Bootstrap-Profil;
• werkseitige oder lokale Konnektivität;
• WLAN oder kabelgebundenen Zugang;
• ein anderes aktives Profil;
• ein kontrolliertes Inbetriebnahmenetz;
• im Bereitstellungsprozess des Geräts bereitgestellte Konnektivität.

Die Bootstrap-Lösung muss hinsichtlich Abdeckung, Kosten, Lebensdauer und Lieferantenabhängigkeit bewertet werden. Ein Profil, das zu früh abläuft oder nur im Herstellungsland funktioniert, kann späteres Provisioning verhindern.

Auch Ausfallsicherheit ist wichtig. Scheitert der Download oder die Verbindung des Zielprofils, muss das Gerät möglicherweise einen funktionierenden Fallback-Weg behalten, damit eine weitere Operation versucht werden kann.

Gerätekompatibilität erfordert mehr als ein eSIM-Logo

Ein „eSIM-fähiges“ Gerät unterstützt möglicherweise nur eine bestimmte Architektur oder einen bestimmten Ablauf.

Für einen zuverlässigen Einsatz prüfen Sie:

• eUICC-Hardware und Betriebssystemunterstützung;
• unterstützte GSMA-Architektur und Spezifikationsversion;
• LPA- oder IPA-Implementierung;
• erforderliche eIM-Kompatibilität;
• SM-DP+-Interoperabilität;
• Modem- und Funkbandunterstützung;
• Bootstrap- und Fallback-Verhalten;
• Remote-Firmware-Update-Fähigkeit;
• Grenzen für Profilspeicherung und -aktivierung;
• Fehlerbehebung nach Strom- oder Netzunterbrechung;
• Konformitäts- und Zertifizierungsnachweise.

Ein Consumer-eSIM-Router, der einen QR-Code akzeptiert, ist nicht automatisch ein SGP.32-Router. Eine eingebettete eUICC lässt sich nicht automatisch über jeden Remote-Provisioning-Dienst verwalten.

Betriebliche Anforderungen an eine IoT-eSIM-Plattform

Profil-Download ist nur ein Teil des IoT-Flottenmanagements.

Eine praxistaugliche Plattform benötigt möglicherweise:

• Geräte- und eUICC-Inventar;
• Zuordnung zwischen Gerät, EID, Profil, ICCID und Kundenanlage;
• Massenoperationen mit Freigabekontrollen;
• Zeitplanung und gestaffelte Rollouts;
• Status, Wiederholungen und Fehlerkategorisierung;
• Connectivity-Richtlinien und Netztransparenz;
• Nutzungsüberwachung und Warnungen;
• Sperrung und Reaktivierung;
• Audit-Historie;
• Zugriffsrollen für Kundenorganisationen;
• API- und Webhook-Integration;
• Bootstrap- und Fallback-Management;
• sichere Lieferantenübergabe und Ausstiegsverfahren.

Das System sollte Profilzustand und Netzzustand unterscheiden. „Profil aktiviert“ beweist nicht, dass ein Sensor sich in ein Netz eingebucht, seinen Anwendungsendpunkt erreicht oder nutzbare Daten geliefert hat.

Kommerzielle und vertragliche Fragen

Architekturentscheidungen schaffen langfristige kommerzielle Abhängigkeiten.

Verträge sollten klären:

• Eigentum an eUICCs, Profilen und Kennungen;
• Kontrolle über eIM, SM-DP+, SM-SR oder zugehörige Managementkonten;
• Rechte zum Umzug von Profilen oder Geräten zu einem anderen Anbieter;
• Verantwortung für Bootstrap-Konnektivität;
• Service Levels für Provisioning-Operationen;
• Unterstützung eingesetzter Spezifikationsversionen;
• Verantwortung für Zertifikatserneuerung und -lebenszyklus;
• Datenzugriff und Aufbewahrung;
• Incident-Eskalation;
• Kosten für Downloads, Wechsel, Aktivierung, Speicherung und API-Nutzung;
• Umgang mit Geräten nach Vertragsende.

Der niedrigste Megabytepreis kann bedeutungslos werden, wenn die Flotte den Anbieter nicht wechseln oder sich von einem fehlgeschlagenen Profilwechsel erholen kann.

Migration und Koexistenz

Große Organisationen sollten mit mehreren parallel betriebenen Architekturen rechnen.

Ein Unternehmen kann gleichzeitig betreiben:

• ältere Fahrzeuggeräte mit SGP.01/02;
• Smartphones mit SGP.21/22;
• neue Sensoren für SGP.31/32;
• werkseitig provisionierte Geräte, die über IFPP in Betrieb gehen.

Alle Geräte auf einmal zu ersetzen ist selten wirtschaftlich. Die Managementebene sollte deshalb für jede Gerätegruppe ein klares Inventar der Architektur, eUICC-Fähigkeiten, Profilanbieter und verfügbaren Lebenszyklusoperationen führen.

Ein sinnvoller Migrationsansatz

1. Segmentieren Sie den Bestand nach Gerät, Modem, eUICC und Architektur.
2. Bestimmen Sie, welche Geräte ein neues Provisioning-Verfahren unterstützen können und welche ersetzt werden müssen.
3. Definieren Sie Anforderungen an künftige Geräte unter ausdrücklicher Angabe der GSMA-Zielarchitektur.
4. Testen Sie die Interoperabilität der tatsächlichen Kombination aus eUICC, IPA, eIM und SM-DP+.
5. Prüfen Sie Bootstrap-, Rollback- und Verbindungsverlustszenarien.
6. Führen Sie einen kontrollierten Piloten in repräsentativen Ländern und Netzen durch.
7. Migrieren Sie schrittweise mit messbaren Erfolgskriterien.
8. Behalten Sie einen Betriebsweg für Altgeräte während ihrer verbleibenden Lebensdauer bei.

Eine Architekturmigration sollte niemals mit einem massenhaften Profilwechsel ohne getesteten Wiederherstellungsweg beginnen.

Häufige Missverständnisse

„Alle eSIMs funktionieren mit SGP.22 und SGP.32“

Nein. Kompatibilität hängt von eUICC, Gerätesoftware, Provisioning-Komponenten und unterstützter Architektur ab.

„SGP.32 ist nur Consumer-eSIM ohne Bildschirm“

Nein. Es führt ein IoT-spezifisches Managementmodell mit IPA und eIM für eingeschränkte Geräte und Flottenoperationen ein.

„SGP.32 ersetzt sofort jede M2M-eSIM“

Nein. Bestehende M2M-Geräte können noch viele Jahre funktionieren und möglicherweise nicht auf die neue Architektur aufgerüstet werden.

„Mit einem SM-DP+ unterstützt die gesamte Lösung SGP.32“

Nein. Der SM-DP+ ist ein Teil der Architektur. Gerät, eUICC, IPA, eIM und Schnittstellen müssen die benötigten Verfahren ebenfalls unterstützen.

„IoT-eSIM liefert automatisch Multi-Netz-Abdeckung“

Nein. Remote Provisioning verändert die Profilverwaltung. Netzzugang hängt weiterhin vom kommerziellen Profil, Betreiber und Roamingvereinbarungen ab.

„Eine Flotte kann den Anbieter immer remote wechseln“

Nur wenn das vollständige technische und vertragliche Design dies zulässt. Bootstrap-Konnektivität, Autorisierung, Managementkontrolle, kompatible Profile und Wiederherstellungsverfahren sind entscheidend.

„Jeder Router sollte SGP.32 verwenden“

Nicht unbedingt. Ein vom Nutzer verwalteter Router kann gut mit Consumer-Architektur funktionieren. Die richtige Wahl hängt von Flottengröße, Zugänglichkeit und Lebenszyklus ab.

Die Rolle von SIM24.biz bei der Architekturentscheidung

SIM24.biz unterstützt Unternehmen beim Aufbau eigener Markenangebote für Consumer-Connectivity, physische SIM und IoT.

Der kommerzielle Ausgangspunkt sollte der Produkt- und Gerätelebenszyklus sein, nicht eine isoliert ausgewählte Spezifikationsnummer. Eine Reisemarke für Smartphones hat andere Provisioning-Anforderungen als ein Hersteller, der versiegelte Tracker in mehreren Ländern einsetzt.

SIM24.biz kann Partnern helfen, das benötigte Connectivity-, Plattform- und Betriebsmodell zu strukturieren. Die konkrete Unterstützung einer GSMA-Architektur, eines eUICC-Typs, einer Provisioning-Komponente oder Remote-Lebenszyklusfunktion muss für die ausgewählte Implementierung und Lieferantenkombination bestätigt werden. Zum Zeitpunkt dieses Entwurfs wird nicht öffentlich behauptet, dass SIM24.biz selbst einen eIM, SM-DP+, SM-SR oder eine zertifizierte SGP.32-Plattform betreibt.

Diese Unterscheidung schützt beide Seiten. Sie verhindert das Versprechen, ein Consumer-QR-Code-Produkt biete vollständiges IoT-Flottenmanagement oder eine IoT-eUICC könne ohne Kompatibilitätsprüfung jede Profilplattform verwenden.

Fazit

Consumer-eSIM und IoT-eSIM beruhen auf derselben Grundidee: Mobilfunkbetreiberprofile können sicher auf einer kompatiblen eUICC provisioniert werden. Ihre Betriebsumgebungen unterscheiden sich jedoch grundlegend.

Die Consumer-Architektur SGP.21/22 setzt ein Gerät voraus, das an einem interaktiven Profilbezugsprozess teilnehmen kann. Sie nutzt Komponenten wie SM-DP+, LPA und optional SM-DS und passt gut zu Smartphones, Tablets und nutzerbedienten Geräten.

Die IoT-Architektur SGP.31/32 ist für Geräte mit eingeschränkter Konnektivität, Benutzeroberfläche oder beidem ausgelegt. Sie führt IPA und eIM für flottenorientiertes Remote-Management ein und nutzt dabei SM-DP+-Profilinfrastruktur.

Die M2M-Architektur SGP.01/02 bleibt für etablierte Fahrzeug- und Industrieeinsätze wichtig. SGP.41 ergänzt eine separate Option zur Profilbereitstellung während der Fertigung.

Keiner dieser Standards ersetzt Gerätetests, Bootstrap-Konnektivität, Netzvereinbarungen, Flottenbetrieb oder klare Lieferantenverträge. Die richtige Architektur kann den tatsächlichen Gerätebestand während seiner gesamten vorgesehenen Lebensdauer provisionieren, verbinden, wiederherstellen und migrieren.

Häufig gestellte Fragen

Was ist der wichtigste Unterschied zwischen SGP.22 und SGP.32?

SGP.22 ist die technische Spezifikation der Consumer-eSIM-Architektur, die häufig in interaktiven Geräten wie Smartphones eingesetzt wird. SGP.32 ist die technische Spezifikation der IoT-Architektur für IoT-Geräte mit eingeschränkter Netzkommunikation oder Benutzeroberfläche und für Flottenmanagement.

Was unterscheidet SGP.21 von SGP.22?

SGP.21 definiert Consumer-Architektur und Anforderungen. SGP.22 liefert die detaillierte technische Spezifikation zur Implementierung dieser Architektur.

Was unterscheidet SGP.31 von SGP.32?

SGP.31 definiert Architektur und Anforderungen für eSIM-Provisioning in eingeschränkten IoT-Geräten. SGP.32 spezifiziert die detaillierten technischen Verfahren, Schnittstellen, eUICC-Architektur und Sicherheitsfunktionen.

Was sind IPA und eIM?

Der IoT Profile Assistant ist die geräteseitige Funktion für Profiloperationen in der SGP.31/32-Architektur. Er kann als IPAd im Gerät oder als IPAe in der eUICC liegen. Der eSIM IoT Remote Manager unterstützt autorisierte Remote-Management-Interaktionen mit dem IPA.

Verwendet SGP.32 einen SM-DP+?

Ja. Die IoT-Architektur nutzt einen SM-DP+ für Profilvorbereitung und -bereitstellung. Eine vollständige Lösung benötigt weiterhin kompatible IoT-Geräte, eUICCs, IPA, eIM und Managementschnittstellen.

Ist SGP.32 besser als SGP.22?

Für bestimmte IoT-Umgebungen ist es besser geeignet, aber nicht universell besser. Eine Smartphone-Reise-eSIM passt normalerweise zur Consumer-Architektur. Eine unbeaufsichtigte Sensorflotte kann zu SGP.32 passen.

Ersetzt SGP.32 SGP.01 und SGP.02?

Es bietet eine neuere Architektur für geeignete IoT-Einsätze, doch bestehende M2M-Geräte und -Plattformen werden noch Jahre parallel betrieben. Die Migration hängt von Hardware, Software, Verträgen und Geräteaustauschzyklen ab.

Kann ein bestehendes Consumer-eSIM-Gerät auf SGP.32 aufgerüstet werden?

Nicht automatisch. Gerät, eUICC und Software müssen die IoT-Architektur unterstützen. Ein Firmware-Update allein reicht möglicherweise nicht aus.

Kann SGP.32 ein Gerät zwischen Mobilfunkbetreibern wechseln lassen?

Es unterstützt Remote-Profil-Provisioning und -Management und kann dadurch Betreiberwechsel ermöglichen, wenn kompatible Profile, Autorisierungen, Konnektivität und kommerzielle Vereinbarungen vorhanden sind. Es setzt Geräte-, Vertrags- oder Netzbeschränkungen nicht außer Kraft.

Ist SGP.32 für jeden IoT-Einsatz erforderlich?

Nein. Manche zugänglichen Router oder Terminals können Consumer-eSIM erfolgreich nutzen. Bestehende Industrieeinsätze können die M2M-Architektur verwenden. Die Entscheidung hängt vom tatsächlichen Betriebsmodell ab.

Was ist SGP.41?

SGP.41 definiert Architektur und Anforderungen für In-Factory Profile Provisioning. Es betrifft die Profilbereitstellung während der Gerätefertigung und ergänzt das Lebenszyklusmanagement im Feld, statt es zu ersetzen.

Wählen Sie eine eSIM-Architektur für den gesamten Gerätelebenszyklus

SIM24.biz hilft Unternehmen, Consumer- und IoT-Connectivity-Angebote unter eigener Marke anhand realer Geräte, Betriebsbedingungen und Managementanforderungen zu gestalten.

Sprechen Sie mit SIM24.biz über das passende Provisioning- und Connectivity-Modell für Ihr Produkt oder Ihre Flotte.

Quellen

1. GSMA, „eSIM Consumer and IoT Specifications“: https://www.gsma.com/solutions-and-impact/technologies/esim/esim-specification/
2. GSMA, „A Guide to eSIM Architectures“: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/a-guide-to-esim-architectures/
3. GSMA, „SGP.21 v2.6, eSIM Consumer Architecture and Requirements“: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-21-v2-6/
4. GSMA, „SGP.22 v2.7, eSIM Consumer Technical Specification“: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-22-v2-7/
5. GSMA, „SGP.31 v1.3, eSIM IoT Architecture and Requirements“: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-31-v1-3/
6. GSMA, „SGP.32 v1.3, eSIM IoT Technical Specification“: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-3/
7. GSMA, „M2M Specifications“: https://www.gsma.com/solutions-and-impact/technologies/esim/esim-m2m-specifications/
8. GSMA, „SGP.01 v4.3, Embedded SIM Remote Provisioning Architecture“: https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2022/11/SGP.01-v4.3-1.pdf
9. GSMA, „SGP.02 v4.3, Remote Provisioning Architecture for Embedded UICC Technical Specification“: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-02-remote-provisioning-architecture-for-embedded-uicc-technical-specification-v4-3/
10. GSMA, „SGP.41 v1.0, eSIM IFPP Architecture and Requirements“: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/esim-ifpp-architecture-and-requirements/
11. Android Open Source Project, „Implement eSIM“: https://source.android.com/docs/core/connect/esim-overview