Konsumencki eSIM a eSIM dla IoT: SGP.22, SGP.32 i inne architektury GSMA

eSIM w smartfonie podróżnego i eSIM w zdalnie zainstalowanym liczniku energii mogą przechowywać pobierane profile operatorów komórkowych. Nie muszą jednak korzystać z tej samej architektury provisioningu ani tego samego modelu operacyjnego.

Konsumencki eSIM powstał z myślą o urządzeniach z ekranem, systemem operacyjnym, dostępem do internetu i użytkownikiem, który może zatwierdzić instalację. Wdrożenia IoT mogą obejmować tysiące bezobsługowych urządzeń o ograniczonym zasilaniu, sporadycznej łączności, bez aparatu i praktycznej możliwości zeskanowania kodu QR.

Dlatego GSMA opracowała różne architektury zdalnego provisioningu SIM dla różnych środowisk:

• SGP.01 i SGP.02 definiują dotychczasową architekturę M2M;
• SGP.21 i SGP.22 definiują architekturę konsumencką, szeroko stosowaną w smartfonach i innych urządzeniach konsumenckich;
• SGP.31 i SGP.32 definiują nowszą architekturę IoT dla urządzeń z ograniczeniami sieciowymi lub ograniczonym interfejsem użytkownika;
• SGP.41 definiuje architekturę i wymagania dotyczące provisioningu profili w fabryce, czyli IFPP.

Numery mają znaczenie, ale nie powinny być punktem wyjścia do decyzji biznesowej. Właściwa architektura zależy od urządzenia, sposobu wdrożenia, dostępnej łączności, udziału użytkownika, przewidywanego okresu eksploatacji oraz podmiotu odpowiedzialnego za zarządzanie profilami.

Najważniejsze informacje

• Architektury konsumencka, M2M i IoT rozwiązują różne problemy operacyjne. Nie są jedynie różnymi nazwami tego samego procesu.
• SGP.21 opisuje architekturę i wymagania konsumenckiego eSIM. SGP.22 zawiera odpowiadającą im specyfikację techniczną.
• SGP.31 opisuje nowszą architekturę i wymagania eSIM dla IoT. SGP.32 zawiera specyfikację jej technicznej implementacji.
• Konsumencki eSIM zwykle wykorzystuje SM-DP+, Local Profile Assistant oraz opcjonalnie SM-DS. Użytkownik lub urządzenie zazwyczaj bezpośrednio uczestniczy w pobieraniu profilu.
• Architektura IoT SGP.31/32 wprowadza IoT Profile Assistant i eSIM IoT Remote Manager, aby obsługiwać urządzenia bez odpowiedniego lokalnego interfejsu użytkownika i urządzenia o ograniczonej łączności.
• Architektura IoT może korzystać z infrastruktury SM-DP+, ale nie oznacza to, że każda konsumencka usługa eSIM automatycznie nadaje się do flot SGP.32.
• Dotychczasowa architektura M2M wykorzystuje między innymi SM-DP i SM-SR, a sterowanie odbywa się głównie po stronie serwerów. Nadal ma znaczenie w istniejących wdrożeniach motoryzacyjnych i przemysłowych.
• SGP.32 nie aktualizuje zdalnie każdego wdrożonego urządzenia M2M lub konsumenckiego. Wymagane jest wsparcie w eUICC, oprogramowaniu urządzenia, ścieżce komunikacyjnej i systemach zarządzania.
• Podczas długiego okresu migracji flota może wymagać obsługi więcej niż jednej architektury.
• Dobra platforma komercyjna rozdziela provisioning profili, łączność sieciową i zarządzanie cyklem życia floty, zamiast traktować je jako jedną funkcję o nazwie „eSIM”.

Dlaczego eSIM potrzebuje więcej niż jednej architektury?

Zdalny provisioning SIM musi uwzględniać rzeczywiste warunki działania urządzenia docelowego.

Smartfon zwykle ma:

• ekran i menu ustawień;
• użytkownika, który może wyrazić zgodę;
• Wi-Fi lub inne połączenie z internetem;
• system operacyjny z interfejsem eSIM;
• wystarczające zasilanie i moc obliczeniową do interaktywnej instalacji;
• aparat, aplikację lub mechanizm obsługi linków.

Podłączony do sieci czujnik może nie mieć żadnej z tych cech. Może znajdować się pod ziemią, wewnątrz szczelnie zamkniętej maszyny lub należeć do instalacji rozmieszczonej w kilku krajach. Może wybudzać się tylko okresowo, korzystać z technologii radiowej o ograniczonych możliwościach i wymagać dziesięciu lat pracy bez ręcznej obsługi.

Producent samochodów ma jeszcze inne wymagania. Pojazdy mogą powstawać w jednym kraju, trafiać na cały świat, być przypisywane różnym dostawcom usług oraz przez długi okres eksploatacji obsługiwać połączenia alarmowe, diagnostykę i usługi online.

Jednej architektury nie da się równie dobrze zoptymalizować pod wszystkie te warunki.

Przegląd specyfikacji GSMA

Tabela jest celowo uproszczona. Każda specyfikacja określa szczegółowe role, interfejsy, procedury bezpieczeństwa i funkcje cyklu życia. Firmy powinny potwierdzić odpowiednią wersję i implementację u dostawców eUICC, urządzeń, łączności i platformy.

Co oznaczają numery dokumentów GSMA?

Standardy eSIM GSMA są podzielone na powiązane dokumenty.

Dokumenty dotyczące architektury i wymagań

Opisują role, zastosowania, zasady i wymagania danej architektury.

• SGP.01 obejmuje architekturę i wymagania M2M.
• SGP.21 obejmuje architekturę i wymagania konsumenckie.
• SGP.31 obejmuje architekturę i wymagania IoT.
• SGP.41 obejmuje architekturę i wymagania provisioningu profili w fabryce.

Specyfikacje techniczne

Definiują szczegółowe procedury techniczne, interfejsy, komunikaty i funkcje bezpieczeństwa potrzebne do zapewnienia interoperacyjności implementacji.

• SGP.02 to specyfikacja techniczna architektury M2M.
• SGP.22 to specyfikacja techniczna konsumenckiego zdalnego provisioningu SIM.
• SGP.32 to specyfikacja techniczna architektury eSIM IoT.

Skróty „eSIM SGP.22” i „eSIM SGP.32” są wygodne, ale żaden z tych numerów nie opisuje odmiennego fizycznego formatu SIM. Dokumenty opisują architektury zdalnego provisioningu i zachowanie techniczne kompatybilnego eUICC oraz ekosystemu profili.

Jak działa architektura konsumenckiego eSIM?

Architektura konsumencka jest modelem najlepiej znanym użytkownikom smartfonów. Klient kupuje pakiet i dodaje go przez ustawienia urządzenia, kod QR, aplikację operatora, powiadomienie, link aktywacyjny lub proces przeniesienia obsługiwany przez system operacyjny.

SGP.21 definiuje architekturę i wymagania. SGP.22 zawiera specyfikację techniczną.

Główne komponenty architektury konsumenckiej

eUICC

eUICC to chroniony komponent, który przechowuje profile operatorów i nimi zarządza. Może przechowywać kilka profili, choć konstrukcja urządzenia określa, ile z nich może być jednocześnie włączonych.

Profil eSIM

Profil zawiera subskrypcję operatora i chronione dane uwierzytelniające wymagane do uwierzytelnienia w sieci oraz konfiguracji usług.

SM-DP+

Subscription Manager Data Preparation Plus przygotowuje, zabezpiecza i dostarcza profile do uprawnionych urządzeń konsumenckich.

Local Profile Assistant

Local Profile Assistant, czyli LPA, działa po stronie urządzenia. Wspiera pobieranie profili i zarządzanie nimi oraz pośredniczy pomiędzy SM-DP+ a eUICC.

W smartfonie LPA jest zwykle zintegrowany z ustawieniami sieci komórkowej w systemie operacyjnym i bezpiecznymi funkcjami eSIM. Użytkownik może widzieć aplikację lub sklep pod marką dostawcy, ale chronione operacje na profilach nadal pozostają pod kontrolą platformy urządzenia.

SM-DS

Opcjonalny Subscription Manager Discovery Service pomaga urządzeniu wykryć dostępność profilu. Umożliwia procesy, które nie polegają wyłącznie na ręcznym wpisaniu adresu SM-DP+ lub zeskanowaniu standardowego kodu QR.

Typowy proces provisioningu konsumenckiego

1. Klient kupuje lub zamawia pakiet komórkowy.
2. Operator lub dostawca przygotowuje albo przydziela profil przez SM-DP+.
3. Urządzenie otrzymuje informacje aktywacyjne lub wykrywa dostępny profil.
4. Użytkownik zatwierdza instalację, jeżeli jest to wymagane.
5. LPA nawiązuje wymaganą komunikację z SM-DP+.
6. Profil jest bezpiecznie pobierany i instalowany w eUICC.
7. Użytkownik lub system włącza profil.
8. Modem wykorzystuje go do rejestracji w dozwolonej sieci.

Architektura konsumencka sprawdza się, gdy użytkownik może reagować na komunikaty, potwierdzić zgodę, wybrać właściwą linię i zapewnić połączenie z internetem do pobrania profilu.

Gdzie konsumencki eSIM sprawdza się najlepiej?

• podróżne eSIM dla smartfonów;
• podstawowe abonamenty komórkowe;
• tablety i laptopy z odpowiednim interfejsem eSIM;
• smartwatche powiązane z kontem konsumenckim;
• zastosowania, w których właściciel urządzenia aktywnie wybiera dostawcę;
• niewielkie grupy urządzeń z dostępnym interfejsem i możliwością indywidualnego zarządzania.

Zalety architektury konsumenckiej

• dojrzała obsługa w wielu smartfonach i systemach operacyjnych;
• znane użytkownikom procesy aktywacji cyfrowej i za pomocą kodu QR;
• wybór klienta i jego zgoda uwzględnione w modelu działania;
• wspólny ekosystem SM-DP+;
• bezpośrednia sprzedaż detaliczna i dystrybucja przez aplikacje;
• możliwość przechowywania wielu subskrypcji w kompatybilnych urządzeniach.

Ograniczenia w przypadku flot IoT

Model konsumencki może stwarzać trudności, gdy urządzenia pracują bez obsługi lub nie mają odpowiedniego interfejsu użytkownika.

Operator floty może nie mieć możliwości:

• zeskanowania osobnego kodu QR dla każdego urządzenia;
• zatwierdzenia komunikatu na każdym ekranie;
• utrzymania ciągłej łączności wszystkich urządzeń podczas provisioningu;
• fizycznego odzyskania dostępu do urządzenia po nieudanym pobraniu;
• korzystania z interfejsu konsumenckiego systemu operacyjnego;
• ręcznego skoordynowania tysięcy zmian profili.

Nie oznacza to, że architektury konsumenckiej nigdy nie można używać w urządzeniu o zastosowaniu zbliżonym do IoT. Router z ekranem, interfejsem internetowym i w odpowiednio małej flocie może z niej korzystać. Sprawdzenie rzeczywistych warunków operacyjnych jest ważniejsze niż etykieta produktu.

Jak działa dotychczasowa architektura eSIM M2M?

Architekturę M2M zaprojektowano dla urządzeń zarządzanych zdalnie, szczególnie w motoryzacji i przemyśle. Jej główne dokumenty GSMA to SGP.01 i SGP.02.

W odróżnieniu od modelu konsumenckiego nie zakłada ona, że użytkownik końcowy wybierze pakiet i będzie obsługiwał LPA na urządzeniu.

Główne komponenty M2M

SM-DP

Funkcja Subscription Manager Data Preparation przygotowuje i zabezpiecza profile operatorów przed dostarczeniem.

SM-SR

Funkcja Subscription Manager Secure Routing zarządza bezpieczną komunikacją z eUICC i wspiera zdalne operacje w cyklu życia profilu.

eUICC M2M

eUICC obsługuje odpowiednie procedury zdalnego provisioningu M2M i otrzymuje polecenia za pośrednictwem tej architektury.

Ogólny model działania M2M

Architektura jest w dużym stopniu sterowana przez serwery. Systemy zarządzania inicjują pobranie, włączenie, wyłączenie i usunięcie profilu bez udziału konsumenta stojącego obok urządzenia.

Odpowiada to potrzebom sprzętu zainstalowanego w odległych lokalizacjach i kontrolowanego na podstawie umów biznesowych. Model ten od wielu lat wspiera istotne wdrożenia samochodów połączonych z siecią i systemów przemysłowych.

Zalety architektury M2M

• zaprojektowana dla urządzeń kontrolowanych centralnie;
• nie wymaga konsumenckiego interfejsu użytkownika;
• ugruntowana pozycja w wieloletnich programach motoryzacyjnych i przemysłowych;
• obsługa zdalnego zarządzania cyklem życia;
• dostosowanie do ściśle kontrolowanych biznesowych łańcuchów dostaw.

Wyzwania operacyjne

SM-SR pełni centralną rolę w modelu M2M. Zależności handlowe i techniczne związane z tym komponentem mogą sprawiać, że zmiana dostawcy jest trudniejsza, niż kupujący początkowo zakładał.

Wyzwania mogą obejmować:

• złożoność integracji obejmującej kilka podmiotów;
• długie procesy wdrożenia i certyfikacji;
• zależność od wybranego łańcucha zarządzania subskrypcjami;
• skomplikowane ustalenia dotyczące własności i migracji;
• ograniczoną przydatność w mniejszych lub bardziej elastycznych wdrożeniach;
• trudności handlowe przy zmianie dostawcy łączności.

Dotychczasowa architektura M2M pozostaje właściwa dla wdrożeń zbudowanych na jej podstawie. Nowy projekt IoT powinien jednak porównać ją z SGP.31/32, zamiast zakładać, że „eSIM M2M” jest jedynym wariantem zdalnego zarządzania.

Jak działa architektura IoT SGP.31/32?

GSMA opracowała nowszą architekturę IoT dla eUICC w urządzeniach IoT z ograniczeniami sieciowymi lub ograniczeniami interfejsu użytkownika, albo z oboma rodzajami ograniczeń.

SGP.31 definiuje architekturę i wymagania. SGP.32 zawiera techniczny opis zdalnego provisioningu i zarządzania, architektury eUICC, interfejsów i funkcji bezpieczeństwa.

Projekt łączy użyteczne zasady wcześniejszych architektur:

• zdalne zarządzanie dostosowane do flot;
• możliwość wykorzystania infrastruktury SM-DP+ z ekosystemu konsumenckiego;
• funkcje po stronie urządzenia dostosowane do ograniczeń sprzętu IoT;
• zarządzanie bez konieczności obsługi lokalnego ekranu przez człowieka.

Główne komponenty IoT

SM-DP+

Architektura IoT wykorzystuje SM-DP+ do przygotowania i dostarczania profili. Może to ograniczać potrzebę budowania całkowicie odrębnego ekosystemu przygotowywania profili.

Nie oznacza to, że dowolna integracja z SM-DP+ automatycznie zapewnia kompletną usługę SGP.32. Urządzenie IoT, eUICC, role zarządzania, interfejsy i procedury bezpieczeństwa muszą obsługiwać odpowiednią architekturę.

IoT Profile Assistant

IoT Profile Assistant, czyli IPA, wspiera operacje na profilach po stronie urządzenia w architekturze IoT.

Funkcja ta może być zaimplementowana w różnych miejscach:

• IPAd, gdy IPA jest zaimplementowany w urządzeniu IoT;
• IPAe, gdy IPA jest zaimplementowany w eUICC.

Właściwy wariant zależy od zasobów urządzenia, kontroli nad oprogramowaniem, implementacji eUICC i projektu wdrożenia.

eSIM IoT Remote Manager

eSIM IoT Remote Manager, czyli eIM, wspiera interakcje zdalnego zarządzania z urządzeniami IoT i ich komponentami IPA.

eIM pozwala uprawnionemu procesowi zarządzania flotą inicjować i koordynować operacje w cyklu życia profilu bez skanowania kodu QR na każdym urządzeniu. Jego podpisane pakiety mogą obsługiwać wyzwalanie pobierania profilu, operacje zarządzania stanem profilu, operacje konfiguracji eIM, żądania danych IPA lub eUICC oraz potwierdzenia.

Nie należy mylić eIM z SM-DP+. eIM wspiera zdalną koordynację i zarządzanie, natomiast SM-DP+ przygotowuje i dostarcza profile.

eIM ma centralne znaczenie dla zdalnie koordynowanych operacji floty, ale nie każde pobranie profilu SGP.32 musi rozpoczynać się od instrukcji eIM. Specyfikacja obsługuje również procedury inicjowane przez IPA, w tym wykorzystanie skonfigurowanych informacji SM-DP+ i mechanizmów wykrywania, jeżeli zostały zaimplementowane.

eUICC IoT

eUICC musi obsługiwać odpowiednią architekturę IoT i procedury techniczne. Urządzenie zawierające wbudowany bezpieczny element nie staje się automatycznie kompatybilne z SGP.32.

Uproszczony proces zdalnego zarządzania SGP.32

1. Proces przedsiębiorstwa lub usługi IoT identyfikuje urządzenie wymagające operacji na profilu.
2. Uprawnione środowisko zarządzania wykorzystuje eIM do przekazania wymaganej czynności.
3. IPA urządzenia uczestniczy w procedurze.
4. Profil jest pozyskiwany z SM-DP+ poprzez obsługiwaną procedurę pobierania bezpośredniego lub pośredniego.
5. Profil zostaje zainstalowany i jest zarządzany w eUICC IoT.
6. Urządzenie wykorzystuje wybrany profil do połączenia zgodnie z odpowiednimi zasadami sieci i usługi.

Przy pobieraniu bezpośrednim IPA komunikuje się z SM-DP+. Przy pobieraniu pośrednim eIM uczestniczy w pozyskiwaniu i przekazywaniu zabezpieczonego pakietu profilu przez określone interfejsy. SGP.32 obejmuje także mechanizmy wykrywania, przywracania poprzedniego profilu, profilu awaryjnego i obsługi błędów.

Dokładna kolejność zależy od zastosowania, dostępnej łączności, implementacji IPA i konfiguracji technicznej. Wartość biznesowa polega na możliwości zarządzania operacją na poziomie floty bez konsumenckiego interfejsu w każdym urządzeniu.

Co oznacza „urządzenie IoT z ograniczeniami”?

Ograniczenia nie muszą dotyczyć wyłącznie fizycznego rozmiaru.

Ograniczenia interfejsu użytkownika

Urządzenie może:

• nie mieć wyświetlacza;
• nie mieć klawiatury ani ekranu dotykowego;
• nie mieć aparatu do skanowania kodu QR;
• nie mieć lokalnego operatora;
• znajdować się w zamkniętej lub niedostępnej obudowie.

Ograniczenia sieciowe

Urządzenie może mieć:

• sporadyczną łączność;
• ograniczoną przepustowość;
• wysokie opóźnienia;
• ograniczony zakres protokołów;
• długie okresy uśpienia;
• energooszczędną łączność dalekiego zasięgu;
• zasięg tylko w określonych momentach cyklu pracy.

Ograniczenia zasobów

Urządzenie może mieć również ograniczone:

• możliwości obliczeniowe;
• zasoby pamięci;
• dostępne zasoby energii;
• możliwości obsługi złożonych aplikacji;
• możliwości aktualizacji oprogramowania układowego.

Nie każde urządzenie z ograniczeniami ma wszystkie te cechy. Architekturę należy oceniać w odniesieniu do rzeczywistego sprzętu i warunków pracy.

Konsumenckie SGP.22 a IoT SGP.32

Tabela nie rozstrzyga każdego przypadku granicznego. Niektóre routery działają jak urządzenia konsumenckie. Część urządzeń przemysłowych ma rozbudowany system operacyjny i lokalny interfejs. Niektórymi urządzeniami ubieralnymi zarządza się przez sparowany telefon, a nie bezpośrednio.

Wybór architektury powinien wynikać z rzeczywistego cyklu życia, a nie kategorii marketingowej.

SGP.32 a dotychczasowa architektura M2M

SGP.32 jest często opisywane jako następca wcześniejszego modelu M2M. Taki opis dobrze oddaje kierunek rozwoju, ale może wprowadzać w błąd w kwestiach operacyjnych.

Istniejące wdrożenia M2M nie znikną natychmiast. Pojazdy, liczniki i urządzenia przemysłowe mogą pozostawać aktywne przez dziesięć lat lub dłużej. Ich eUICC i oprogramowanie zaprojektowano dla SGP.01/02 i nie zawsze można je zdalnie przekształcić tak, aby obsługiwały inną architekturę.

Najważniejsze różnice

Co może usprawnić SGP.32?

W odpowiednich nowych wdrożeniach architektura może zapewnić:

• bardziej skalowalne rozwiązanie dla urządzeń IoT z ograniczeniami;
• mniejszą zależność od interakcji z konsumentem;
• wykorzystanie szerszego ekosystemu SM-DP+;
• koordynację na poziomie floty przez funkcje eIM;
• większą elastyczność projektowania łańcuchów dostaw łączności;
• lepsze dopasowanie działań producentów urządzeń, dostawców usług IoT i dostawców łączności.

Są to możliwości architektury, a nie gwarantowane rezultaty biznesowe. Konstrukcja umów, jakość implementacji, interoperacyjność i prawa do zakończenia współpracy pozostają kluczowe.

Czym jest provisioning profili w fabryce?

Niektóre urządzenia potrzebują odpowiedniego profilu podczas produkcji, testów lub początkowej dystrybucji. SGP.41 GSMA definiuje architekturę i wymagania dla provisioningu profili w fabryce, czyli IFPP.

IFPP dotyczy innego etapu niż standardowe zarządzanie profilami urządzeń już wdrożonych. Może pomagać producentom zapewniać łączność podczas produkcji, zamiast wkładania osobno spersonalizowanej karty SIM lub wymagania, aby gotowe urządzenie pobrało pierwszy profil dopiero po wdrożeniu.

Potencjalne korzyści obejmują:

• uproszczenie wariantów produkcyjnych;
• automatyczne przypisywanie profili podczas produkcji;
• wcześniejsze testowanie łączności;
• ograniczenie fizycznej obsługi kart SIM;
• obsługę urządzeń wymagających łączności natychmiast po włączeniu zasilania.

Provisioningu fabrycznego nie należy traktować jako strategii obejmującej cały okres eksploatacji. Po opuszczeniu fabryki urządzenie może nadal potrzebować zdalnego zarządzania profilami i łącznością.

Wybór architektury według zastosowania

Podróżne eSIM dla smartfonów

Prawdopodobny wybór: architektura konsumencka.

Klient ma kompatybilny telefon, może zatwierdzić instalację i korzystać z kodu QR, linku aktywacyjnego lub aplikacji. Priorytety biznesowe to natychmiastowa realizacja zamówienia, jasne instrukcje, zasięg, ceny i wsparcie.

Smartfony pracowników zarządzane przez przedsiębiorstwo

Prawdopodobny wybór: architektura konsumencka połączona z firmowym zarządzaniem urządzeniami i procesami operatora.

Telefony pozostają urządzeniami klasy konsumenckiej, nawet jeśli kupuje je i administruje nimi przedsiębiorstwo. Firmowe mechanizmy kontroli nie zmieniają ich automatycznie w urządzenia IoT SGP.32.

Zarządzane routery

Możliwy wybór: architektura konsumencka lub IoT, zależnie od routera.

Router z interfejsem internetowym i dostępnym procesem instalacji może korzystać z konsumenckiego eSIM. Duża bezobsługowa flota może skorzystać z architektury IoT. Kupujący muszą sprawdzić dokładny modem, eUICC, oprogramowanie układowe i obsługę zarządzania, zamiast uznawać określenie „eSIM-ready” za wystarczające.

Telematyka pojazdów

Możliwy wybór: dotychczasowe M2M dla istniejących programów, SGP.32 dla odpowiednich nowych projektów.

Programy motoryzacyjne mają długie cykle życia, wymagania bezpieczeństwa i złożone łańcuchy dostaw. Migracja wymaga starannego planowania sprzętu i platformy.

Inteligentne liczniki i czujniki środowiskowe

Prawdopodobny wybór dla nowych projektów urządzeń z ograniczeniami: architektura IoT.

Urządzenia te mogą nie mieć ekranów, dysponować ograniczonym zasilaniem i pracować przez wiele lat. Zdalne zarządzanie na poziomie floty jest bardziej odpowiednie niż indywidualna instalacja kodem QR.

Terminale płatnicze i kioski

Możliwy wybór: architektura konsumencka lub IoT.

Decyzja zależy od tego, czy terminal udostępnia kontrolowany interfejs lokalny, czy dostępny jest personel terenowy oraz ile urządzeń wymaga skoordynowanej zmiany profili.

Urządzenia uzyskujące łączność w fabryce

Możliwy wybór: IFPP do początkowego provisioningu połączone z zarządzaniem cyklem życia w M2M lub IoT.

Proces fabryczny może zapewnić początkową łączność, a architektura wdrożenia określa sposób późniejszych zmian.

Pytania przed wyborem SGP.22 lub SGP.32

1. Czy urządzenie ma użyteczny interfejs lokalny?
2. Czy podczas początkowego provisioningu będzie obecny człowiek?
3. Czy urządzenie może skanować, otwierać lub odbierać konsumenckie informacje aktywacyjne?
4. Czy przed zainstalowaniem nowego profilu dostępne jest niezawodne połączenie z internetem?
5. Iloma urządzeniami trzeba zarządzać?
6. Czy zmiany profili będą indywidualne, czy obejmą całą flotę?
7. Jak długo urządzenia pozostaną w eksploatacji?
8. Czy oprogramowanie układowe urządzenia i eUICC obsłużą wymaganą architekturę?
9. Czy IPA jest zaimplementowany w urządzeniu, czy w eUICC?
10. Kto będzie operatorem lub dostawcą eIM?
11. Które platformy SM-DP+ i którzy dostawcy profili są kompatybilni?
12. Jaka łączność początkowa, czyli bootstrap, lub awaryjna, czyli fallback, jest dostępna?
13. Co się stanie, jeżeli pobieranie profilu zostanie przerwane?
14. Czy urządzenie może odzyskać sprawność bez fizycznego dostępu?
15. Który podmiot może zlecać i zatwierdzać zmiany profili?
16. Jak flota przejdzie do innego dostawcy łączności?
17. Jakie certyfikaty, procesy zgodności i mechanizmy kontroli produkcji mają zastosowanie?
18. Które zdarzenia cyklu życia platforma zarządzania może rzeczywiście obserwować?

Dlaczego łączność bootstrap jest ważna?

Zdalne pobranie profilu wymaga ścieżki komunikacyjnej. Nowy profil nie pomoże urządzeniu skontaktować się z usługą provisioningu, dopóki nie zostanie pobrany.

Projekt IoT potrzebuje więc strategii początkowej łączności. Zależnie od implementacji może ona obejmować:

• profil początkowy, czyli bootstrap;
• łączność fabryczną lub lokalną;
• dostęp przez Wi-Fi lub przewód;
• inny aktywny profil;
• kontrolowaną sieć uruchomieniową;
• łączność zapewnioną w procesie wdrażania urządzenia.

Rozwiązanie bootstrap należy ocenić pod kątem zasięgu, kosztu, okresu działania i zależności od dostawcy. Profil, który wygaśnie zbyt wcześnie lub działa wyłącznie w kraju produkcji, może uniemożliwić późniejszy provisioning.

Znaczenie ma również odporność na awarie. Jeśli pobranie profilu docelowego lub połączenie przez niego nie powiedzie się, urządzenie może potrzebować zachowanej, działającej ścieżki awaryjnej, aby umożliwić kolejną próbę operacji.

Kompatybilność urządzenia wymaga więcej niż logo eSIM

Urządzenie „obsługujące eSIM” może wspierać tylko określoną architekturę lub proces.

Aby zapewnić niezawodne wdrożenie, należy zweryfikować:

• sprzęt eUICC i obsługę w systemie operacyjnym;
• obsługiwaną architekturę GSMA i wersję specyfikacji;
• implementację LPA lub IPA;
• kompatybilność eIM tam, gdzie jest wymagany;
• interoperacyjność SM-DP+;
• modem i obsługiwane pasma radiowe;
• działanie bootstrap i fallback;
• możliwość zdalnej aktualizacji oprogramowania układowego;
• ograniczenia przechowywania i włączania profili;
• odzyskiwanie sprawności po przerwaniu zasilania lub łączności;
• dowody zgodności i certyfikacji.

Konsumencki router eSIM przyjmujący kod QR nie jest automatycznie routerem SGP.32. Wbudowany eUICC nie jest automatycznie zarządzalny przez każdą usługę zdalnego provisioningu.

Wymagania operacyjne wobec platformy eSIM IoT

Pobieranie profili to tylko część zarządzania flotą IoT.

Praktyczna platforma może wymagać następujących funkcji:

• inwentaryzacja urządzeń i eUICC;
• powiązania między urządzeniem, EID, profilem, ICCID i zasobem klienta;
• operacje zbiorcze z kontrolą zatwierdzania;
• harmonogramy i etapowe wdrożenia;
• statusy, ponowienia i klasyfikacja błędów;
• zasady łączności i widoczność sieci;
• monitorowanie zużycia i alerty;
• zawieszanie i ponowne uruchamianie usług;
• historia audytowa;
• role dostępu dla organizacji klientów;
• integracja przez API i webhooki;
• zarządzanie bootstrap i fallback;
• bezpieczne przekazanie obsługi innemu dostawcy i procedury zakończenia współpracy.

System powinien odróżniać stan profilu od stanu sieci. „Profil włączony” nie dowodzi, że czujnik zarejestrował się w sieci, połączył z docelowym punktem aplikacji lub dostarczył użyteczne dane.

Pytania handlowe i umowne

Decyzje dotyczące architektury tworzą długoterminowe zależności handlowe.

Umowy powinny wyjaśniać:

• własność eUICC, profili i identyfikatorów;
• kontrolę nad eIM, SM-DP+, SM-SR lub powiązanymi kontami zarządzania;
• prawa do przenoszenia profili lub urządzeń do innego dostawcy;
• odpowiedzialność za łączność bootstrap;
• poziomy usług dla operacji provisioningu;
• wsparcie wdrożonych wersji specyfikacji;
• odpowiedzialność za odnawianie certyfikatów i ich cykl życia;
• dostęp do danych i ich retencję;
• eskalację incydentów;
• koszty pobrań, zmian profilu, włączeń, przechowywania i używania API;
• postępowanie z urządzeniami po zakończeniu umowy.

Najniższa cena za megabajt może stracić znaczenie, jeżeli flota nie może zmienić dostawcy lub odzyskać sprawności po nieudanej zmianie profilu.

Migracja i współistnienie architektur

Duże organizacje powinny zakładać współistnienie architektur.

Firma może jednocześnie obsługiwać:

• starsze urządzenia motoryzacyjne wykorzystujące SGP.01/02;
• smartfony wykorzystujące SGP.21/22;
• nowe czujniki zaprojektowane dla SGP.31/32;
• urządzenia z profilami wgranymi fabrycznie, rozpoczynające eksploatację dzięki IFPP.

Wymiana wszystkich urządzeń naraz rzadko jest ekonomicznie uzasadniona. Warstwa zarządzania powinna więc utrzymywać przejrzystą ewidencję architektury, możliwości eUICC, dostawcy profilu i dostępnych operacji cyklu życia dla każdej grupy urządzeń.

Rozsądne podejście do migracji

1. Podziel istniejącą bazę według urządzeń, modemów, eUICC i architektury.
2. Określ, które urządzenia mogą obsłużyć nową metodę provisioningu, a które wymagają wymiany.
3. Zdefiniuj wymagania dla przyszłych urządzeń, wskazując wprost docelową architekturę GSMA.
4. Przetestuj interoperacyjność rzeczywistego zestawu eUICC, IPA, eIM i SM-DP+.
5. Zweryfikuj scenariusze bootstrap, przywracania poprzedniego profilu i utraty łączności.
6. Przeprowadź kontrolowany pilotaż w reprezentatywnych krajach i sieciach.
7. Migruj etapami według mierzalnych kryteriów powodzenia.
8. Zachowaj możliwość operacyjnej obsługi starszych urządzeń przez pozostały okres ich eksploatacji.

Migracja architektury nigdy nie powinna zaczynać się od zbiorczej zmiany profili bez przetestowanej ścieżki odzyskania sprawności.

Częste nieporozumienia

„Wszystkie eSIM działają z SGP.22 i SGP.32”

Nie. Kompatybilność zależy od eUICC, oprogramowania urządzenia, komponentów provisioningu i obsługiwanej architektury.

„SGP.32 to po prostu konsumencki eSIM bez ekranu”

Nie. Wprowadza model zarządzania właściwy dla IoT, z IPA i eIM, który uwzględnia ograniczenia urządzeń i operacje na flotach.

„SGP.32 natychmiast zastępuje wszystkie eSIM M2M”

Nie. Istniejące urządzenia M2M mogą działać jeszcze przez wiele lat i mogą nie nadawać się do aktualizacji do nowej architektury.

„Używanie SM-DP+ oznacza, że całe rozwiązanie obsługuje SGP.32”

Nie. SM-DP+ to jeden z elementów architektury. Urządzenie, eUICC, IPA, eIM i interfejsy również muszą obsługiwać wymagane procedury.

„eSIM IoT automatycznie zapewnia zasięg wielu sieci”

Nie. Zdalny provisioning zmienia sposób zarządzania profilami. Dostęp do sieci nadal zależy od komercyjnego profilu, operatora i umów roamingowych.

„Flota zawsze może zdalnie zmienić dostawcę”

Tylko wtedy, gdy pozwala na to kompletny projekt techniczny i umowny. Liczą się łączność bootstrap, uprawnienia, kontrola nad zarządzaniem, kompatybilne profile i procedury odzyskiwania sprawności.

„Każdy router powinien korzystać z SGP.32”

Niekoniecznie. Router zarządzany przez użytkownika może dobrze działać z architekturą konsumencką. Właściwy wybór zależy od skali floty, dostępności urządzeń i ich cyklu życia.

Jaką rolę SIM24.biz odgrywa w wyborze architektury?

SIM24.biz wspiera firmy budujące pod własną marką ofertę łączności konsumenckiej, fizycznych kart SIM i IoT.

Biznesowym punktem wyjścia powinny być produkt i cykl życia urządzenia, a nie numer specyfikacji wybrany w oderwaniu od kontekstu. Marka podróżna obsługująca smartfony ma inne wymagania provisioningu niż producent wdrażający zamknięte lokalizatory w kilku krajach.

SIM24.biz może pomóc partnerowi określić wymagany model łączności, platformy i operacji. Dokładną obsługę architektury GSMA, typu eUICC, komponentu provisioningu lub funkcji zdalnego cyklu życia należy potwierdzić dla wybranej implementacji i zestawu dostawców. Na etapie tego draftu nie deklaruje się publicznie, że SIM24.biz samodzielnie obsługuje eIM, SM-DP+, SM-SR lub certyfikowaną platformę SGP.32.

To rozróżnienie chroni obie strony. Pozwala uniknąć obietnic, że konsumencki produkt z kodem QR zapewnia pełne zarządzanie flotą IoT albo że eUICC IoT może korzystać z dowolnej platformy profili bez prac nad kompatybilnością.

Podsumowanie

Konsumencki eSIM i eSIM IoT opierają się na tej samej ogólnej idei: profile operatorów komórkowych mogą być bezpiecznie dostarczane do kompatybilnego eUICC. Ich środowiska operacyjne zasadniczo się jednak różnią.

Architektura konsumencka SGP.21/22 zakłada urządzenie zdolne do udziału w interaktywnym procesie pozyskiwania profilu. Wykorzystuje takie komponenty jak SM-DP+, LPA i opcjonalny SM-DS oraz dobrze pasuje do smartfonów, tabletów i urządzeń obsługiwanych przez użytkownika.

Architekturę IoT SGP.31/32 zaprojektowano dla urządzeń z ograniczeniami łączności, interfejsu użytkownika lub obu tych obszarów. Wprowadza IPA i eIM, aby umożliwić zdalne zarządzanie flotą z wykorzystaniem infrastruktury profili SM-DP+.

Architektura M2M SGP.01/02 pozostaje ważna w istniejących wdrożeniach motoryzacyjnych i przemysłowych. SGP.41 dodaje odrębny wariant provisioningu profili podczas produkcji.

Żaden z tych standardów nie eliminuje potrzeby testowania urządzeń, łączności bootstrap, umów sieciowych, obsługi floty ani jasnych umów z dostawcami. Właściwa architektura pozwala realizować provisioning, zapewniać łączność, odzyskiwać sprawność i migrować rzeczywistą grupę urządzeń przez cały planowany okres ich eksploatacji.

Najczęściej zadawane pytania

Jaka jest główna różnica między SGP.22 a SGP.32?

SGP.22 to specyfikacja techniczna konsumenckiej architektury eSIM, powszechnie używanej w interaktywnych urządzeniach, takich jak smartfony. SGP.32 to specyfikacja techniczna architektury IoT zaprojektowanej dla urządzeń IoT z ograniczeniami sieciowymi lub interfejsu użytkownika oraz do zarządzania flotą.

Czym różni się SGP.21 od SGP.22?

SGP.21 definiuje architekturę konsumencką i wymagania. SGP.22 zawiera szczegółową specyfikację techniczną implementującą tę architekturę.

Czym różni się SGP.31 od SGP.32?

SGP.31 definiuje architekturę i wymagania provisioningu eSIM w urządzeniach IoT z ograniczeniami. SGP.32 określa szczegółowe procedury techniczne, interfejsy, architekturę eUICC i funkcje bezpieczeństwa.

Czym są IPA i eIM?

IoT Profile Assistant to funkcja po stronie urządzenia wspierająca operacje na profilach w architekturze SGP.31/32. Może znajdować się w urządzeniu jako IPAd lub w eUICC jako IPAe. eSIM IoT Remote Manager wspiera uprawnione interakcje zdalnego zarządzania z IPA.

Czy SGP.32 wykorzystuje SM-DP+?

Tak. Architektura IoT wykorzystuje SM-DP+ do przygotowania i dostarczania profili. Kompletne rozwiązanie nadal wymaga kompatybilnego urządzenia IoT, eUICC, IPA, eIM i interfejsów zarządzania.

Czy SGP.32 jest lepsze od SGP.22?

Jest lepiej dopasowane do określonych środowisk IoT, ale nie jest uniwersalnie lepsze. Podróżny eSIM dla smartfona zwykle pasuje do architektury konsumenckiej. Bezobsługowa flota czujników może pasować do SGP.32.

Czy SGP.32 zastępuje SGP.01 i SGP.02?

Zapewnia nowszą architekturę dla odpowiednich wdrożeń IoT, ale istniejące urządzenia i platformy M2M będą współistnieć przez lata. Migracja zależy od sprzętu, oprogramowania, umów i cykli wymiany urządzeń.

Czy istniejące urządzenie z konsumenckim eSIM można zaktualizować do SGP.32?

Nie automatycznie. Urządzenie, eUICC i oprogramowanie muszą obsługiwać architekturę IoT. Sama aktualizacja oprogramowania układowego może nie wystarczyć.

Czy SGP.32 może przełączyć urządzenie między operatorami komórkowymi?

Obsługuje zdalny provisioning profili i zarządzanie nimi, co może umożliwiać zmianę operatora, jeżeli istnieją kompatybilne profile, uprawnienia, łączność i ustalenia handlowe. Nie znosi ograniczeń urządzenia, umowy ani sieci.

Czy SGP.32 jest wymagane w każdym wdrożeniu IoT?

Nie. Niektóre dostępne dla obsługi routery lub terminale mogą skutecznie korzystać z konsumenckiego eSIM. Istniejące wdrożenia przemysłowe mogą korzystać z architektury M2M. Decyzja zależy od rzeczywistego modelu operacyjnego.

Czym jest SGP.41?

SGP.41 definiuje architekturę i wymagania provisioningu profili w fabryce. Dotyczy dostarczania profili podczas produkcji urządzenia i uzupełnia, a nie zastępuje, zarządzanie cyklem życia po wdrożeniu.

Wybierz architekturę eSIM dopasowaną do całego cyklu życia urządzenia

SIM24.biz pomaga firmom projektować ofertę łączności konsumenckiej i IoT pod własną marką z uwzględnieniem rzeczywistych urządzeń, warunków pracy i wymagań zarządzania.

Porozmawiaj z SIM24.biz o odpowiednim modelu provisioningu i łączności dla Twojego produktu lub floty.

Źródła

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