Mission critical communication и при чем тут NFV?

Ищут пожарные,
Ищет милиция...

На днях посетил конференцию «Critical Communications Russia 2017», спешу поделиться полученной информацией и постараюсь ответить на вопрос, что в этой связи ждет операторов связи в ближайшем будущем? Но давайте все по порядку. Что такое «Mission critical communication»? Это связь, от надежности которой зависят жизни людей. Примеры служб, для которых такая связь нужна, — это система-112, МЧС, силовые структуры (МВД, ФСБ, Министерство обороны). Также mission critical связь необходима в зоне чрезвычайных ситуаций и на объектах, аварии на которых могут принести разрушительные последствия: энергетика, химическая промышленность, общественный транспорт и т.п.
Mission critical сети связи строятся на основе стандартов профессиональной мобильной радиосвязи (ПМР). На данный момент есть два основных стандарта: TETRA (Terrestrial Trunked Radio) ETSI EN 300 392 и DMR (Digital Mobile Radio) ETSI 102 361. Не буду вдаваться в подробности (информация по этим стандартам доступна в сети), но у них, помимо достоинств, есть существенный недостаток: они заточены на голос, а скорость передачи данных и видео существенно ограничена. Хотя всем понятно, что возможность передать видео с места событий может иметь критическое значение. Что же делать?

Когда речь заходит о высокоскоростном мобильном интернете, то сразу вспоминаются LTЕ сети, которые уже широко распространены как за рубежом, так и в России. Решение видится простым и логичным — построить профессиональную связь на сети LTE. Помимо скоростей, сразу получаем покрытие, которое обеспечивают мобильные операторы. Сказано — сделано и в 2014 появился стандарт 3GPP TS 22.179 «Mission Critical Push to Talk (MCPTT) over LTE». Все, 3GPP сделал свое дело, теперь осталось производителям оборудования реализовать поддержку MCPTT, а операторам связи внедрить это оборудование и ПМР по всей стране! :) Ну договориться еще о RAN Sharing между операторами — это уже организационные мелочи.

Примеры проектов, где используется ПМР

• В России строится служба 112, при этом источниками информации для нее являются не только голосовые вызовы людей, но и Глонасс, видео с камер наблюдения и даже видеокамеры с домофонов.
• Прорабатываются возможность управления светофорами для обеспечения зеленой полосы пожарным машинам. «Информационные системы за безопасность»
• ПМР на транспорте и энергетике: «МС-Спецтелеком» готов к запуску MVNO
• МегаФон и проект для МВД

Несмотря на наличие примеров, для проектов ПМР есть существенное ограничение. В России, как известно, взят курс на импортозамещение оборудования, а в такой важной для государства области, как ПМР, требования к комплектующим только ужесточаются. Но зачастую невозможно найти замену даже производителям оборудования для обычных мобильных сетей связи (таким как Huawei, Ericsson, Nokia), а для ПМР проблема стоит еще более остро. Не говоря уже о специализированных терминалах, выбор которых вообще единицы.

IMS

Смайлик во введении был неспроста… Все, разумеется, не так легко, начинаем погружаться в стандарты… Основная функциональность ПМР — это надежная голосовая связь, поэтому прежде всего смотрим, что предлагает LTE. С удивлением обнаруживаем, что голос в LTE изначально не был предусмотрен и технологии, используемые для VoLTE прошли нелегкий путь от Circuit-Switched Fallback (CSFB) до использования IMS (IP Multimedia Subsystem). На текущий момент использование IMS или SIP core в LTE признано целевой архитектурой для мобильных сетей. Что такое IMS? Стандарты IMS появились задолго до LTE и используются для организации передачи голоса и видео в пакетных сетях передачи данных. Очень упрощенная схема выглядит так:



Cложную схему даже не буду пытаться рисовать, т.к. IMS — это отдельный мир с сотнями стандартов, если интересно, немного подробнее тут: «Предоставление голосовых услуг в сетях связи следующего поколения». Кратко по схеме: основная идея IMS — это разделение архитектуры на слои: транспортный, управление и уровень приложений. На транспортном уровне находится MRF (Media Resource Function), она обеспечивает реализацию таких услуг, как конференц-связь, оповещение, перекодирование передаваемого сигнала и MGW (Media Gateway) — медиа шлюзы. Для упрощения схемы тут же нарисовал MGCF (Media Gateway Control Function) — функцию управления транспортными шлюзами, хотя на самом деле она находится на уровне управления. Коммутацию и управление вызовами осуществляет CSCF (Call Session Control Function), которая взаимодействует с серверами приложений и медиа шлюзами по SIP протоколу. Профили абонентов хранятся в HSS, взаимодействие HSS c миром происходит по Diameter протоколу.

VoLTE

Как же стыкуется IMS c LTE? Для этого есть специальный стандарт c требованиями: GSMA PRD IR.92 v9.0: «IMS Profile for Voice and SMS». Т.е. если у оператора уже есть система IMS, то он интегрирует ее в соответствии со стандартом. Если нет, то для VoLTE можно ограничиться функциональными элементами, реализующими только необходимые интерфейсы, тогда это будет называться SIP core. Внесем в схему LTE сеть:


Реальная архитектура будет зависеть от того, какие системы уже существуют у оператора связи. Для наглядности не делил PGW (Packet Data Network Gateway) для IMS и Internet. Опять же для наглядности нарисовал HSS общим для LTE, IMS и PCRF, хотя HSS для LTE и IMS в общем случае разные, а для PCRF надо рисовать отдельный UDR или SPR. PCRF (Policy and Charging Rules Function) в LTE управляет скоростью трафика, который проходит через PGW. Соответственно, когда CSCF понимает, что начинается голосовой вызов, то дает команду PCRF установить для трафика определенный приоритет QCI (QoS Class Identifier), подробнее про PCRF можно посмотреть тут: «Тарификация современных услуг передачи данных в мобильных сетях связи и управление политиками обслуживания абонентов».
Для установки и контроля голосового вызова в VoLTE необходимо, чтобы SIP шел от абонентского устройства, т.е. устройство должно поддерживать SIP нативно или через приложение. На схеме показаны потоки SIP сигнализации (красные стрелки мелким пунктиром) и данных (синие стрелки крупным пунктиром). Application сервера используются для реализации услуг поверх чистого VoLTE, например организация переадресации вызовов, реализация черных / белых списков и т.п.

MCPTT

Так, с VoLTE немного разобрались, для MCPTT требования к сети ужесточаются:

Добавляется новая функциональность — широковещательная связь: один ко многим, многие ко многим.

Необходима приоритизация звонков и трафика, для этого вводятся специальные QCI 65,66, которые должны обеспечивать задержку голоса не более чем 75 ms и 100 ms соответственно.
Сами устройства также должны поддерживать MCPTT нативно и иметь возможность взаимодействовать друг с другом напрямую, без наличия сети связи.

Давайте обратимся к стандартам и посмотрим, что же нужно сделать оператору связи чтобы запустить MCPTT поверх LTE. В соответствии со стандартом в MCPTT появляются элементы для поддержки широковещательных сообщений MBMS GW (Multimedia Broadcast Multicast Services) и BM-SC (Broadcast Multicast Services Centre), а также MCPTT Application Service и для реализации логики услуги и MCPTT User DB для настройки и хранения групп абонентов:


Немного более подробно. MCPTT Application Service состоит из MCPTT server, «Common service core», MCPTT User Database и MCPTT клиента, работающего на пользовательском терминале. От схемы из стандарта становится грустно:



Поэтому нарисовал более наглядно:


MCPTT server
MCPTT server — функциональный элемент (реализующий GCS AS (Group Communication Service Application Server), как описано в 3GPP TS 23.468) для контроля широковещательных (multicast) и одиночных вызовов. MCPTT server включает в себя SIP AS (Application Server), HTTP клиент и сервер. Взаимодействует с IMS и MTTP client по SIP протоколу для:

• Получения информации о местонахождении UE для определения возможности использования multicast вещания
• Согласование и управление медиа потоками (floor control). Используется протокол Secure RTCP (SRTCP))
• Передачу самих медиа потоков (media distribution). Используется протокол Secure RTP (SRTP).
• Может напрямую управлять PCRF по Rx интерфейсу или взаимодействовать с ним через систему IMS.
• При наличии в сети Multimedia Broadcast Multicast Services запрашивает multicast ресурсы для вещания

MCPTT DB
Для взаимодействия с MCPTT DB используется протокол DDMA (Diameter Data Management Applications). Как транспорт рекомендуется SCTP. Обеспечивает получение данных, подписку/отписку на нотификацию об изменениях, получение изменений, модификация данных. При получении данных MCPTT Users идентифицируются по MCPTT ID. Для MCPTT ID рекомендуется формат URI.

Common service core
Взаимодействует с функциональным элементом «Common service core» по HTTP и SIP протоколам. Common service core обеспечивает:

• Аутентификацию и авторизацию абонентов (Identity)
• Подключение абонентов к групповым вызовам, управление группами (Group management)
• Управление конфигурацией, например политики обслуживания (Configuration)
• Хранит и передает ключи шифрования (Key server)
• Получает нотификации о подключении MCPTT UE, информирование UE о вызовах
• Организует очереди и приоритизацию вызовов

Для активации MCPTT услуги происходит следующая последовательность взаимодействия:

1. В начале вызова мобильный терминал осуществляет обычную установку интернет соединения
2. А вот далее начинает работать MCPTT клиент, который производит аутентификацию абонента
3. Далее происходит регистрация SIP клиента в IMS / SIP core
4. После успешной SIP регистрации происходит авторизация услуг
5. Для этого запрашивается профиль абонента из MCPTT DB
6. На MCPTT клиента отправляется необходимая конфигурация из профиля
7. И информация о группах, в которых участвует абонент
8. Происходит запрос необходимых медиа ресурсов
9. И устанавливаются голосовые или видео потоки

Как выглядит полный CallFlow для установки end-to-end соединения можно посмотреть, например, тут.

При чем тут NFV?

Про то, что такое NFV я уже писал. Как же связаны Network Functions Virtualization и MCPTT? Для операторов связи запуск VoLTE — это второй шаг после построения самой сети LTE. Но у большинства операторов отсутствует IMS. Возникает естественное желание минимизировать денежные и трудовые затраты. Разворот виртуальной среды и запуск на ней необходимых элементов IMS в виде виртуальных сетевых функций (VNF) позволяет быстро достичь желаемого. Также хорошо виртуализируются и другие сетевые функции, например HSS или PCRF. И, если у оператора они отсутствуют, их виртуализация вполне логична. К тому же к элементам самой системы MCPTT предъявляются требования работы в виртуальных средах. Что, наверное, стоит делать железным, так это функцию «Media distribution», которая осуществляет кодирование потоков данных.
Так что для NFV нашлось еще одно достойное применение — MCPTT service!

Цикл статей про NFV

SDN & NFV и при чем тут Облака
Облака как любовь
Mission critical communication и при чем тут NFV?
Интерфейсы и функциональные блоки NFV (в работе)
Производители и кейсы использования SDN и NFV (планируется)
Готовим NFV в домашних условиях (планируется)
BigData и NFV — есть ли связь? (планируется)