SGP.22 vs SGP.32 - was der Wechsel des eSIM-Standards für die Reisekonnektivität bedeutet

Ziel: Reisenden eSIM-Käufern und Reise-/MVNO-Betreibern eine standardkundige Karte der Verbraucher- vs. IoT-Fernbereitstellung von SIMs zu geben - damit das Branchengespräch über „den nächsten eSIM-Standard“ nicht zwei verschiedene Wege vermischt.

Zielgruppe: Praktiker, die Verbraucher-Reisekonnektivität versenden oder kaufen (und alle, die angrenzende IoT-/Reise-Hardware bewerten), nicht GSMA-Ausschussmitglieder.

Wenn Sie eine Reise-eSIM kaufen, einen QR-Code scannen und mit Daten landen, befinden Sie sich bereits in einer GSMA-Fernbereitstellungsarchitektur (RSP) - auch wenn Sie die Spezifikationsnummern nie sehen. Diese Zahlen sind wichtig.SGP.22 ist der technische Verbraucher-RSP-Standard hinter Smartphone- und Reise-eSIM-Abläufen.SGP.32 ist der technische IoT-RSP-Standard für kopflose, eingeschränkte und flottenweite Geräte. Sie teilen einige Bausteine. Sie lösen unterschiedliche Probleme.

Diese Unterscheidung lässt sich in Marketing-Präsentationen leicht verwischen. Es ist auch der Unterschied zwischen einem Reisenden, der ein temporäres Profil auf einem Telefon installiert, und einem Unternehmen, das die Konnektivität über Tausende von Sensoren orchestriert, die nie einen Bildschirm sehen werden. Für Reisemarken, MVNOs und alle, die auf Verbraucher-eSIM-Stacks aufbauen, ist es entscheidend zu wissen, wo SGP.22 endet und SGP.32 beginnt - nicht weil Reisende GSMA-PDFs benötigen, sondern weil das Branchengespräch oft Verbraucher- und IoT-Wege vermischt.

Dieser Artikel kartiert Architektur, Akteure, Lebenszyklusunterschiede und praktische Auswirkungen für die Reisekonnektivität - ohne SGP.32 als Drop-in-Upgrade für das Verbraucher-Roaming zu behandeln.

Warum die Branche mehr als einen eSIM-„Standard“ benötigte #

eSIM ist kein einzelnes Protokoll. Es ist eine Familie von GSMA-Spezifikationen, die definieren, wie Betreiberprofile sicher vorbereitet, geliefert, installiert, aktiviert, deaktiviert und auf einer eUICC (der eingebetteten SIM-Plattform) gelöscht werden.

Der öffentliche Spezifikationsindex der GSMA macht die Aufteilung deutlich: Consumer RSP fällt unter SGP.21 (Architektur) und SGP.22 (technisch); IoT RSP fällt unter SGP.31 (Architektur und Anforderungen) und SGP.32 (technisch). Aktive Consumer-Veröffentlichungen laufen weiter über SGP.22 v2.x und v3.x; IoT-Veröffentlichungen laufen weiter über SGP.31/SGP.32 v1.x, einschließlich neuerer Überarbeitungen von 2024-2026 auf der eSIM-Spezifikationsseite der GSMA (GSMA eSIM Consumer and IoT Specifications).

Vor SGP.32 lebten IoT und M2M Remote Provisioning weitgehend in einem früheren Machine-to-Machine-Modell (SGP.02), mit einer Dual-Server-Aufteilung von SM-DP (Datenvorbereitung) und SM-SR (sichere Weiterleitung). Dieses Modell ermöglichte das Remote-Profile-Management für industrielle und automobile Anwendungsfälle, brachte jedoch auch betriebliche Reibungen mit sich: SMS-orientierte Auslöser, engere kommerzielle Kopplung von SM-SR/SM-DP und eine schlechte Eignung für stark eingeschränkte LPWAN-Geräte. Betreiber und IoT-Plattform-Erklärer nennen diese Einschränkungen konsequent als Grund dafür, dass die GSMA eine dedizierte IoT-Architektur entwickelte, anstatt Consumer RSP auf jedes Modem zu zwingen (Eseye zu SGP.31/32; 1oT zu SGP.02 vs SGP.22 vs SGP.32).

Kurzversion: eine physische Form (eSIM/eUICC), mehrere Bereitstellungsphilosophien.

SGP.22 in einfachen Worten: Consumer RSP für Geräte mit einem Menschen im Prozess #

SGP.22 ist die technische Beschreibung der GSMA für Remote SIM Provisioning für Verbrauchergeräte. Sein Zweck ist eindeutig: eine technische Lösung für die Remote-Bereitstellung und Verwaltung der eUICC in Verbrauchergeräten, die auf Interoperabilität über Betreiberbereitstellungen abzielt - einschließlich SM-DP+ Plattformen und eUICC-Anbietern.

Kernakteure im Verbrauchermodell #

Akteurrollen #

• eUICC: Sichere Plattform, die Profile speichert (Betreiberanmeldeinformationen und zugehörige Komponenten)
• LPA (Local Profile Assistant): Auf dem Gerät (oder teilweise auf der eUICC) befindlicher Assistent, der den Download, die lokale Aktivierung/Deaktivierung/Löschung und das benutzerorientierte Profilmanagement steuert
• SM-DP+: Subscription Manager - Data Preparation +: bereitet vor, schützt und liefert gebundene Profilpakete
• SM-DS: Subscription Manager - Discovery Service: optionaler Entdeckungspfad, wenn das Gerät den richtigen SM-DP+ ohne QR-/Aktivierungscode finden muss
• Betreiber / Profilherausgeber: Besitzt das kommerzielle Abonnement hinter dem Profil

Im Ablauf, den Reisende erkennen:

1. Kaufen Sie einen Reiseplan und erhalten Sie einen Aktivierungscode (oft als QR).
2. Das Gerät LPA kontaktiert das SM-DP+.
3. Das verschlüsselte Profilpaket wird heruntergeladen und auf dem eUICC installiert.
4. Der Nutzer aktiviert das Profil (und kann es später deaktivieren oder löschen).

Dies ist ein benutzerinitiiertes / pull-orientiertes Modell. Eine Person ist anwesend, das Gerät hat eine Benutzeroberfläche, und die Zustimmung erfolgt durch eine explizite Installationsaktion. Deshalb passen der eSIM-Checkout für Reisen, Partnerschaften mit Fluggesellschaften/Fintechs und die app-basierte Aktivierung alle zum SGP.22-Klassenverbraucher-RSP - nicht zur IoT-Flottenorchestrierung.

Der HTTPS/TLS-Transport passt zu Smartphones. Er ist schwerer als viele IoT-Duty-Cycles es sich leisten können, aber angemessen für ein Mobiltelefon, das bereits IP-Konnektivität und einen vollständigen Sicherheitsstack aufrechterhält.

SGP.32 in einfachen Worten: IoT RSP für Geräte, die nicht auf „eSIM hinzufügen“ zugreifen können #

SGP.32 ist die technische Spezifikation für die eSIM IoT Architektur der GSMA, definiert in SGP.31. Die GSMA beschreibt es als Abdeckung der Fernbereitstellung und Verwaltung des eUICC in IoT-Geräten, die netzwerkbeschränkt und/oder benutzeroberflächenbeschränkt sind, sowie der eUICC-Architektur, Schnittstellen und Sicherheitsfunktionen für dieses Modell.

Kernakteure im IoT-Modell #

Akteurrollen #

• eUICC: IoT-fähiges eUICC, das Profile speichert und IoT-Fernverwaltungszuordnungen unterstützt
• IPA (IoT Profile Assistant): Geräte- oder eUICC-seitiger Assistent, der Bereitstellungs-/Verwaltungsarbeiten ohne Verbraucher-Benutzeroberfläche ausführt; kann IPAd (auf dem Gerät) oder IPAe (auf eUICC) sein
• eIM (eSIM IoT Remote Manager): Cloud-/Orchestrierungseinheit, die Profil-Lebenszyklusoperationen für ein Gerät oder eine Flotte ausführt
• SM-DP+: Aus dem Verbrauchersystem wiederverwendet für die Profilvorbereitung und geschützte Lieferung
• SM-DS: Entdeckungsrolle, wo relevant beibehalten
• Operator: Profilquelle, wie im Verbraucher-RSP

Die architektonische Absicht ist in den Materialien der GSMA und den Branchenführungen konsistent: Behalten Sie bei, was im Verbraucher-RSP bereits funktionierte (insbesondere SM-DP+), und ersetzen Sie die Annahme von Mensch/LPA durch einen Fernmanager plus einen IoT-nativen Assistenten (Velocity IoT Standards-Erklärer; 1oT-Vergleich).

Warum IoT ein anderes Modell benötigte #

Verbraucher-RSP geht davon aus:

• ein Bildschirm oder Begleit-UX,
• eine Person, die den Download starten kann,
• relativ stabile IP-Konnektivität für TLS-Sitzungen,
• lebenszyklusbezogene Entscheidungen pro Gerät, die vom Benutzer getroffen werden.

IoT-Flotten gehen oft vom Gegenteil aus:

• keine Benutzeroberfläche,
• unterbrochene oder geringe Bandbreitenkonnektivität (einschließlich LPWAN-Szenarien),
• asynchrone Check-ins anstelle von immer aktiven Sitzungen,
• richtliniengesteuertes Aktivieren/Deaktivieren/Löschen über viele EIDs gleichzeitig.

SGP.31/32 führt daher eine flottenorientierte Profilzustandsverwaltung und ein eIM ein, das Downloads auslösen oder vermitteln kann. Branchenanalysen betonen auch leichte Protokolloptionen (zum Beispiel CoAP/DTLS als alternativer Weg für eingeschränkte Geräte), die Entfernung von SMS als harte Abhängigkeit für moderne IoT RSP und die Unterstützung für direkte vs. indirekte Profilbereitstellung, je nachdem, ob das Gerät selbstständig mit dem SM-DP+ kommunizieren kann (Eseye; 1oT).

Entscheidend ist, dass SGP.32 kein rückwärtskompatibles „Software-Upgrade“ für jede SGP.02 eUICC ist, die bereits im Einsatz ist. Eseye und andere IoT-Spezialisten weisen darauf hin, dass M2M-Standardbereitstellungen typischerweise auf diesem Modell bis zum Lebensende bleiben; Greenfield-IoT ist der Bereich, in dem SGP.32 als Standard konzipiert ist.

SGP.22 vs SGP.32: strukturierter Vergleich #

Vergleich Dimension für Dimension #

Primäres GSMA-Paar

• SGP.22 (Consumer RSP): SGP.21 Architektur + SGP.22 technisch
• SGP.32 (IoT RSP): SGP.31 Architektur/Anforderungen + SGP.32 technisch

Entwickelt für

• SGP.22 (Consumer RSP): Smartphones, Tablets, Wearables, Verbrauchergeräte mit Benutzeroberfläche
• SGP.32 (IoT RSP): Headless / UI-eingeschränkte / netzwerkeingeschränkte IoT-Geräte und Flotten

Mensch in der Schleife?

• SGP.22 (Consumer RSP): Ja - Benutzer initiiert oder bestätigt Installation/Wechsel
• SGP.32 (IoT RSP): Nein - eIM/IPA orchestrieren Operationen aus der Ferne

Lokaler Assistent

• SGP.22 (Consumer RSP): LPA
• SGP.32 (IoT RSP): IPA (IPAd oder IPAe)

Fernorchestrierung

• SGP.22 (Consumer RSP): Eingeschränkt / nicht das Designzentrum
• SGP.32 (IoT RSP): eIM als erstklassiger Fernmanager

Profilserver

• SGP.22 (Verbraucher RSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (wiederverwendet)

Entdeckung

• SGP.22 (Verbraucher RSP): SM-DS (optional in vielen Abläufen)
• SGP.32 (IoT RSP): SM-DS in der Architektur beibehalten

Auslösemodell

• SGP.22 (Verbraucher RSP): Überwiegend Pull (QR / Aktivierungscode / App)
• SGP.32 (IoT RSP): Push und/oder Pull über eIM und Geräte-Check-in-Muster

Transporthaltung

• SGP.22 (Verbraucher RSP): HTTPS/TLS-zentrierter Verbraucher-IP-Stack
• SGP.32 (IoT RSP): IP-basiert; Optionen für eingeschränkte Geräte betont (z.B. CoAP/DTLS-Pfade in branchenspezifischen Zusammenfassungen der Spezifikation)

Schmerzpunkte des Vorgängers, die es adressiert

• SGP.22 (Verbraucher RSP): Physische SIM-Wechsel und Betreiberbindung auf Verbraucherhardware
• SGP.32 (IoT RSP): SGP.02-Betriebsbindung, SMS-Abhängigkeit und schlechte Passform für eingeschränkte Geräte

Relevanz von Reise-eSIMs

• SGP.22 (Verbraucher RSP): Direkt - dies ist der Stack hinter typischen Telefon-Reise-eSIM-Installationen
• SGP.32 (IoT RSP): Indirekt - beeinflusst angrenzende IoT-/Reise-Hardware-Ökosysteme, nicht Telefon-QR-Abläufe

Profillebenszyklus: gleiche Verben, unterschiedliche Grammatik #

Beide Welten sprechen über Herunterladen, Installieren, Aktivieren, Deaktivieren und Löschen. Die Grammatik unterscheidet sich:

• SGP.22 Lebenszyklus ist lokal und benutzerzentriert. Einmal installiert, entscheidet der Reisende (oder die LPA-Benutzeroberfläche), wann ein Profil für Roaming-Daten aktiviert, pausiert oder entfernt wird.
• SGP.32 Lebenszyklus ist fern- und richtlinienzentriert. Der eIM kann Profilzustandsverwaltungsoperationen über eine oder viele EIDs ausgeben, und die IPA führt sie aus, wenn das Gerät erreichbar ist - wichtig für Geräte, die den Großteil des Tages schlafen.

Deshalb bedeutet „Profilwechsel“ in jeder Welt unterschiedliche kommerzielle Dinge. Im Verbraucherreisebereich ist der Wechsel oft ein neuer Kauf oder ein zweites installiertes Profil, das der Benutzer auswählt. Im IoT-Bereich ist der Wechsel ein Bestandsvorgang: Wechsel des Konnektivitätsanbieters, Reaktion auf Abdeckung oder Rotation von Profilen ohne einen Vor-Ort-Einsatz.

Wo frühere IoT-Spezifikationen passen: SGP.02 und SGP.31 #

Ein klares mentales Modell:

1. SGP.02 - ursprüngliches M2M RSP mit SM-DP + SM-SR. Grundlegend, immer noch in langlebigen Bereichen präsent (insbesondere im Automobilbereich und anderen fabrikgebundenen Einsätzen), wird jedoch zunehmend als veraltet für neue eingeschränkte IoT-Projekte betrachtet (1oT).
2. SGP.22 - Verbraucher-RSP, das die Bereitstellung um SM-DP+ und LPA vereinfachte; der Massenmarktweg für Telefone und Reise-eSIM.
3. SGP.31 / SGP.32 - IoT RSP, das SM-DP+ wiederverwendet und eIM + IPA für kopfloses Flottenmanagement hinzufügt.

SGP.32 erschien nicht, weil die Verbraucher-eSIM „gescheitert“ ist. Es erschien, weil die Verbraucher-eSIM für Menschen erfolgreich war- und dieser Erfolg löst immer noch nicht einen Sensor, der in einem Schiffscontainer verschraubt ist.

Auswirkungen auf Reise-eSIM, Verbraucher-Roaming und MVNO-Stacks #

Reiseverbindungen bleiben eine Verbraucher-RSP-Geschichte #

Für Telefone und die meisten Reisedevices bleibt der operative Standard SGP.22-Klasse Verbraucher-RSP. Das Produkterlebnis, das Reisende interessiert - vor der Abreise kaufen, per QR oder App installieren, verbunden landen - entspricht LPA ↔ SM-DP+ Flows, nicht eIM Flottenbefehlen.

Der eigene Branchenkommentar der GSMA für 2026 beschreibt Reiseverbindungen als strukturellen Wandel im internationalen Roaming: App-basierte eSIM-Reiseangebote sind transparenter und flexibler, und die Verteilung rückt näher an den Endnutzer, bevor die Reise beginnt (GSMA: eSIM Massenmarkteinführung bewegt sich von Prognose zu Tatsache). Dieser kommerzielle Wandel basiert auf der Reife der Verbraucher-RSP und der Unterstützung von Handgeräten, nicht auf der Einführung von IoT eIM.

Was SGP.32 *für reisebezogene Ökosysteme* ändert #

Auch wenn Reisende SGP.32 nie berühren, ist der Standard an den Rändern der Reise wichtig:

• Verbundene Gepäcktracker, Flottenfahrzeuge, Logistiksensoren und Veranstaltungs-IoT benötigen zunehmend ein Fernprofilmanagement ohne QR-Zeremonie.
• Reiserouter und einige „eSIM-Hardware“ können in einer unordentlichen Mitte sitzen: Verbraucherähnliche Aktivierung für einen menschlichen Besitzer, aber betriebliche Bedürfnisse, die im großen Maßstab eher flottenähnlich aussehen.
• Betreiber und MVNOs können sowohl Verbraucher-SM-DP+ Bereiche als auch IoT eIM Bereiche betreiben. Das Teilen von SM-DP+ DNA zwischen SGP.22 und SGP.32 ist beabsichtigt; es bedeutet nicht, dass die beiden Gerätekategorien die gleiche UX oder Zertifizierungspfad teilen.

Multi-IMSI, MVNO-Stacks und wahrheitsgemäße Grenzen #

Multi-IMSI (mehrere Identitäten, die innerhalb oder neben einem Konnektivitätsprodukt auswählbar sind) und eUICC-Profil-Download werden oft zusammen diskutiert, aber sie sind nicht der gleiche Mechanismus. Multi-IMSI kann das Netzwerkverbindungsverhalten innerhalb eines kommerziellen Angebots verbessern; eUICC RSP (SGP.22 oder SGP.32) geht darum, vollständige Betreiberprofile sicher auf der eUICC zu installieren und zu verwalten. Reise-Marken und MVNOs können beide Techniken kommerziell kombinieren, aber architektonische Klarheit ist weiterhin wichtig: Verbraucherreisen-Installationen auf Telefonen werden nach SGP.22-Interoperabilität und Aktivierungs-UX beurteilt; IoT-Bereiche werden nach eIM/IPA-Bedienbarkeit und Netzwerkwiderstandsfähigkeit beurteilt.

Eine nützliche Warnung von der IoT-Seite gilt auch kommerziell: Technische Portabilität in einer Spezifikation bedeutet nicht automatisch kommerzielle Portabilität in einem Vertrag. SGP.32 reduziert bestimmte architektonische Lock-in-Muster, die mit SGP.02 verbunden sind, aber die kommerziellen Bedingungen des Anbieters bestimmen weiterhin, wie frei Flotten eIM-Assoziationen oder externe SM-DP+ Beziehungen bewegen können (1oT). Verbraucherreise-Käufer stehen vor einer ähnlichen Lektion im kleineren Maßstab - interoperable RSP garantiert nicht von selbst identische Abdeckungsqualität, Fair-Use-Politik oder Support-Erfahrung über Anbieter hinweg.

Markttiming und Annahmesignale (öffentlich, 2025-2026) #

Öffentliche GSMA-Materialien im Jahr 2026 beschreiben, dass die Verbraucher-eSIM in den operativen Maßstab eintritt, anstatt ein Konzeptnachweis zu sein. Laut der GSMA-Zusammenfassung von Mai 2026 der GSMA Intelligence-Zahlen lag die globale eSIM-Smartphone-Durchdringung bei etwa 5% Ende 2025, mit einem angegebenen Weg zu etwa 10 % bis Ende 2026, und weiteres Wachstum danach; derselbe Artikel nennt ungefähr drei von vier / 73 % der Mobilfunknetzbetreiber bieten kommerzielle Smartphone-eSIMs an, während er die verbleibende Lücke zwischen Verfügbarkeit und aktiver Verbraucheraktivierung feststellt (GSMA-Massenmarkt-eSIM-Artikel).

Auf der IoT-Seite hebt derselbe GSMA-Kommentar SGP.32 als strukturellen Ermöglicher für globale Produktvarianten und In-Field-Profilwechsel hervor - eine Sprache, die mit der Positionierung des Standards durch IoT-Plattformen übereinstimmt. Die Reife der Spezifikation ist auch in den öffentlichen Tabellen der GSMA sichtbar: SGP.31/SGP.32 schreiten weiterhin durch aktive v1.2- und neuere v1.3-Listen in den Jahren 2024-2026 voran, zusammen mit den zugehörigen Testspezifikationen (GSMA-Spezifikationsindex).

Interpretation ohne Übertreibung: Verbraucher-Reise-eSIM ist bereits ein skaliertes kommerzielles Anwendungsbeispiel auf SGP.22-Schienen; SGP.32 ist die parallele Industrialisierung von IoT RSP. Sie verstärken die breitere eSIM-Geschichte, ohne sich gegenseitig zu ersetzen.

Was Reisende und Marken mitnehmen sollten #

Für Reisende #

Sie müssen sich nicht zwischen SGP.22 und SGP.32 entscheiden, wenn Sie einen Reiseplan kaufen. Wenn Sie eine eSIM auf einem Telefon über QR-Code oder App installieren, befinden Sie sich in der Verbraucher-RSP-Welt. Was für Sie wichtig ist, ist praktisch: Gerätekompatibilität, Installationszuverlässigkeit vor der Abreise, Abdeckungsbereich des Reiseziels, transparente Fair-Use-Bedingungen und Unterstützung, wenn etwas am Gate schiefgeht.

Anbieter wie Roamify befinden sich in dieser Verbraucherschicht für Reisen - Zielpläne, digitale Installation und Online-Bleiben im Ausland - anstatt im industriellen eIM-Flottenmanagement. Die Standardgeschichte hinter dem QR ist immer noch SGP.22-geprägt.

Für Reisemarken, OTAs, Fintechs und Verbraucher-MVNOs #

• Behandeln Sie SGP.22-Interoperabilität und Aktivierungs-UX als Produktgrundlage.
• Vermarkten Sie „SGP.32“ nicht als reisendenorientiertes Upgrade, es sei denn, Ihre tatsächliche Hardware-/Flottenarchitektur verwendet IoT RSP.
• Wenn Sie Konnektivität für Tracker, Router oder B2B-Reisehardware verkaufen oder als White-Label anbieten, bewerten Sie separat, ob die Geräteklasse Verbraucher-LPA-Flows, IoT-eIM-Flows oder einen gestuften Hybrid benötigt.
• Investieren Sie in Bildung: Die eigenen Marktkommentare der GSMA weisen immer noch auf eine Lücke zwischen eSIM-Verfügbarkeit und Verbraucherverständnis/-aktivierung hin. Klare Installationsanleitungen bleiben ein wettbewerbsfähiges Unterscheidungsmerkmal.

Für Betreiber und Konnektivitätsplattformen #

Das parallele Betreiben von Verbraucher- und IoT-RSP wird zunehmend normal. Gemeinsames SM-DP+-Erbe hilft, aber Zertifizierung, Sicherheitsakkreditierung, Geräteagenten (LPA vs. IPA) und kommerzielle Betriebsmodelle bleiben unterschiedlich. Das Mischen der Vokabulare in öffentlichen Mitteilungen schafft falsche Erwartungen sowohl für Reisende als auch für Unternehmenskäufer.

Fazit: zwei Standards, eine eSIM-Erzählung - halten Sie die Bahnen klar #

SGP.22 und SGP.32 sind keine Rivalen auf einer einzigen Bestenliste. Sie sind Antworten auf zwei Geräte-Realitäten:

• SGP.22 geht davon aus, dass eine Person anwesend ist und ein Profil auf ein Verbrauchsgerät laden kann. Das ist die Architektur hinter modernen Reise-eSIMs auf Telefonen.
• SGP.32 geht davon aus, dass das Gerät allein - oder im Ruhezustand - ist und eine ferngesteuerte, flottenfähige Verwaltung durch eIM und IPA benötigt, während es weiterhin die SM-DP+-Profilbereitstellung wiederverwendet. Das ist die Architektur, die die GSMA für eingeschränktes IoT gebaut hat, nachdem die Grenzen von SGP.02 offensichtlich wurden.

Für Reisekonnektivität ist die strategische Lektion Präzision. Der Verbraucher-RSP-Weg verändert bereits, wie Menschen Roaming kaufen. Der IoT-RSP-Weg verändert, wie Maschinen über Jahre hinweg verbunden bleiben. Marken, die diese Bahnen klar halten, werden eSIM glaubwürdiger erklären - und Produkte entwickeln, die dem Standard entsprechen, den sie tatsächlich liefern.

Weicher Markenhinweis: Roamify ist ein Anbieter von Reise-eSIMs, der Pläne für viele Reiseziele mit digitaler Aktivierung für kompatible Telefone anbietet. Dieser Artikel ist eine Standardbildung, kein Anspruch darauf, dass Roamify IoT SGP.32-Flottenmanagement implementiert.