Главная   Каталог   Распродажа    Справочник    Контакты   Карта сайта
Дейта Плюс
+7 (916) 296-38-88
123007, Москва, 2й Силикатный пр-д,
д.14, корп.2,стр.14
Справочник > Статьи
 Версия для печати


Качество IPTV услуг


Перед большинством IPTV операторов, помимо всего прочего, стоит, пожалуй, самая важная задача - обеспечить качество транслируемых ТВ и видео программ, как минимум, не хуже качества программ, транслируемых традиционными операторами эфирного и кабельного телевидения. Обычные требования абонента (быстрое переключение между каналами, изображение на экране без каких-либо помех) ведут к предъявлению более высоких требований к функционированию и настройке IP сети по сравнению с сетями, предоставляющими традиционные услуги по передаче данных (домовые сети, доступ в Интернет и т.п.).

Определение QoE и QoS

Одним из ключевых требований к сети IPTV, обеспечивающей высокий уровень качества, является внедрение системы измерений качества услуг (qualitu of experience, QoE), которая будет четко отслеживать и измерять восприятие услуг абонентами. Это относится не только к качеству картинки, но может также охватывать другие области, такие как удобство использования, быстрота реагирования на запрос абонента и т.п. . Другие факторы,  такие как  плохое качество сжатия исходного сигнала, проблемы с IP пакетами, задержки, неправильные настройки сети, также могут влиять на уровень QoE и приводить к увеличению недовольства абонентов.

Наиважнейшей целью QoS, относящейся к сетевой инфраструктуре, в отличие от QoE, является обеспечение приоритетов, включая выделения полосы (необходимо учитывать разные методы сжатия, разрешение картинки и т.п.), контролируемого джиттера,  задержек (время с начала отправки пакета с головной станции до поступления в абонентский приемник) и уменьшение потерь пакетов (как часто пакеты теряются, сколько пакетов теряется). Распределение приоритетов не должно вести к тому, что сервисы с более низким уровнем приоритета будут недоступны в сети. Рассмотрим некоторые факторы, приводящие к уменьшению уровня QoE и QoS.

Очередность пакетов

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

Предположим, сервер IP вещания посылает мультикаст пакеты ТВ программы, сжатой в H.264, с постоянным битрейтом (constant bitrate, CBR) 2.5 Мб/с. Некоторые возможные узкие места сети показаны на рис.1

Первый сценарий иллюстрирует ситуацию, когда сеть идеальна и пакеты идут с интервалов в 1.5 мсек. В этом случае межпакетные интервалы не изменяются на всем пути следования через все узлы сети. К сожалению, в реальной сети этого практически не бывает.

Во втором сценарии два IPTV пакета посылаются в сеть друг за другом без временного промежутка, а третий пакет через 3.5 мсек после первых двух. В этом случае так же не возникает проблемы с очередностью пакетов.

Третий сценарий более близок к тому, что происходит в реальной IP сети, используемой для предоставления triple-play IP услуг. При этом сценарии VoIP, IPTV и WEB одновременно присутствуют в сети. В такой сети межпакетные интервалы всех трех потоков, приходящих на маршрутизатор, более менее одинаковы. Т.к. маршрутизатор не может обрабатывать все пакеты  одновременно, то формируется очередь, и пакеты помещаются в буферную память, до момента, когда по ним будет принято решение об отправке на нужный порт. В этом примере очередь переполняет буфер, и пакеты, относящиеся к данным Internet, отбрасываются. В свою очередь, потоки VoIP и IPTV услуг сохранят межпакетные интервалы.

Это упрощенные модели разных типов сетей, которые должны учитываться при развертывании IPTV услуг.

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

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

Джиттер пакетов видео услуг

IPTV услуги достаточно чувствительны к задержкам, возникающим в перегруженных серверах, маршрутизаторах, "узких" местах сети, очередях. Качество видео напрямую связано с доставкой IP потока без потерь с постоянной скоростью. Декодер в абонентском устройстве требует стабильного входящего IP потока. Это достигается усложненной синхронизацией между декодером в абонентском устройстве и кодером в IPTV головной станции. Отклонения фактического от ожидаемого времени поступления пакета (раньше или позже)  называют джиттером (jitter). Рисунок 2 показывает к чему может приводить эффект джитерра для IPTV потока.

Как показано выше, первый сценарий прохождения потока по IP сети является идеальным, качество ТВ сигнала отличное. Пакеты равномерно поступают в сеть и так же равномерно поступают в абонентское устройство.

Во втором сценарии наблюдаются проблемы с недостаточно быстрым заполнением буфера, что приводит к перерывам поступления пакетов в декодер.

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

 
Рассмотрим более детально задержки и джиттер. К примеру, возьмем поток видео SPTS с

  • полосой 4.7 Mbps.
  • на 1 кадр Ethernet пакет приходится 7 DVB пакетов, т.е. 7 х 188 = 1316 байт
  • инкапсуляция IP/UDP/RTP потребует еще 54 байта на заголовки
  • теоретически 1 Ethernet кадр длиной 1370 байт дает полосу 4.886 Mbps
  • поток Ethernet (кадров в секунду) = 4.886.000 (битрейт) / 8 (бит в байте) * 1370 (байт в кадре) = 445.8 кадров в секунду 
  • интервал между кадрами 1/445.8 = 0.00224 секунды

В идеале видео пакеты должены поступать в декодер с интервалом 2.24 мсек. Любое отклонение от этого идеала  ведет к необходимости применения буфера. Если с фиксированным отклонением еще можно бороться, то с переменным отклонением (джиттером) не все так просто. На него влияет структура IP сети, размер буферов маршрутизаторов, а так же степень поддержки QoS абонентским устройством.

Постоянное отслеживание значения джиттера может помочь заблаговременно устранить возможность появления проблемы на том или ином  участке сети.

Буферы абонентских устройств

Выше в основном говорилось о преимуществах использования больших буферов в абонентских устройствах. Но есть и отрицательные последствия использования неоптимизированного по размеру буфера. Перечислим некоторые из них:

  • повышение стоимости абонентского устройства (микросхемы оперативной памяти, используемые в качестве буфера стоят относительно дорого)
  • увеличение времени переключения между каналами (при переключении между каналами, абонентское устройство сначала очищает имеющийся буфер, потом заполняет его до некоего уровня входными пакетами новой ТВ программы и только после этого направляет пакеты на декодер, т.е. на экран. Данная процедура может занимать несколько секунд, что ведет к появлению раздражения абонентов)
  • усложнение программного обеспечения абонентского устройства (операции с большими объемами памяти, алгоритмы восстановления последовательности  и т.п. - требуется большее время на создание ПО устройства, а также проведение более трудоемких тестирований и отладок)