Экосистема eSIM для потребительских устройств

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

В данной статье рассматриваются различные части экосистемы eSIM. В ней также рассматривается как работает удаленное предоставление SIM-карт для потребительских устройств, и дается обзор архитектуры eUICC. Это определено GSMA в документах SGP.21 и SGP.22 и основано на предыдущей работе, проделанной в этой области, и постоянно обновляется, например, для решения любых проблем связанных с безопасностью. В завершение этой главы мы проанализируем некоторые существующие решения для продажи eSIM.

В этом разделе будут описаны различные части eUICC, как показано на рисунке 1, и для чего они используются, как описано в GSMA в [15] и [16].

ECASD (встроенный домен безопасности управляющего центра UICC) отвечает за безопасное хранение конфиденциальных учетных данных. Он содержит закрытые ключи eUICC для создание подписи и сертификата с открытым ключом eUICC для аутентификации. Он также содержит сертификаты и набор ключей, принадлежащих EUM (eUICC Производитель), который можно использовать для обновления ключей и сертификатов на eUICC, а также используемые корневые открытые ключи GSMA CI (издателя сертификата) для аутентификации объектов вне карты, таких как SM-DS и SM-DP+. Там существует только один ECASD на eUICC, и он устанавливается EUM во время Процесс изготовления eUICC.

ISD-P (домен безопасности эмитента — profile) в eUICC действует как безопасный контейнер для размещения уникального профиля. Может существовать более одного ISD-P в eUICC, так как можно загрузить и установить несколько профилей. Это встроенный представитель SM-DP+ (объяснение SM-DP+ см. в разделе 2.2), а также используется для загрузки и установки пакета связанного профиля вместе с интерпретатором пакета профилей, который используется для перевода и декодирования bound profile package к установленному профилю на карте eUICC. Bound profile package будет дополнительно описан в разделе 2.1.

ISD-R (домен безопасности эмитента — root), в свою очередь, отвечает за создание ISD-P по запросу от SM-DP+ и управление жизненным циклом всех созданных им ISD-P.

Как видно на рисунке 1 профиль состоит из множества компонентов, таких как NAA (приложения доступа к сети), SSD (дополнительные домены безопасности) и CASD. (домен безопасности контролирующего органа), а также файловая система и другие апплеты и приложения. Он также содержит MNO-SD (оператор мобильной сети - Security Domain), который является представителем оператора на eUICC. Там содержатся OTA-ключи оператора, которые используются для обеспечения безопасного OTA-соединения, через которое оператор может управлять различными операторскими услугами профиля, например обновление правил политики профиля.

LPA (Local Profile Assistant) может существовать в устройстве (LPAd) или в eUICC (LPAe), но LPA в eUICC не является обязательным. Когда существует LPA и в устройстве и в eUICC, тот, который должен использоваться является необязательным и настраивается в настройках устройства. Более подробное объяснение LPA и его составляющих приведено в разделе 2.3.

Функция сервисов LPA заключается в предоставлении LPA доступа к данным и сервисам, необходимых LAP для выполнения своих функций. Это включает в себя такие вещи, как предоставление EID (идентификатор eUICC), корневого адреса SM-DS и адреса SM-DP+ по умолчанию, если они настроены на LPA. Он также отвечает за передачу связанного пакет профиля из LPA в ISD-P.

Целью телекоммуникационной инфраструктуры является предоставление приложений доступа к сети в ISD-P со стандартизированными алгоритмами сетевой аутентификации и возможностью настройки этих алгоритмов с разными параметрами из профиля.

Активатор политик профилей — это служба в операционной системе eUICC, которая отвечает за проверку, интерпретацию и обеспечение соблюдения профилем правил политики, установленных в профилях. Правила политики профиля – это способ для оператора обеспечить соблюдение определенных условий в отношении услуги, предоставляемой пользователю. Набор правил в профиле применяется только к тому конкретному профилю, в котором он определен. Примеры правил политики профиля: «отключение этого профиля не разрешено» и «удаление этого профиля требуется после его успешного отключения".

RSP (удаленная подготовка SIM-карты) — это процесс, позволяющий использовать eSIM в устройстве. В этом разделе будет рассказано, как работает удаленная инициализация SIM-карты, в соответствии тем как описано в [7] и [16] и с какой целью показаны различные компоненты системы на рисунке 2, но сначала описывается профиль и различные этапы, которые он проходит с момента его создания до установки на карту eUICC.

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

• Незащищенный пакет профиля.

• Пакет защищенных профилей.

• Пакет связанного профиля.

• Пакет сегментированных связанных профилей.

Ниже следует описание различных форматов пакетов профилей вместе с объяснение, когда и зачем это нужно [15].

Unprotected Profile Package

Незащищенный пакет профиля создается при вызове функции создания пакета профиля в SM-DP+. На вход функция принимает профиль спецификации, предоставленный оператором. Полученный профиль представляет собой набор закодированных элементов профиля TLV (tag-length-value) , и, как следует из названия, это полностью незащищенный профиль.

Protected Profile Package

Пакет защищенного профиля SM-DP+ делает незащищенный пакет защищенным. Это делается с помощью шифрование сегментов закодированных элементов профиля и добавление MAC (Message Authentication Code) в конце него и шифрования полученного зашифрованного сегмента вместе с MAC еще раз. Теперь профиль можно безопасно хранить на SM-DP+, пока он не будет загружен на карту eUICC. Шифрование может быть выполнено с использованием сеансовых ключей, согласованных eUICC и SM-DP+ или с помощью случайных ключей для каждого профиля. Если случайные ключи пакета защищенного профиля уже использованы, то он может быть создан заранее через SM-DP+ без каких-либо сообщений или информации о eUICC, где профиль установлен. Таким образом, оператор может запросить у SM-DP+ создание несколько профилей заранее и оптом.

Bound Profile Package

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

Segmented Bound Profile Package

Если LPA находится в устройстве, то LPD (что объясняется в разделе 2.3) должен сгенерировать пакет сегментированного связанного профиля перед дальнейшей передачей профиля в eUICC. Это делается путем разделения пакета связанного профиля на меньшие сегменты. Если LPA находится в eUICC, этот шаг не требуется.

SM-DP+ (Subscription Manager - Data Preparation +) играет важную роль в системе RSP. К имени добавляется «+», потому что оно выполняет задачи как SM-DP, так и SM-SR в процессе удаленной подготовки M2M. Это сущность, которая отвечает за создание профиля по запросу от оператора. После создания профиля он также отвечает за защиту результирующего профиля и безопасную доставку профиля через bound profile в eUICC.

Как упоминалось в разделе 1.2, ISD-P является представителем SM-DP+ на карте, что, конечно, означает, что SM-DP + является представителем ISD-P вне карты. Он будет запрашивать у ISD-R создание нового ISD-P и будет отвечать за управление (включение, отключение, удаление и обновление) создаваемого ISD-P на протяжении всего его жизненного цикла. SM-DP+ управляет этим за счет использования шести функций, которые суммированы ниже:

• Profile package generation: Используется для создания нового пакета профиля, включающего, например, IMSI, ключ аутентификации Ki и ICCID (Integrated Circuit Card Identifier) по согласованию с оператором. Это может либо выполняться офлайн или в режиме реального времени.

• Profile package protection: используется для защиты созданного пакета профиля и создание пакета защищенного профиля.

• Profile package binding: используется для привязки защищенного пакета профиля к конкретному eUICC, создающему связанный пакет профиля.

• Profile package storage: используется для безопасного хранения защищенного профиля или связанного пакета профиля до доставки на указанный eUICC.

• Profile package delivery: Используется для передачи связанного пакета профиля в карту eUICC через LPA для установки.

• SM-DS event registration: регистрация событий SM-DS используется для уведомления SM-DS о наличии ожидающей операции для конкретной карты eUICC.

LPA (Local Profile Assistant) может, как поясняется в разделе 1.4, существовать как в устройстве так и в eUICC. В этом разделе основное внимание уделяется LPA в устройстве. Как показано на рисунке 2. LPA в устройстве (LPAd) использует службы LPA в eUICC для обеспечения трех функций: LDS (Local Discovery Service), LPD (локальная загрузка профиля) и LUI (локальный пользовательский интерфейс), которые описаны ниже:

• LDS: используется для извлечения ожидающей записи о событии из SM-DS.

• LPD: Используется для загрузки связанного пакета профиля в LPA из SM-DP+ и для дальнейшего переноса на карту eUICC.

• LUI: интерфейс, который позволяет пользователю устройства управлять профилями в eUICC.

Назначение SM-DS (Subscription Manager - Discovery Service) состоит в том, чтобы позволить LDS в LPA устройства знать, что SM-DP+ хочет связаться. SM-DP+ делает это, отправляя сообщение о регистрации события для конкретного устройства в SM-DS. Устройство опрашивает SM-DS и, если SM-DS имеет в ожидающиеся события он ответит адресом SM-DP+, а если нет, то ответит нулевым сообщением.

SM-DS не является обязательным при развертывании решения RSP для eSIM, а также цель и реализация опциональны и зависят от сети оператора, чтобы решить, хотят ли они использовать его или нет [4].

Система RSP состоит из нескольких стандартизированных интерфейсов для связи между компонентами системы, как показано на рис. 2. Интерфейсы ESop (интерфейс между конечным пользователем и оператором) и ESeu (интерфейс между конечным пользователем и LUI) не стандартизированы и поэтому могут отличаться между разными операторами и устройствами. Ниже приводится краткое саммери некоторых интерфейсов:

• ES2+: Интерфейс между SM-DP+ и оператором. Используется для пример оператором для заказа нового профиля.
• ES6: Интерфейс между eUICC и оператором. Используется оператором для • получить доступ к MNO-SD по защищенному каналу OTA, чтобы иметь возможность управлять • профиль, например обновление правил политики профиля и изменение SMS-центра. • Адрес [4].
• ES8+: интерфейс между eUICC и SM-DP+, туннелированный в ES9+ и ES10b. Используется, например, для обеспечения безопасного сквозного канала для загрузки профиля.
• ES 9+: Интерфейс между LPD и SMTP+. Используется для безопасной доставки профиля.
• Es10: Интерфейс между службами IDS и IPS в eUICC. Используется LDS для получения корневых адресов SM-DS и SM-DP+ по умолчанию, если они настроены.
• ES10b: Интерфейс между службами LPS и LPA. Используется для передачи полученного пакета связанного профиля в eUICC.
• ES10c: Интерфейс между LUI и службами LPA. Используется для того, чтобы позволить конечному пользователю выполнять локальное управление профилем.

В этом разделе будут описаны некоторые из наиболее важных процедур в процессе подготовки удаленной SIM-карты, такие как способ загрузки профилей и другие связанные процедуры для управления профилями. Эти процедуры описаны в Технической спецификации RSP [15] и архитектуре RSP [16] GSMA.

Процесс заказа eSIM можно разделить на четыре части:

• Контрактная подписка,

• Подготовка к загрузке,

• Завершение контракта,

• Активация подписки,

где последняя часть, активация подписки, необязательна и не всегда необходима.

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

Оператор может также на этом этапе при желании получать информацию о целевом устройстве, такую как EID и IMEI (Международная идентификация мобильного оборудования). Если они получены, оператор может на этом этапе проверить, поддерживается ли целевое устройство.

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

Если подписка по контракту проходит успешно, начинается подготовка к загрузке. Этот процесс такой же, как и с обычными SIM-картами, но с той разницей, что полученные данные не помещаются на физическую SIM-карту, а сохраняются в SM-DP+ как профиль [2]. Оператор вызывает SM-DP+ с соответствующими вводными данными, запрашивая его подготовить новый профиль для загрузки. SM-DP+ резервирует ICCID для запроса, либо выбирая его из своего инвентаря, либо получая его от оператора. Он также выбирает пакет защищенного профиля, связанный с выбранным ICCID из своего инвентаря или создает новый пакет защищенного профиля, соответствующий ICCID. SM-DP+ отвечает выбранным ICCID оператору, который теперь, поскольку ICCID известен, может выполнять другие необходимые внутренние операции, такие как инициализация HLR (Home Location Register). Генерируется так называемый соответствующий идентификатор, который связывается с ICCID для последующей идентификации профиля в процессе загрузки. Если оператор требует, чтобы конечный пользователь ввел код подтверждения, чтобы иметь возможность загрузить профиль, этот код также следует отправить на SM-DP+.

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

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

После выполнения всех шагов, описанных в предыдущем разделе, профиль готов к загрузке и установке. Это инициируется конечным пользователем путем предоставления кода активации LPA через LUI либо путем ручного ввода кода активации, либо путем сканирования его с помощью QR-кода. LPA анализирует код активации и извлекает адрес SM-DP+ и маркер кода активации, который совпадает с идентификатором соответствия в SM-DP+. Если требуется код подтверждения, пользователю предлагается ввести код подтверждения, предоставленный оператором. LPA теперь инициирует общую процедуру взаимной аутентификации, которая аутентифицирует eUICC на SM-DP +, а также наоборот. Общая процедура взаимной аутентификации далее здесь обсуждаться не будет, но она гарантирует, что обе вовлеченные стороны должным образом аутентифицированы.

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

SM-DP+ подготавливает пакет связанного профиля с помощью сессионного ключа и отправляет его для воспроизведения на устройстве, которое, в свою очередь, передает его в eUICC. Если eUICC может успешно установить профиль, eUICC продолжает, подтверждая это LPA и SMTP+. LPA, в свою очередь, уведомляет конечного пользователя об установке, а SM-DP+ уведомляет оператора. Профиль теперь установлен на eUICC в отключенном состоянии и должен быть включен конечным пользователем перед использованием. В качестве меры безопасности SMTP+ ведет подсчет количества неудачных попыток загрузить профиль и количества неудачных попыток ввести правильный код подтверждения. Если было сделано слишком много попыток, CMBP+ прервет загрузку и сообщит оператору.

Конечный пользователь может выполнять локальное управление профилем через LUI в LPA. Перед началом любой процедуры LPA должен подтвердить намерение пользователя. Чтобы включить ранее загруженный профиль, пользователь выбирает профиль для включения в списке всех установленных профилей. Затем LPA отправляет запрос на включение профиля в ISD-R, указывающий, какой профиль включить. ISD-R, в свою очередь, проверяет правила политики профиля, разрешена ли операция. Если это разрешено, то ISD-R начнет с проверки, включен ли в данный момент какой-либо другой профиль, и в этом случае отключит его. Затем выбранный профиль включается, и пользователь получает соответствующую информацию. Процедура последующего отключения включенного профиля почти такая же, как и для его включения. Пользователь выбирает отключить текущий включенный профиль из списка всех установленных профилей. Затем LPA отправляет запрос на отключение профиля в ISD-R, который проверяет правила политики профиля, разрешено ли отключать профиль. Если это так, то ISD-R отключает профиль и уведомляет пользователя через LPA, а если это не так, то операция будет прервана.

Чтобы удалить профиль, установленный на eUICC, пользователь выбирает профиль из списка всех профилей на устройстве и проверяет намерение удалить его. Если профиль включен, то он сначала будет отключен, прежде чем продолжить. Затем LPA отправляет запрос в ISDR на удаление профиля. ISD-R проверяет правила политики профиля, можно ли удалить профиль, и если это разрешено, удаляет профиль и его ISD-P. Затем и пользователь, и SMTP+ получают уведомление о том, что профиль был удален.

Если пользователь, по какой-либо причине переключает мобильный телефон, он или она может с помощью обычной SIM-карты просто переместить SIM-карту со старого устройства на новое. С eSIM это не так просто. В настоящее время не существует стандартизированного способа передачи профиля между устройствами, но было сделано несколько предложений о том, как это можно было бы сделать возможным, например, в [4].

В этом разделе рассматривается, как выглядят уже существующие решения при покупке eSIM, например, у оператора мобильной связи. Мы проанализируем, как потребитель может найти и заказать ESIM, как eSIM доставляется пользователю, а также как потребитель может отслеживать, сколько осталось на eSIM с точки зрения суммы денег, оставшихся минут, объема оставшихся данных и т.д., И как его можно пополнить, если это предоплаченный eSIM.

ESIM от MNOs и MVNOs можно найти и купить либо в одном из их физических магазинов, онлайн на их веб-сайте, либо у некоторых операторов, таких как T-Mobile USA, в их собственном приложении. Многие операторы также предлагают возможность заменить физическую SIM-карту на eSIM. Процесс покупки eSIM очень похож на покупку обычной SIM-карты, единственное реальное отличие заключается в том, как она доставляется. При использовании обычной SIM-карты карту необходимо либо отправить потребителю, либо получить в магазине одного из операторов. Однако с eSIM доставка может быть мгновенной, например, в виде электронного письма с учетными данными профиля. Затем, когда профиль eSIM установлен на устройстве, eSIM действует и работает точно так же, как обычная SIM-карта. Таким образом, такие вещи, как отслеживание того, сколько данных было использовано, и так далее, а также процесс пополнения предоплаченного eSIM, работают для eSIM точно так же, как и с обычной SIM-картой того же оператора.

В отличие от обычных предоплаченных SIM-карт, которые продаются сторонними реселлерами в таких местах, как продуктовые магазины, заправочные станции и т.д. ESIM, по крайней мере пока, не продаются таким образом. Однако можно найти сторонние компании, перепродающие подписки на SIM-карты как в интернет-магазинах, так и в приложениях, которые в основном ориентированы на путешественников. Эти решения относятся к тому типу, в котором потребителю предоставляется адрес SM-DP + и маркер кода активации или QR-код, содержащий их, и он должен вручную установить профиль через настройки eSIM на устройстве, что означает, что приложение не может напрямую загрузить и установить профиль eSIM на устройстве. Этот вид решения и альтернативные решения будут дополнительно рассмотрены в дальнейшем. Так же, как при покупке непосредственно у MNO или MVNO, такие вещи, как отслеживание объема используемых данных и пополнение предоплаченной eSIM, работают точно так же, как с обычной SIM-картой.

Литература

[1] D. Gleeson, eSIM Device Sales Forecast: Smartphones, Tablets, and Wear- ables, 2019–24, 2019.

https://ovum.informa.com/resources/product-content/esim-device- sales-forecast-smartphones-tablets-and-wearables-201924- ces004-000118 Accessed: 2020-01-30.

[2] E. Vahidian, Evolution of the SIM to eSIM, Norwegian University of Science and Technology, Department of Telematics, 2013.

http://hdl.handle.net/11250/262765 Accessed: 2020-01-31.

[3] D. G. Koshy, S. N. Rao, Evolution of SIM Cards – What’s Next?, Interna- tional Conference on Advances in Computing, Communications and Infor- matics (ICACCI), Bangalore, 2018, pp. 1963-1967.

https://ieeexplore.ieee.org/document/8554774 Accessed: 2020-01-21.

[4] B. A. Abdou, Commercializing eSIM for Network Operators, 2019 IEEE 5th World Forum on Internet of Things (WF-IoT), Limerick, Ireland, 2019, pp. 616-621.

https://ieeexplore.ieee.org/document/8767260 Accessed: 2020-01-21.

[5] T. J. Gerpott, S. May, Embedded Subscriber Identity Module eSIM, Business

& Information Systems Engineering 59, 2017, pp. 293–296. https://doi.org/10.1007/s12599-017-0474-4 Accessed: 2020-01-21.

[6] P. Hristova and J. Bryan, eSIM For The Roaming Consumer, Roaming Con- sultancy Company Limited, 2018.

http://marketing.uros.com/ROCCO Roaming Consumer eSIM% 20Strategy%20Report%202018.pdf Accessed: 2020-04-01.

[7] GSMA, eSIM Whitepaper, The what and how of Remote SIM Provisioning, 2018.

https://www.gsma.com/esim/wp-content/uploads/2018/12/esim- whitepaper.pdf Accessed: 2020-01-30.

[8] M. Meyer, E. A. Quaglia and B. Smyth, An Overview of GSMA’s M2M Remote Provisioning Specification, 2019.

http://arxiv.org/abs/1906.02254 Accessed: 2020-03-30.

[9] A. Vesselkov, H. Hammainen and P. Ikalainen, Value networks of embedded SIM-based remote subscription management, 2015 Conference of Telecommu- nication, Media and Internet Techno-Economics (CTTE), Munich, 2015, pp. 1-7.

https://ieeexplore.ieee.org/document/7347220 Accessed: 2020-03-30.

[10] M. Tsurusawa, Latest Trends in Remote SIM Provisioning Technology, Special Feature - The future of cellular networks, New Breeze Vol. 29 No.3 Summer, 2017, pp. 1-10.

https://www.ituaj.jp/wp-content/uploads/2017/08/nb29-3_web.pdf

Accessed: 2020-04-06.

[11] J. Park, K. Baek and C. Kang, Secure Profile Provisioning Architecture for Embedded UICC, 2013 International Conference on Availability, Reliability and Security, Regensburg, 2013, pp. 297-303.

https://ieeexplore.ieee.org/document/6657256 Accessed: 2020-01-21.

[12] S. Chitroub, N. Zidouni, H. Aouadia, D. Blaid and R. Laouar, SIM Card of the Next-Generation Wireless Networks: Security, Potential Vulnerabilities and Solutions, 2018 2nd European Conference on Electrical Engineering and Computer Science (EECS), Bern, Switzerland, 2018, pp. 502-509.

https://ieeexplore.ieee.org/document/8910042 Accessed: 2020-01-30.

[13] M. Meyer, E. A. Quaglia and B. Smyth, Attacks against GSMA’s M2M Re- mote Provisioning, Financial Cryptography and Data Security, 2018, pp. 243- 252.

https://www.blackhat.com/docs/eu-17/materials/eu-17-Meyer- Attacks-Against-GSMAS-M2M-Remote-Provisioning-wp.pdf Accessed: 2020-04-02.

[14] Ernst & Young Mobile network operator on-demand subscription management study, 2015.

https://www.ey.com/Publication/vwLUAssets/EY-mobile-network-operator-on-demand-subscription-management/%24FILE/EY-mobile-network-operator-on-demand-subscription-management.pdf Accessed: 2020-03-30.

[15] GSMA, RSP Technical Specification Version 2.2.1, 2018. https://www.gsma.com/newsroom/wp-content/uploads//SGP.22- v2.2.1-2.pdf

Accessed: 2020-01-20. [16] GSMA, RSP Architecture Version 2.2, 2017. https://www.gsma.com/newsroom/wp-content/uploads//SGP.21_v2.2.pdf
Accessed: 2020-01-20.