Wie SGP.32 das Remote-Profilmanagement ermöglicht
Die Architektur führt zwei zentrale Komponenten ein: den eIM (eSIM IoT Remote Manager), der die Fernverwaltungsfunktion bereitstellt, und die IPA (IoT Profile Assistant), die die Kommunikation zwischen der eUICC und der übrigen Remote-Provisioning-Infrastruktur ermöglicht. Gemeinsam erlauben sie es, Profile herunterzuladen und ihren Status aus der Ferne zu verwalten – einschließlich Aktivieren, Deaktivieren und Löschen von Profilen.
SGP.32 funktioniert zusammen mit SGP.31. SGP.31 definiert die Architektur und die Anforderungen für das IoT-eSIM-Modell der GSMA, während SGP.32 die technische Spezifikation zur Umsetzung festlegt. Die aktuellen Spezifikationen SGP.31 und SGP.32 tragen beide die Version 1.3, datiert auf den 22. Mai 2026 und veröffentlicht auf der GSMA-Website am 28. Mai 2026.
Für IoT-Unternehmen ist die Bedeutung klar: Konnektivität kann bereitgestellt und geändert werden, nachdem ein Gerät hergestellt, versendet und eingesetzt wurde – ohne dass eine Person physisch am Gerät anwesend sein muss.
Diese Seite beleuchtet, wie SGP.32 funktioniert, was die Spezifikation standardisiert, was weiterhin in der Verantwortung von Geräteherstellern und Konnektivitätsanbietern liegt, und was Anbieter tatsächlich meinen, wenn sie behaupten, SGP.32 zu unterstützen.
Warum SGP.32 entwickelt wurde
Die GSMA hat drei eSIM-Architekturen definiert, die jeweils für ein unterschiedliches Einsatzmodell konzipiert sind. SGP.02 und SGP.22 sind jeweils auf eine Ressource angewiesen, die in einem IoT-Bestand möglicherweise nicht verfügbar ist.
- SGP.02für Machine-to-Machine-Bestände: Der Subscription Manager des Betreibers überträgt das Profil auf die SIM, wobei der Auslöser per SMS erfolgt
- SGP.22für Endkundengeräte: Der Standard-Profildownload beginnt, wenn eine Person einen QR-Code scannt oder einen Aktivierungscode eingibt, woraufhin der Local Profile Assistant des Geräts das Profil abruft
- SGP.32für IoT: Ein Server, der eIM, löst den Vorgang aus, und die IPA des Geräts führt ihn über eine IP-Verbindung aus
Ein ressourcenbeschränkter Sensor ohne nutzbare Schnittstelle, mit begrenzter Kommunikationskapazität und ohne geplanten Vor-Ort-Einsatz kann sich womöglich weder auf eine Person am Gerät noch auf eine SMS-Zustellung verlassen. SGP.32 macht im Remote-Provisioning-Prozess beides überflüssig.
Die fünf Komponenten – und wer sie jeweils betreibt
Ein SGP.32-Deployment besteht aus fünf Komponenten. Ein Käufer, der eine Ausschreibung erstellt, sollte in der Lage sein, für jede Komponente die verantwortliche Organisation zu benennen. Diese Definitionen entsprechen fünf der sechs Begriffe, die in unserem Blogbeitrag zu eSIM-Management und rSIM-Resilienz definiert sind, der einen sechsten Eintrag für eSIM selbst ergänzt. Die erste FAQ weiter unten geht auf diesen Unterschied ein.
Die IPA kann im Gerät (IPAd) oder innerhalb der eUICC (IPAe) implementiert werden; der GSMA-Compliance-Prozess bewertet beide Varianten getrennt.
Wie ein Profilvorgang das Gerät erreicht
Der eIM kann vier Profilvorgänge auslösen: den Download eines neuen Profils sowie das Aktivieren, Deaktivieren oder Löschen eines bereits installierten Profils. Zudem kann er Informationen darüber abrufen, welche Profile vorhanden und welches davon aktiv ist.
Für eine Änderung an einem installierten Profil bereitet der eIM ein signiertes eUICC-Paket vor. Die IPA überträgt dieses Paket über eine IP-Verbindung an die eUICC und meldet das Ergebnis zurück. Die eUICC prüft die Signatur des eIM, bevor sie den Inhalt ausführt, und weist ein Paket zurück, das sie keinem ihr bekannten eIM zuordnen kann.
Ein Download verläuft anders. Der eIM sendet der IPA einen Aktivierungscode, woraufhin das Profil auf einem von zwei Wegen eintrifft: als direkter Download vom SM-DP+-Server des Betreibers oder als indirekter Download, bei dem der eIM als Proxy fungiert. In beiden Fällen ist weder eine Person am Gerät noch eine SMS erforderlich.
Die Spezifikation schreibt kein bestimmtes Protokoll zwischen eIM und IPA vor. Sie verlangt lediglich Integrität und Vertraulichkeit vom jeweils genutzten Protokoll und empfiehlt HTTP mit TLS-Absicherung, sofern TCP verfügbar ist, beziehungsweise für ressourcenbeschränkte Geräte das Constrained Application Protocol (CoAP) mit DTLS-Absicherung. Diese Transportflexibilität unterstützt Implementierungen über ressourcenbeschränkte Mobilfunktechnologien wie NB-IoT und LTE-M, bei denen Sitzungen kurz und Bandbreite oder Datenverbrauch streng limitiert sein können.
Was SGP.32 dem Käufer überlässt
SGP.32 liefert die Architektur für das Remote-Provisioning und -Management von Profilen. Ein vollständiges Deployment muss darüber hinaus drei weitere Bereiche abdecken: das Betreiber- und Subscription-Management, die Anforderungen an lokale Konnektivität und Roaming sowie die Kontinuität, wenn das aktive Netz nicht verfügbar ist.
SGP.32 wählt weder den Betreiber aus noch richtet es den Vertrag ein. Der eIM löst lediglich den Download eines Profils aus, das existiert, weil ein Betreiber es im Rahmen einer kommerziellen Vereinbarung ausgestellt hat. Tarif, Access Point Name, Aktivierung und Abrechnung liegen beim Betreiber oder Konnektivitätsanbieter. Ein eIM-Vorgang, der ohne die entsprechende Vertragsaktion abgeschlossen wird, kann daher dazu führen, dass ein Profil zwar aktiviert ist, aber nicht wie vorgesehen Datenverkehr verarbeiten kann.
SGP.32 sorgt nicht dafür, dass eine Roaming-Flotte lokale Anforderungen erfüllt. Es kann ein lokales Profil aktivieren, sobald dieses auf der eUICC bereitgestellt wurde. Ob in einem bestimmten Markt ein lokales Profil erforderlich ist, welcher Betreiber es bereitstellen kann und zu welchen Konditionen, bleibt eine regulatorische und kommerzielle Frage.
SGP.32 sorgt allein nicht dafür, dass ein Gerät verbunden bleibt, wenn sein aktives Netz ausfällt. Es verwaltet Profile über einen funktionierenden Kommunikationspfad. Verhindert der Ausfall des aktiven Netzes zugleich, dass das Gerät den eIM erreicht, kann der eIM diesen Pfad nicht nutzen, um einen Profilwechsel anzuweisen.
Seit Version 1.2 definiert die Spezifikation einen optionalen Fallback-Mechanismus, bei dem die IPA ein vorab festgelegtes Fallback-Profil aktivieren kann, sobald das Gerät einen dauerhaften Verbindungsverlust erkennt. Erkennungslogik und Timing liegen beim Gerätehersteller, und die eUICC muss diese Funktion nicht unterstützen. Die rSIM®-Technologie hält zwei getrennte Multi-Network-Roaming-Profile vor und verlagert die Konnektivitätsprüfung sowie die Profilauswahl in eine auf der SIM residente Logik. Bleibt der aktive Pfad gemäß der konfigurierten Umschaltrichtlinie nicht verfügbar, kann diese Logik das bereits auf der SIM vorhandene alternative Profil auswählen, ohne dass der eIM oder eine Remote-Management-Plattform das Gerät in diesem Moment erreichen muss.
Was Anbieteraussagen bedeuten
Anbieter verwenden bei der Beschreibung der SGP.32-Unterstützung mitunter drei unterschiedliche Begriffe. Käufer sollten genau klären, was jeder Begriff bedeutet und welche Nachweise ihn stützen.
Im Rahmen des GSMA-Compliance-Prozesses SGP.24 gelten die IoT-eUICC, das IoT-Gerät mit IPA und der eIM als eigenständige Produkttypen. Jeder von ihnen kann eine GSMA Compliance Confirmation erhalten, wobei nur die eUICC für ein Zertifikat im Rahmen der Public-Key-Infrastruktur der GSMA infrage kommt. Jede Compliance- oder Zertifizierungsaussage muss daher den jeweils abgedeckten Produkttyp benennen, statt pauschal auf das gesamte SGP.32-Deployment angewendet zu werden.
Wie CSL SGP.32 anwendet
CSL Group bietet Managed IoT Connectivity, die SIMs oder eSIMs, Hardware, privates Routing, Monitoring und Support je nach den Anforderungen des Deployments zusammenführt. Innerhalb dieses Service stellt die CSL IoTM-Plattform die Management- und Orchestrierungsebene über unterstützte Mobilfunkbetreiber-Portale, Connectivity-Management-Plattformen und Remote-SIM-Provisioning-Systeme bereit, während rSIM lokale Resilienz auf SIM-Ebene liefert. Die Plattform bereitet die Konnektivität über den gesamten Lebenszyklus des Bestands vor, verwaltet und steuert sie. rSIM agiert bei einem Konnektivitätsvorfall lokal, unter Verwendung von Profilen und Umschaltrichtlinien, die bereits auf der SIM vorhanden sind.
Von den drei oben genannten Begriffen trifft „Ausgerichtet” zu. Die rSIM-Technologie und die eSIM-Management-Funktionen der CSL IoTM-Plattform sind nach der SGP.32-Architektur aufgebaut. Die Zertifizierung nach SGP.24 wird für einzelne eUICC-, IPA- und eIM-Produkte vergeben, weshalb CSL diese Produkte und ihre Nachweise für das jeweilige Deployment benennt.
SGP.32-FAQ
Dies sind die Fragen, die Käufer am häufigsten stellen, wenn SGP.32 in einem Datenblatt oder einer Ausschreibung auftaucht. Unser Blogbeitrag zu eSIM-Management und rSIM-Resilienz behandelt die eIM-Portabilität, einschließlich der Frage, wovon ein Wechsel des eIM-Anbieters abhängt.
Ist SGP.32 dasselbe wie eSIM?
Nein. eSIM bezeichnet üblicherweise die Technologie, die es ermöglicht, Betreiberprofile auf einer eUICC herunterzuladen und zu verwalten, wobei der Begriff häufig auch für einen verlöteten SIM-Formfaktor verwendet wird. Die eUICC ist die sichere Hardware und Software, die diese Profile speichert und verwaltet. SGP.32 ist die GSMA-Spezifikation für das Remote-Provisioning und -Management einer eUICC in einem IoT-Gerät. Ein Gerät kann eine eUICC enthalten, ohne SGP.32 zu unterstützen.
Was ist der Unterschied zwischen SGP.32 und SGP.22?
Ersetzt SGP.32 SGP.02?
Was sind der eIM und die IPA?
Welche Version von SGP.32 ist aktuell?
Unterstützen bestehende IoT-Geräte SGP.32?
Ist SGP.32 für IoT-Geräte verpflichtend?
Ist SGP.32 zertifiziert, und ist CSL dagegen zertifiziert?
Macht SGP.32 ein Gerät resilient gegenüber einem Netzausfall?
Wo finde ich die relevanten GSMA-Quellen?
Aktuelle Branchennews: Netzänderungen
