Принцип передачи видео по сети IP

Для того чтобы интегрировать вещательное видео с пакетной природой IP-сетей, необходимо выполнения нескольких требований по параметрам качества обслуживания: джиттера и потери пакетов.

Джиттер представляет собой изменение времени задержки между пакетами данных и выражается в неравномерной передаче видео. Стандарт DVB допускает джиттер до 50нс(DVB-C (VHF/UHF)используется QAM: 16-QAM, 32-QAM, 64-QAM, 128-QAM или 256-QAM),но типичный сетевой джиттер может достигать 100 мс. При использовании улучшенной технологии, основанной на сложных алгоритмах управления буфером можно снизить джиттер до определенного стандартом DVB значения и добиться приемлемого качества видео.

Пакеты выпадают, что выражается в появлении видимых «дыр» в видео. Для решения этой проблемы применяются алгоритмы FEC (системы прямого исправленияошибок).

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

 

Форматы вещания

В основном в сетях IPTV используются три типа передачи, таких как unicast, multicast и broadcast. Unicast (одноадресная передача) предусматривает индивидуальную доставку потока каждому отдельному абоненту. С технической точки зрения это реализуется достаточно просто, но отправку одного и того же канала с вещательного сервера в этом случае приходится дублировать для каждого абонента, запрашивающего его просмотр. Это приводит к неэффективной загрузке транспортной сети и высокой нагрузке на сервер. Схема реализации вещания без использования маршрутизаторов и коммутаторов представлена на рис. 5.1. В данном случае мониторинг ведется различными программными средствами.

Рисунок 5.1 Схема unicast вещания

 

Broadcast (широковещание) предусматривает то, что один и тот же IPTV-канал передается всем подключенным к сети абонентским устройствам. Ресурсы абонентских приставок загружаются при этом обработкой большого количества ненужных в данный момент видеопакетов. Помимо приставок в таком режиме перегружались бы и сетевые маршрутизаторы, которые и так обычно работают с высокой нагрузкой.

Multicast (многоадресная передача) наиболее распространенная технология IPTV-вещания. В этом случае с сервера передается только одна копия ТВ-потока, который доставляется всем абонентским устройствам, пославшим запрос на его получение. Важным моментом multicast передачи является факт того, что она не предполагает отправки абонентских запросов на вещательный сервер — они доходят лишь до ближайшего маршрутизатора, на который в данный момент уже поступает требуемый ТВ- поток. Для этой цели используется протокол IGMP.

 

Рисунок 5.2Схема multicast вещания

 

В данном случае есть источник multicast потока и посредством маршрутизатора и коммутаторов поток принимают клиентские приставки STB. Вещание реализуется через протокол UDP. Особенность построения данной архитектуры сети позволяют с легкостью вести мониторинг multicast потока с помощью маршрутизатора и коммутаторов.

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

Мультикаст в то же время имеет и ряд недостатков:

1 Не поддерживает такие функции, как пауза, возврат или быстрая перемотка контента. Их можно реализовать только средствами абонентского приемника

2 Абонентам предоставляется ограниченный выбор — как и в классических вещательных сетях, настроиться на прием программ, вещаемых в сети в текущий момент.

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

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

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

 

Протокол IGMP

Протокол IGMP (Internet Group Management Protoсol) управляет взаимодействием между источниками мультикастовых потоков и их получателями. Процедура подключения к мультикастовой группе выглядит следующим образом. Устройство, подключаемое к определенной мультикастовой группе, формирует IGMP-сообщение о подключении (membership report), содержащее адрес требуемой мультикастовой группы, и отправляет его в сеть в направлении источника мультика- стового потока. Когда запрос доходит до ближайшего маршрутизатора, по- лучающего этот поток в ответ на более ранние запросы, последний начинает ретранслировать его и на порт, с которого новый запрос поступил.

На сегодняшний день разработаны три версии протокола. В IGMP v.1 никаких активных сообщений о желании абонентского устройства отключиться от мультикастовой группы не предусмотрено. Маршрутизатор, ближайший к источнику мультикаста, периодически отправляет запрос (membership query) о наличии в сети активных потребителей этого мультикастового потока. При отсутствии подтверждений его вещание прекращается. Другими словами, запрошенный мультикастовый поток перестает передаваться на все запросившие его устройства только при отключении от группы последнего абонентского устройства. В некоторых ситуациях такая схема сильно загружает сеть лишним трафиком и легко может привести к перегрузке оконечного коммутатора. Минутного серфинга абонента по каналам достаточно, чтобы они «зависли» на коммутаторе, перегрузив его порты. Эта проблема решается при переходе на более поздние версии IGMP и одновременном использовании коммутаторов доступа с функцией IGMP Snooping.

С появлением самой распространенной на сегодня версии IGMP v.2 у абонентских устройств добавилась возможность отправлять сообщение об отключении от мультикастовой группы (leave group). Получая такое сообщение, источник сигнала с помощью запроса проверяет наличие активных членов группы, получающей конкретный поток; в случае если их не оказывается, вещание потока прекращается. Это несколько ускоряет процесс остановки неактуальных мультикастовых потоков, но слабо помогает в борьбе с перегрузкой коммутатора, к которому подключен потребитель данных потоков. Причем если вспомнить, что обычный коммутатор — устройство второго уровня, при коммутации оперирующее не IP-, а МАС-адресами, и что МАС-адрес устройства назначения в мультикастовом пакете указать невозможно, становится ясным, что коммутатор не в состоянии распознать, кому из подключенных к нему устройств адресован пакет. Поэтому он вынужден раздавать его на все выходные порты. Другими словами, при «зависании» лишних мультикастовых потоков перегружаются все порты сразу. Для борьбы с этой проблемой в коммутаторы внедряют механизм IGMP Snooping. Он позволяет «подслушивать» проходящие через них IGMP-сообщения и самостоятельно на них реагировать. «Подслушав» запрос на подключение к мультикастовой группе и считав ее адрес, коммутатор с такой функцией направляет полученный в ответ поток на порт, с которого поступил запрос. Затем он выявляет просьбу об отключении от мультикастовой группы и перестает пропускать поток с соответствующим адресом на порт, с которого пришла просьба. Таким образом. IGMP Snooping в сочетании с IGMP v.2 исключает передачу лишнего мультикастового трафика через коммутаторы доступа. Данная функция требует достаточно много памяти и более высокой процессорной мощности, чем у типовых домовых коммутаторов, что, разумеется, делает их дороже обычных. Тем не менее, в сетях c услугой IPTV без этой функции обойтись нельзя.

Третья версия IGMP отличается от второй в основном тем, что позволяет абонентскому устройству составлять перечень источников, из которых он хочет принимать потоки, и тех, из которых принимать не хочет. Помимо обмена сообщения- ми в рамках IGMP источник мультикаста формирует SAP (Service Announcement Protocol) сообщения, передаваемые в вещательном режиме и содержащие информацию о доступных мультикастовых потоках.