Привет, Хабр! Меня зовут Алексей Степанов, я работаю аналитиком в проектах IoT Connected Car и eSIM M2M в «МТС Диджитал».
Среди наших клиентов — совершенно разные компании. Производители умных счётчиков для воды, терминалов для эквайринга, и даже автомобилей.
В этом посте расскажу, как наша команда разработала сервис, позволяющий управлять большим количеством eSIM, выпущенных специально для такого оборудования.
Подробнее о том, что такое eSIM, мои коллеги рассказывали тут. В этой статье поговорим и про один из вариантов использования и применения протоколов спецификации GSMA SGP.02.
Знакомство с технологией
Для справки: стандарт SGP.02 — та самая технология, благодаря которой eSIM-чипы могут удалённо записывать в себя цифровую SIM-карту. Конечный эффект полностью аналогичен операции, при которой в оборудование со слотом вставляется физическая симка.
Наш бизнес-заказчик попросил реализовать интересный сервис. Организации-владельцы, купленных у нас eSIM (дальше будем называть их «партнерами») — должны были получить возможность управлять своими картами.
Функции будущего сервиса нам виделись такими:
валидация запросов партнёра на, например, активацию, деактивацию и другие действия с профилем. Все запросы стандартизированы по SGP.02 и одинаковы у всех участников ассоциации GSM,
их логирование,
авторизация запроса партнёра и выдача разрешения или запрета на его исполнение в зависимости от прав на эту eSIM.
В общем, у нас заказали админку для пользователя в МТС с этими возможностями.
Создание сервиса. Архитектурные решения. Трудности и их преодоление
Логика работы бизнес-подсистемы операторов связи (BSS — business support system) с технологией eSIM M2M не покрывается стандартами GSMA, и каждый оператор связи решает эту задачу так, как считает нужным. Подробнее мы писали про это в другой нашей статье.
Изучив спецификацию от GSMA и место MNO (Mobile Network Operator) в ней, мы приступили к формированию архитектурной схемы решения:
Мы исходили из того, что для решения наших задач нам нужно не только идентифицировать зарегистрированного на платформе партнёра, но и проверить его запрос перед выполнением.
На схеме ниже высокоуровнево показан процесс:
Потребитель (наш партнёр-инициатор) вызывает службу идентификации, предъявляет выданный ему ранее токен, входит в систему. Это 1-й этап обработки запроса.
Если всё введено верно, дальше наш сервис (вендор API на схеме) валидирует запрос. Парсит и проверяет ключевые параметры из него.
Проверяется тип запроса, объект, в отношении которого получен запрос, текущее и целевое состояние объекта, актуальные настройки политик для партнёра-инициатора запроса.
На уровне сервиса из входящего запроса мы проверяем указанный тип запроса из параметра Action:
<wsa:Action>http://gsma.com/ES2/ProfileManagement/ES2-DownloadProfile</wsa:Action> Например, запрос на загрузку профиля. Смотрим также на значения EID, ICCID в теле запроса и значения некоторых других параметров. Это 2-й этап обработки запроса.
Наконец, финальный этап — это применение политик и пропуск запроса на исполнение. Если запрос не соответствует разрешениям политики, произойдёт отбивка запроса с ошибкой 403 Forbidden. Пользователь админ-панели может настроить политику для партнёра.
Карточка партнёра с политикой в админ-панели:
Если все проверки пройдены, запрос партнёра исполняется перенаправлением в связанный исполняющий сервис, а результат возвращается ему в интерфейсе нашего сервиса.
Разумеется, понадобились минорные доработки по нашим потребностям со стороны смежных команд, управляющих общими техническими продуктами, которыми мы воспользовались.
Среди таких решений, например, могут быть популярные на рынке системы мониторинга и логирования.
Мы также подготовили типовую спецификацию нашего API для партнёров, чтобы они смогли к нам подключаться.
Бэклог и новые запросы
По мере развития продукта начали появляться новые задачи второго приоритета.
Например, нужно было сделать систему отчётов, анализирующих состояние eSIM партнёров. Пользователь хотел видеть в одном окне, в каком состоянии, какие eSIM и какому партнёру принадлежат.
Мы добавили подробные данные по каждой карте. Например, такие:
ICCID (серийный номер карты),
статус eSIM на текущий момент,
справочные данные по подключенным услугам,
прочие данные о партнёре и его eSIM.
В самом первом релизе у пользователя не было доступа к этой информации. Теперь же она визуализировалась на фронте в админке пользователя.
Табличная часть раздела «SIM-карты» в админ-панели:
Пример заказываемого отчёта в админ-панели:
В некоторых частях админки сделали агрегацию нужных заказчику параметров. Это упростило восприятие большого объёма данных.
Другая задача была связана с опросом и актуализацией состояния (активность/неактивность) SIM-карт посредством обращения в смежный внешний сервис и действий над SIM-картами в случае их нецелевого статуса в автоматическом режиме по расписанию.
Тут возникла сложность. При передаче данных по SIM в смежный сервис и массовой их обработке возвращались ошибки по некоторым картам. Сервис, к которому мы обращались, не успевал обрабатывать все наши запросы. Эту проблему мы решили после дополнительных совместных тестов.
Оказалось, когда мы разом отправляли в исполняющий сервис больше Х запросов, иногда возникали ошибки с TLS handshake.
Мы провели нагрузочное тестирование и выяснили, при какой нагрузке такие ошибки не возникают вообще. В итоге пришлось закрепить её в качестве лимита, который наш сервис не должен превышать.
При выставлении лимита возникла другая проблема. Запросы на управление eSIM отправляем и мы сами, и наши партнёры. Предсказать такую нагрузку и заранее её ограничить, понятное дело, мы не могли.
Чтобы с этим разобраться, мы разработали модуль RequestsMaster. Он постепенно забирает запросы из очереди и отправляет их на обработку, регулируя количество одновременных задач, чтобы не выходить за пределы лимита.Перспективы и направления развития продукта
Наше решение позволяет партнёру-владельцу SIM-карт управлять профилями на своих eSIM, а бизнес-пользователю — управлять аккаунтом партнёра и его правами на партии SIM-карт, выпущенных под определённые задачи. Так же через него можно настраивать роли, политики, задания (таски) в админке.
Со временем в наше решение можно добавлять новые фичи по запросу. Сейчас, например, мы внедряем поддержку новой спецификации SGP.32 от GSMA.
Спасибо, что дочитали! Если у вас есть вопросы, пишите. С удовольствием отвечу на них в комментариях.