Потребительская eSIM и IoT eSIM: SGP.22, SGP.32 и другие архитектуры GSMA

eSIM в смартфоне путешественника и eSIM в удалённо установленном электросчётчике могут хранить загружаемые профили мобильных операторов. При этом они не обязательно используют одинаковую архитектуру провижининга или операционную модель.

Потребительская eSIM разрабатывалась для устройств с экранами, операционными системами, доступом в интернет и людьми, которые могут подтвердить установку. IoT-развёртывания могут включать тысячи необслуживаемых устройств с ограниченным питанием, непостоянной связью, без камеры и без практической возможности отсканировать QR-код.

Поэтому GSMA разработала разные архитектуры удалённого провижининга SIM для разных условий:

• SGP.01 и SGP.02 определяют устоявшуюся архитектуру M2M;
• SGP.21 и SGP.22 определяют потребительскую архитектуру, широко используемую смартфонами и другими потребительскими устройствами;
• SGP.31 и SGP.32 определяют более новую архитектуру IoT для устройств с ограниченными сетевыми возможностями или пользовательским интерфейсом;
• SGP.41 определяет архитектуру и требования для заводского провижининга профилей, или IFPP.

Номера важны, но они не должны становиться отправной точкой коммерческого решения. Правильная архитектура зависит от устройства, модели развёртывания, доступной связи, степени участия пользователя, ожидаемого срока эксплуатации и стороны, отвечающей за управление профилями.

Главное

• Потребительская, M2M- и IoT-архитектуры eSIM решают разные операционные задачи. Это не просто разные названия одного рабочего процесса.
• SGP.21 описывает архитектуру и требования потребительской eSIM. SGP.22 содержит соответствующую техническую спецификацию.
• SGP.31 описывает более новую архитектуру и требования eSIM IoT. SGP.32 содержит спецификацию её технической реализации.
• Потребительская eSIM обычно использует SM-DP+, Local Profile Assistant и, необязательно, SM-DS. Пользователь или устройство, как правило, непосредственно участвует в загрузке профиля.
• IoT-архитектура SGP.31/32 добавляет IoT Profile Assistant и eSIM IoT Remote Manager для поддержки устройств без подходящего локального интерфейса и устройств с ограниченными возможностями связи.
• IoT-архитектура может использовать инфраструктуру SM-DP+, но это не означает, что любой потребительский eSIM-сервис автоматически подходит для парков SGP.32.
• Устоявшаяся архитектура M2M использует такие компоненты, как SM-DP и SM-SR, и в значительной степени управляется с серверной стороны. Она сохраняет значение для существующих автомобильных и промышленных внедрений.
• SGP.32 не обновляет удалённо любое уже развёрнутое M2M- или потребительское устройство. Поддержка должна существовать на уровне eUICC, ПО устройства, канала связи и систем управления.
• Парку устройств может потребоваться поддерживать более одной архитектуры в течение длительного переходного периода.
• Качественная коммерческая платформа разделяет провижининг профилей, сетевую связь и управление жизненным циклом парка, а не объединяет их в одну функцию под названием «eSIM».

Зачем eSIM несколько архитектур?

Удалённый провижининг SIM должен учитывать реальные возможности целевого устройства.

Смартфон обычно имеет:

• экран и меню настроек;
• пользователя, который может дать согласие;
• Wi-Fi или другое интернет-соединение;
• операционную систему с интерфейсом eSIM;
• достаточное питание и вычислительные возможности для интерактивной установки;
• камеру, приложение или обработчик ссылок.

У подключённого датчика может не быть ничего из перечисленного. Он может находиться под землёй, внутри герметичного оборудования или входить в парк, распределённый по нескольким странам. Он может просыпаться только периодически, использовать радиотехнологию с ограниченными возможностями и должен работать десять лет без ручного вмешательства.

У автопроизводителя другой набор требований. Автомобили могут выпускаться в одной стране, поставляться по всему миру, назначаться разным поставщикам услуг и должны поддерживать экстренные вызовы, диагностику и подключённые сервисы на протяжении длительного жизненного цикла.

Одна архитектура не может быть одинаково оптимизирована для всех этих условий.

Краткий обзор спецификаций GSMA

Таблица намеренно упрощена. Каждая спецификация содержит подробные роли, интерфейсы, процедуры безопасности и функции жизненного цикла. Компаниям следует подтверждать применимую версию и реализацию у поставщиков eUICC, устройств, связи и платформы.

Что означают номера документов GSMA?

Стандарты GSMA для eSIM разделены на взаимосвязанные документы.

Документы архитектуры и требований

Они описывают роли, сценарии использования, принципы и требования архитектуры.

• SGP.01 охватывает архитектуру и требования M2M.
• SGP.21 охватывает потребительскую архитектуру и требования.
• SGP.31 охватывает архитектуру и требования IoT.
• SGP.41 охватывает архитектуру и требования заводского провижининга профилей.

Технические спецификации

Они определяют подробные технические процедуры, интерфейсы, сообщения и функции безопасности, необходимые для совместимых реализаций.

• SGP.02 является технической спецификацией архитектуры M2M.
• SGP.22 является технической спецификацией удалённого провижининга потребительских SIM.
• SGP.32 является технической спецификацией архитектуры eSIM IoT.

Сокращённые обозначения «eSIM SGP.22» или «eSIM SGP.32» удобны, но ни один из номеров не описывает отдельный физический формат SIM. Документы описывают архитектуры удалённого провижининга и техническое поведение вокруг совместимой eUICC и экосистемы профилей.

Как работает потребительская архитектура eSIM

Потребительская архитектура наиболее знакома пользователям смартфонов. Клиент покупает тариф и добавляет его через настройки устройства, QR-код, приложение оператора, уведомление, ссылку активации или поддерживаемый операционной системой процесс переноса.

SGP.21 определяет архитектуру и требования. SGP.22 содержит техническую спецификацию.

Основные потребительские компоненты

eUICC

eUICC представляет собой защищённый компонент, который хранит профили операторов и управляет ими. Он может хранить несколько профилей, хотя конструкция устройства определяет, сколько из них можно включить одновременно.

Профиль eSIM

Профиль содержит подписку оператора и защищённые учётные данные, необходимые для сетевой аутентификации и настройки услуг.

SM-DP+

Subscription Manager Data Preparation Plus подготавливает, защищает и доставляет профили подходящим потребительским устройствам.

Local Profile Assistant

Local Profile Assistant, или LPA, работает на стороне устройства. Он поддерживает загрузку и управление профилями и выступает посредником между SM-DP+ и eUICC.

В смартфоне LPA обычно интегрирован с настройками сотовой связи операционной системы и защищёнными функциями eSIM. Пользователь может видеть брендированное приложение или витрину, но защищённые операции с профилем остаются под контролем платформы устройства.

SM-DS

Необязательный Subscription Manager Discovery Service помогает устройству обнаружить доступный профиль. Он позволяет реализовывать сценарии, которые не зависят полностью от ручного ввода адреса SM-DP+ или сканирования обычного QR-кода.

Типичный процесс потребительского провижининга

1. Клиент покупает или запрашивает мобильный тариф.
2. Оператор или поставщик подготавливает или назначает профиль через SM-DP+.
3. Устройство получает сведения для активации или обнаруживает доступный профиль.
4. Пользователь подтверждает установку, когда это требуется.
5. LPA устанавливает необходимое взаимодействие с SM-DP+.
6. Профиль безопасно загружается и устанавливается на eUICC.
7. Пользователь или система включает профиль.
8. Модем использует его для регистрации в разрешённой сети.

Потребительская архитектура хорошо работает, когда пользователь может отвечать на запросы, подтверждать согласие, выбирать нужную линию и обеспечивать доступ в интернет для загрузки профиля.

Где потребительская eSIM подходит лучше всего

• туристические eSIM для смартфонов;
• основные мобильные подписки;
• планшеты и ноутбуки с подходящим интерфейсом eSIM;
• умные часы, связанные с потребительским аккаунтом;
• сценарии, в которых владелец устройства самостоятельно выбирает поставщика;
• небольшие количества оборудования с доступным интерфейсом и возможностью индивидуального управления.

Сильные стороны потребительской архитектуры

• зрелая поддержка во многих смартфонах и операционных системах;
• привычные сценарии QR-кодов и цифровой активации;
• выбор и согласие клиента встроены в операционную модель;
• распространённая экосистема SM-DP+;
• прямая розничная продажа и распространение через приложения;
• поддержка нескольких сохранённых подписок на совместимых устройствах.

Ограничения для IoT-парков

Потребительская модель может быть неудобной, когда устройства работают без присутствия человека или не имеют подходящего пользовательского интерфейса.

Оператор парка может не иметь возможности:

• сканировать отдельный QR-код для каждого устройства;
• подтверждать запрос на каждом экране;
• поддерживать непрерывное подключение каждого устройства во время провижининга;
• физически восстанавливать устройство после неудачной загрузки;
• зависеть от интерфейса потребительской операционной системы;
• вручную координировать тысячи изменений профилей.

Это не означает, что потребительскую архитектуру никогда нельзя использовать в устройстве, похожем на IoT. Роутер с экраном, веб-интерфейсом и управляемым размером парка может её использовать. Проверка реальной эксплуатации важнее категории продукта.

Как работает устоявшаяся архитектура M2M eSIM

Архитектура M2M разрабатывалась для удалённо управляемых устройств, прежде всего в автомобильной и промышленной среде. Её основные документы GSMA: SGP.01 и SGP.02.

В отличие от потребительской модели, она не предполагает, что конечный пользователь выберет тариф и будет взаимодействовать с LPA на устройстве.

Основные компоненты M2M

SM-DP

Функция Subscription Manager Data Preparation подготавливает и защищает профили операторов для доставки.

SM-SR

Функция Subscription Manager Secure Routing управляет защищённым взаимодействием с eUICC и поддерживает удалённые операции жизненного цикла профиля.

M2M eUICC

eUICC поддерживает соответствующие процедуры удалённого провижининга M2M и получает команды через эту архитектуру.

Общая операционная модель M2M

Архитектура в значительной степени управляется с серверной стороны. Системы управления инициируют загрузку, включение, выключение и удаление профиля, не завися от потребителя, находящегося рядом с устройством.

Это подходит оборудованию, установленному удалённо и управляемому в рамках корпоративных договоров. Такая модель много лет поддерживает значимые автомобильные и промышленные внедрения.

Сильные стороны архитектуры M2M

• рассчитана на централизованно управляемые устройства;
• не требует потребительского пользовательского интерфейса;
• давно используется в автомобильных и промышленных программах с длительным сроком жизни;
• поддерживает удалённое управление жизненным циклом;
• подходит строго контролируемым корпоративным цепочкам поставок.

Операционные сложности

SM-SR играет центральную роль в модели M2M. Коммерческие и технические отношения вокруг этого компонента могут делать смену поставщиков сложнее, чем покупатели первоначально ожидают.

Сложности могут включать:

• интеграцию нескольких сторон;
• длительные программы подключения и сертификации;
• зависимость от выбранной цепочки управления подписками;
• сложные условия владения и миграции;
• ограниченную пригодность для небольших или более гибких внедрений;
• коммерческие затруднения при смене поставщика связи.

Устоявшаяся архитектура M2M остаётся подходящей для систем, спроектированных под неё. Тем не менее новому IoT-проекту следует сравнить её с SGP.31/32, а не предполагать, что «M2M eSIM» является единственным вариантом удалённого управления.

Как работает IoT-архитектура SGP.31/32

GSMA разработала более новую IoT-архитектуру для eUICC в IoT-устройствах с ограниченными сетевыми возможностями и/или пользовательским интерфейсом.

SGP.31 определяет архитектуру и требования. SGP.32 содержит техническое описание удалённого провижининга и управления, архитектуры eUICC, интерфейсов и функций безопасности.

Проект объединяет полезные принципы более ранних архитектур:

• удалённое управление, подходящее для парков устройств;
• возможность использовать инфраструктуру SM-DP+ из потребительской экосистемы;
• функции на стороне устройства, адаптированные к IoT-оборудованию с ограничениями;
• управление без необходимости работы человека с локальным экраном.

Основные компоненты IoT

SM-DP+

IoT-архитектура использует SM-DP+ для подготовки и доставки профилей. Это может уменьшить потребность в полностью отдельной экосистеме подготовки профилей.

Это не означает, что любая интеграция SM-DP+ автоматически предоставляет полноценный сервис SGP.32. IoT-устройство, eUICC, роли управления, интерфейсы и процедуры безопасности должны поддерживать соответствующую архитектуру.

IoT Profile Assistant

IoT Profile Assistant, или IPA, обеспечивает поддержку операций с профилями на стороне устройства в IoT-архитектуре.

Эта функция может быть реализована в разных местах:

• IPAd, когда IPA реализован в IoT-устройстве;
• IPAe, когда IPA реализован в eUICC.

Подходящий вариант зависит от ресурсов устройства, контроля над программным обеспечением, реализации eUICC и проекта развёртывания.

eSIM IoT Remote Manager

eSIM IoT Remote Manager, или eIM, поддерживает взаимодействия удалённого управления с IoT-устройствами и их IPA.

eIM позволяет уполномоченному процессу управления парком запускать и координировать операции жизненного цикла профиля без необходимости сканирования QR-кода пользователем на каждом устройстве. Его подписанные пакеты могут поддерживать запуск загрузки профиля, операции управления состоянием профиля, операции настройки eIM, запросы данных IPA или eUICC и подтверждения.

eIM не следует путать с SM-DP+. eIM помогает в удалённой координации и управлении, тогда как SM-DP+ подготавливает и доставляет профили.

eIM занимает центральное место в удалённо координируемых операциях парка, но не каждая загрузка профиля SGP.32 должна начинаться с команды eIM. Спецификация также поддерживает процедуры, инициируемые IPA, включая использование настроенных данных SM-DP+ и механизмов обнаружения там, где они реализованы.

IoT eUICC

eUICC должна поддерживать применимую IoT-архитектуру и технические процедуры. Наличие встроенного защищённого элемента не делает устройство автоматически совместимым с SGP.32.

Упрощённый удалённо управляемый процесс SGP.32

1. Корпоративный процесс или процесс IoT-сервиса определяет устройство, которому требуется операция с профилем.
2. Уполномоченная среда управления использует eIM для передачи требуемого действия.
3. IPA устройства участвует в процедуре.
4. Профиль получается из SM-DP+ через поддерживаемую процедуру прямой или непрямой загрузки.
5. Профиль устанавливается на IoT eUICC и управляется на ней.
6. Устройство использует выбранный профиль для подключения согласно применимым сетевым и сервисным политикам.

При прямой загрузке IPA взаимодействует с SM-DP+. При непрямой загрузке eIM участвует в получении и передаче защищённого пакета профиля через определённые интерфейсы. SGP.32 также включает механизмы обнаружения, отката профиля, резервного профиля и обработки ошибок.

Точная последовательность зависит от сценария, доступной связи, реализации IPA и технической конфигурации. Бизнес-ценность состоит в том, что операцией можно управлять на уровне парка без потребительского интерфейса на каждом устройстве.

Что означает «IoT-устройство с ограничениями»?

Ограничения могут касаться не только физического размера.

Ограничения пользовательского интерфейса

У устройства может быть:

• отсутствие дисплея;
• отсутствие клавиатуры или сенсорного экрана;
• отсутствие камеры для QR-кода;
• отсутствие оператора на месте;
• герметичный или недоступный корпус.

Сетевые ограничения

Устройство может иметь:

• непостоянную связь;
• ограниченную пропускную способность;
• высокую задержку;
• ограничения протоколов;
• длительные интервалы сна;
• подключение через энергоэффективную сеть большой дальности;
• покрытие только в определённые моменты рабочего цикла.

Ограничения ресурсов

Устройство также может иметь ограниченные:

• вычислительные возможности;
• память;
• энергетический бюджет;
• возможности по сложности приложений;
• возможности обновления прошивки.

Не у каждого ограниченного устройства присутствуют все эти характеристики. Архитектуру необходимо оценивать применительно к фактическому оборудованию и условиям эксплуатации.

Потребительская SGP.22 и IoT SGP.32

Таблица не решает каждый пограничный случай. Некоторые роутеры ведут себя как потребительские устройства. Некоторое промышленное оборудование имеет мощную операционную систему и локальный интерфейс. Некоторые носимые устройства управляются через связанный телефон, а не напрямую.

Архитектуру следует выбирать по реальному жизненному циклу, а не по маркетинговой категории.

SGP.32 и устоявшаяся архитектура M2M

SGP.32 часто описывают как преемника более ранней модели M2M. Это полезно для понимания направления развития, но может вводить в заблуждение с операционной точки зрения.

Существующие M2M-развёртывания не исчезнут сразу. Автомобили, счётчики и промышленные устройства могут работать десять лет и дольше. Их eUICC и ПО разрабатывались для SGP.01/02 и не обязательно могут быть удалённо переведены на другую архитектуру.

Ключевые различия

Что может улучшить SGP.32

Для подходящих новых внедрений архитектура может предложить:

• более масштабируемый подход для IoT-оборудования с ограничениями;
• меньшую зависимость от взаимодействия с потребителем;
• использование более широкой экосистемы SM-DP+;
• координацию на уровне парка через функции eIM;
• большую гибкость построения цепочек поставщиков связи;
• лучшее согласование производителей устройств, поставщиков IoT-сервисов и поставщиков связи.

Это архитектурные возможности, а не гарантированные коммерческие результаты. Структура договора, качество реализации, совместимость и права на выход из отношений с поставщиком остаются критически важными.

Что такое заводской провижининг профилей?

Некоторым устройствам подходящий профиль нужен во время производства, тестирования или первоначального распределения. SGP.41 GSMA определяет архитектуру и требования заводского провижининга профилей, или IFPP.

IFPP относится к другому этапу, чем обычное управление профилями в эксплуатации. Он может помочь производителям обеспечить провижининг связи во время производства вместо установки отдельно персонализированной SIM-карты или необходимости первой загрузки профиля готовым устройством только после развёртывания.

Потенциальные преимущества включают:

• упрощение производственных вариантов;
• автоматическое назначение профиля во время производства;
• более раннюю проверку связи;
• уменьшение работы с физическими SIM;
• поддержку устройств, которым связь нужна сразу после включения.

Заводской провижининг не следует считать полной стратегией на весь срок службы. После выхода с завода устройству всё ещё может потребоваться удалённое управление профилями и связью.

Выбор архитектуры по сценарию использования

Туристическая eSIM для смартфонов

Вероятный выбор: потребительская архитектура.

У клиента есть совместимый телефон, он может подтвердить установку и использовать QR-код, ссылку активации или приложение. Коммерческими приоритетами являются мгновенная доставка, понятные инструкции, покрытие, цены и поддержка.

Смартфоны сотрудников под управлением предприятия

Вероятный выбор: потребительская архитектура вместе с корпоративным управлением устройствами и процессами оператора.

Телефоны остаются устройствами потребительского класса, даже если их покупает и администрирует компания. Корпоративные средства контроля не превращают их автоматически в IoT-устройства SGP.32.

Управляемые роутеры

Возможный выбор: потребительская или IoT-архитектура в зависимости от роутера.

Роутер с веб-интерфейсом и доступной процедурой установки может использовать потребительскую eSIM. Для большого необслуживаемого парка может быть полезна IoT-архитектура. Покупателям необходимо проверять конкретную поддержку модема, eUICC, прошивки и управления, а не считать обозначение «eSIM-ready» достаточным.

Автомобильная телематика

Возможный выбор: устоявшаяся M2M для существующих программ, SGP.32 для подходящих новых разработок.

Автомобильные программы имеют длительные жизненные циклы, требования безопасности и сложные цепочки поставщиков. Миграция требует тщательного планирования оборудования и платформы.

Умные счётчики и датчики окружающей среды

Вероятный выбор для новых устройств с ограничениями: IoT-архитектура.

Такие устройства могут не иметь экранов, работать с ограниченным питанием и оставаться в эксплуатации годами. Удалённое управление на уровне парка подходит лучше, чем индивидуальная установка по QR-коду.

Платёжные терминалы и киоски

Возможный выбор: потребительская или IoT-архитектура.

Решение зависит от того, может ли терминал предоставить контролируемый локальный интерфейс, доступен ли выездной персонал и сколько устройств требуют согласованных изменений профилей.

Оборудование, подключаемое на заводе

Возможный выбор: IFPP для первоначального провижининга вместе с управлением жизненным циклом M2M или IoT.

Заводской процесс может обеспечить первоначальную связь, тогда как архитектура эксплуатируемого устройства определяет последующие изменения.

Вопросы перед выбором SGP.22 или SGP.32

1. Есть ли у устройства пригодный локальный интерфейс?
2. Будет ли человек присутствовать при первоначальном провижининге?
3. Может ли устройство сканировать, открывать или получать потребительские сведения для активации?
4. Доступен ли надёжный интернет до установки нового профиля?
5. Каким количеством устройств нужно управлять?
6. Будут ли изменения профилей индивидуальными или охватывать весь парк?
7. Как долго устройства будут оставаться в эксплуатации?
8. Могут ли прошивка устройства и eUICC поддерживать нужную архитектуру?
9. Реализован ли IPA в устройстве или eUICC?
10. Кто будет управлять eIM или предоставлять его?
11. Какие платформы SM-DP+ и поставщики профилей совместимы?
12. Какая начальная или резервная связь доступна?
13. Что произойдёт при прерывании загрузки профиля?
14. Может ли устройство восстановиться без физического доступа?
15. Какая сторона уполномочена заказывать и одобрять изменения профилей?
16. Как парк будет переходить к другому поставщику связи?
17. Какие сертификаты, процессы подтверждения соответствия и производственные проверки применяются?
18. Какие события жизненного цикла платформа управления действительно может наблюдать?

Почему важна начальная связь

Для удалённой загрузки профиля нужен канал связи. Новый профиль не может помочь устройству связаться с сервисом провижининга, пока сам ещё не загружен.

Поэтому IoT-проекту нужна стратегия первоначального подключения. В зависимости от реализации она может включать:

• начальный, или bootstrap-профиль;
• заводскую или локальную связь;
• Wi-Fi или проводной доступ;
• другой активный профиль;
• контролируемую сеть ввода в эксплуатацию;
• связь, предоставляемую в процессе развёртывания устройства.

Начальное подключение необходимо оценить по покрытию, стоимости, сроку действия и зависимости от поставщика. Профиль, срок которого заканчивается слишком рано или который работает только в стране производства, может сделать последующий провижининг невозможным.

Устойчивость также важна. Если целевой профиль не загружается или не подключается, устройству может потребоваться сохранить работающий резервный канал, чтобы можно было повторить операцию.

Для совместимости устройства недостаточно логотипа eSIM

Устройство с «поддержкой eSIM» может поддерживать только конкретную архитектуру или сценарий.

Для надёжного внедрения проверьте:

• поддержку оборудования и операционной системы eUICC;
• поддерживаемую архитектуру GSMA и версию спецификации;
• реализацию LPA или IPA;
• совместимость с eIM, где требуется;
• совместимость с SM-DP+;
• поддержку модема и радиодиапазонов;
• поведение начального и резервного подключения;
• возможность удалённого обновления прошивки;
• ограничения хранения и включения профилей;
• восстановление после перебоя питания или сети;
• подтверждения соответствия и сертификации.

Потребительский eSIM-роутер, принимающий QR-код, не становится автоматически роутером SGP.32. Встроенной eUICC не обязательно можно управлять через любой сервис удалённого провижининга.

Операционные требования к IoT eSIM-платформе

Загрузка профиля является лишь частью управления IoT-парком.

Практической платформе могут потребоваться:

• инвентаризация устройств и eUICC;
• соответствие между устройством, EID, профилем, ICCID и активом клиента;
• массовые операции с контролем согласования;
• планирование и поэтапное развёртывание;
• статусы, повторные попытки и классификация ошибок;
• политики связи и видимость сети;
• мониторинг потребления и оповещения;
• приостановка и возобновление;
• история аудита;
• роли доступа для клиентских организаций;
• интеграция через API и вебхуки;
• управление начальным и резервным подключением;
• безопасная передача другому поставщику и процедуры выхода.

Система должна отличать состояние профиля от состояния сети. «Профиль включён» не доказывает, что датчик подключился к сети, достиг конечной точки приложения или передал пригодные данные.

Коммерческие и договорные вопросы

Решения по архитектуре создают долгосрочные коммерческие зависимости.

Договоры должны уточнять:

• владение eUICC, профилями и идентификаторами;
• контроль над eIM, SM-DP+, SM-SR или связанными аккаунтами управления;
• права на перенос профилей или устройств к другому поставщику;
• ответственность за начальную связь;
• уровни обслуживания операций провижининга;
• поддержку развёрнутых версий спецификаций;
• ответственность за продление сертификатов и жизненный цикл;
• доступ к данным и их хранение;
• эскалацию инцидентов;
• стоимость загрузок, смены профиля, включения, хранения и использования API;
• обращение с устройствами после прекращения договора.

Самая низкая цена за мегабайт может потерять значение, если парк не способен сменить поставщика или восстановиться после неудачного перехода на другой профиль.

Миграция и сосуществование

Крупным организациям следует ожидать сосуществования архитектур.

Компания может одновременно эксплуатировать:

• старые автомобильные устройства с SGP.01/02;
• смартфоны с SGP.21/22;
• новые датчики, разработанные для SGP.31/32;
• устройства с заводским провижинингом, вводимые в эксплуатацию через IFPP.

Одновременная замена всех устройств редко экономически оправданна. Поэтому уровень управления должен вести чёткий учёт архитектуры, возможностей eUICC, поставщика профиля и доступных операций жизненного цикла для каждой группы устройств.

Разумный подход к миграции

1. Разделите установленную базу по устройствам, модемам, eUICC и архитектурам.
2. Определите, какие устройства могут поддерживать новый способ провижининга, а какие требуют замены.
3. Сформулируйте требования к будущим устройствам с явным указанием целевой архитектуры GSMA.
4. Проверьте совместимость фактического сочетания eUICC, IPA, eIM и SM-DP+.
5. Проверьте сценарии начального подключения, отката и потери связи.
6. Проведите контролируемый пилот в репрезентативных странах и сетях.
7. Выполняйте миграцию поэтапно с измеримыми критериями успеха.
8. Сохраняйте рабочий путь для старых устройств на протяжении оставшегося жизненного цикла.

Миграция архитектуры никогда не должна начинаться с массового переключения профилей без проверенного способа восстановления.

Распространённые заблуждения

«Все eSIM работают с SGP.22 и SGP.32»

Нет. Совместимость зависит от eUICC, ПО устройства, компонентов провижининга и поддерживаемой архитектуры.

«SGP.32 является просто потребительской eSIM без экрана»

Нет. Она вводит специализированную IoT-модель управления с IPA и eIM для устройств с ограничениями и операций парка.

«SGP.32 немедленно заменяет все M2M eSIM»

Нет. Существующие M2M-устройства могут работать ещё много лет и не иметь возможности обновления до новой архитектуры.

«Использование SM-DP+ означает, что всё решение поддерживает SGP.32»

Нет. SM-DP+ является только одной частью архитектуры. Устройство, eUICC, IPA, eIM и интерфейсы тоже должны поддерживать необходимые процедуры.

«IoT eSIM автоматически обеспечивает покрытие нескольких сетей»

Нет. Удалённый провижининг меняет способ управления профилями. Доступ к сетям по-прежнему зависит от коммерческого профиля, оператора и роуминговых соглашений.

«Парк всегда может сменить поставщика удалённо»

Только если это допускает полная техническая и договорная конструкция. Начальная связь, полномочия, владение управлением, совместимые профили и процедуры восстановления имеют значение.

«Каждый роутер должен использовать SGP.32»

Не обязательно. Роутер, управляемый пользователем, может хорошо работать с потребительской архитектурой. Правильный выбор зависит от масштаба парка, доступности устройств и жизненного цикла.

Роль SIM24.biz в выборе архитектуры

SIM24.biz поддерживает компании, создающие предложения потребительской связи, физических SIM и IoT под собственным брендом.

Коммерческой отправной точкой должны быть продукт и жизненный цикл устройств, а не номер спецификации, выбранный изолированно. У туристического бренда, обслуживающего смартфоны, другие требования к провижинингу, чем у производителя, развёртывающего герметичные трекеры в нескольких странах.

SIM24.biz может помочь партнёру определить необходимую модель связи, платформы и операций. Конкретную поддержку архитектуры GSMA, типа eUICC, компонента провижининга или удалённой функции жизненного цикла необходимо подтвердить для выбранной реализации и сочетания поставщиков. На момент подготовки исходного черновика не делается публичного утверждения о том, что SIM24.biz самостоятельно управляет eIM, SM-DP+, SM-SR или сертифицированной платформой SGP.32.

Это различие защищает обе стороны. Оно помогает избежать обещаний, будто потребительский продукт с QR-кодом предоставляет полноценное управление IoT-парком или IoT eUICC может использовать любую платформу профилей без проверки совместимости.

Заключение

Потребительская eSIM и IoT eSIM используют одну общую идею: профили мобильных операторов можно безопасно устанавливать на совместимую eUICC через провижининг. Их рабочие среды принципиально различаются.

Потребительская архитектура SGP.21/22 предполагает устройство, способное участвовать в интерактивном процессе получения профиля. Она использует SM-DP+, LPA и необязательный SM-DS и хорошо подходит смартфонам, планшетам и устройствам под управлением пользователя.

IoT-архитектура SGP.31/32 предназначена для устройств с ограничениями связи, интерфейса или обоих. Она вводит IPA и eIM для удалённого управления парком, используя инфраструктуру профилей SM-DP+.

M2M-архитектура SGP.01/02 остаётся важной для существующих автомобильных и промышленных внедрений. SGP.41 добавляет отдельный вариант провижининга профилей во время производства.

Ни один из этих стандартов не устраняет необходимость тестировать устройства, обеспечивать начальную связь, заключать сетевые соглашения, управлять парком или иметь ясные договоры с поставщиками. Правильная архитектура позволяет выполнять провижининг, подключать, восстанавливать и мигрировать реальный парк устройств на протяжении запланированного срока эксплуатации.

Часто задаваемые вопросы

В чём главное различие SGP.22 и SGP.32?

SGP.22 является технической спецификацией потребительской архитектуры eSIM, обычно используемой интерактивными устройствами, например смартфонами. SGP.32 является технической спецификацией IoT-архитектуры для IoT-устройств с ограниченными сетевыми возможностями или интерфейсом и для управления парком.

В чём разница между SGP.21 и SGP.22?

SGP.21 определяет потребительскую архитектуру и требования. SGP.22 содержит подробную техническую спецификацию, реализующую эту архитектуру.

В чём разница между SGP.31 и SGP.32?

SGP.31 определяет архитектуру и требования провижининга eSIM в IoT-устройствах с ограничениями. SGP.32 задаёт подробные технические процедуры, интерфейсы, архитектуру eUICC и функции безопасности.

Что такое IPA и eIM?

IoT Profile Assistant является функцией на стороне устройства, поддерживающей операции с профилями в архитектуре SGP.31/32. Она может находиться в устройстве как IPAd или в eUICC как IPAe. eSIM IoT Remote Manager поддерживает разрешённые взаимодействия удалённого управления с IPA.

Использует ли SGP.32 SM-DP+?

Да. IoT-архитектура использует SM-DP+ для подготовки и доставки профилей. Полноценному решению всё равно нужны совместимые IoT-устройство, eUICC, IPA, eIM и интерфейсы управления.

Лучше ли SGP.32, чем SGP.22?

Она лучше подходит определённым IoT-средам, но не является универсально лучшей. Туристической eSIM для смартфона обычно подходит потребительская архитектура. Необслуживаемому парку датчиков может подходить SGP.32.

Заменяет ли SGP.32 SGP.01 и SGP.02?

Она предоставляет более новую архитектуру для подходящих IoT-внедрений, но существующие M2M-устройства и платформы будут сосуществовать с ней годами. Миграция зависит от оборудования, ПО, договоров и циклов замены устройств.

Можно ли обновить существующее потребительское eSIM-устройство до SGP.32?

Не автоматически. Устройство, eUICC и программное обеспечение должны поддерживать IoT-архитектуру. Одного обновления прошивки может оказаться недостаточно.

Может ли SGP.32 переключать устройство между мобильными операторами?

Она поддерживает удалённый провижининг и управление профилями, что может позволить смену оператора при наличии совместимых профилей, полномочий, связи и коммерческих соглашений. Она не отменяет ограничения устройства, договора или сети.

Нужна ли SGP.32 каждому IoT-внедрению?

Нет. Некоторые доступные для обслуживания роутеры или терминалы могут успешно использовать потребительскую eSIM. Существующие промышленные внедрения могут использовать M2M-архитектуру. Решение зависит от реальной операционной модели.

Что такое SGP.41?

SGP.41 определяет архитектуру и требования заводского провижининга профилей. Она относится к доставке профилей во время производства устройства и дополняет, а не заменяет управление жизненным циклом в эксплуатации.

Выберите архитектуру eSIM для всего жизненного цикла устройства

SIM24.biz помогает компаниям разрабатывать предложения потребительской и IoT-связи под собственным брендом с учётом реальных устройств, условий эксплуатации и требований к управлению.

Обсудите с SIM24.biz подходящую модель провижининга и связи для вашего продукта или парка.

Источники

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