Оптимизация видеотранспорта в мультисервисных IP сетях. Часть 2

По материалам компании Cisco составила Анна Бителева
Опубликовано: журнал Теле-Спутник - 4(150) Апрель 2008 г.
Ссылка на статью: http://www.telesputnik.ru/archive/150/article/86.html

Скорость переключения каналов, передаваемых в мультикастовых потоках
Постоянное увеличение числа каналов в сети приводит к тому, что абоненты все чаще переключаются с одного канала на другой. Более того, они привыкли к тому, что в вещательных сетях это переключение происходит практически мгновенно, и ожидают того же от сетей IPTV. Время переключения между каналами (ССT — Channel Change Time) — это интервал между посылкой абонентом запроса на присоединение к новой мультикастовой группе и появлением нового канала на экране. Приставки с поддержкой IP функциональности используют для переключения IGMP протокол. Когда подписчик запрашивает смену каналов, STB сначала посылает IGMP команду leave — на отключение от мультикастовой группы, а затем команду join — на присоединение к новой мультикастовой группе. И через какое-то время на экране у абонента появляется новый канал. Рассмотрим факторы, определяющие ССT:

• Задержка из-за IGMP сигнализации — IGMP команды на отключение и присоединение либо транзитом передаются на маршрутизатор уровня агрегации, либо обрабатываются каким-то устройством с поддержкой IGMP snooping, стоящим на пути к маршрутизатору, например, DSLAM-ом.
  В крупных сетях маршрутизатор уровня агрегации обычно обслуживает одновременно тысячи подписчиков. Так как их количество значительно превосходит число передаваемых каналов, то вероятность того, что запросу на присоединение придется пройти весь путь до видеоисточника, близка к нулю. Поэтому задержка на передачу IGMP сообщений вносит незначительный вклад в совокупную задержку.
• Задержка на декодирование MPEG потока. При переключении на прием другого мультикастового потока приставка должна дождаться получения PSI таблиц, которые помогут ей правильно прочитать содержание потока. В первую очередь, речь идет о таблице PAT (Program Association Table), которая по спецификации DVB должна пересылаться каждые 0,5 с.
• Задержка получения I кадра. Как известно, в MPEG выделяют три типа кадров, I-, P- и B кадры, различающиеся по принципам их компрессии. I кадры-— единственные, которые компрессируются без применения предыдущих и последующих кадров. P кадры используют информацию о предыдущих кадрах, а B — о предыдущих и о последующих. Последовательность совместно кодируемых кадров называется группой Group Of Pictures — GOP. При компрессии MPEG-2 GOP включает примерно 12-15 кадров, в том числе один I кадр, с которого надо начинать декомпрессию всей группы. Задержка получения I кадра пропорциональна длине GOP. В традиционных вещательных сетях эта задержка составляет примерно 0,5 с, но в сетях IPTV из-за более сильной компрессии сигнала она, как правило, выше. При переходе к компрессии MPEG-4 она возрастет еще больше. Ожидание I кадра — основной фактор задержки при переключении с канала на канал.
• Ожидание ключа для работы системы условного доступа. В стандартных системах доступа шифровка сопровождается пересылкой сообщений ECM и EMM, первые из которых переносят зашифрованную информацию о ключах. Для начала декодирования приставка должна получить ECM с ключами. Ожидание ECM также может внести свою лепту в общую задержку.
• Заполнение буфера, предназначенного для компенсации джиттера и создания временного запаса для повторного запроса потерянных пакетов.

Типичное время задержки, вносимой перечисленными факторами, приведено в таблице 1:

Для сокращения времени переключения Cisco VQE предлагает технологию Rapid Channel Change (быстрой смены каналов), которая сокращает или устраняет задержки, вызванные следующими факторами:

• Задержкой отключения от мультикастовой группы.
• Задержкой получения информации, необходимой для начала декодирования. В том числе:
  – таблиц PAT, PMT (Programm Map Table) и ECM (если поток закрыт);
  – PCR (Programm Clock Reference) и всей информацией из заголовков, например, о скорости передачи;
• получением первого I кадра.
• Совокупной задержкой при переходе на другой канал.

Применение SSM для доставки видео в распределительной сети
Все маршрутизаторы и коммутаторы третьего уровня в стандартной конфигурации поддерживают IP мультикаст и протокол PIM (Protocol Independent Multicast). PIM — это протокол маршрутизации, позволяющий сформировать дерево распределения ТВ каналов по сети. Сетевые устройства Cisco поддерживают версию PIM - SSM (Source Specific Multicast).Она позволяет приставке выбрать конкретный источник видеосигнала при их дублировании.
PIM-SSM имеет-ряд преимуществ по сравнению с другими версиями:

• Оптимизирует дерево распределения. Маршрутизация производится непосредственно в направлении видеоисточника. Поэтому путь от приставки к источнику получается максимально коротким. Это особенно важно для провайдеров, у которых видеоуслуга занимает значительную полосу.
• Усиленная безопасность: такое построение дерева позволяет предотвратить вещание от сомнительных источников, которые могут запускать мультикаст для DoS (Denial of Service) атак, направленных против зрителей, принимающих определенный канал. STB могут узнавать IP адрес канала из EPG и использовать его для запроса на подключение к мультикастовой группе. Если приставка не поддерживает IGMP v3, необходимый для включения в запрос IP адреса источника, то маршрутизаторы Cisco 7600 могут самостоятельно подставлять в запрос нужный IP адрес, находя его на DNS сервере.
• Простота инсталляции и администрирования. Так как сетевые устройства не должны отслеживать появление новых видеоисточников, то их добавление или исключение не сопряжено ни с какими сложностями. Это особенно важно для быстрорастущей и модифицирующейся сети.

Уровни агрегации и доступа
Кластер доступа может быть организован различными способами. В частности, существуют следующие альтернативы:

• Одно виртуальное соединение на DSL линке vs много виртуальных соединений.
• Одна VLAN (виртуальная локальная сеть) на одного пользователя vs VLAN на одну услугу.
• Одна VLAN для скоростного Интернета на одного пользователя или на одну услугу.
• Домашний DSL шлюз с поддержкой второго или третьего уровня.
• Поддержка QoS на базе VLAN или на базе битов приоритета, вводимых в пакетах второго уровня.

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


В этой модели домашние шлюзы разделяют трафик, направляя каждую VLAN на свой порт внутри дома. Маршрутизатор уровня агрегации может быть сконфигурирован для единого набора VLAN или задать индивидуальный набор VLAN для каждого DSLAM-а. Например, маршрутизатор может быть рассчитан на обслуживание 10 тысяч абонентов. С использованием ненумерованных виртуальных интерфейсов коммутации, все абоненты могут быть подключены к одной подсети.
Авторизация абонентов видеоуслуг проводится на уровне приложений. Тем не менее, у сервис-провайдера может появиться желание идентифицировать и саму приставку.
DSL форум определил методы такой идентификации в своей спецификации WT101, которая использует тэги Point-to-Point или DHCP option 82. DHCP option 82 работает следующим образом: когда приставка подключается к сети, она посылает DSLAM-у DHCP запрос. DSLAM перехватывает этот запрос и вставляет идентификатор абонентской линии, с которой он был получен, в текстовое поле, DHCP запроса, именуемое option 82; в таком дополненном виде запрос передается DHCP серверу, который ассоциирует пославшую запрос приставку с идентификатором линии.

Разделение услуг
При организации видеотранспорта в мультисервисной сети важным моментом является степень поддержки сетью дифференцированных требований к передаче разных услуг. Сеть как минимум должна обеспечивать разные уровни задержек и потерь для всех услуг, передаваемых по общей физической линии. В решении Cisco IP NGN, помимо поддержки упомянутых требований QoS возможно отдельное конфигурирование маршрутов для каждой из услуг. Такое разделение очень удобно для сервис-провайдера, желающего администрировать адресное пространство, топологию и IP инфраструктуру применительно к каждой услуге отдельно. Такая архитектура позволяет агрегировать или терминировать трафик, относящийся к разным услугам, на разных устройствах и с использованием разных компонентов инфраструктуры. Она, например, позволяет сочетать агрегацию интернет-трафика на сервере удаленного широкополосного доступа с передачей видеотрафика непосредственно на сетевые терминалы.

QoS
Передача видео по широкополосной сети основана на IP протоколах. В связи с этим, биты IP Differentiated Services Code Point (DSСP)1 де факто стали стандартным механизмом для обеспечения QoS. В рассматриваемой архитектуре IP DSCP — самый масштабируемый способ контроля QoS в рамках каждого сетевого линка. Каждый тип трафика — голос, видео, скоростной Интернет и сигнализация, сопровождающая передачу голоса/видео, помещаются в свою очередь. Это допускает возможность дифференцированного контроля за прохождением каждого потока в плане джиттера задержек и потерь. В таблице 1 показаны примеры возможных установок, для элементов уровней доступа и агрегации.

Если какой-то сетевой элемент, например DSLAM, не умеет читать биты IP DSCP, то маршрутизатор уровня агрегации переводит эту информацию в термины второго уровня, представляя ее в форме битов Ethernet 802.1p. Используя эту информацию, DSLAM может размещать кадры в соответствующих виртуальных каналах ATM VC и выполнять ATM SAR (Segmentation And Reassembling), то есть разбивать информацию по ATM фреймам.

• Контроль добавления каналов Суммарный трафик, формируемый потоками видео-по-требованию и мультикастовым вещанием, может превысить пропускную способность любой сетевой линии. Это особенно вероятно при сетевых сбоях, когда трафик отправляется альтернативными путями. В случае перегрузки часть пакетов с видео начинает случайным образом теряться. Это сказывается на качестве ТВ сигнала у всех абонентов, получающих сигнал с ветки, на которой возникла проблема. Провайдеры должны иметь в своем распоряжении механизмы для предотвращения таких катастрофических ситуаций. Иногда рассчитывают сеть с большим запасом, так, чтобы она позволяла реализовать любой сценарий предоставления VOD. Тем не менее, подсчет пиковой нагрузки на сеть при максимуме одновременных запросов показывает непривлекательность такого подхода. Cisco предлагает варианты контроля добавления в сеть новых потоков, обеспечивающие высокое качество восприятия услуг (Quality of Experience) даже в моменты, когда загрузка сети близка к максимальной. Они позволяют найти оптимальный баланс между стоимостью сети и доступностью услуг в пиковые периоды.
• Контроль введения новых вещательных каналов. Присутствие в сети 200 и более вещательных каналов сегодня уже не являются редкостью. Если принять во внимание, что средняя скорость кодирования вещательных каналов составляет 3,75 Мбит/с, то трансляция 200 каналов потребует 75% гигабитного аплинка DSLAM-а. Для полноценной услуги VOD оставшейся полосы может не хватить.
  В этом случае оператор может снизить ширину полосы, занимаемой вещанием, без ухудшения качества восприятия услуги, используя алгоритм коммутации вещательных каналов. Маршрутизатор уровня агрегации, пропускающий мультикастовые IP потоки, может ограничить количество вещательных каналов, одновременно отправляемых DSLAM-у. Критериями выбора может служить популярность каналов или полоса, требуемая для их передачи (например, стандартное разрешение vs высокое разрешение). Можно также гарантировать обязательную пересылку на DSLAM некой базовой группы каналов.
• Контроль введения новых потоков VOD. VOD проблема транспортной полосы может оказаться еще более серьезной. Если востребованность услуги окажется выше планируемой, то каналы, ведущие от серверов VOD к подписчикам, могут быстро перегрузиться. Предположим, что во время пиковой нагрузки видео-по-требованию будут получать 20% приставок одновременно. В этом случае узел коммутации, обслуживающий 10 тысяч абонентов, запросит 2 тысячи потоков, что для ТВ стандартного разрешения ориентировочно составит от 4 до 7 ГГбит (в зависимости от характеристик и настроек кодеков). Если добавить контент в ТВЧ, то требуемая полоса окажется еще больше. Что же произойдет, если спрос превысит пиковую нагрузку, на которую рассчитаны каналы сети? Если проблема в том, что сервер VOD, получивший запрос, не в состоянии его обслужить, то этот запрос может быть перенаправлен на другой сервер. Но если исчерпана пропускная способность основных сетевых каналов, то добавление новых сессий по предоставлению VOD приведет к потере пакетов во всех видеопотоках без исключения. Это явление известно как проблема 1001 потока. При отказе сети из-за перегрузки возможна ситуация, когда перебой в работе ощутят все абоненты одновременно. Один из способов избежать массовых перебоев заключается в использовании комплексного контроля за добавлением новых каналов — программного координатора потоков. Если видеосессию не удается открыть ни с ближайшего, ни с альтернативных серверов, то этот координатор потоков отправит приставке сообщение, что услуга в данный момент не может быть предоставлена. Хотя такое сообщение не обрадует ни одного абонента, но перспектива массового сбоя услуги значительно страшнее. А если у координатора есть информация о времени освобождения канала для новых потоков, то сообщение может быть более информативным. Оно позволит абоненту выбрать между ожиданием видео-по-требованию, подключением к вещательным каналам или выбором просмотра VOD по тарифу с более высоким приоритетом.
  В случае перегруза сети координатор потоков может также быть сконфигурирован на прекращение, в первую очередь, бесплатных VOD сессий и лишь затем платных.
• Рассмотрим предлагаемую Cisco систему комплексного управления добавлением потоков более подробно. Она использует в внутриканальную и внеканальную сигнализацию. Система должна принимать во внимание сложную топологию сети. В магистральной части, в частности, следует учитывать наличие резервных линий и факт совместного использования каналов разными службами. В секторе доступа следует принимать во внимание ограничения, которые могут быть искусственно наложены на пропускную способность линии в соответствии с тарифными условиями предоставления услуг или в связи с другими факторами.

Система контроля добавления потоков, разработанная Cisco для сетевого ядра и распределительного сектора NGN сетей, основана на установлении сессии VOD с использованием RSVP сигнализации, передаваемой в канале данных. Рис. 2. Запрос на предоставление фильма, отправленный с абонентской приставки, поступает на сервер агрегации и оттуда переправляется к серверу VOD. В ответ сервер VOD или сетевой элемент, установленный перед сервером, посылает свое RSVP сообщение, которое следует за сообщением EMM (Entitlement Management Server) от сервера администрирования приложений. RSVP ответы отправляются тем же самым путем, которым предполагается передавать контент, что позволяет отследить текущие изменения в сложной сетевой топологии. Маршрутизаторы, на которые приходят эти сообщения, оценивают доступность полосы для передачи видео и, соответственно, разрешают или запрещают открытие сессии. Для запрета сессии маршрутизаторы возвращают VOD серверу сообщение RSVP-CAC. А сервер, в свою очередь, отправляет абоненту сообщение о временной невозможности предоставлении услуги. Такая система контроля через рабочий канал возможна только при поддержке функциональности третьего уровня всеми сетевыми элементами на пути от VOD сервера до маршрутизатора уровня.


Сетевая архитектура второго уровня в устройствах агрегации (например, H-VPLS или IEEE 802.1 ad) не в состоянии поддерживать данную схему динамического управления добавлением сессий.
Если недостаточной оказывается пропускная способность канала абонентской линии, то отправка приставке заказанного видеопотока предотвращается другим способом. Сервер VOD или сетевое устройство, обеспечивающее маршрутизацию потока, отправляет соответствующую просьбу координирующему серверу, который контролирует загрузку абонентских каналов и реализуюет политику доступа абонентов к услугам. Рис. 3.

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

Сеть доступа — восстановление ошибок в видеопотоках
Одна из главных проблем, с которыми сталкиваются провайдеры, доставляющие потоки IPTV по медным проводам, — совокупное количество ошибок, генерируемых в абонентских линиях. Несомненно, искажающий эффект ошибок, появляющихся в линиях доступа превосходит негативное воздействие всех рассмотренных ранее сетевых проблем вместе взятых. Сети большинства провайдеров изначально были ориентированы на предоставление скоростного доступа в Интернет. В силу возможностей TCP протокола, эти услуги гораздо менее чувствительны к потерям пакетов, чем видео. Поэтому большинство сетей рассчитывалось так, чтобы потерянные пакеты не превышали 10-4. В то же время передача видео требует снижения потерь до уровня 10-6, что соответствует появлению одного артефакта в минуту. Количество ошибок, наводимых в абонентских линиях, напрямую зависит от количества отводов одном жгуте, находящихся под сигналом. Таким образом, требование к низкому уровню потерь пакетов ограничивает процент абонентов, которых можно охватить услугой. В результате провайдеры сталкиваются с невозможностью подключить к услуге весь круг абонентов, которому они адресуют свои маркетинговые акции.
И даже если линии в целом пригодны для массовой передачи IPTV, процент потерь может в любой момент возрасти — под влиянием температуры, влажности или интерференционных шумов. Система обеспечения высокого качества восприятия видеоуслуг, предложенная Cisco, использует метод восстановления потерянных пакетов. В рамках этого решения задействована функциональность самих приставок — их буферов, возможности мониторинга, а также интеллектуальных систем контроля за добавлением потоков, позволяющая удержаться в пределах допустимого уровня ошибок при большем количестве видеопотоков в абонентских линиях. Решение предусматривает мониторинг приставкой потери пакетов с применением протокола RTCP (Real-Time Transport Protocol). При выявлении пропажи пакета приставка запрашивает его повторную посылку. Сеть доставки видео перехватывает этот запрос и переправляет приставке пакет до того, как дойдет его очередь быть переданным из буфера в декодер. То есть, решение сочетает в себе современную схему мониторинга с сетевыми механизмами повторения пакетов.

• ← Весь архив