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

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


    Что такое «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 между операторами, но это уже организационные мелочи.

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



    Несмотря на наличие примеров, для проектов ПМР есть существенное ограничение. В России, как известно, взят курс на импортозамещение оборудования, а в такой важной для государства области, как ПМР, требования к комплектующим только ужесточаются. Но зачастую невозможно найти замену даже производителям оборудования для обычных мобильных сетей связи (таким как 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 — есть ли связь? (планируется)
    Поделиться публикацией
    Похожие публикации
    Комментарии 2
    • 0
      Спасибо автору за интересные темы, жду продолжения.
      • 0
        Прежде всего хочу сказать спасибо, что есть этот цикл статей, где рассматриваются различные аспекты NFV.

        Теперь немного конструктивной критики :). Прочитав заголовок статьи ожидал увидеть что-то типа архитектуры или дизайна или хотя бы анализа требований для виртуализации mission critical workloads/services. К сожалению содержимое статьи свелось по сути к высокоуровневому описанию реализации IMS/VoLTE и MCPTT. Последний абзац по моему мнению притянут за уши к NFV и слабо связан с контентом выше. Я так и не понял, что Вы пытались сказать в заключительном абзаце — что IMS и сервисы построенные на IMS можно виртуализировать Или, что внедрение IMS в виде VNF будет дешевле нежели чем в виде традиционного «ящика»?
        Итого, лично для меня тема NFV и развертывания mission critical services осталась не раскрыта.

        Если говорить о названии/теме этой публикации был бы интересен следующий контекст, ниже возможное содержание:
        — Имеем mission critical сервис/приложение, описание и предназначение этого сервиса (то что у вас есть в первом абзаце).
        — Эксплуатационных характеристики этого сервиса, перечень требований (у вас частично это упоминается в контексте задержки для MCPTT)
        — Для развертывание сервиса решили использовать виртуализированную инфраструктуру и NFV. Для выполнения заданных требований нам требуется (и далее по горизонтальным уровням):
        • принять ряд технических рещений на уровне инфрструктуры, например обеспечить высокую доступность NFVI компонентов, внедрить приоритезацию траффика и т.д.
        • на уровне платформы/гипервизора использоваться такие-то техники/практики для бесперебойной работы платформы/сервиса
        • на уровне самой сетевой функции, приложения и компонентов (например упоминаемые вами HSS или PCRF) используем следующие техники, что б добиться высокой доступности mission critical сервиса.

        Уверен, что подобное описание NFV подходов и практик, которые вы применяете для внедрения mission critical сервисов было бы действительно интересным. Если у вас есть, что сказать по этой теме предлагаю добавить такую статью в список планируемых публикаций :)

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое