SGP.22 против SGP.32 - что означает переход на новый стандарт eSIM для путешествий

Цель: Дать покупателям eSIM для путешествий и операторам MVNO карту стандартов, чтобы разговоры в индустрии о "следующем стандарте eSIM" не смешивали два разных пути.

Аудитория: Практики, которые отправляют или покупают потребительское подключение для путешествий (и все, кто оценивает смежное IoT/оборудование для путешествий), а не члены комитета GSMA.

Если вы покупаете eSIM для путешествий, сканируете QR-код и получаете данные, вы уже находитесь внутри архитектуры GSMA Remote SIM Provisioning (RSP) - даже если никогда не видите номера спецификаций. Эти номера имеют значение.SGP.22 - это технический стандарт потребительского RSP, лежащий в основе потоков смартфонов и eSIM для путешествий.SGP.32 - это технический стандарт IoT RSP для устройств без экрана, ограниченных и масштабируемых. Они имеют общие строительные блоки. Они решают разные задачи.

Это различие легко размыть в маркетинговых материалах. Это также разница между путешественником, устанавливающим временный профиль на телефон, и предприятием, организующим подключение для тысяч датчиков, которые никогда не увидят экран. Для брендов путешествий, MVNO и всех, кто строит на потребительских стэках eSIM, знание, где заканчивается SGP.22 и начинается SGP.32, является обязательным - не потому, что путешественникам нужны PDF от GSMA, а потому, что разговор в индустрии часто смешивает потребительские и IoT пути.

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

Почему индустрии понадобилось больше одного "стандарта" eSIM #

eSIM - это не один протокол. Это семейство спецификаций GSMA, которые определяют, как профили операторов безопасно подготавливаются, доставляются, устанавливаются, активируются, отключаются и удаляются на eUICC (встроенной SIM-платформе).

Публичный индекс спецификаций GSMA делает разделение явным: потребительский RSP находится под SGP.21 (архитектура) и SGP.22 (технический); IoT RSP находится под SGP.31 (архитектура и требования) и SGP.32 (технический). Активные потребительские выпуски продолжаются через SGP.22 v2.x и v3.x; выпуски IoT продолжаются через SGP.31/SGP.32 v1.x, включая новые ревизии 2024-2026 годов на странице спецификаций eSIM GSMA (GSMA eSIM Consumer and IoT Specifications).

До SGP.32, удаленное предоставление IoT и M2M в основном существовало в более ранней модели "машина-машина" (SGP.02), с разделением на два сервера SM-DP (подготовка данных) и SM-SR (безопасная маршрутизация). Эта модель позволяла удаленное управление профилями для промышленных и автомобильных случаев использования, но также приносила операционные трения: триггеры, ориентированные на SMS, более тесная коммерческая связь SM-SR/SM-DP и плохая совместимость с сильно ограниченными устройствами LPWAN. Операторы и платформы IoT постоянно указывают на эти ограничения как на причину, по которой GSMA создала отдельную архитектуру IoT, а не заставляла потребительский RSP работать на каждом модеме (Eseye on SGP.31/32; 1oT on SGP.02 vs SGP.22 vs SGP.32).

Краткая версия: одна физическая форма (eSIM/eUICC), несколько философий предоставления.

SGP.22 простыми словами: потребительский RSP для устройств с участием человека #

SGP.22 - это техническое описание GSMA удаленного предоставления SIM для потребительских устройств. Его цель однозначна: техническое решение для удаленного предоставления и управления eUICC в потребительских устройствах, направленное на совместимость между развертываниями операторов - включая платформы SM-DP+ и поставщиков eUICC.

Основные участники в потребительской модели #

Роли участников #

• eUICC: Безопасная платформа, которая хранит профили (учетные данные оператора и связанные компоненты)
• LPA (Local Profile Assistant): Ассистент на устройстве (или частично на eUICC), который управляет загрузкой, локальным включением/отключением/удалением и управлением профилями, видимыми пользователю
• SM-DP+: Менеджер подписок - Подготовка данных +: подготавливает, защищает и доставляет пакеты связанных профилей
• SM-DS: Менеджер подписок - Служба обнаружения: необязательный путь обнаружения, когда устройству нужно найти правильный SM-DP+ без QR/кода активации
• Оператор / эмитент профиля: Владеет коммерческой подпиской, стоящей за профилем

В процессе, который узнают путешественники:

1. Купить план путешествий и получить код активации (часто в виде QR).
2. Устройство LPA связывается с SM-DP+.
3. Зашифрованный пакет профиля загружается и устанавливается на eUICC.
4. Пользователь активирует профиль (и может позже отключить или удалить его).

Это модель, инициируемая пользователем / ориентированная на запросы. Человек присутствует, устройство имеет пользовательский интерфейс, и согласие является явным действием установки. Именно поэтому оформление eSIM для путешествий, партнерства с авиакомпаниями/финтехами и активация через приложения соответствуют потребительскому RSP класса SGP.22, а не оркестрации IoT флота.

Транспортировка HTTPS/TLS подходит для смартфонов. Она тяжелее, чем могут позволить себе многие циклы работы IoT, но разумна для телефона, который уже поддерживает IP-соединение и полный стек безопасности.

SGP.32 простыми словами: IoT RSP для устройств, которые не могут использовать "Добавить eSIM" #

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

Основные участники в модели IoT #

Роли участников #

• eUICC: eUICC, поддерживающий IoT, который хранит профили и поддерживает ассоциации удаленного управления IoT
• IPA (IoT Profile Assistant): Ассистент на стороне устройства или eUICC, который выполняет работу по предоставлению/управлению без пользовательского интерфейса; может быть IPAd (на устройстве) или IPAe (на eUICC)
• eIM (eSIM IoT Remote Manager): Облачная/оркестрационная сущность, которая выполняет операции жизненного цикла профиля для устройства или флота
• SM-DP+: Используется из потребительской экосистемы для подготовки профиля и защищенной доставки
• SM-DS: Роль обнаружения сохраняется, где это уместно
• Оператор: Источник профиля, как в потребительском RSP

Архитектурное намерение согласуется с материалами GSMA и отраслевыми обзорами: сохранить то, что уже работало в потребительском RSP (особенно SM-DP+), и заменить предположение о человеке/LPA на удаленного менеджера плюс IoT-ассистента (Объяснение стандартов Velocity IoT; сравнение 1oT).

Почему IoT потребовалась другая модель #

Потребительский RSP предполагает:

• экран или сопутствующий UX,
• человек, который может начать загрузку,
• относительно стабильное IP-соединение для TLS-сессий,
• решения о жизненном цикле, принимаемые пользователем для каждого устройства.

флоты IoT часто предполагают обратное:

• нет пользовательского интерфейса,
• прерывистое или низкоскоростное соединение (включая сценарии LPWAN),
• асинхронные проверки вместо постоянных сессий,
• управление включением/отключением/удалением на основе политики для многих EID одновременно.

SGP.31/32, следовательно, вводит управление состоянием профиля, ориентированное на флоты, и eIM, который может инициировать или проксировать загрузки. Анализы отрасли также подчеркивают легковесные протокольные опции (например, CoAP/DTLS как альтернативный путь для ограниченных устройств), удаление SMS как жесткой зависимости для современных IoT RSP и поддержку прямой или косвенной доставки профиля в зависимости от того, может ли устройство комфортно общаться с SM-DP+ самостоятельно (Eseye; 1oT).

Критически важно, что SGP.32 не является обратно совместимым «обновлением программного обеспечения» для каждого SGP.02 eUICC, уже находящегося в эксплуатации. Eseye и другие специалисты по IoT отмечают, что развертывания по стандарту M2M обычно остаются на этой модели до конца срока службы; зеленое поле IoT - это то, где SGP.32 предназначен стать стандартом по умолчанию.

SGP.22 против SGP.32: структурированное сравнение #

Сравнение по измерениям #

Основная пара GSMA

• SGP.22 (потребительский RSP): архитектура SGP.21 + технические характеристики SGP.22
• SGP.32 (IoT RSP): архитектура/требования SGP.31 + технические характеристики SGP.32

Предназначен для

• SGP.22 (потребительский RSP): смартфоны, планшеты, носимые устройства, потребительские устройства с пользовательским интерфейсом
• SGP.32 (IoT RSP): устройства и флоты IoT без интерфейса / с ограниченным интерфейсом / с ограниченной сетью

Человек в цикле?

• SGP.22 (потребительский RSP): Да - пользователь инициирует или подтверждает установку/переключение
• SGP.32 (IoT RSP): Нет - eIM/IPA управляют операциями удаленно

Локальный помощник

• SGP.22 (потребительский RSP): LPA
• SGP.32 (IoT RSP): IPA (IPAd или IPAe)

Удаленное управление

• SGP.22 (потребительский RSP): Ограничено / не центр дизайна
• SGP.32 (IoT RSP): eIM как полноценный удаленный менеджер

Сервер профилей

• SGP.22 (потребительский RSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (повторное использование)

Обнаружение

• SGP.22 (потребительский RSP): SM-DS (опционально во многих потоках)
• SGP.32 (IoT RSP): SM-DS сохранен в архитектуре

Модель триггера

• SGP.22 (потребительский RSP): Преимущественно pull (QR / код активации / приложение)
• SGP.32 (IoT RSP): Push и/или pull через eIM и паттерны регистрации устройства

Транспортная позиция

• SGP.22 (потребительский RSP): HTTPS/TLS-центрированный потребительский IP-стек
• SGP.32 (IoT RSP): Основан на IP; акцент на опциях для ограниченных устройств (например, пути CoAP/DTLS в отраслевых резюме спецификации)

Проблемы предшественников, которые он решает

• SGP.22 (потребительский RSP): Замена физических SIM и привязка к оператору на потребительском оборудовании
• SGP.32 (IoT RSP): Операционная привязка SGP.02, зависимость от SMS и плохая совместимость с ограниченными устройствами

Актуальность eSIM для путешествий

• SGP.22 (потребительский RSP): Прямая - это стек, стоящий за типичными установками eSIM для путешествий на телефонах
• SGP.32 (IoT RSP): Косвенная - формирует смежные экосистемы IoT/оборудования для путешествий, а не потоки QR для телефонов

Жизненный цикл профиля: те же глаголы, разная грамматика #

Оба мира говорят о загрузке, установке, включении, отключении и удалении. Грамматика различается:

• Жизненный цикл SGP.22 локальный и ориентирован на пользователя. После установки путешественник (или интерфейс LPA) решает, когда профиль включается для роуминга данных, когда он приостанавливается и когда удаляется.
• Жизненный цикл SGP.32 удаленный и ориентирован на политику. eIM может выполнять операции управления состоянием профиля для одного или нескольких EID, а IPA выполняет их, когда устройство доступно - важно для устройств, которые большую часть дня находятся в спящем режиме.

Вот почему «переключение профиля» означает разные коммерческие вещи в каждом мире. В потребительских путешествиях переключение часто является новой покупкой или вторым установленным профилем, который выбирает пользователь. В IoT переключение - это операция с имуществом: смена провайдера связи, реакция на покрытие или ротация профилей без выезда на место.

Где ранее использовались спецификации IoT: SGP.02 и SGP.31 #

Четкая ментальная модель:

1. SGP.02 - оригинальный M2M RSP с SM-DP + SM-SR. Основополагающий, все еще присутствует в долгосрочных проектах (особенно в автомобильной и других заводских установках), но все чаще рассматривается как устаревший для новых ограниченных IoT проектов (1oT).
2. SGP.22 - потребительский RSP, который упростил настройку вокруг SM-DP+ и LPA; массовый путь для телефонов и туристических eSIM.
3. SGP.31 / SGP.32 - IoT RSP, который повторно использует SM-DP+, добавляя eIM + IPA для управления флотом без участия человека.

SGP.32 не появился из-за того, что потребительский eSIM "провалился." Он появился, потому что потребительский eSIM успешен для людей- и этот успех все еще не решает проблему датчика, закрепленного внутри контейнера для перевозки.

Последствия для туристических eSIM, потребительского роуминга и стэков MVNO #

Подключение в путешествиях остается историей потребительского RSP #

Для телефонов и большинства устройств путешественников действующим стандартом остается потребительский RSP класса SGP.22. Опыт продукта, который важен для путешественников - покупка до отъезда, установка через QR или приложение, подключение по прибытии - соответствует потокам LPA ↔ SM-DP+, а не командам флота eIM.

Собственный комментарий GSMA за 2026 год описывает подключение в путешествиях как структурный сдвиг в международном роуминге: предложения eSIM для путешествий на основе приложений более прозрачны и гибки, а распространение приближается к конечному пользователю до начала поездки (GSMA: массовое развертывание eSIM переходит от прогноза к факту). Этот коммерческий сдвиг основывается на зрелости потребительского RSP и поддержке устройств, а не на развертывании IoT eIM.

Что SGP.32 *действительно* меняет для экосистем, связанных с путешествиями #

Даже если путешественники никогда не касаются SGP.32, стандарт имеет значение на границах путешествий:

• Подключенные трекеры багажа, автопарки, логистические датчики и IoT на объектах все чаще нуждаются в удаленном управлении профилями без церемонии с QR.
• Маршрутизаторы для путешествий и некоторые "eSIM-устройства" могут находиться в сложной середине: активация в стиле потребителя для владельца-человека, но операционные потребности, которые выглядят более похожими на флот в масштабе.
• Операторы и MVNO могут управлять как потребительскими SM-DP+ проектами, так и IoT eIM проектами. Совместное использование SM-DP+ между SGP.22 и SGP.32 является намеренным; это не означает, что два класса устройств имеют одинаковый UX или путь сертификации.

Мульти-IMSI, стэки MVNO и честные границы #

Мульти-IMSI (несколько идентичностей, выбираемых внутри или рядом с продуктом подключения) и загрузка профиля eUICC часто обсуждаются вместе, но это не один и тот же механизм. Мульти-IMSI может улучшить поведение подключения к сети внутри коммерческого предложения; eUICC RSP (SGP.22 или SGP.32) касается безопасной установки и управления полными профилями операторов на eUICC. Туристические бренды и MVNO могут комбинировать обе техники коммерчески, но ясность архитектуры все еще важна: установки для путешествий на телефонах оцениваются по совместимости SGP.22 и UX активации; IoT проекты оцениваются по работоспособности eIM/IPA и устойчивости к ограниченной сети.

Полезное предостережение со стороны IoT также применимо коммерчески: техническая портативность в спецификации не автоматически равна коммерческой портативности в контракте. SGP.32 снижает определенные архитектурные паттерны блокировки, связанные с SGP.02, но коммерческие условия провайдера все еще определяют, насколько свободно флоты могут перемещать ассоциации eIM или внешние отношения SM-DP+ (1oT). Покупатели туристических услуг сталкиваются с аналогичным уроком в меньшем масштабе - совместимый RSP сам по себе не гарантирует одинаковое качество покрытия, политику честного использования или опыт поддержки у разных провайдеров.

Сигналы времени выхода на рынок и принятия (публичные, 2025-2026) #

Публичные материалы GSMA в 2026 году описывают потребительский eSIM, входящий в операционный масштаб, а не в доказательство концепции. Согласно майскому резюме GSMA за 2026 год, глобальное проникновение смартфонов с eSIM составило около 5% к концу 2025 года, с заявленным путем к около 10% к концу 2026 года, и дальнейший рост после этого; в той же статье упоминается, что примерно три из четырех / 73% операторов мобильных сетей предлагают коммерческие eSIM для смартфонов, при этом отмечая оставшийся разрыв между доступностью и активной активацией потребителями (статья GSMA о массовом рынке eSIM).

Что касается IoT, то в том же комментарии GSMA выделяется SGP.32 как структурный фактор для глобальных продуктовых вариантов и переключения профилей в поле - язык, который соответствует тому, как платформы IoT позиционируют стандарт. Зрелость спецификации также видна в публичных таблицах GSMA: SGP.31/SGP.32 продолжают развиваться через активные версии v1.2 и новые версии v1.3 в 2024-2026 годах, наряду с соответствующими тестовыми спецификациями (индекс спецификаций GSMA).

Интерпретация без преувеличений: потребительский eSIM для путешествий уже является масштабным коммерческим случаем использования на рельсах SGP.22; SGP.32 - это параллельная индустриализация IoT RSP. Они укрепляют более широкую историю eSIM, не заменяя друг друга.

Что должны усвоить путешественники и бренды #

Для путешественников #

Вам не нужно выбирать между SGP.22 и SGP.32, когда вы покупаете план для путешествий. Если вы устанавливаете eSIM на телефон через QR-код или приложение, вы находитесь в мире потребительского RSP. Что вам следует учитывать, так это практические аспекты: совместимость устройства, надежность установки до отправления, покрытие в пункте назначения, прозрачные условия справедливого использования и поддержка, если что-то не работает на границе.

Поставщики, такие как Roamify, находятся в этом потребительском слое для путешествий - планы для пунктов назначения, цифровая установка и возможность оставаться онлайн за границей - а не в управлении промышленными парками eIM. История стандартов за QR-кодом все еще имеет форму SGP.22.

Для туристических брендов, OTA, финтехов и потребительских MVNO #

• Рассматривайте интероперабельность SGP.22 и UX активации как основу продукта.
• Не продвигайте “SGP.32” как обновление для путешественников, если ваша фактическая архитектура оборудования/парка не использует IoT RSP.
• Если вы продаете или предлагаете под своим брендом подключение для трекеров, маршрутизаторов или B2B-оборудования для путешествий, отдельно оценивайте, нуждается ли класс устройства в потоках потребительского LPA, потоках IoT eIM или гибриде с поэтапным подходом.
• Инвестируйте в образование: собственный рыночный комментарий GSMA все еще указывает на разрыв между доступностью eSIM и пониманием/активацией потребителями. Четкое руководство по установке остается конкурентным преимуществом.

Для операторов и платформ подключения #

Одновременное использование потребительского и IoT RSP становится все более нормальным. Общая наследственность SM-DP+ помогает, но сертификация, аккредитация безопасности, агенты устройств (LPA против IPA) и коммерческие операционные модели остаются различными. Смешивание словарей в публичных сообщениях создает ложные ожидания как для путешественников, так и для корпоративных покупателей.

Заключение: два стандарта, один рассказ о eSIM - держите полосы четкими #

SGP.22 и SGP.32 не являются соперниками на одной доске лидеров. Они являются ответами на две реальности устройств:

• SGP.22 предполагает, что человек присутствует и может загрузить профиль на потребительское устройство. Это архитектура, лежащая в основе современных eSIM для путешествий на телефонах.
• SGP.32 предполагает, что устройство находится в одиночестве - или в спящем режиме - и нуждается в удаленном управлении, способном работать с парком, через eIM и IPA, при этом все еще используя доставку профилей SM-DP+. Это архитектура, которую GSMA построила для ограниченного IoT после того, как ограничения SGP.02 стали очевидными.

Для подключения в путешествиях стратегический урок - это точность. Путь потребительского RSP уже меняет то, как люди покупают роуминг. Путь IoT RSP меняет то, как машины остаются подключенными на протяжении многих лет. Бренды, которые держат эти полосы четкими, объяснят eSIM более убедительно - и создадут продукты, соответствующие стандарту, который они действительно поставляют.

Мягкая заметка о бренде: Roamify - это поставщик eSIM для путешествий, предлагающий планы для многих направлений с цифровой активацией для совместимых телефонов. Эта статья - образовательный материал о стандартах, а не утверждение, что Roamify реализует управление парком IoT SGP.32.