Технология VoLTE

Следующим шагом в развитии голосовых услуг в сетях LTE является технология VoLTE (Voice over LTE), созданная на базе подсистемы мультимедийных сообщений (IP Multimedia Subsystem, IMS). При VoLTE абонент пользуется услугами телефонии, находясь в сети LTE, без использования 2G/3G сетей. Проще говоря, VoLTE представляет собой обычную IP-телефонию (Voice over IP, VoIP), но с поддержкой гарантированного качества обслуживания (QoS), обеспечиваемого за счет соблюдения единого стандарта качества на всем пути следования IP-трафика (End to End Quality of Service, E2E QoS).

Как было показано в табл. 8.3, для организации VoLTE необходима поддержка двух QCI: 1 и 5 для передачи голоса и для передачи сигнальных IMS сообщений соответственно.

1. По соединению с QCI 5 реализуется передача управляющих сообщений к IMS для формирования/расформирования соединения в случае передачи голосовых данных. При этом используется протокол инициации сессии (Session Initiation Protocol, SIP). Для отправки контрольных сообщений используется соединение с поп- GBR, имеющее высший приоритет. Кроме этого, данное соединение предъявляет высокие требования к надежности передачи (10б), которые обеспечиваются режимом передачи с подтверждениями на уровне управления радиосоединением (Radio Link Control, RLC). Следует отметить, что для такого соединения не используется механизм надежного сжатия заголовков (Robust Header Compression, RoHC).

2. Передача голосовых данных осуществляется посредством соединения с QCI 1 без подтверждений с использованием механизма сжатия заголовков RoHC и стека протоколов RTP/UDP/IP (также возможен вариант c RTCP/UDP/IP), где RTP(RealTimeTransportProtocol) - это протокол передачи данных в реальном времени, RTCP (Real- Time Transport Control Protocol) - протокол управления передачей в реальном времени. Это протокол, используемый совместно с RTP.

Подсистема IMS - базовая подсистема услуг IP-мультимедиа сети LTE, выполняющая функции управления и синхронизации при передаче пакетов данных (речи, видео, аудио, текстовых сообщений) абонента, а также резервирование сетевых ресурсов, маршрутизацию IP-пакетов в режиме реального времени, поддержку интерфейса с серверами приложений, системами управления и биллинга оператора. Подсистема IMS обеспечивает абонентам сети LTE услуги телефонии, услуги обмена короткими, мультимедийными и мгновенными сообщениями, реализует взаимодействие сети LTE с другими сетями: сетями подвижной радиотелефонной связи (PLMN), сетями VoIP. Для обеспечения бесшовности голосовых услуг с помощью подсистемы IMS реализуется технология SRVCC [гл. 10.3.5].

Среди особенностей архитектуры IMS можно отметить следующие:
• многоуровневая дифференцированная архитектура сети;
• независимость от среды доступа, которая позволяет операторам и сервис-провайдерам реализовывать конвергенцию фиксированных и мобильных сетей;
• поддержка мультимедийного персонального обмена информацией в реальном времени (речь, видеотелефония) и аналогичного обмена информацией между людьми и автоматизированными системами;
• полная интеграция мультимедийных приложений реального и нереального времени (например, потоковые приложения и чаты);
• возможность взаимодействия услуг разных видов (например, услуг присутствия Presence или обмена мгновенными сообщениями Instant Messaging);
• возможность предоставления нескольких услуг в одном сеансе или организации нескольких одновременных синхронизированных сеансов.

Структура сети LTE с интегрированной подсистемой IMS представлена на рис. 10.8.


загрузить изображение

AS (Application Server) - сервер приложений, реализующий логику обработки сигнализации и обеспечивающий предоставление услуг абонентам. Примеры:
• сервер приложений, предназначенный для выполнения услуг, на базе протокола SIP (SIP Application Server, SIP AS). Позволяет обеспечить непрерывность предоставления услуг абоненту независимо от сети доступа (CS-домен, PS-домен);
• сервер услуг, обеспечивающий открытый доступ к услугам (Open Service Access Application Server, OSA AS).
• функция коммутации услуг (IP Multimedia Service Switching Function, IM-SSF) позволяет применять в IMS услуги усовершенствованной логики мобильной связи для абонентских приложений (Customized Applications Mobile Enhanced Logic, CAMEL), разработанные для сетей GSM.

Серверы приложений AS взаимодействуют с системами тарификации в реальном масштабе времени (Diameter Billing Real Time) по протоколу DIAMETER (приложение Diameter Credit Control Application, DCCA). Кроме обязательных для всех серверов приложений SIP-интерфейса со стороны IMS, они могут также иметь интерфейсы к HSS, причем SIP AS и OSA-SCS взаимодействуют с HSS по протоколу DIAMETER для получения данных об абоненте или для обновления этих данных в HSS, а обмен информацией между IM SSF и HSS ведется по протоколу MAP (Mobile Application Protocol - протокол мобильных приложений). Серверы приложений могут быть расположены либо в домашней, либо в любой другой сети, с которой у провайдера есть сервисное соглашение, но в последнем случае непосредственное взаимодействие с HSS не предусмотрено.

HSS (Home Subscriber Server - домашний сервер базы данных абонентов, являющийся совокупностью регистров HLR/AuC и содержащий базу данных профилей абонентов, доступную для узлов AS, ММЕ, S-CSCF, I-CSCF и пульта управления СОРМ (ПУ СОРМ) [см. гл. 13]. В HSS хранятся все данные, которые могут понадобиться при организации мультимедийного сеанса: данные о местонахождении абонента, информация для обеспечения безопасности (аутентификация и авторизация), информация об абонентских профилях, об обслуживающем абонента S-CSCF и о триггерных точках обращения к услугам.

SLF (Subscription Locator Function) - сервер определения базы
данных HSS, хранящей профиль абонента. Сервер SLF предоставляет информацию серверам S-CSCF, I-CSCF об адресе обслуживающего HSS и используется, когда в подсистеме IMS реализовано несколько HSS. SLF, как и HSS, использует для взаимодействия с прочими элементами IMS протокол DIAMETER [см. гл. 2.8.2].

P-CSCF (Proxy Call Session Control Function) - прокси-сервер, являющийся первым сетевым элементом подсистемы IMS (рис. 10.9), с которым взаимодействует UE. Прокси-сервер P-CSCF обеспечивает маршрутизацию SIP-сообщений от UE к обслуживающему SIP- серверу S-CSCF, трансляцию имен в адреса и обратно. Помимо этого, он выполняет задачи по обслуживанию экстренных вызовов, тарификации (генерации записей CDR).


загрузить изображение

S-CSCF (Serving Call Session Control Function) - центральный обслуживающий сервер подсистемы IMS, обеспечивающий аутентификацию и авторизацию абонентов и управление сессиями. Помимо этого, управляет предоставлением дополнительных услуг, для чего взаимодействуете серверами приложений (рис. 10.10).


загрузить изображение

I-CSCF (Integrating Call Session Control Function) - опрашивающий сервер, являющийся пограничным элементом подсистемы IMS, с которым устанавливает контакт внешняя подсистема IMS. Сервер I-CSCF запрашивает у домашнего сервера базы данных абонента HSS адрес сервера S-CSCF, обслуживающего абонента, и обеспечивает маршрутизацию SIP-соббщений к нему (рис. 10.11).


загрузить изображение

MGCF (Media Gateway Control Function) - контроллер медиашлюза IMS-MGW, обеспечивающий управление ресурсами медиашлюза по протоколу H.248/MEGACO. Контроллер MGCFявляется промежуточной точкой обмена сигнализацией между контроллером BGCF и медиашлюзом IMS-MGW, выполняет преобразование сигнализации ISUP/TSAP/SIP-1, принимает и передает сигнальную информацию абонента вне полосы голосового канала (например, сигнальную информацию тонального набора (Dual-Tone Multi-Frequency, DTMF), поддерживает протоколы SIGTRAN для обмена (приема и передачи) сообщениями прикладной части цифровой сети с интеграцией служб (ISDN User Part, ISUP) с сетями мобильной связи (Public Land Mobile Network PLMN) и телефонными сетями общего пользования (Public Switched Telephone Network, PSTN).

IMS-MGW(MediaGatewayFunction)-медиашлюз, обеспечивающий передачу голосового трафика по протоколу реального времени (Real¬time Transport Protocol, RTP), транскодирование голосового сигнала (смена голосового кодека), компенсацию эха. Этот медиашлюз является пограничной точкой между сетями с временным мультиплексированием (Time Division Multiplexing, TDM) и сетями VoIP. Медиашлюз позволяет детектировать сигналы DTMF в полосе сигнала и передавать их контроллеру в сообщении сигнализации SIP.

BGCF (Breakout Gateway Control Function) - контроллер, обеспечивающий выбор сети PLMN (CS Domain), PSTN и маршрута передачи сообщений сигнализации SIP от сервера S-CSCF в сеть регистрации вызываемого абонента. В зависимости от выбранной сети (PLMN или PSTN) контроллер BGCF задействует в цепочке сигнализации тот или иной контроллер MGCF.

MRFP (Multimedia Resource Function Processor) - процессор ресурсов мультимедиа, обеспечивающий воспроизведение аудио и видео контента абоненту. Процессор MRFP позволяет проигрывать мультимедиа уведомления абонентам, организует обмен мультимедиа в режиме конференций (транскодирование, микширование, вещание).

MRFC (Multimedia Resource Function Controller) - контроллер, обеспечивающий управление процессором MRFP в соответствии с командами от серверов AS и S-CSCF, генерацию записей о соединениях (Call Data Records, CDR).

TrGW (Transition Gateway)-транзитный шлюз, предназначенный для передачи мультимедийного трафика от абонентов других IMS, а также сетей с коммутацией пакетов. TrGW управляется функцией пограничного взаимодействия (Interconnection Border Control Function, IBCF) no протоколу H.248 (интерфейс Ix), что позволяет согласовывать адресацию с другими операторами, согласовывать используемые кодеки, скрывать топологию сети, осуществлять фильтрацию вызовов для СОРМ, генерировать CDR, контролировать SLA, обеспечивать взаимодействие SIP-H.323. Аналогично другим контроллерам IBCF взаимодействует с CSCF по протоколу SIP (интерфейс Мх). Обмен сигнализацией между IBCF различных операторов определен интерфейсом Ici.

Процедура регистрации абонента в подсистеме IMS и сообщения SIP-протокола, применяемые при осуществлении IMS-соединения, приведены в дополнительных материалах к книге.

10.3.5. Технология SRVCC

Технология SRVCC (Single Radio Voice Call Continuity) обеспечивает передачу голосового трафика из сети LTE в сеть UMTS/GSM при выходе абонента из зоны покрытия сети LTE. В этой технологии конвергенция реализована на абонентском уровне: UE должен поддерживать работу в обеих сетях, взаимодействие сетей LTE и UMTS/GSM осуществляется на уровне оборудования IMS.

Обмен данными ММЕ с сервером MSC при выполнении хэндовера голосовых вызовов из сети LTE в традиционный домен коммутации каналов (CS-домен) сети UMTS/GSM выполняется при помощи интерфейса Sv. Он обеспечивает передачу сессии и команд по выделению ресурсов на принимающей стороне.

Взаимодействие ММЕ с узлом SGSN при осуществлении хэндовера голосовых вызовов из сети LTE в PS-домен сети 3GPP выполняется при помощи интерфейса S3.

Идеология SRVCC состоит в том, что любой вызов с точки зрения сигнализации «закрепляется» в домене IMS за специальным сервером приложений (Service Centralization and Continuity Application Server, SCC-AS).

Сеть LTE сообщает центру коммутации MSC об ожидаемом хэндовере UE в UMTS/GSM, и центр коммутации MSC, модернизированный для поддержки SRVCC, инициирует процесс перевода голосового вызова (от SCC-AS до UE) на себя, координируя процедуру с процессом обычного хэндовера UE в UMTS/GSM. При этом условная «вторая» часть вызова, от SCC-AS до адресата, сохраняется без изменений. Архитектура SRVCC приведена на рис. 10.12. Архитектура SRVCC использует расширенный вариант SIP для обработки голосовых вызовов и текстовых сообщений.


загрузить изображение

Сетевая архитектура LTE с поддержкой усовершенствованной в Rel'10 версии SRVCC (enhanced SRVCC, eSRVCC) приведена на рис. 10.13. Отличия между SRVCC (Rel'9) и eSRVCC (Rel'10) приведены на рис. 10.14 и в табл. 10.3. На рис. 10.13 появились новые якорные узлы: функция управления передачей доступа (Access Transfer Control Function, ATCF) и шлюз передачи доступа (Address Translation Gateway, ATGW).


загрузить изображение

Передачу сессии из сети LTE в UMTS/GSM в случае выхода абонента из зоны покрытия сети LTE можно обобщенно разделить на следующие этапы:
• подготовка ресурсов принимающей сети;
• ATCF: переключение сигнализации SIP с плеча P-CSCF на плечо улучшенного MSC-сервера (enhanced Mobile Switching Center Server, eMSC-S);
• ATGW: переключение медиа с плеча PGW на плечо медишлюза коммутации каналов (Circuit Switched - Media Gateway, CS-MGW).


загрузить изображение


загрузить изображение

Для успешной реализации технологии SRVCC на сети необходимо решение следующих проблем:
• необходимо наличие терминалов с поддержкой SRVCC;
• внедрение IMS в сети оператора (высокая стоимость);
• модернизация центра коммутации MSC в сети UMTS/GSM.
Однако реализация решения SRVCC на базе IMS позволяет решить ряд важных задач:
• обеспечить поддержку экстренных служб;
• решить проблему, связанную с длительными задержками при хэндовере, когда абонент находился в роуминге.

Сигнальный обмен eSRVCC приведен на рис. 10.15.


загрузить изображение

10.3.6. ОТТ-сервисы

Расширение возможностей абонентских терминалов (UE) способствовало развитию сервисов, доставляющих медиаконтент в режиме реального времени поверх сетей мобильной связи (Over The Тор, ОТТ), таких как Skype, Viber, Google voice и др. Они конкурируют с традиционными услугами операторов мобильной связи, такими как голосовая связь, SMS, видеовызовы и др.

Популярность OTT-сервисов объясняется низкой стоимостью голосовых вызовов для абонентов, так как плата со стороны оператора взимается только за потребленный Интернет-трафик.


загрузить изображение

Ключевыми критериями эффективности оказания голосовых услуг в сетях мобильной связи являются:
• минимальные задержки передачи данных;
• диспетчеризация ресурсов между абонентами;
• пропускная способность сети при перегрузках;
• эффективность передачи коротких пакетов путем сокращения служебной информации (заголовков);
• предоставление голосовых услуг на краю соты;
• минимизация энергопотребления UE.

Согласно этим критериям, выполним сравнение технологии ОТТ (рис 10.16, а) и VoLTE (рис. 10.16, б).

Особое внимание стоит уделить скоростям и задержкам при совершении голосовых вызовов. Как показано на рис. 10.17 и в табл. 10.4, через ОТТ голосовая связь устанавливается без обеспечения гарантированной скорости передачи с низкоприоритетными QCI. В технологии VoLTE, в свою очередь, используют тип трафика с высоким приоритетом (QCI 1) и гарантированной скоростью передачи. Таким образом, скорость и допустимая задержка гарантируются для VoLTE высокоприоритетными классами QoS.


загрузить изображение

В VoLTE заголовки сжимаются благодаря надежному (помехоустойчивому) сжатию заголовков (Robust Header Compression, RoHC) с 40 до 3 байт. Это крайне важно при передаче голоса, поскольку размер пакетов в этом случае сравнительно мал. В случае применения кодека, использующего адаптивное кодирование с переменной скоростью (Adaptive multi rate, AMR), со скоростью 23,85 Кбит/с размер пакета составляет 60 байт, а при кодеке AMR со скоростью 12,65 Кбит/с-32 байта. Следовательно, размер полезных данных может быть даже меньше, чем размер IP заголовка, если сжатие заголовков не применяется. В связи с этим следует отметить, что использование функционала сжатия заголовков позволяет существенно увеличить количество одновременно поддерживаемых VoLTE соединений.

Относительно расхода заряда аккумуляторной батареи VoLTE сервисы являются менее энергоемкими в связи с реализацией данной функциональности в чипсете. Это позволяет основному процессору при совершении VoLTE вызовов оставаться в режиме энергосбережения (sleep mode). Также для экономии энергии в VoLTE, помимо прерывистой передачи (Discontinuous transmission, DTX), используется прерывистый прием (Discontinuous reception, DRX). Идея DRX состоит в том, чтобы во время между получением VoLTE пакетов переводить UE в режим энергосбережения. VoLTE пакеты передаются каждые 20 мс, а время передачи занимает всего 1 мс. Активация и конфигурация DRX осуществляется eNodeB.

Для трафика VoLTE, которому соответствует QCI 1, при плохих радиоусловиях активизируется такая процедура как объединение интервалов времени передачи (Transmit Time Interval Bundling, TTI Bundling). При ее активизации пакет VoIP дублируется на протяжении четырех идущих друг за другом TTI, не ожидая подтверждения от eNodeB, что равнозначно увеличению энергии на каждый передаваемый бит VoIP. Такая процедура увеличивает надежность передачи и дает выигрыш в бюджете линии ~ 4 дБ. При этом вероятность ошибки (Block Error Rate, BLER) может быть снижена с 73% до 9%.

Для трафика с индикатором QCI≠1 (ОТТ VoIP) TTI Bundling не активизируется, следовательно, при высокой нагрузке качество ОТТ VoIP на краю соты не гарантируется. В табл. 10.5 представлены основные сравнительные характеристики технологий VoLTE и ОТТ.


загрузить изображение

Согласно вышеприведенному анализу, можно сделать вывод, что только услуга VoIP операторского класса (VoLTE) может гарантировать качественные показатели передачи речи во время голосового вызова.

Среди вариантов решения проблемы потери доходов операторы рассматривают возможность монетизации трафика ОТТ-сервисов:
• организация сети доставки контента (Content Delivery Network, CDN) с платным размещением контента ОТТ провайдеров [см. гл. 14.9];
• предоставление платного гарантированного QoS для ОТТ- сервисов;
• модификация трафика ОТТ (вставка баннеров, ссылок и т.д.) в рекламных целях.

10.3.7. Сравнение технологий передачи речи в LTE

В завершение анализа технологий реализации голосовых услуг в сетях LTE приведем сравнение достоинств и недостатков этих технологий (табл. 10.6).


загрузить изображение

ПРОДОЛЖЕНИЕ

Да здравствует то, благодаря чему мы — несмотря ни на что! © Zinoviy Papernyy

Ninety percent of everything is crap (Sturgeon’s Law)